Canton reference

This page lists the Canton-specific API fields, identifiers, and errors in Ripple Custody. For task procedures, see Set up Canton accounts with the API and Send and receive Canton assets with the API.

v0_CreateLedger takes the following parameters for a Canton ledger. You must provide every field.

v0_CreateLedger also requires id, alias, and customProperties.

The daRegistryOperator is the same on all three networks:

DigitalAsset-UtilityOperator::12202679f2bbe57d8cba9ef3cee847ac8239df0877105ab1f01a77d47477fdce1204

Get the synchronizerId and operatorId from your validator operator. DevNet resets regularly, so check the DevNet values after each reset.

In v0_ValidateTickers, a Canton ticker's ledgerDetails has type set to Canton and a properties object of one of the following types.

Set decimals to 10 for every Canton ticker.

For a Canton transaction order, parameters has the following fields.

Canton orders don't take a feeStrategy, and they don't support maximumFee. Ripple Custody rejects a Canton order that sets maximumFee.

A dry run of a Canton order returns an estimate with type set to Canton and a fee field. The fee is always 0, because your validator operator party pays network fees as traffic.

For a Canton transaction, ledgerTransactionData.ledgerData has type set to Canton and can contain the following fields. Ripple Custody fills them for two-step transfer offers.

The ledgerTransactionId of a Canton transaction is the Canton update ID. Ripple Custody sets it after the network sequences the transaction.

A Canton account's party key is an Ed25519 key that Ripple Custody derives in your vault. The vault derives it from the account's ED25519_CUSTODY_1 key on a reserved derivation path, which only the vault's Canton support can use. You can't request a key on this path.

In the keys array of the account's provider details, the party key has the key ID ED25519_CANTON_PARTY_1 and the type VaultReserved:

{
  "id": "ED25519_CANTON_PARTY_1",
  "publicKey": {
    "type": "PublicKey",
    "value": "..."
  },
  "type": "VaultReserved"
}

A VaultReserved key has a public key only, never an extended public key. Accounts without a Canton ledger don't have VaultReserved keys. If your integration reads the keys array, make sure it accepts this type before you create Canton accounts.

The party key appears in the keys array when you first add your Canton ledger to the account, with a v0_CreateAccount intent that includes the Canton ledger ID in ledgerIds, or with a v0_AddAccountLedgers intent.

The party key doesn't need a separate backup. The vault re-derives it from the account's ED25519_CUSTODY_1 key whenever it needs it, so backing up the vault covers it. After a restore, the key reappears in the keys array when the notary replays the request that first added the Canton ledger to the account.

c::<fingerprint>

The fingerprint identifies the account's Ed25519 public key, so you can reproduce the party ID from the public key alone. For more information, see Parties and party IDs.

To confirm on-ledger state independently of Ripple Custody, look up the party in a Canton block explorer, such as Cantonscan for MainNet or CCView for DevNet.