CIP-56 Tokens in Canton Applications — Practical USDCx Integration Notes
Hi everyone,
I wanted to share a practical article we published after working through a real CIP-0056 / USDCx integration case in Rapid Wallet:
https://medium.com/@rapidchainio/using-cip-56-tokens-in-canton-applications-91584eb651e7
This is not meant as a product announcement, but as a technical contribution to the Canton builder community.
While integrating USDCx into Rapid Wallet, we ran into several issues that I believe other application and wallet developers may also face:
- missing Utility Registry DAR packages,
- the difference between Amulet / CC flows and Utility Registry token flows,
- why a visible token balance is not the same as full token support,
- why
TransferInstruction_Acceptcannot be called with empty context, - how
choiceContextDataanddisclosedContractsfit into CIP-0056 token workflows, - and how validator / nginx routing can affect token-standard integrations.
The main lesson for us was that CIP-0056 support is not only about displaying token balances. A production wallet or application also needs to understand registry APIs, choice-context, disclosed contracts, concrete token implementations, and Canton’s privacy model.
We documented the full Rapid Wallet / USDCx case study so other teams can avoid the same debugging path and hopefully build faster on Canton.
Feedback, corrections, or additional implementation notes are very welcome. If this helps even a few builders integrate CIP-0056 tokens more easily, it will have achieved its purpose.
Best,
Murat İnceer
Founder & CEO, Rapid Chain- toggle quoted message Show quoted textThanks Murat, for sharing this detailed and thoughtful write-up. It is a technically accurate and valuable guide for other wallet builders. Here are a few points that I've noticed while reading the quoted sections in your text.> Keep the CC / Amulet flow and the USDCx / Utility Registry flow separate unless your validator version explicitly supports a unified generic path.This sounds like you already have a native integration with CC working. Probably built on `TransferCommand`? Note that in contrast to ETH, CC is not built into Canton's protocol layer. It is special only because SV nodes allow purchasing traffic with CC and because rewards are minted as CC.CC fully implements the CIP-0056 APIs. You should be able to use the exact same code path as you use for USDx with the one small change that you query one of the SV's Scan endpoints listed here: https://canton.foundation/sv-network-status-2/For example:❯ curl https://scan.sv-1.dev.global.canton.network.digitalasset.com/registry/metadata/v1/instruments
{"instruments":[{"id":"Amulet","name":"Canton Coin","symbol":"CC","totalSupply":"84218066227431072013672.6516898554","totalSupplyAsOf":"2026-05-19T15:00:00Z","decimals":10,"supportedApis":{"splice-api-token-metadata-v1":1,"splice-api-token-allocation-v1":1,"splice-api-token-transfer-instruction-v1":1,"splice-api-token-holding-v1":1,"splice-api-token-allocation-instruction-v1":1}}],"nextPageToken":null}⏎Side note: this upcoming CIP on the CN Credential standard will provide a streamlined resolution of admin party-ids to off-ledger registry API endpoints: https://github.com/canton-foundation/cips/pull/204/changes#diff-1315b53b163fa309985eb362a1db8690a47f5f4ce57e7a34a259950277433208R23> especially around unknown counterparties at order placement time, partial fills, and how allocations should be modeled.Consider looking into the support for committed and iterated settlement that's coming with the CIP-112 (aka the V2 token standard). I'd be keen to hear your feedback, as to whether the V2 allocation API works for your usecase. See this description by @Bernhard Elsner for a primer: https://lists.sync.global/g/cip-discuss/message/743Kind regards,SimonOn Tue, May 19, 2026 at 4:44 PM Murat Inceer via lists.sync.global <murat.inceer=rapidchain.io@...> wrote:Hi everyone,
I wanted to share a practical article we published after working through a real CIP-0056 / USDCx integration case in Rapid Wallet:
https://medium.com/@rapidchainio/using-cip-56-tokens-in-canton-applications-91584eb651e7
This is not meant as a product announcement, but as a technical contribution to the Canton builder community.
While integrating USDCx into Rapid Wallet, we ran into several issues that I believe other application and wallet developers may also face:
- missing Utility Registry DAR packages,
- the difference between Amulet / CC flows and Utility Registry token flows,
- why a visible token balance is not the same as full token support,
- why
TransferInstruction_Acceptcannot be called with empty context, - how
choiceContextDataanddisclosedContractsfit into CIP-0056 token workflows, - and how validator / nginx routing can affect token-standard integrations.
The main lesson for us was that CIP-0056 support is not only about displaying token balances. A production wallet or application also needs to understand registry APIs, choice-context, disclosed contracts, concrete token implementations, and Canton’s privacy model.
We documented the full Rapid Wallet / USDCx case study so other teams can avoid the same debugging path and hopefully build faster on Canton.
Feedback, corrections, or additional implementation notes are very welcome. If this helps even a few builders integrate CIP-0056 tokens more easily, it will have achieved its purpose.
Best,
Murat İnceer
Founder & CEO, Rapid Chain--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. Hi Murat,
There is one distinction missing in the article that may be important when developing a wallet — namely, handling transfer preapproval. The presence of a preapproval for the transfer receiver determines whether the tokens are credited to their account immediately, or whether they must manually confirm the receipt.
For CC, if the receiver has a transfer preapproval, the Registry API returns an additional value in the choice context namedtransfer-preapproval, containing the ContractId of the corresponding contract.
For Utility tokens, the returned choice context is the same regardless of whether a preapproval exists. However, different values are returned in thefactoryIdfield. If a preapproval exists, that value is returned, meaningTransferFactory_Transfershould be called on theTransferPreapprovalcontracts. If no preapproval exists, the default factory is returned instead.
Best regards,
SergeiHi Simon, hi Sergei,
Thank you both for the valuable technical feedback. I really appreciate it.
Simon — your point about CC / Amulet fully implementing the CIP-0056 APIs is especially important. In the article I separated the CC / Amulet and USDCx / Utility Registry paths because that was the practical state of our Rapid Wallet implementation during the debugging process. But your note makes the broader direction much clearer: CC is not protocol-native in the same way ETH is on Ethereum, and it should be possible to move toward a more unified CIP-0056 code path for both CC and Utility Registry tokens, with the main difference being which registry / Scan endpoint is queried.
The upcoming CN Credential standard for resolving admin party IDs to off-ledger registry API endpoints also looks very relevant. That would make wallet and application integrations much cleaner, especially for teams supporting multiple CIP-0056 assets.
Your note about CIP-0112 / the V2 token standard is also very helpful for our DEX work. The questions around unknown counterparties, partial fills, committed settlement, and iterated settlement are exactly the areas we are now thinking through for Rapid DEX. Rapid Wallet now has working multi-asset CC / USDCx flows, and Rapid Trade is currently in testing, so this feedback is very timely for us. I will review the CIP-0112 material and would be happy to share feedback from the perspective of a CLOB / DEX implementation.
Sergei — thank you as well for pointing out the missing transfer preapproval distinction. This is an important wallet-level detail that I should add to the article.
As I understand it:
- For CC, if the receiver has a transfer preapproval, the Registry API returns an additional
transfer-preapprovalvalue in the choice context, containing the ContractId of the corresponding preapproval contract. - For Utility tokens, the choice context itself does not change in the same way, but the returned
factoryIddiffers depending on whether a preapproval exists. - If a preapproval exists,
TransferFactory_Transfershould be called on theTransferPreapprovalcontract. - If no preapproval exists, the default factory is used and the receiver may need to manually accept the transfer.
This distinction is very useful for wallet builders, because it explains why some token transfers can be credited immediately while others appear as pending incoming transfers that require user confirmation.
I will update the article with a “Community feedback / implementation notes” section and credit both of you by name for these points. These learnings are directly feeding back into Rapid Wallet and the Rapid Trade test work, so I really appreciate the guidance.
Thanks again — this is exactly the kind of feedback that makes the article more useful for the Canton builder community.
Best,
Murat- For CC, if the receiver has a transfer preapproval, the Registry API returns an additional
