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

Development Fund Proposal

Payvol: Open Programmable Payment Intent, Lifecycle and Reconciliation Infrastructure for Canton

Field	Value
Organization	Cayvox Labs (open-source infrastructure company building on the Canton Network)
Author / Primary Contact	Anıl Karaçay, Cayvox Labs; a***@cayvox.com
Status	Draft
Created	2026-09-05
Last Updated	2026-11-11
Proposal Type	RFP-aligned
RFP / Roadmap Area	RFP 13, Payments and DeFi; secondary alignment with RFP 14, Wallet and dApp Integration Tooling
Champion	Needs Champion
Total Funding Request	1,900,000 CC, plus up to 200,000 CC for an external security audit as a separate line
Project Duration	23 weeks
Label	financial-workflows-composability (primary); dapp-integration (secondary)
Website & Live Application	Project site: payvol.xyz · Playground: payvol.xyz/app
Published Packages (v0.4.0, Apache-2.0)	@payvol/core · @payvol/qr · @payvol/conformance · @payvol/cli

---

Abstract

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. A Payvol 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 will turn the existing self-funded prototype into a stable public standard, production TypeScript implementation, conformance suite, Canton execution profiles, lifecycle and reconciliation toolkit, self-hostable resolver, an ISO 20022 Request-to-Pay reference converter prototype, and a version-pinned x402 representation mapping. Together, these components give Canton applications and wallets a common payment language built directly on the Canton Token Standard and dApp/wallet standards. 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.

The request is 1,900,000 CC over 23 weeks: 1,200,000 CC across Milestones 1 and 2, paid on acceptance, and 700,000 CC in Milestone 3, paid as seven adoption tranches of 100,000 CC, one for each independent organization that integrates Payvol and completes a real Canton payment flow. 36.8% of the request is therefore paid only on verified adoption. An independent security audit of the wallet-critical components is the final gate before the v1.0 release; its fee, up to 200,000 CC, is requested as a separate line.

---

Specification

1. Objective

Deliver an open and implementable standard for the complete Canton payment-intent lifecycle:

Express a payment request once, let a compatible payer choose and authorize a valid execution path, and let both sides determine the outcome without exposing private transaction data or depending on a proprietary wallet or processor.

Today, Canton applications can construct and settle transactions, and wallets can authorize them, but applications still need bespoke conventions for the earlier and later stages: what the payee is requesting, which accounts and instruments are acceptable, what requirements apply, what the wallet must show before signing, and how the parties classify the eventual result. Shared payment conventions can reduce integration effort as the Canton ecosystem grows.

Payvol fills that coordination gap. “Programmable” in this proposal means a declarative, bounded set of choices and policies: amount rules, accepted instruments, execution methods, expiry, payer requirements, settlement constraints, and lifecycle behavior that wallets and applications can interpret consistently.

2. Payment Request Standards Are Established Infrastructure

Major blockchain ecosystems standardized payment requests after reaching the same stage Canton is reaching now: several wallets, multiple assets, different applications, and a growing need for one interoperable way to move a payment instruction from an application to the payer’s chosen wallet.

Ecosystem	Open standard	What it standardized	Interoperability role defined by the standard
Bitcoin	BIP-321, replacing BIP-21	bitcoin: payment instructions, multiple payment methods, payer authorization, and optional proof-of-payment return	A payment link or QR code can invoke a compatible wallet with a commonly understood instruction
Bitcoin Lightning	BOLT 12 Offers	Reusable offers, invoice requests, signed invoices, payer notes, and blinded delivery paths	Defines reusable and interactive payment initiation rather than a one-time address exchange
Ethereum	ERC-681	ethereum: URLs for native-asset, ERC-20, and contract-call transaction requests	Web pages, QR codes, email, and chat can hand a structured request to the user’s wallet
Stellar	SEP-0007	web+stellar: delegated-signing requests, optional origin binding and request signatures, callbacks, and QR transport	Applications that do not hold user keys can request transactions from independently implemented wallets
Solana	Solana Pay	Non-interactive SOL/SPL transfer requests and interactive transaction requests through URLs, links, and QR codes	Defines request formats that supporting wallets and payment applications can interpret and reference-based payment validation
Canton + Payvol: proposed grant outcome	Payvol Core Protocol v1 and independently versioned Canton execution profiles	Signed portable intents and Offers, wallet handoff, actual-transaction verification, lifecycle responses, exact correlation, and party-scoped reconciliation	Adds a common request-to-outcome payment layer without replacing Canton wallets, custody, the Token Standard, or settlement applications

The comparison in Figure 1 covers only what the linked standard itself defines. A ✕ does not mean that the wider ecosystem cannot implement the capability; it means the named standard does not specify it as part of its shared payment-request contract. ◐ means optional, mode-specific, or narrower than the Payvol capability. ✓* is a funded delivery target subject to the proposal's milestone acceptance evidence, not a claim that the capability is already available today.

The qualified cells are intentional. BIP-321's proof-of-payment return is optional and it can carry other payment instructions; BOLT 12 signs invoice requests and invoices while an Offer itself need not be signed; SEP-0007 request signing, origin binding, and callback are optional; and Solana Pay defines interactive transaction requests, wallet-side transaction validation, and reference-based payment confirmation without a separate Payvol-style canonical intent/profile comparison. Canton already provides generic wallet/dApp interfaces and private party-scoped ledger views, but the cited CIPs do not define a shared payment-request artifact or request-linked reconciliation protocol. Each Payvol ✓* applies to the versioned profile and wallet/custody path whose conformance has been demonstrated; it does not claim universal support across every Canton integration.

