Documentation

cBNB — Integration

cBNB is a tokenized BNB on the Canton Network, issued by Nuxaris and backed one-for-one by BNB locked on BNB Chain. It is registered through the Digital Asset Registry and implements the Canton Network Token Standard, so any wallet, exchange or application that already handles a registry asset handles cBNB with no custom code.

Figures in this document were read from the registry on 3 October 2026.

Token identity

Every field below is readable from the public registry. Nothing here needs to be taken on trust.

NamecBNB
SymbolcBNB
Instrument IDcBNB
Decimals10
NetworkCanton Network MainNet
Registrar / admin party cbnb-admin::122065645666a14e30513626b92fd348b76fe0430557d08f68ac3e2beb37b407b3c9
Synchronizer global-domain::1220b1431ef217342db44d516bb9befde802be7d8899637d290895fa58880f19accc
Utility backendhttps://api.utilities.digitalasset.com
PausedNo

The registrar party is also the instrument admin and the only party able to mint or burn cBNB. It is hosted on the Nuxaris validator.

Registry and APIs

cBNB is served by the standard registry metadata API. Replace {admin} with the registrar party above.

# Registry capabilities
GET https://api.utilities.digitalasset.com/api/token-standard/v0/registrars/{admin}/registry/metadata/v1/info

# All instruments issued by this registrar
GET .../registry/metadata/v1/instruments

# cBNB, including live total supply
GET .../registry/metadata/v1/instruments/cBNB

The instrument response carries totalSupply with a totalSupplyAsOf timestamp. That is the figure to display to users and to reconcile against.

The registry advertises ten supported APIs:

APIVersionUse
splice-api-token-metadata-v11Instrument identity and supply
splice-api-token-holding-v1 / -v21Reading balances
splice-api-token-transfer-instruction-v1 / -v21Sending cBNB
splice-api-token-allocation-v1 / -v21Locking for settlement
splice-api-token-allocation-instruction-v1 / -v21Creating allocations
splice-api-token-allocation-request-v11Responding to settlement requests

Holding and receiving

cBNB balances are Utility.Registry.Holding.V0.Holding contracts, exposed through the standard holding interfaces. Query them from the ledger API with an interface filter rather than by template, so your integration keeps working across registry upgrades.

No permission is required to hold cBNB

The instrument is configured with empty issuer requirements and empty holder requirements. No credential, allowlist or onboarding step gates receiving, holding or sending cBNB. A party simply needs to exist.

Transfer preapprovals

A receiving party can publish a transfer preapproval so that incoming cBNB settles without a second step on its side. A preapproval can cover every instrument from this registrar or be restricted to one, and the receiver can withdraw it at any time.

Transfers

Use the transfer instruction API, v1 or v2. The sender asks the registry for a transfer factory and its choice context, then exercises that factory on the ledger with the disclosed contracts the registry returned. The registry hands back the contracts your submission needs, so you do not track registry state yourself.

Amounts carry ten decimals. Round down and never pad: a value with more than ten decimal places is rejected by the ledger, not silently truncated.

Atomic settlement

cBNB supports allocations in both v1 and v2, so it can take part in delivery-versus-payment settlement against another asset, including Canton Coin. Each side locks its leg through the allocation factory, then an executor settles every leg in a single transaction: either all legs move or none do.

An allocation that is never settled is not stuck. It carries allocateBefore and settleBefore deadlines, it can be cancelled by its owner, and it expires on its own, returning the funds.

Issuance and redemption

Issuance. Minting is controlled by the registrar and follows a request-and-accept flow. New cBNB is issued to the issuance party, and only after the matching BNB deposit is final on BNB Chain.

Redemption. cBNB is returned to the redemption party, burned by the registrar, and the corresponding BNB is released from the vault. The redemption party publishes a standing preapproval, so a holder can send to it directly.

RoleParty
Registrar, provider, instrument admincbnb-admin::1220656456…
Issuancecbnb-issuer::1220656456…
Redemptioncbnb-redeem::1220656456…

All three share the namespace of the Nuxaris validator party, shown in full in the identity table. No party other than the registrar can create or destroy cBNB, whatever rights it holds elsewhere on the ledger.

Backing

Each cBNB in circulation is matched by one BNB locked in a vault contract on BNB Chain. Deposits are credited only once final on BNB Chain, so a reorganised block cannot produce cBNB without backing.

Security model

  • Authenticated ledger access. The Nuxaris ledger API accepts only signed tokens from our identity provider. Unauthenticated requests are rejected.
  • Network isolation. Ledger and validator endpoints are reachable only from allowlisted addresses.
  • Separated identities. The bridge, the relayer and operations each use a distinct machine identity. The relayer that issues cBNB holds rights on the three cBNB parties and nothing else, with no administrative rights on the participant.
  • Revocation. Issuance rights can be withdrawn on the ledger and take effect on the next request. That is the control used to stop issuance, rather than rotating a secret, since tokens already issued stay valid until they expire.

Status

cBNB is live on MainNet, in early access. This table is the state of the asset, not a roadmap.

ItemStateDetail
Registrar onboardedLiveApproved by Digital Asset, 24 September 2026
Instrument registeredLivecBNB, published in the registry
Transfers and allocationsLiveTen token standard APIs advertised
Supply in circulationLiveFirst 0.1 cBNB minted, 29 September 2026
Third-party auditCompletedCompleted by Nethermind, 8 October 2026

Nethermind Security reviewed the router and vault contracts that hold the BNB on BNB Chain. The review found no critical, high or medium issues: one low and one informational finding, both acknowledged. You can read the full report here: Nethermind audit report (PDF, 207 KB).

Integrator checklist

What an exchange or wallet needs to confirm before listing cBNB.

  • The registry packages are vetted on the participant hosting your parties.
  • Balances are read through the holding interfaces, not through a hardcoded template identifier.
  • Amounts are handled at ten decimals, rounded down, with no padding.
  • Deposits are credited against the instrument ID cBNB and the registrar party, never against the symbol alone.
  • The first transfer in each direction has been exercised at the smallest meaningful amount (one unit = 0.0000000001 cBNB) before any real volume.
  • Supply shown to users comes from the registry endpoint, with its totalSupplyAsOf timestamp.
  • Redemption sends to the redemption party, and your system expects the burn to follow rather than an immediate return.

Brand assets

Logos for listings, articles and partner pages, in a single download. Every file is a PNG with a transparent background, except the two Nuxaris marks on dark.

cBNB press kit 8 PNG files · ZIP · 3.1 MB cBNBIcon, 3D coin, logo for light backgrounds, logo for dark backgrounds NuxarisMark, cropped mark, mark with glow, mark on dark Download the kit

cBNB colours

  • Lime#F3FF97
  • Charcoal#222222

Contact

For integration support or incident reporting, contact the Nuxaris validator operator. Include the instrument ID and the party identifiers involved; for a transfer, include the update identifier, which is the only reference that resolves unambiguously on the ledger.

Nuxaris · cBNB on Canton Network MainNet · Figures in this document were read from the registry on 3 October 2026.

Contact the team

Tell us what you need and we will come back to you by email.