Docs · Network
Assets
Issued tokens with a fixed or capped supply, and the absences that are the design.
Two supply models, and only two
| Model | What it means |
|---|---|
| FIXED | The entire supply exists at creation. There is no mint authority — not a dormant one, not a disabled one. None. |
| CAPPED_MINTABLE | A mint authority may mint up to a maximum fixed at creation. The cap cannot be raised afterwards. |
A FIXED asset is never shown as carrying a mint authority, because it does not have one. An interface that displayed a greyed-out mint button would be describing a capability that does not exist.
What assets deliberately cannot do
- No generic administrator. There is no role that can do anything to anybody's asset.
- No freeze. Nobody can immobilise a holder's balance.
- No blacklist. There is no per-account denial list.
- No burn authority. A holder burns from its own balance; nobody can burn somebody else's.
- No transfer policy. A transfer is authorized by owning the sending account, plus a gate the issuer opted into.
- No authority transfer. A mint authority cannot be handed to somebody else.
- No mutable metadata. Name, symbol and decimals are set once, at creation.
- No clawback, seizure, forced transfer, transfer hooks or callbacks.
These are not missing features and they are not on a roadmap. They are not part of the v1 protocol model: there is no message that expresses any of them, so no interface can offer one and no configuration can enable one.
Each is a power that, once it exists, somebody will be asked to use — and an issuer who can freeze can be compelled to freeze. Freeze in particular carries legal and policy consequences that outlive the code, so it would arrive through its own decision and its own threat model, never as a setting.
NOT AVAILABLE Freeze or blacklist a holder
Not part of the v1 protocol model. `x/assets` has no freeze, account freeze, blacklist, clawback, seizure or forced transfer, and no message that could express one. Freeze carries legal and policy consequences that outlive the code, so it would need its own decision gate and its own threat model rather than arriving as a setting.
NOT AVAILABLE Administer somebody else's asset
Not part of the v1 protocol model. There is no generic administrator and no owner-of-everything: creating an asset confers no standing authority, mint authority is scoped to one asset, and burning is something a holder does to its own balance. A burn authority over another account would be seizure under another name.
NOT AVAILABLE Transfer or rotate an asset's mint authority
Not part of the v1 protocol model. Mint authority is fixed at creation and there is no message that rotates, delegates or replaces it — which is what makes it readable: whoever holds it held it from the beginning. Metadata is immutable for the same reason.
Identity
A symbol is not an identity. Two assets can share one. The asset id is authoritative, and any interface that let a symbol act as an identifier would let one asset impersonate another.
Native BGR
The network's own denomination is udevbgr, displayed as DEVBGR. It is devnet branding: the mainnet name and ticker are not decided. Native BGR is not a Trust-gated asset and never appears in gating interfaces.
Status
AVAILABLE Browse assets, holders and transfers
Where: Scan → Assets
AVAILABLE Issue an asset from the Console — /projects/[projectId]/assets/new
Where: Console → Assets → Create an asset
First: An organization signing key, provisioned on the Assets page, and a funded chain account to pay the fee.
Requires: ADMIN