Figure 1. Capability comparison: only what each linked standard itself defines, and the funded delivery target for Canton + Payvol on the demonstrated profile and path. ✓ defined · ◐ partial or optional · ✕ not defined by the named standard · ✓* funded delivery target, subject to milestone acceptance evidence.

The proposed outcome is therefore not another settlement rail. It is a common Canton layer intended to carry a request from a business application to a supported authorization path, verify the corresponding execution where the path exposes the required capabilities, and return authorized evidence that the payee can reconcile privately.

The common lesson is not that every network should copy the same URI, nor that Payvol replaces these standards. Shared payment conventions complement settlement capabilities and support broader ecosystem adoption. Applications and wallets also need a shared language for the request, user authorization, safe transaction interpretation, and completion evidence. Payvol combines that established category with the Canton-specific requirements that the other standards do not attempt to solve: versioned Token Standard execution profiles, synchronizer-aware options, verification of the actual transaction awaiting authorization, and private reconciliation from the payee's authorized view.

Building on Canton's existing foundations

Canton already has the essential foundations:

Canton foundation	Capability available today	Layer completed by Payvol
CIP-0056 and CIP-0112 Token Standard	Standard transfer and allocation execution for Canton assets	A portable intent describing what payment outcome is requested and which execution choices are acceptable
CIP-0103 dApp Standard	Wallet connection, accounts, signing, ledger access, transaction submission, and lifecycle events	A payment-specific object that any compatible application can pass through that interface
Canton privacy and party-scoped ledger views	Confidential execution and participant-authorized observation	Private payment matching and reconciliation without dependence on a public transaction index
Canton’s multi-asset, multi-application architecture	Many issuers and workflows can interoperate on a shared network	Consistent payment options, requirements, clear-signing checks, responses, and operational status across those workflows

The current Canton CIP catalog contains these execution and wallet building blocks, but no published CIP defines the complete portable payment-intent and reconciliation layer represented by the standards above. Payvol completes that stack in a Canton-native way: multi-party, multi-asset, synchronizer-aware, privacy-preserving, and compatible with institutional payment operations.

Figure 2. Payvol between requesting applications and measured wallet or custody capabilities, settled by the Token Standard on Canton.

3. Existing Proof of Work

The following work has already been completed or substantially completed by Cayvox Labs and provides evidence of feasibility:

• a sealed v0.1 payment-request format and a richer v0.2 draft data model;
• structured account, payee, instrument, requested-receive, execution-scope, security-requirement, and payment-option types;
• open-source TypeScript packages for core encoding and validation, QR payload handling, NFC Forum NDEF URI serialization/parsing, conformance, and command-line use, published on npm under Apache-2.0 as @payvol/core, @payvol/qr, @payvol/conformance, and @payvol/cli;
• a web playground and integration-oriented application shell at payvol.xyz/app, with the project site at payvol.xyz;
• a captured Canton DevNet reference-CLI path covering prepare, local signing with a dedicated externally held Ed25519 key, execute, update-ID retrieval, Canton Coin v1 transfer-instruction creation and recipient acceptance, with payee-side correlation metadata captured on the instruction-creation update, which remains readable after acceptance;
• an end-to-end payment captured on a local Canton and Splice 0.6.11 network over the Token Standard V1 transfer-instruction and holding interfaces, during which the Canton Coin registry emitted the Token Standard V2 EventLog_HoldingsChange event and the payee's ReceiverSide transfer leg carried the payvol.digest metadata: the transfer offer, the recipient's acceptance, the settled holding, and the reconciliation record, committed as fixtures with a SHA-256 manifest and replayed by the test suite, so the observation and reconciliation path runs without a network;
• a documentation set at payvol.xyz/docs whose every code sample is executed against the published packages and shows the output that run produced;
• three Payvol guides in the Cayvox Developer Center: a payment request example with source, a locked dependency set and ten draft-format tests, a validation and payment evidence guide, and a browser request inspector that runs the Payvol validator on six synthetic requests with editable JSON;
• 146 passing conformance vectors, 62 for the sealed v0.1 profile and 84 for the v0.2-draft profile; and
• 1,803 passing automated tests, with type checking, linting and format checks passing in continuous integration on 2026-09-14.

The grant turns this foundation into a stable, supported v1 protocol: it completes the security and lifecycle model, ships production packages, proves a direct-transfer profile and an allocation-handoff profile against their stated acceptance boundaries, establishes interoperability, and validates the result with independent ecosystem participants.

Figure 3. The existing, tested foundation and the three grant steps that turn it into a stable, supported v1 protocol.

4. Implementation Mechanics

4.1 Intent plane

The intent plane describes what outcome the payee will accept, independently of the wallet that will authorize it. Its v1 objects will include:

• PaymentIntent: identity, payee, requested receive amount, currency/instrument policy, expiry, network and synchronizer scope, human-readable purpose, private reconciliation reference, and security envelope;
• PaymentOption: one permissible combination of account, instrument, amount rule, execution profile, and requirements;
• Requirement: machine-readable preconditions such as payer acknowledgement, credential or eligibility references, memo requirements, and timing constraints; and
• Offer: a signed reusable invitation whose portable envelope identifies immutable offer terms and its resolver binding without embedding mutable server state; the resolver issues a separately identified and signed PaymentIntent for each successful resolution.

The same semantics will have deterministic JSON and URI forms. Transport helpers will cover QR, deep links, browser links, and NFC Forum NDEF URI records. A digest and signature envelope will allow a wallet to identify which fields it is authorizing and detect changes between presentation and execution.

