Token identity
Every field below is readable from the public registry. Nothing here needs to be taken on trust.
| Name | cBNB |
|---|---|
| Symbol | cBNB |
| Instrument ID | cBNB |
| Decimals | 10 |
| Network | Canton Network MainNet |
| Registrar / admin party | cbnb-admin::122065645666a14e30513626b92fd348b76fe0430557d08f68ac3e2beb37b407b3c9 |
| Synchronizer | global-domain::1220b1431ef217342db44d516bb9befde802be7d8899637d290895fa58880f19accc |
| Utility backend | https://api.utilities.digitalasset.com |
| Paused | No |
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:
| API | Version | Use |
|---|---|---|
splice-api-token-metadata-v1 | 1 | Instrument identity and supply |
splice-api-token-holding-v1 / -v2 | 1 | Reading balances |
splice-api-token-transfer-instruction-v1 / -v2 | 1 | Sending cBNB |
splice-api-token-allocation-v1 / -v2 | 1 | Locking for settlement |
splice-api-token-allocation-instruction-v1 / -v2 | 1 | Creating allocations |
splice-api-token-allocation-request-v1 | 1 | Responding 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.
| Role | Party |
|---|---|
| Registrar, provider, instrument admin | cbnb-admin::1220656456… |
| Issuance | cbnb-issuer::1220656456… |
| Redemption | cbnb-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.
| Item | State | Detail |
|---|---|---|
| Registrar onboarded | Live | Approved by Digital Asset, 24 September 2026 |
| Instrument registered | Live | cBNB, published in the registry |
| Transfers and allocations | Live | Ten token standard APIs advertised |
| Supply in circulation | Live | First 0.1 cBNB minted, 29 September 2026 |
| Third-party audit | Completed | Completed 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
cBNBand 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
totalSupplyAsOftimestamp. - 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 kitcBNB 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.