Splice Daml APIs

The APIs below are published by Splice to aid decoupling different Canton Network applications. Consider using them to decouple your code from the upgrading cycles of your dependencies, when building Daml code that interacts with workflows of other apps in the Canton Network.

These APIs are not mandatory to use. Feel free to build your own Daml APIs, potentially using the APIs below as inspiration.

Canton Network Token Standard APIs (CIP-0056)

• See the text of the CIP-0056 for an overview of the APIs that are part of the Canton Network Token Standard.

• See the README in its source-code for background on how to use the APIs.

• See the reference docs below for the Daml interfaces that are part of the Canton Network Token Standard; or read the source code.

  • splice-api-token-metadata-v1 docs
  • splice-api-token-holding-v1 docs
  • splice-api-token-transfer-instruction-v1 docs
  • splice-api-token-allocation-request-v1 docs
  • splice-api-token-allocation-instruction-v1 docs
  • splice-api-token-allocation-v1 docs

Featured App Activity Markers API (CIP-0047)

• See the text of the CIP-0047 for its background on its design and its specification.

• See the reference docs below for the Daml interfaces that are part of the Featured App Activity Markers API; or read the source code.

  • splice-api-featured-app-v1 docs

Additional Splice Daml APIs

The app provider of an asset registry is not necessarily the same as the party controlling the minting and burning of tokens. A typical example are tokens that are bridged from another network. The following API targets that use-case; and thus enables to decouple the upgrade cycles of an asset registry from the ones of the bridging app.

• splice-api-token-burn-mint-v1 docs

The API is built in a similar style as the token standard APIs, but is not part of the token standard. In particular, implementors of the token standard are not required to implement this API.

Nevertheless the API definition is guaranteed to be stable, and can be used by for the purpose explained above. If there were changes to the API, then they would be published as a new version of the API using a fresh package name, so that both the old and the new version can be used in parallel.

Comments