Payvol v1 will report payload integrity, signing-key verification, and payee identity binding as separate results. A valid signature proves control of a key over the canonical intent; it does not by itself prove that the key belongs to the merchant or payee the payer expected. PV-03 will therefore define a pluggable trust-binding interface and a reference policy for pinned key/party allowlists and out-of-band expected-payee bindings. Wallets remain free to add compatible directory or naming-system resolvers. When no recognized binding is available, the wallet reports the request as integrity-verified but identity-unbound rather than upgrading it to trusted.

Payvol separates the Core Protocol from Canton Execution Profiles so each can evolve without silently changing the other. Milestone 1 freezes the transport-independent object grammar, canonicalization, security envelope, profile identifier and registry contract, feature negotiation, and fail-closed handling of unknown profiles. Execution-profile semantics, extractors, compatibility manifests, and profile-specific vectors are versioned independently and released in Milestone 2. A core implementation can therefore preserve and validate a profile reference without claiming it can execute a profile it does not support.

Offer resolution has an equally explicit boundary. The M1 protocol defines a resolution request containing the signed Offer digest and an opaque client request identifier. The M3 reference resolver adds a unique resolver nonce, derives the new intent identity with the M1 domain-separated hashing rules, atomically persists the (offerDigest, clientRequestId) mapping before responding, and returns the same result when that request is safely retried. The resulting intent carries sourceOfferDigest, cannot widen the signed Offer's immutable constraints, expires no later than the Offer, and has its own resolver/payee signature. Thus M1 standardizes what consumers verify while M3 supplies the stateful issuance service.

Figure 4. The Core Protocol frozen at Milestone 1 acceptance and the independently versioned Canton execution profiles released in Milestone 2, joined only by the profile registry.

4.2 Execution plane

Payvol will define profiles that translate a selected payment option into existing Canton execution mechanisms. The implementation will:

1. validate the intent, expiry, network, integrity status, configured identity-binding policy, selected option, and requirements;
2. resolve the relevant Token Standard instrument and account information;
3. hand the request to a wallet through a neutral interface compatible with the direction of CIP-0103;
4. map direct-payment choices to the Token Standard transfer flow and express conditional or coordinated choices as an allocation handoff for a settlement application/executor under CIP-0056 and CIP-0112;
5. derive a PreparedExecutionSummary from the prepared transaction and its preparation context through a versioned execution-profile extractor, then compare it with the accepted intent before signing; and
6. return normalized submission evidence and lifecycle status without leaking private ledger data.

Wallet capability and conformance model

Payvol is designed so that any wallet or custody system can participate at the level it supports, and so that applications can rely on a published, versioned conformance model instead of integration-by-integration assumptions. A direct-transfer integration can use either of two implementation modes with identical guarantees:

1. application-visible preparation, in which the execution adapter obtains the prepared transaction and context, PV-08 verifies them, and the wallet authorizes the verified signable payload; or
2. wallet-owned preparation, in which the wallet constructs the transaction and runs the same profile extractor and clear-signing check over the actual transaction before authorization.

In both modes, exact correlation to the intent is established when the submitted transaction carries the profile-defined Payvol payload digest and execution-profile identifier and those values are observable in the payee's authorized update stream, identified by a real ledger updateId; whether the payment is complete, and how the outcome is classified, is determined separately from the profile's settlement evidence.

Conformance is expressed by capability so that wallets, custodians, and applications share one vocabulary:

Capability class	What it guarantees
Core Conformant	Parses, validates, verifies, and displays the Payvol artifact and its trust statuses
Execution Conformant	PV-08 evaluates the actual transaction awaiting authorization, through application-visible preparation or a wallet-internal guard
Reconciliation Conformant	The submitted execution preserves the exact Payvol digest/profile correlation and the payee observes it with real update evidence
Full Conformant	Core, Execution, and Reconciliation conformance for the named profile and version

Conformance is versioned per profile and published with the conformance suite, so a wallet or custody path can adopt Payvol incrementally, advertise exactly what it supports, and be verified by anyone using the public vectors. Milestone 2 publishes the first measured, versioned capability report for the wallet and custody paths exercised by the reference flow; the model itself is not tied to any particular wallet product.

Prepared-execution interpretation boundary

Payvol will reuse compatible Canton transaction-hashing and visualization components where they satisfy the supported profile's verification requirements. Its payment-specific contribution is checking the prepared execution against the accepted PaymentIntent and binding that check to the payload awaiting authorization. PV-08 is deliberately bounded to known execution profiles; it is not a general interpreter for arbitrary Daml transactions. The v1 direct-transfer extractor will use the exact Token Standard interface/package versions listed in a published compatibility manifest. The default extractor ships with content-addressed descriptors bound to the Payvol release; participant package services may supply package data but do not define the trusted interpretation. An externally supplied descriptor is accepted only when its digest and authenticated release provenance match an explicitly trusted manifest.

Comparison input	Authorization-critical information	v1 rule
Accepted Payvol option	Expected payee/destination, requested receive amount, instrument, account, execution method, expiry, and execution scope	Read only from the validated canonical intent
Known Token Standard command/choice	Actual destination, transfer amount, instrument, account, execution method, and any extractable fee/receive semantics	Independently extracted by the versioned profile; never accepted from an untrusted builder-supplied summary
Preparation and wallet context	Network, logical synchronizer ID, execute-before constraint, hashing scheme, and transaction hash	Bound to the summary; the logical synchronizer ID is derived from the prepared transaction's synchronizer_id by the profile's manifest-pinned rule, which accepts both the Canton 3.4 and the suffixed Canton 3.5 formats; executeBefore must not be later than intent expiry
Package/interface identity	Package ID, interface/choice identity, supported schema version, profile version, and descriptor digest	Must match the release-authenticated compatibility manifest or fail closed

