Funding Proposal by FTP: x402 Protocol Integration for Canton

Thank you for the detailed proposal and for the work already done around CanTrustAI and the surrounding infrastructure. The facilitator, SDK, and middleware approach is an interesting way to make x402-style payments accessible to Canton builders.

One point that may be helpful to clarify is how this implementation relates to the upstream x402 integration process for adding a new network. The x402 ecosystem typically requires a specification phase followed by a reference implementation. It would be useful to understand whether this work is intended to align with or contribute to that upstream process, or if it is designed as an independent Canton-side implementation.

Additionally, part of the requested funding is retroactive for CanTrustAI infrastructure. Since the Development Fund typically prioritizes forward-looking ecosystem infrastructure, it may be helpful to clarify how the retroactive component directly contributes to reusable tooling for the broader Canton ecosystem.

@hythloda

Thank you for the thoughtful feedback - this is a very helpful point. Our intention is to align this work with the x402 upstream integration process, rather than treat it as a purely independent Canton-side implementation. Concretely, we see our current proposal as covering both the reference implementation layer and the specification work required for upstream inclusion:

The facilitator implements the core verification and settlement flow adapted to Canton The SDK and middleware provide a developer-facing interface for integrating x402-style payments into Canton applications A formal scheme specification (scheme_exact_canton.md) is a named Milestone 1 deliverable, covering Canton's payment model and transaction semantics, payload structure, signing and verification flow, and how Canton maps to the x402 scheme/network abstraction. It will be submitted upstream to the x402 repository alongside the facilitator code, not published as standalone Canton-internal documentation.

On the upstream alignment question, we can point to a concrete precedent: the recently merged Solana (SVM) integration demonstrates exactly how a non-EVM chain gets added to x402 upstream. That PR followed the pattern we intend to replicate for Canton:

A new facilitator implementation handling /verify and /settle for the target chain's settlement layer Client-side SDK extensions for constructing and signing chain-native payment payloads Middleware packages (x402-express, x402-fetch) updated to support the new scheme A formal scheme specification (specs/schemes/exact/scheme_exact_svm.md) submitted alongside the code

Our Canton integration is scoped to follow the same structure. The specification document we will produce mirrors the scheme_exact_svm.md artifact from that PR, and its upstream submission will be an explicit acceptance criterion for Milestone 1. This gives us a clear, already-accepted template for what upstream Canton support looks like in practice, and confirms that the x402 project is actively welcoming non-EVM integrations through exactly this kind of contribution.

Regarding the retroactive part of the proposal, our team has decided to remove it from Proposal #78.

Question: do you need any changes to the token standard (CIP-56) for your work to land?

I'm asking because there's an active conversation on cip-discuss) wrt an improved version of the token standard motivated in part by TradFi requirements for extra privacy.

There might also be changes that are not a blocker, but would make your work significantly easier. It would be great to hear about the these and in particular about blockers on cip-discuss or directly on the PR linked from there: https://github.com/canton-foundation/cips/pull/187

@meiersi-da Thanks for checking in. For our x402 integration, no changes to the existing CIP-0056 token standard are strictly required - our facilitator and SDK can work with the current standard as-is

That said, some of the proposed enhancements in CIP-0112 (e.g., improvements around privacy and settlement efficiency) could make integration smoother and reduce edge-case handling in the facilitator. None of these are blockers for us, but they would be nice-to-haves

