Understanding how to discover and interact with existing Canton platform/token contracts from an application

Hi everyone,

I’m currently exploring Canton and trying to understand how developers interact with the existing platform and token contracts.

I have a few questions about the practical development workflow:

1. How can we see what functionality an existing platform/token contract provides?

For example, how can we inspect the available templates, interfaces, choices, parameters, and return values? Is there something similar to an ABI in Ethereum?

1. Once we know the available choices, what is the recommended way to call them from an application?

For example, what would the typical flow look like:

Application → Canton API → Contract Choice

Are there any official examples showing this?

1. Where can we find the API/interface documentation for the existing platform contracts? Is the Daml source code the main reference, or is there generated documentation available?

2. Coming from Ethereum, I’m also trying to understand the equivalent concept of token standards.

Ethereum has standards such as ERC-20, ERC-721 and ERC-3643 with defined interfaces and functions. What is the closest equivalent approach in Canton? Should we think in terms of Daml interfaces, templates and choices, or are there specific Canton token standards that provide a similar abstraction?

1. Are there any official sample projects showing how to build an application using these existing contracts without implementing the underlying contracts from scratch?

I’m mainly trying to understand how a developer discovers the available functionality and then integrates it into an application.

Thanks!

Hi! You can use existing Canton contracts without implementing them yourself. Here’s how the pieces compare with Ethereum.

1. Is there something like an ABI?
Yes, the closest equivalent is the contract’s typed Daml definitions, distributed in a package called a DAR.
A template defines a contract type, an interface defines a shared API, and a choice is an operation you can call. Choices specify their arguments and return types.
Start with the provider’s documentation or DAR. You can generate JavaScript/TypeScript bindings from that DAR, similar to generating typed Ethereum bindings from an ABI. See official code generation documentation.
2. How does an application call a choice?
The basic flow is:
Application → participant node's Ledger API → exercise a contract choice
You identify the contract, specify its template, choice name and arguments, and submit with the required party authorization.
For standard token transfers, there is an additional step. You should ask the token registry’s HTTP API for the transfer factory and supporting contract data, then submit the choice through the Ledger API. With externally controlled keys, the flow includes preparing, signing and executing the transaction.
Unlike Ethereum’s public state, contract discovery is limited by your party’s visibility. You query contracts available to your party, rather than browse everyone’s holdings. The official integration guide explains these flows.
3. Must I read the source code?
No. Published reference documentation is available for Splice’s platform contracts.
For a concrete example, the TransferInstruction reference lists interfaces, choices, parameters, return types and who can call each choice.
The Daml reference describes the contract API. OpenAPI documentation describes the HTTP endpoints. For another provider’s custom contracts, you should use that provider’s documentation and package version.
4. What corresponds to ERC token standards?
Canton has a Canton Network Token Standard, introduced by CIP-0056, using shared Daml interfaces and supporting HTTP APIs.
Rough Ethereum comparisons:
EthereumCanton Token StandardbalanceOf()Read the owner’s token holdingstransfer()Initiate a transfer through the transfer interfaceapprove() / transferFrom() for settlementReserve assets for a specific settlement using allocations
Allocations are not unrestricted ERC-20 allowances. The standard supports common token workflows while allowing issuers to retain their own rules. See CIP-0056’s Ethereum comparison.
Current documentation also covers V2, defined by CIP-0112. Use the version supported by your token registry. Version references.
5. Are there sample projects?

• Official reference code: Splice Token Standard CLI. Demonstrates reading holdings, initiating transfers and accepting transfers using existing token contracts. The documentation labels it experimental.
• Official SDK starting point: Wallet SDK quickstart, with links to integration guides.
• Our unofficial learning example: LimeChain Canton Demo. Shows a frontend/backend application, authentication and Ledger API choice calls. It uses custom demo contracts, so it illustrates the integration mechanics rather than integration with existing standard tokens.

Hey @anskp! I see most of your questions were answered, so let me add my two cents on what I would recommend you read:

• Canton for Ethereum Developers and the Concept Translation Tables are written for your exact starting point.
• cn-quickstart is a good match to what you describe. It’s a full-stack reference app: Daml, a Java/Spring backend, a React frontend, and LocalNet running a local Splice network with Canton Coin. It’s not updated to the latest Canton component versions, but you should still find it useful for learning the structure and components with a clear example.

Hope it is helpful!