If any field declared authorization-critical for a profile cannot be independently extracted or bound, PV-08 returns a stable UNSUPPORTED_EXECUTION or INDETERMINATE_SUMMARY result and the wallet does not authorize through that profile. For supported profiles, the clear-signing verifier compares the independently derived values and rejects any mismatch before wallet authorization.

The check covers the supported profile's entire signable transaction structure, not merely one matching transfer inside it. Each profile defines its permitted root actions and associated authorization-relevant structure, including any supported fee and change operations. Additional unauthorized transfers or authority-changing actions, and authorization-relevant structure that the profile cannot interpret, fail closed. Using the supported Canton hashing scheme, the verifier independently derives the transaction hash and binds the checked transaction and authorization context to the exact payload the wallet will sign. Rebuilding or changing that payload invalidates the check and requires verification again; a matching builder-supplied summary is insufficient.

Each profile declares its amount semantics. The fixed-receive direct-transfer profile compares requestedReceive.amount only where the supported asset/profile semantics establish that the extracted transfer amount is the amount credited to the destination; separately charged payer fees are displayed as fees and do not reduce that receive amount. If receiver-side deductions, conversion, netting, or an unextractable fee make the credited amount indeterminate, that option fails closed under the fixed-receive profile. This leaves room for separately versioned quote, fixed-send, variable-receive, and other future profiles without weakening v1 authorization.

The authorization deadline is the earliest applicable deadline. A prepared execution is eligible only while the intent and selected option are current and its enforceable executeBefore is no later than the intent expiry. A missing, later, or unbindable execution deadline produces a stable fail-closed result rather than extending the signed intent's lifetime.

The compatibility manifest is itself authorization-critical. Its content digest, release provenance, supported package/interface identities, and extractor version are recorded in the PreparedExecutionSummary. Unknown, altered, stale-incompatible, or mismatched descriptors are rejected. This makes profile expansion an explicit release action instead of allowing mutable runtime metadata to redefine what a wallet believes it is signing.

Figure 5. The clear-signing guard: every gate must pass before Payvol marks the execution approval-safe; unknown or unextractable inputs fail closed.

Allocation ownership is separate and explicit. The settlement application/executor creates the settlement and AllocationRequest, coordinates the parties, and completes the settlement. Payvol standardizes the payment-option representation, wallet handoff, correlation, and normalized outcome for that external flow. Milestone 2 validates this integration contract against current Token Standard interfaces while the live reference execution remains the direct-transfer profile.

Synchronizer behavior is also deterministic: a pinned option is available only on the named synchronizer; if the payer cannot source a valid execution there, the option is rejected with a stable reason. For an any policy, the wallet/execution adapter selects a supported synchronizer and records the selected value in the prepared summary and response. Asset reassignment remains an explicit wallet or settlement-application operation, and Payvol never silently falls back to a different synchronizer.

Synchronizer scope binds to the logical synchronizer identity introduced with Logical Synchronizer Upgrades in Canton 3.5 / Splice 0.6.x, not to the physical synchronizer node. A pinned option therefore stays valid across an LSU in which the physical synchronizer changes but the logical SynchronizerID is preserved. Because the Ledger API does not guarantee the format of the synchronizer_id field and the Canton 3.5 format adds a suffix to the 3.4 format, PV-08 treats the field as opaque and derives the logical identity through a manifest-pinned rule that accepts both formats; an unrecognised format fails closed. An LSU topology freeze or upgrade window is classified as a retry-safe pending submission, not as a rejected payment, and the prepared summary records the logical identity it compared.

4.3 Lifecycle and reconciliation plane

A payment request is not complete when it is displayed or submitted. Payvol will define a transport-neutral PaymentResponse and status model covering presentation, acceptance, decline, authorization, submission, settlement, failure, expiry, and closure. The reference reconciler will classify:

• exact, partial, and over-payment;
• wrong account or instrument;
• duplicate, replayed, late, expired, and superseded payment attempts;
• submitted but not yet observable outcomes;
• failures and retry-safe resubmission; and
• privacy-preserving evidence checkpoints for environments where ledger history is pruned.

The private commercial reference remains off-ledger by default. For a reconciliation-conforming direct-transfer profile, the correlation envelope written to Transfer.meta.values contains the domain-separated Payvol payload digest and execution-profile identifier, not the invoice number or other private business reference. The payee-side adapter reads that envelope from its authorized update stream and records the ledger updateId, effective time, instrument, amount, and receiver as execution evidence. The captured DevNet fixture captures the draft digest/profile metadata on the instruction-creation update and separately records the recipient-acceptance update ID; the creation update remains readable by the payee after acceptance. It does not establish metadata on the acceptance credit event or the final v1 execution-profile identifier. M2 links an instruction to its successful acceptance outcome before counting it as settled; creating an instruction alone is not payment completion.

Token Standard V2 (CIP-0112) keeps the correlation surface: the V2 Transfer record carries the same meta : Metadata field, and the V1-to-V2 upcast preserves payvol.* keys. The V2 EventLog_HoldingsChange event exposes meta on each transfer leg side, but the standard defines that field only as extensible and does not require a registry to copy Transfer.meta into it; the Canton Coin registry does at Splice 0.6.11, and the LocalNet capture shows the payvol.digest key on the payee's ReceiverSide leg. Payvol therefore treats EventLog leg metadata as registry-specific evidence, verified per profile and per registry, and never assumes it for a registry that has not been captured. For allocation handoff, correlation uses the V2 SettlementInfo (id, contract, meta) triple that executors must keep unique, together with AllocationRequest and Allocation metadata. Metadata survival and payee-side observability on the V2 transfer-instruction path, the preapproval/direct-credit path, and the allocation settlement path for Canton Coin are separate Milestone 2 verification items. No path or profile is marked supported until captured evidence passes its profile-specific conformance suite.

