CIP-0059: Add Woodside AI as an SV of Weight 10

1. #1DrAmandaLMartin18-05-2026source ↗
   Hi Maranda,

   I think we are saying the same thing only you can express it better than myself.  The ‘gap’ that needs the work is in the rules and conditions that need to be applied to the transaction - which varies by industry, jurisdiction, regulatory bodies, point in time and so on.  

   The use of DAML is its unwavering insistence on enforcing the rules it is provided with.

   Look forward to seeing these products evolve.

   Daryn

   
   

   
   
2. #2Chris Zuehlke19-05-2026source ↗

   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_Accept cannot be called with empty context,
   • how choiceContextData and disclosedContracts fit 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

3. #3Wayne Collier19-05-2026source ↗
   Thanks 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/743 

   
   

   Kind regards,

   Simon
4. #4James Lang20-05-2026source ↗

   Hi 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-preapproval value 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 factoryId differs depending on whether a preapproval exists.
   • If a preapproval exists, TransferFactory_Transfer should be called on the TransferPreapproval contract.
   • 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

5. #5Wayne Collier21-05-2026source ↗

   Hi everyone,

   I recently prepared a detailed technical guide for setting up and operating a Canton Network Validator on version 0.6.2 using Docker Compose.

   The guide is based on real validator setup and troubleshooting experience, and it focuses not only on the basic installation steps, but also on the operational issues that node operators may encounter during Mainnet onboarding and catch-up.

   It covers topics such as:

   • Docker Compose validator setup

   • Sponsor SV, Scan URL, onboarding secret, party hint, and participant ID

   • JVM heap and Linux OOM Killer issues

   • Swap and memory tuning

   • Docker network and participant hostname problems

   • participant:5002 connection refused

   • 503 → 404 → 200 healthcheck lifecycle

   • PostgreSQL catch-up monitoring queries

   • Validator and participant database inspection

   • Local UI access through SSH tunnel / localhost

   • When to use or avoid OIDC authentication

   • Common troubleshooting patterns and fixes

   I hope this can be useful for other validator operators and builders who are setting up Canton infrastructure or debugging similar issues.

   Article link:
   https://medium.com/@rapidchainio/canton-network-mainnet-validator-0-6-2-4896a0854037

   Feedback, corrections, and additional operational tips are very welcome.

   Best,
   Murat