We’ll monitor the discussion on cip-discuss and the PR you linked (canton-foundation/cips#187) and provide feedback if we identify anything that would materially simplify our implementation

Thank you very much for the quick turn-around @Denend . Much appreciated.

Glad to hear that V2 makes your product better, but is not a hard requirement. :+1:

We're actively looking into agent-driven workflows where services need to pay for data and compute dynamically. x402 is one of the few approaches that actually makes pay-per-call viable for agents without adding friction like auth or billing setup. Would definitely consider integrating something like this.

hi there, imo being able to charge per request instead of managing plans or quotas would be a big improvement, particularly for external consumers

hi there, imo being able to charge per request instead of managing plans or quotas would be a big improvement, particularly for external consumers

Agreed - that’s exactly the direction we’re aiming for. Simplifying access while enabling pay-per-use

We’ve looked at similar approaches for enabling microtransactions, and most of them break down due to UX or integration complexity.

x402 feels like a cleaner abstraction, especially with stablecoin payments and no need for user accounts

@Denend I have few questions

1. Can you also write a short architecture comparison on how this differs with EVM model .

2. Who are the stakeholders of the escrow contract — payer, merchant, facilitator? Does the facilitator need party standing on every merchant's synchronizer, or one shared one?

3. If you will use Escrow how does a merchant express "accepts" in the 402 response when the real precondition is "payer has a funded escrow with me"? That changes the accepts semantics meaningfully vs. EVM.

4. I see "stateless verification against signed Canton Coin transfer payloads" + "duplicate settlement protection (equivalent to the settlement cache pattern in the x402 SVM reference implementation"

• I doubt if this works under Canton's privacy . the facilitator can only see contracts where it's a stakeholder. So /verify either skips solvency and becomes a signature echo (useless), or it needs on-ledger visibility that the proposal doesn't grant. Let me know if there's any different architecture which I'm missing

5. How are you planning to handle Replay or Double Spend?

• On EVM the chain burns the nonce on first settle. A facilitator-side "settlement cache" only dedupes at that facilitator — two facilitator instances, or a self-hosted one plus FTP's, settle the same payload twice. Canton command dedup is keyed on submitter + command ID, not on a signature blob the facilitator didn't author.

6. Autonomous AI agent holding a Canton wallet" presupposes external signing keys that produce standalone transfer payloads. Canton's authorization goes through participant nodes and party keys; an agent signing offline and handing a blob to a facilitator is not how CC transfers get authorized today. The PR doesn't say how this gap is bridged.

7. Participant/party topology is denied, not solved. "Configurable Canton node endpoint, party ID" — singular. But payer and merchant are on different participants, possibly different synchronizers. A facilitator with one node config can't span both sides of a CC transfer as a non-stakeholder. Whose participant node? Whose party? The document doesn't answer

From your reply I felt architecture is stateful, pre-funded, on-ledger lifecycle. So if you can create or write a short note on architecture and how you are planning to implement that will help clear most of these.

@Denend I have few questions

1. Can you also write a short architecture comparison on how this differs with EVM model .

2. Who are the stakeholders of the escrow contract — payer, merchant, facilitator? Does the facilitator need party standing on every merchant's synchronizer, or one shared one?

3. If you will use Escrow how does a merchant express "accepts" in the 402 response when the real precondition is "payer has a funded escrow with me"? That changes the accepts semantics meaningfully vs. EVM.

4. I see "stateless verification against signed Canton Coin transfer payloads" + "duplicate settlement protection (equivalent to the settlement cache pattern in the x402 SVM reference implementation"

• I doubt if this works under Canton's privacy . the facilitator can only see contracts where it's a stakeholder. So /verify either skips solvency and becomes a signature echo (useless), or it needs on-ledger visibility that the proposal doesn't grant. Let me know if there's any different architecture which I'm missing

5. How are you planning to handle Replay or Double Spend?

• On EVM the chain burns the nonce on first settle. A facilitator-side "settlement cache" only dedupes at that facilitator — two facilitator instances, or a self-hosted one plus FTP's, settle the same payload twice. Canton command dedup is keyed on submitter + command ID, not on a signature blob the facilitator didn't author.

6. Autonomous AI agent holding a Canton wallet" presupposes external signing keys that produce standalone transfer payloads. Canton's authorization goes through participant nodes and party keys; an agent signing offline and handing a blob to a facilitator is not how CC transfers get authorized today. The PR doesn't say how this gap is bridged.
7. Participant/party topology is denied, not solved. "Configurable Canton node endpoint, party ID" — singular. But payer and merchant are on different participants, possibly different synchronizers. A facilitator with one node config can't span both sides of a CC transfer as a non-stakeholder. Whose participant node? Whose party? The document doesn't answer

From your reply I felt architecture is stateful, pre-funded, on-ledger lifecycle. So if you can create or write a short note on architecture and how you are planning to implement that will help clear most of these.

@srikanth-bitdynamics

1. EVM vs Canton

On EVM the facilitator verifies a stateless signed payment proof against public chain state. On Canton all state is private and authorization is participant-mediated, so our implementation preserves the x402 HTTP negotiation layer while settlement runs through a stateful on-ledger workflow. The verification anchor on Canton is the facilitator's own participant node reading on-ledger contract state rather than a globally visible chain.

2. Escrow stakeholders + party topology

The real precondition is not "attach a signed transfer payload" but "payer has exercised a choice on an on-ledger payment contract where the facilitator is named as observer." At merchant registration the facilitator and merchant co-create a lightweight Daml payment template with the facilitator party as observer, giving it full visibility into payment execution. Party standing is required on one shared synchronizer domain, not on every merchant's synchronizer

3. Accepts semantics

The accepts field signals that the resource is payable via the Canton x402 backend. The payment requirement is a Canton-native authorization state rather than an asset/proof format as on EVM — concretely, that a valid funded payment contract exists on-ledger with the facilitator as observer. x402 explicitly supports multiple networks and facilitators so this backend-specific semantics is within spec.

4. Stateless verification under Canton privacy

/verify is not stateless in the EVM sense. The facilitator is named as observer on the payment execution contract and reads it directly from its own participant node. Stakeholder visibility is established at merchant registration time, not assumed.

5. Replay / double-spend

Replay protection in Canton is contract archival via on-ledger state transitions. A contract is archived on first exercise and any second attempt receives a "contract not found" from the ledger regardless of which facilitator instance submits it. A facilitator-side cache is therefore redundant for correctness.

6. Autonomous agent signing

Canton natively supports external party signing. The agent holds its own submission key registered via a PartyToParticipant topology transaction and the facilitator's node acts as confirming node only, unable to submit on the agent's behalf without an explicit agent signature.

7. Participant topology

The facilitator runs its own participant node connected to the Global Synchronizer. Payer and merchant operate on their own nodes and atomic cross-participant settlement is handled natively by the Global Synchronizer. The facilitator gets visibility into settlement contracts through observer status established at merchant registration, not by spanning both sides of the transaction.

Probably do not want to delete this 😉

"accepts array” ?

Would it be beyond the scope of this proposal to allow any CIP-56 token be used for payment?

Will this work be open sourced, or how will it be maintained to account for Ledger API improvements?

Exciting proposal

resolved

Yes, analogous to ERC-20 support in x402 on EVM - we plan to support any CIP-56 token the same way

Fully open-source. Maintenance for Ledger API updates is on us, and since it's open-source, the community can contribute as well

@Denend I have few questions

1. Can you also write a short architecture comparison on how this differs with EVM model .

2. Who are the stakeholders of the escrow contract — payer, merchant, facilitator? Does the facilitator need party standing on every merchant's synchronizer, or one shared one?

3. If you will use Escrow how does a merchant express "accepts" in the 402 response when the real precondition is "payer has a funded escrow with me"? That changes the accepts semantics meaningfully vs. EVM.

4. I see "stateless verification against signed Canton Coin transfer payloads" + "duplicate settlement protection (equivalent to the settlement cache pattern in the x402 SVM reference implementation"

• I doubt if this works under Canton's privacy . the facilitator can only see contracts where it's a stakeholder. So /verify either skips solvency and becomes a signature echo (useless), or it needs on-ledger visibility that the proposal doesn't grant. Let me know if there's any different architecture which I'm missing

5. How are you planning to handle Replay or Double Spend?

• On EVM the chain burns the nonce on first settle. A facilitator-side "settlement cache" only dedupes at that facilitator — two facilitator instances, or a self-hosted one plus FTP's, settle the same payload twice. Canton command dedup is keyed on submitter + command ID, not on a signature blob the facilitator didn't author.

6. Autonomous AI agent holding a Canton wallet" presupposes external signing keys that produce standalone transfer payloads. Canton's authorization goes through participant nodes and party keys; an agent signing offline and handing a blob to a facilitator is not how CC transfers get authorized today. The PR doesn't say how this gap is bridged.
7. Participant/party topology is denied, not solved. "Configurable Canton node endpoint, party ID" — singular. But payer and merchant are on different participants, possibly different synchronizers. A facilitator with one node config can't span both sides of a CC transfer as a non-stakeholder. Whose participant node? Whose party? The document doesn't answer

From your reply I felt architecture is stateful, pre-funded, on-ledger lifecycle. So if you can create or write a short note on architecture and how you are planning to implement that will help clear most of these.

@srikanth-bitdynamics

1. EVM vs Canton

On EVM the facilitator verifies a stateless signed payment proof against public chain state. On Canton all state is private and authorization is participant-mediated, so our implementation preserves the x402 HTTP negotiation layer while settlement runs through a stateful on-ledger workflow. The verification anchor on Canton is the facilitator's own participant node reading on-ledger contract state rather than a globally visible chain.

2. Escrow stakeholders + party topology

The real precondition is not "attach a signed transfer payload" but "payer has exercised a choice on an on-ledger payment contract where the facilitator is named as observer." At merchant registration the facilitator and merchant co-create a lightweight Daml payment template with the facilitator party as observer, giving it full visibility into payment execution. Party standing is required on one shared synchronizer domain, not on every merchant's synchronizer

3. Accepts semantics

The accepts field signals that the resource is payable via the Canton x402 backend. The payment requirement is a Canton-native authorization state rather than an asset/proof format as on EVM — concretely, that a valid funded payment contract exists on-ledger with the facilitator as observer. x402 explicitly supports multiple networks and facilitators so this backend-specific semantics is within spec.

4. Stateless verification under Canton privacy

/verify is not stateless in the EVM sense. The facilitator is named as observer on the payment execution contract and reads it directly from its own participant node. Stakeholder visibility is established at merchant registration time, not assumed.

5. Replay / double-spend

Replay protection in Canton is contract archival via on-ledger state transitions. A contract is archived on first exercise and any second attempt receives a "contract not found" from the ledger regardless of which facilitator instance submits it. A facilitator-side cache is therefore redundant for correctness.

6. Autonomous agent signing

Canton natively supports external party signing. The agent holds its own submission key registered via a PartyToParticipant topology transaction and the facilitator's node acts as confirming node only, unable to submit on the agent's behalf without an explicit agent signature.

7. Participant topology

The facilitator runs its own participant node connected to the Global Synchronizer. Payer and merchant operate on their own nodes and atomic cross-participant settlement is handled natively by the Global Synchronizer. The facilitator gets visibility into settlement contracts through observer status established at merchant registration, not by spanning both sides of the transaction.

@srikanth-bitdynamics Can you comment on whether the response from @Denend resolves your concerns?

@waynecollier-da yes, all answers were satisfactory. One suggestion: given this deals with financial flows, I'd want to confirm whether an audit is required, and have the detailed architecture reviewed and approved by DA (or someone at Canton) before Milestone 1 work begins post-approval.

@Denend two asks before proceeding:

Add an audit line item to the budget covering the Daml payment templates, the settlement exercise flow and anything else that would needs to be covered in audit.

Until audit lands, explicitly scope this as an unaudited reference implementation with a clear gate preventing mainnet use.

A sequence diagram covering merchant registration → 402 response → payment contract creation → verification → settlement exercise → archival would also help close out the remaining ambiguity around exercise authority and the agent signing flow.

@srikanth-bitdynamics , sequence diagram:

sequenceDiagram
    participant C as Client / Agent
    participant RS as Resource Server
    participant F as Facilitator
    participant L as Canton Ledger

    Note over RS, L: Merchant Registration (one-time)
    RS->>F: register(merchantParty, price)
    F->>L: co-create PaymentContract<br/>(facilitator as observer)

    Note over C, L: Per-request flow
    C->>RS: GET /api/data
    RS-->>C: 402 PAYMENT-REQUIRED<br/>(canton scheme, price, facilitator URL)

    C->>L: exercise PaymentContract.Pay()<br/>(signed with agent's own key)

    C->>F: POST /verify (payment payload)
    F->>L: read contract state (as observer)
    F-->>C: 200 verified

    C->>RS: retry + PAYMENT-SIGNATURE
    RS->>F: POST /settle (payment payload)
    F->>L: exercise Settle() → contract archived
    F-->>RS: settlement confirmed
    RS-->>C: 200 + response body

Can you elaborate what a CC payment payload is? I am Alice. I have a Loop wallet. I access a web resource that returns 402. How is the CC payment request now funnelled through to my BRON wallet such that I pick a UTXO, construct the TX and sign it with my private key? Who then submits the transaction etc?

Party ID of who? Recipient? Payer?

I made the comment already below, but to rephrase what I currently struggle with is:

• How is this x402 protocol going to integrate with the existing wallet infrastructure?
• How will I be able to use my SEND, Bron or Loop wallet for such payments? Who runs what who integrates what? That's not clear to me from skimming through this proposal.

The "party ID" in the facilitator configuration refers to the facilitator's own Canton party - the identity it uses to connect to the Global Synchronizer and be named as observer on payment contracts during merchant registration. It is not the payer's or merchant's party ID

The x402 protocol is designed as a programmatic, agent-first payment layer - this is true on every supported chain, not just Canton. The official x402 docs describe the wallet role as https://docs.x402.org/core-concepts/wallet.

On EVM, the buyer quickstart shows loading a private key from an environment variable:

privateKeyToAccount(process.env.EVM_PRIVATE_KEY)

and wrapping HTTP clients so the SDK handles 402 responses automatically.

The https://github.com/coinbase/x402 describes the client integration as "1 function for the client" via npm packages (@x402/fetch, @x402/axios) - software libraries, not consumer wallet UIs. There is no MetaMask popup or consumer wallet UX on EVM either.

The Canton Client SDK follows the same model: it targets developers and autonomous AI agents that hold a Canton party key and can pay programmatically. Integration with consumer wallets (Loop, BRON, SEND) would require those wallet providers to embed the Canton x402 Client SDK - that is follow-on work outside the scope of this proposal, exactly as it is on EVM today.

Answered it here https://github.com/canton-foundation/canton-dev-fund/pull/78#discussion_r3194950880

Following our discussion in the voting committee, I haven't seen much commercial demand for X402 payments in Canton. That said, if the milestones are stated in a way that completely tie the payment to adoption metrics, e.g. amount of burn driven by this app, I'd be happy to vote "yes." That way, regardless of my opinion on whether this gets adopted, the developer takes the risk, and the upside is completely tied to aligned incentives.

Author changed Milestones based on Adoption so moved this back to Voting for voting team to decide

@Denend Do you have ideas on how you would account for traffic burned using this x402 implementation?

@Denend Do you have ideas on how you would account for traffic burned using this x402 implementation?

@waynecollier-da

The facilitator runs on FTP-validator-1. x402 agents are external parties - per Canton's ExternalPartyAmuletRules, the submitting delegate participant pays sequencer traffic. Facilitator is the delegate, so submission burn for every Pay() and Settle() lands on FTP-validator-1, plus delivery burn as observer on every PaymentContract

Attribution is direct measurement: total_consumed from the Scan API traffic-status endpoint on FTP-validator-1, queryable from any SV node. CC burned is independently visible via MemberTraffic top-up contracts for that participant. Validator-baseline subtraction methodology to be agreed with Foundation before performance milestones unlock

Can you elaborate whether the burn will be associated with a featured app that the grant takers control or not, as this fundamentally changes the economics and incentives of this milestone?

@daravep Yes - the burn and settlement activity will be associated with CanTrustAI Featured App, since that will serve as the primary production integration and reference implementation for the Canton x402 stack

That said, the facilitator, SDK, and middleware are all designed as open ecosystem infrastructure, so the same payment flow and settlement mechanics can be adopted by other Canton applications as well over time

@hythloda @shaul-da the note is added as requested

Hi everyone, this is Colin Schwarz from ChainSafe.

In the spirit of full transparency, I'm leaving this comment to let the community know that ChainSafe has already built an x402 implementation on Canton which facilitates payments for our Daml Autopilot featured app. We are in the process of breaking out the facilitator into a standalone product and will being applying for this product to become a featured app this week.

We think it's great that there will be multiple implementations and are fully in support of infrastructure diversity within the Canton ecosystem. We are commenting to make our intentions known and to keep the ecosystem up to date.

Hi @ColinSchwarz , thanks for the transparency.

FTP already operates production Canton payment infrastructure through CanTrustAI: on-chain settlement, API gateway infrastructure, and per-request payment flows on mainnet.

This directly overlaps with the core x402 use case: machine-to-machine access to paid HTTP resources, including API and AI inference payments.

FTP is also committing to maintain the stack after delivery, including compatibility updates.

We agree that multiple implementations are healthy for the ecosystem.

@Denend Can you fix the merge conflict?

This is a great proposal — x402 for Canton fills a real gap. I've been building complementary infrastructure on the batch payments side: UTXO-optimized multi-recipient transfers using CIP-0056's TransferFactory, plus MCP tooling for AI agent discovery. Code is live at github.com/plagtech/spraay-canton. Would love to explore how batch payment orchestration could work alongside the x402 facilitator layer you're proposing here.

Hi @Denend, targeted design-partner question from #51, not a request to change this approved proposal.

I revised #51 from an indexer/PQS-adjacent proposal into Canton Participant Event Gateway: direct Ledger API ingestion, interface-aware event subscriptions, REST replay/event history, reliable webhooks, delivery audit, and party-scoped auth.

For the x402 Canton flow, would this kind of gateway be useful for settlement/payment lifecycle callbacks, missed-event replay after downtime, or backend notification delivery around facilitator/resource-server workflows?

If you have a quick yes/no, or a concrete requirement that would make this useful/not useful, a comment on #51 would help validate the app-facing scope.

Milestone 1.1: Canton x402 Facilitator

Estimated Delivery: 2026-06-15
Funding: 0,00 CC upon committee acceptance of delivery

Deliverables:

• Canton x402 facilitator live at a public endpoint, with /verify and /settle compliant with the x402 facilitator spec.
• Open-source facilitator repository with deployment documentation.
• Compatibility matrix: tested against current Canton ledger API version and documented supported Canton Coin denominations.
• Canton x402 payment scheme specification (specs/schemes/exact/scheme_exact_canton.md) covering Canton's payment model and transaction semantics, payload structure, signing and verification flow, and how Canton maps to the x402 scheme/network abstraction — submitted as part of an upstream PR to the x402 repository.
• General submission to the x402 ecosystem directory for inclusion as a supported Canton network facilitator.

Acceptance criteria:

• /verify and /settle endpoints behave per the x402 facilitator spec under normal and error conditions.
• A committee member or delegate can send a test payment payload to the live facilitator and receive a valid verification and settlement response.

Milestone 1.2: Canton x402 Client SDK + Resource Server Middleware

Estimated Delivery: 2026-07-30
Funding: 0,00 CC upon committee acceptance of delivery

Deliverables:

• Canton x402 client SDK published to a public package registry.
• Canton x402 resource server middleware published.
• Developer tutorial.
• End-to-end integration test.

Milestone 1.3: CanTrustAI Reference Implementation + Ecosystem Close-out

Estimated Delivery: 2026-08-15
Funding: 150,000 CC upon committee acceptance of delivery

Deliverables:

• CanTrustAI migrated to use the Canton x402 facilitator and middleware.
• Public reference guide.
• Mainnet transaction demonstrating end-to-end x402 payment flow.
• Maintenance playbook.

Milestone 2 (Performance Based)

850 MB of total network traffic burned on the Canton Network. At current network conditions, this is estimated to correspond to approximately 380,000 $CC burned, though the actual amount of $CC required may vary over time. Traffic counted toward this milestone must originate from real usage by users/companies not affiliated with the FTP team.

Milestone 3 (Performance Based)

1.85 GB of total network traffic burned on the Canton Network. At current network conditions, this is estimated to correspond to approximately 820,000 $CC burned, though the actual amount of $CC required may vary over time. Traffic counted toward this milestone must originate from real usage by users/companies not affiliated with the FTP team.

Milestone 4 (Performance Based)

3.1 GB of total network traffic burned on the Canton Network. At current network conditions, this is estimated to correspond to approximately 1,370,000 $CC burned, though the actual amount of $CC required may vary over time. Traffic counted toward this milestone must originate from real usage by users/companies not affiliated with the FTP team.