Distinct, confirmed settlements correlated to the same digest can be aggregated as partial or over-payment evidence only for the requested destination and instrument. Each profile defines the settlement identity and evidence chain used for deduplication: the same updateId observed again is not new evidence, multiple movements within one update are distinguished where applicable, and an instruction's creation and acceptance are not counted as two payments. An event with no valid Payvol digest is reported as an uncorrelated settlement and is never automatically assigned to an intent from account, amount, or timing similarity. Implementations may expose an auditable operator-assisted linking workflow outside the normative automatic reconciler. An allocation handoff is not advertised as automatically reconcilable until its versioned profile has defined and verified an equivalent correlation surface. Reconciliation otherwise uses returned execution evidence or signed notifications controlled by the parties and never assumes public visibility of private Canton transactions.

Figure 6. Reconciliation uses exact digest correlation and profile-defined settlement evidence; repeated observations and instruction/acceptance evidence are not additional payments, and uncorrelated settlements are never assigned by similarity.

Replay and idempotency controls are defined by layer rather than presented as one universal guarantee:

Case	Control and state boundary	Delivery
Expired or re-presented artifact	Signed expiry plus wallet/application seen-intent policy	Semantics and vectors in M1
Replayed signed prepared submission	Execution-profile-specific transaction identity and ledger rejection rules	Detection/result mapping in M2
Repeated claim for one single-use intent	Shared payee/resolver state and an atomic claim/close operation; participating integrations require an accepted claim before authorizing a new payment attempt	Atomic rejection of a second claim through the durable state provider in M3
Fresh second transfer for an already fulfilled intent	Profile-defined settlement evidence and intent identity; transfers submitted outside the claim-aware path remain possible	Deterministic duplicate-payment detection when correlated evidence is observable in M2; the M3 resolver does not prevent arbitrary on-ledger transfers
Redelivered response or webhook	Stable event/attempt identifier and idempotent consumer rule	M2 response model and M3 notification profile

This distinction allows stateless payment requests to remain portable while making single-use coordination an explicit stateful capability of cooperating integrations, rather than an implied property of a signature or expiry. A resolver claim is not an exactly-once ledger-settlement guarantee; uncertain submissions must be resolved from execution evidence before a retry is authorized.

The resolver's HTTP processing can remain stateless, but current status, Offer resolution, closure, and atomic claim decisions are served by an explicit state provider. The bundled durable provider stores only the identifiers, state transitions, timestamps, expiry, and policy-required claimant context needed for those operations; private commercial references are excluded. The privacy analysis covers identifier and timing linkability, scoped access, minimized logs, configurable retention, and deletion. Payer-identifying data is retained only when an application policy requires it, rather than being a protocol-wide requirement.

4.4 Adapter and institutional integration plane

The grant includes two bounded institutional integrations:

• an ISO 20022 Request-to-Pay mapping and converter prototype, centered on pain.013 request, pain.014 response, the reference linking an accepted request to its separate pacs.008 credit transfer, and relevant cancellation/status semantics; and
• a version-pinned x402 exact-Canton representation mapping showing how the scheme's Canton Coin payment requirement, the payee's live TransferPreapproval prerequisite, payer-signed transfer, facilitator result, and service decision are represented as Payvol intent and lifecycle objects.

The ISO converter documents precise field mapping and loss handling. The ISO mapping does not treat pain.014 as settlement: acceptance is followed by a separate credit transfer, linked through the agreed end-to-end reference. Cancellation is represented as its own creditor/payee-side request path rather than as a payer response.

The x402 mapping is representation only. As the exact-Canton scheme at the pinned version specifies, the client prepares and signs the transfer without submitting it, the resource server calls a configured facilitator, and the facilitator verifies the live TransferPreapproval, relays the payer-signed transaction, and returns the settlement result. Payvol maps those objects and outcomes into PaymentIntent, TrustAssessment, PaymentResponse, and SettlementEvidence representations and reports unsupported or lossy fields. The grant delivers the mapping specification, validated example inputs and outputs, and mapping tests: mapping validation only; no x402 payment verification, transaction submission, or settlement execution. A mapped result keeps its source and trust context; mapping does not verify the payee identity, does not treat the payment as independently settled, and does not reinterpret the payer's signed payload as a re-signable Payvol transaction.

Figure 7. The ISO 20022 request, response, and resulting credit transfer are separate messages linked by reference; the bounded converter maps the supported request-to-pay semantics to Payvol.

4.5 Components delivered

• normative Payvol v1 specification and public standards package;
• published packages: @payvol/core, @payvol/qr, @payvol/conformance, and @payvol/cli in M1, followed by @payvol/canton and @payvol/lifecycle in M2;
• frozen, language-neutral Core Protocol vectors, independently versioned execution-profile vectors, and a conformance runner;
• trust-binding interface and reference pinned-key/party policy;
• Canton execution profiles, versioned prepared-execution extractors, a release-authenticated compatibility manifest and generated support matrix, and a fail-closed clear-signing verifier;
• lifecycle, observation, and reconciliation library;
• self-hostable resolver with explicit state-provider adapters, a durable reference provider, and a signed notification service;
• reference payer, payee, invoice/AP, and ISO 20022 examples plus the version-pinned x402 representation mapping with validated examples;
• threat model, privacy analysis, operational guidance, migration guide, and support matrix; and
• seven independently operated Canton integrations in Milestone 3.

