Skip to content
CCPEDIAby Unity Nodes
#859Incoming Pull Request1.9M CC requested

Proposal: Payvol, Open Payment Intent, Lifecycle and Reconciliation Infrastructure for Canton (RFP 13)

cayvox26-09-2026Last activity 5d ago
dapp-integrationfinancial-workflows-composabilityrfp-13:payments-defirfp-14:wallet-dapp-tooling
References:CIP-0056CIP-0103CIP-0112

Development Fund Proposal Submission

Proposal file:
https://github.com/cayvox/canton-dev-fund/blob/proposal/payvol-rfp13/proposals/2026-09-Cayvox-Payvol.md


Applicant

Organization:
Cayvox Labs, an open-source infrastructure company building on the Canton Network.

Author / Primary Contact:
Anıl Karaçay, Cayvox Labs, anil@cayvox.com

Champion:
Needs Champion. A Development Fund Champion is being sought, and we welcome an introduction from the Payments and DeFi or Wallet Apps SIGs.


Proposal Classification

Proposal Type:

  • RFP-aligned proposal
  • Individual initiative

RFP / Roadmap Area:
RFP 13, Payments and DeFi, under Financial Markets, Standards & Verification. Secondary alignment with RFP 14, Wallet and dApp Integration Tooling, under Developer Experience, Tooling & Education.

Primary SIG:
Financial Workflows & Composability

Secondary SIG Alignment:
dApp Integration
Wallet Apps

Label:
financial-workflows-composability (primary); dapp-integration (secondary)


Funding & Timeline

Total Funding Request:
1,900,000 CC

Project Duration:
23 weeks, three milestones of 600,000 CC, 600,000 CC and 700,000 CC; the third is paid only as seven adoption tranches of 100,000 CC, one for each independent organization that completes a Payvol flow, after the Milestone 3 output is published.

Maximum Amount:
N/A. RFP 13 does not specify a maximum amount.

Maximum Duration:
N/A. RFP 13 does not specify a maximum duration.


Summary

Payvol is an open, wallet-neutral coordination layer for programmable payments on Canton. It standardizes how a payment intent is expressed, safely presented to a payer, translated into an authorized Canton Token Standard transaction, and reconciled through a private lifecycle after submission, so that an intent can travel through a QR code, URI, NFC record, web link, API, invoice, message, or an application-to-wallet handoff without binding the payee to a specific wallet, custodian, token issuer, or settlement application. The grant turns the existing self-funded prototype into a stable public standard, a production TypeScript implementation, a conformance suite, Canton execution profiles, a lifecycle and reconciliation toolkit, a self-hostable resolver, an ISO 20022 Request-to-Pay reference converter prototype, and a version-pinned x402 representation mapping. Every deliverable is an open-source, reusable component or standard designed to support multiple Canton applications, wallets and issuers rather than one-off, application-specific integration work.


Why the ecosystem needs this

Today every Canton application that asks to be paid invents its own request format, and every wallet that pays one writes an integration per application. The same work is repeated on both sides of each pair, and nothing that is built is reusable by the next participant.

Payvol removes that repetition for four groups:

  1. Payment applications, invoice systems, checkout products and autonomous services get one portable way to ask for payment without choosing the payer's wallet.
  2. Wallets and custodians get one validation, presentation, clear-signing and response model instead of a payload per application.
  3. Token issuers and registries get a neutral route into payment options while settlement stays in Token Standard interfaces.
  4. Treasury, ERP and accounts-payable teams get a documented bridge between institutional Request-to-Pay semantics and private Canton settlement.

How it drives adoption: the deliverables are a published format, a conformance suite that a second implementation can check itself against, and a reference implementation under Apache-2.0. A wallet team adds support once and can be paid by every application that speaks the format; an application team adopts it once and is payable from every wallet that does. Milestone 3 pays 100,000 CC for each of seven independent organizations that complete a Payvol flow on TestNet or MainNet, and nothing for its own engineering output, so 36.8% of the request is paid only once outside adoption has happened.


Submission Checklist

  • Full proposal file is included in this PR
  • Organization and primary contact identified
  • Champion identified or Needs Champion selected
  • RFP / roadmap alignment identified, if applicable
  • Total funding request provided
  • Project duration provided
  • Proposal is within any RFP maximum amount
  • Proposal is within any RFP maximum duration
  • Milestones and milestone funding are defined in the proposal
  • Acceptance criteria are based on ecosystem value
  • Architectural alignment is addressed

Notes for Reviewers

Milestone 0 is already delivered and self-funded, before submission: the specification, the four Apache-2.0 packages published on npm at v0.4.0 (@payvol/core, @payvol/qr, @payvol/conformance, @payvol/cli), 146 conformance vectors, 1,803 automated tests, a captured DevNet reference path, an end-to-end payment captured on a local Canton and Splice 0.6.11 network and replayed by the tests, documentation whose samples are executed against the published packages at https://payvol.xyz/docs, and a public playground at https://payvol.xyz/app. The requested funding covers Milestones 1 to 3 only.

The proposal is scoped as shared ecosystem infrastructure built directly on the Canton Token Standard (CIP-0056, CIP-0112) and the dApp standard (CIP-0103), not as a wallet, a custodian, or a settlement application. It is deliberately wallet-neutral and issuer-neutral so that the same intent artifact is usable by any Canton wallet or application.

The document contains thirteen figures, stored beside it in /proposals/ with the same filename prefix, following the convention used by the merged Certora proposal. Relative image paths resolve against the repository and branch being viewed, so before this PR is merged the figures render on the branch link above rather than in the rich diff view. The proposal file link at the top of this description is the one to read.

This resubmits the proposal opened as #760 on 6 September, which the champion check closed automatically at the time. That check has since been removed in Dev Fund 2.0 (#852). Since #760, the figures are refreshed for the work completed in the meantime (package version, vector and test counts, the LocalNet capture and the documentation set).

Revised on 2026-09-29 after review (7bee49f): Milestone 3 is now paid only through seven adoption tranches (adoption share 15.8% to 36.8%), synchronizer scope binds to the logical SynchronizerID with both Canton 3.4 and 3.5 synchronizer_id formats accepted, and both Milestone 2 execution profiles are specified on the CIP-0112 Token Standard V2 interfaces with per-registry metadata evidence required before support is claimed.

← Back to Proposals