4.6 Technical architecture by module

Payvol is organized as a set of small modules with explicit inputs and outputs. Protocol processing remains deterministic and side-effect free; wallet, resolver, and ledger access are isolated at the edges. This allows an application to adopt the complete stack or only the modules it needs while preserving identical payment semantics.

Figure 8. The twelve bounded Payvol modules; resolved intents return through Core verification, while wallets, state providers, facilitators, and settlement executors remain external owners.

ID	Module	Core responsibility	Primary input	Primary output	Milestone
PV-01	Intent and Offer Model	Defines the requested outcome, payee, receive amount, acceptable options, requirements, execution scope, expiry, commercial context, and the contract binding a reusable Offer to each resolved intent	Application or institutional payment instruction	Versioned PaymentIntent or signed reusable Offer envelope	M1
PV-02	Canonicalization	Produces deterministic bytes so independent implementations calculate the same content identity	Payvol payload	Canonical JSON, payload digest, serialization metadata	M1
PV-03	Trust and Identity	Verifies payload integrity and key control, then evaluates signer-to-payee binding under an explicit wallet/application trust policy	Payload digest, security envelope, expected-payee context, configured trust source	Separate integrity, key-verification, and identity-binding statuses with source and stable findings	M1
PV-04	Portable Transports	Carries the same artifact through JSON, URI, QR, browser link, and NFC without changing its meaning	Canonical Payvol artifact	Transport representation and decoded artifact	M1
PV-05	Conformance and Tooling	Proves that independent implementations process Core Protocol objects identically and can add separately versioned profile suites	Core or execution-profile specification and test vectors	Machine-readable conformance report, CLI output, CI result	M1, extended in M2
PV-06	Wallet Handoff	Converts a verified intent and selected option into a normalized, wallet-neutral authorization request	Verified artifact, payer account, selected PaymentOption	CIP-0103-compatible wallet request and normalized wallet result	M2
PV-07	Canton Execution Profiles	Prepares supported direct-transfer executions and maps allocation options into a handoff owned by an external settlement application/executor	Wallet request, instrument, destination account, execution scope	Prepared direct-transfer execution or allocation integration handoff; normalized result	M2
PV-08	Clear-Signing Guard	Checks the supported transaction structure, independently extracts critical fields, compares them with the intent, and binds the result to the wallet's signable payload	Accepted intent, prepared execution and context, release-authenticated package/interface manifest	Verified PreparedExecutionSummary and checked transaction hash, or precise fail-closed rejection	M2
PV-09	Lifecycle and Reconciliation	Normalizes payer response and classifies exactly correlated ledger outcomes against the original request without guessing	Wallet events, authorized ledger events, Payvol payload digest	PaymentResponse, lifecycle status, ReconciliationResult, or uncorrelated-settlement result	M2
PV-10	Resolver and Status	Resolves a signed Offer into a unique signed PaymentIntent, serves dynamic options/status through explicit state-provider adapters, and provides durable atomic state for single-use intents	Offer or intent identifier, privacy-minimized request context, configured state provider	Signed resolved intent, current options/status, terminal result, or atomic claim decision	M3
PV-11	Notifications	Delivers lifecycle changes to the requesting application with authentication and safe redelivery	Versioned lifecycle event	Signed, ordered, idempotent notification	M3
PV-12	Institutional Adapters	Provides the bounded ISO 20022 converter prototype and maps x402 exact-Canton request/response semantics to Payvol objects for representation only	ISO 20022 pain.013 or x402 Canton Coin payment requirement and facilitator result	Payvol intent plus ISO 20022 pain.014, or Payvol representations of the x402 request, payer-signed payload result, and settlement result	M3

4.7 Core protocol objects

The modules exchange a small set of versioned protocol objects rather than application-specific payloads:

Object	Meaning	Important invariants
PaymentIntent	A single requested payment outcome	One authoritative requested-receive amount; explicit network and synchronizer policy; bounded lifetime
Offer	A signed reusable invitation from which a resolver can issue payment intents	Immutable terms and resolver binding are signed; every resolved intent has a unique identity, expiry, sourceOfferDigest, reconciliation context, and its own signature
PaymentOption	One permitted way to satisfy the intent	References a defined instrument, destination, versioned execution profile, amount semantics, and requirement set; unsupported profiles fail closed
SecurityEnvelope	Integrity and signer context attached to canonical intent bytes	Signature input, suite, signer, key reference, and signing time are explicit and versioned; the envelope alone makes no merchant-identity claim
TrustAssessment	The wallet/application's evaluation of the signer against its configured trust source	Integrity, key control, identity binding, evidence source, and unresolved status remain separate
WalletHandoff	The normalized instruction passed to the payer’s wallet	Contains business intent and authorization-critical fields, rather than private key or wallet implementation details
PreparedExecutionSummary	A deterministic, independently extracted interpretation of a supported Canton transaction awaiting approval	Records extractor/profile, package identity, descriptor digest, checked transaction hash and context, amount semantics, extractable fees, and effective deadline; permitted transaction structure and every critical field must be verified, or the profile fails closed
PaymentResponse	The payer-side answer and submission lifecycle	Stable states and reason codes across wallet implementations
SettlementEvidence	The evidence returned from submission or observed on the authorized ledger view	Carries provenance, Payvol digest/profile correlation, effective time, and update identifiers required for reconciliation
ReconciliationResult	The payee-side classification of what occurred	Distinguishes exact, partial, overpaid, duplicate, late, expired, wrong-instrument, failed, and indeterminate outcomes

4.8 End-to-end payment sequence

Figure 9. Off-ledger request and verification, on-ledger settlement with the correlation envelope, and private exact-digest reconciliation returning to the payee.

At the critical authorization boundary, PV-08 evaluates both the accepted Payvol option and the actual prepared Canton execution. The execution adapter may operate beside the wallet or be implemented inside it, but the same profile extractor and fail-closed rules apply. A mismatch, unknown package/profile, or field that cannot be extracted produces a deterministic rejection before the payer signs; a successful check produces the display model bound to the exact signable transaction and context. Separately, the selected profile must preserve its correlation envelope through submission for reconciliation conformance. This establishes execution-to-intent consistency without conflating it with merchant authenticity: payee identity remains a separate PV-03 result and is never inferred from a digest or transaction comparison.

4.9 Module delivery across milestones

Figure 10. Three milestones over 23 weeks; every payment is tied to explicit acceptance evidence, with a live supported path in Milestone 2 and independent integrations in Milestone 3.

This order makes every milestone independently useful. M1 gives the ecosystem an implementable standard and compatibility test. M2 makes that standard executable and operationally observable on Canton. M3 connects it to live application state and institutional payment boundaries, then validates the complete stack through independent implementations.

5. Architectural Alignment

Primary alignment: RFP 13, Payments and DeFi

The Foundation’s 2026–2028 roadmap asks for open-source tooling, reference implementations, and standards for payments, settlement, and liquidity workflows that support real economic activity, improve composability, and make it easier for applications to build financial workflows that are private, auditable, and interoperable, with a stated preference for reusable components or standards that support multiple Canton applications rather than one-off application-specific work. Payvol answers each element of that request directly:

RFP 13 asks for	What Payvol delivers
Open-source standards, tooling, and reference implementations for payments and settlement	Payvol Core Protocol v1, production TypeScript packages, conformance suite, and reference payer/payee, invoice/AP, the ISO 20022 converter prototype and the x402 representation mapping, all under Apache-2.0 / CC0-1.0
Support for real economic activity	Reference invoice/AP flow on a Canton test environment in Milestone 2 and seven independently operated integrations on TestNet or MainNet in Milestone 3
Improved composability	One payment-intent object and lifecycle model that any application, wallet, issuer, or settlement application can compose with, without modifying Token Standard or wallet interfaces
Private, auditable, and interoperable financial workflows	Party-scoped reconciliation from the payee's authorized ledger view, exact-digest correlation, signed evidence, and ISO 20022 Request-to-Pay conversion and x402 semantic mapping
Reusable components rather than one-off work	Twelve bounded modules that applications adopt individually or together with identical payment semantics; no application-specific checkout flow is funded

Payvol also delivers several items that the roadmap lists under Financial Markets Standards: integration mappings for existing institutional systems, API-level compatibility standards, and conformance tests with reference implementations, while supporting multiple issuers and applications rather than a single proprietary implementation.

Secondary alignment: RFP 14, Wallet and dApp Integration Tooling

The roadmap describes wallets as a primary interface for users, hosted parties, application providers, and institutional workflows, and asks for wallet integration tooling, reusable wallet components, signing flows, and application-to-wallet interactions. Payvol gives wallets a stable, reusable object to display, validate, approve, reject, and reconcile, and a clear-signing flow that verifies the actual transaction before the signature. It gives dApps a stable object to create without choosing a payer’s wallet, and a wallet-neutral application-to-wallet handoff compatible with CIP-0103. It uses the wallet/dApp connection surface where available but remains transport-neutral.

Placement in the Canton stack

Layer	Existing Canton capability	Payvol contribution
Asset and settlement	CIP-0056 / CIP-0112 Token Standard transfer and allocation interfaces	Turns acceptable settlement paths into wallet-readable payment options
Wallet authorization	CIP-0103 connection, account, signing, execution, and event interfaces	Supplies consistent payment semantics and display-critical fields to the authorization flow
Ledger execution	Canton prepare, sign, execute, and party-authorized ledger access	Verifies that the prepared execution matches the accepted intent and returns normalized evidence
Application operations	Application-specific invoice, checkout, treasury, and agent workflows	Provides a common lifecycle and reconciliation language reusable across all of them

This creates a clean composition: Payvol expresses and tracks the requested payment; Canton’s existing standards authorize, execute, and record it. Each application keeps control of its product experience while gaining an interoperable payment primitive.

6. Backward Compatibility

No backward compatibility impact. Payvol is additive. Existing applications may adopt only the static v1 format, only the lifecycle library, only the conformance vectors, or none of the project. No ledger contracts, Token Standard interfaces, wallet APIs, or existing application workflows are modified by this grant.

The Core Protocol v1 release will include an explicit migration utility from the existing Payvol v0.1 and v0.2-draft forms. Future changes will follow semantic versioning; unknown optional fields will be handled according to the compatibility rules in the specification.

Release names follow the same boundary: M1 releases stable Core Protocol v1 packages and vectors; M2 releases independently versioned execution profiles and lifecycle tooling; M3 delivers the integrated Payvol suite release candidate, including operational services and adapters. The suite's release-candidate label does not reopen or downgrade the stable Core Protocol v1 specification. After the external security audit, the release candidate is promoted to the Payvol suite v1.0.

7. Real-World Solution Scenarios

The proposed v1 scope supports the following scenarios. Each scenario uses the same open payment primitive and maps directly to funded Payvol modules rather than requiring a separate, application-specific payment format.

Scenario	Real workflow enabled by Payvol	Verifiable outcome	Modules exercised
B2B invoicing and accounts payable	A supplier embeds a signed payment intent in an invoice. The buyer's AP system checks payload integrity and the supplier binding under its configured trust policy, then validates amount, accepted instruments, account, expiry, and private invoice reference before handing authorization to a supported wallet or custody path.	The supplier uses the Payvol digest to locate the corresponding off-ledger invoice record, then classifies the authorized Canton result as exact, partial, overpaid, late, duplicate, uncorrelated, or unresolved from its permitted ledger view.	PV-01–PV-09; PV-11 and PV-12 for notifications and ISO 20022 Request-to-Pay exchange
Merchant checkout and point of sale	A checkout or terminal presents the same request as a QR code, link, or NFC record. A supported wallet or custody path selects an allowed token/account combination, displays the critical terms, and authorizes the corresponding Token Standard execution according to its measured capabilities.	The merchant receives a normalized result and can confirm the requested payment without depending on a proprietary wallet payload or public transaction index.	PV-01–PV-10
Treasury payment requests	A treasury or operations team sends a controlled request to an internal entity or counterparty with an identified payee, amount rule, accepted instrument, execution method, synchronizer scope, requirements, and expiry.	The payer retains its structured response and submission evidence; the payee independently derives reconciliation state from its authorized evidence.	PV-01–PV-09; PV-11 for lifecycle delivery
Agent and API payments	Software receives a machine-readable Payvol intent, verifies it, evaluates the permitted options, and passes the selected payment to a wallet or custody policy for authorization. The x402 representation mapping shows how the existing exact-Canton flow across client, resource server, and configured facilitator is represented in Payvol objects.	The service receives a normalized Payvol representation of the x402 outcome, with its source and trust context preserved, while the wallet's authorization boundary is untouched.	PV-01–PV-10; PV-12 for the x402 representation mapping
Validator and node-service billing	An infrastructure provider issues a signed service invoice whose private payment reference remains in its off-ledger billing record and can use the resolver for current amount, accepted instrument, expiry, and status.	The provider uses the Payvol digest to observe and reconcile each conforming service payment from its authorized Canton view and delivers lifecycle changes to its billing system through signed notifications.	PV-01–PV-11
Marketplace obligations and payouts	A marketplace or payout operator represents each seller, contributor, or service obligation with its own payee, amount, asset choice, private reference, and lifecycle state, using a consistent format across many counterparties.	Each conforming settlement remains independently attributable through its Payvol digest and reconcilable, while partial, duplicate, late, failed, and uncorrelated outcomes remain distinct and direct-transfer or allocation-handoff profiles provide Canton routing choices.	PV-01–PV-10

Figure 11. Four documented solution patterns on the same four bands: business trigger, signed Payvol request, supported Canton execution, evidence-backed business update. Payment completion is confirmed only by the profile's settlement evidence; authorization and pending states are recorded separately.

Anchor scenario A: a B2B invoice automatically matched to its Canton settlement

Starting point. A supplier's ERP has an approved invoice, payment terms, and a private invoice reference. The buyer may use a different AP product, wallet, custodian, or accepted Token Standard instrument.

End-to-end journey:

1. The supplier system creates and signs a Payvol intent containing the payee, requested amount, destination account, accepted instruments, execution options, expiry, requirements, and private reference.
2. The same intent travels with the invoice as a link, QR code, or API payload and retains the same digest across each representation.
3. The buyer's AP system or chosen wallet verifies payload integrity, evaluates the signer-to-payee binding under its configured trust policy, checks the network context and available options, and presents the payment-critical fields with those statuses kept separate.
4. Payvol's clear-signing guard compares the prepared Canton execution with the accepted intent. The payer authorizes it and the supported submission component submits the payer-authorized transaction through the Token Standard direct-transfer flow with the Payvol digest and profile identifier in the defined correlation envelope.
5. Payvol normalizes the wallet result and authorized ledger evidence into a PaymentResponse and lifecycle state.
6. The supplier system uses the observed Payvol digest to locate the off-ledger intent and its private invoice reference, then classifies the result as exact, partial, overpaid, duplicate, late, failed, uncorrelated, or still indeterminate without heuristic auto-matching.

Figure 12. Anchor scenario A as a two-layer flow: signed in the ERP, verified by the buyer's AP system, authorized through a supported wallet or custody path, settled on Canton, and matched back to the invoice by one digest. The invoice record shown is illustrative.

Grant evidence. This is the primary runnable reference implementation and recorded end-to-end demonstration for Milestone 2. The evidence package will include the Canton test-environment flow, clear-signing checks, normalized response, and payee-side reconciliation output. The same runbook is designed for reuse by the independent Milestone 3 integrations.

Anchor scenario B: how an x402 agent payment is represented in Payvol

Starting point. An HTTP service returns an x402 payment requirement that offers Canton as a payment route. The exact-Canton scheme at the pinned version defines the flow: the calling software operates under wallet or custody authorization policy, the payee maintains the live TransferPreapproval the scheme requires, the client prepares and signs the transfer without submitting it, and a configured facilitator verifies, relays, and settles. Payvol does not execute any of these steps; it represents them.

Representation, step by step:

1. The x402 Canton Coin payment requirement is mapped into a Payvol PaymentIntent representation while preserving the trust context of the source request; the mapping does not by itself produce a payee signature or a verified payee identity, and the resulting TrustAssessment records the source context rather than a Payvol