Concepts overview
These pages explain the model that the five CenterChain modules implement. The modules themselves are documented in Modules; this section covers the ideas that cut across more than one of them.
The scope of the chain
CenterChain holds token and NFT state and the rules that govern moving it. It does not model what an asset represents, and it does not model the legal or commercial arrangement behind one. The chain's job ends at: who holds what, who may move it, and what happens when they do.
An on-chain token is a representation, not a claim that the chain can enforce. What backs it, and who owes what, lives outside the chain.
The three layers of authority
The modules use three different authorities, and confusing them is the most common integration mistake.
| Layer | Held by | Governs |
|---|---|---|
| Denom admin | The account that created a tokenfactory denom | Minting, burning its own balance, restriction, delegates, blacklist for that denom |
| Class issuer | The account whose address prefixes an NFT class id | Minting, burning its own tokens, metadata, market configuration for that class |
| Pool owner | The account that created a liquidity pool | Pausing, fees, ownership, emission schedules for that pool |
Above all three sits the module authority, which is the gov module
account. It is the only signer that can change module params, move a class
issuer, register an IBC denom, pause a pool in an emergency, close a pool, or
recover a pool's IBC-denom coins.
None of these are authz grants. Every privileged message compares the signer
against a stored address, and no CenterChain module calls the authz keeper.
The decision engine
A send is decided in one place. tokenfactory.CanSendTokens is consulted for
bank sends, NFT sends, and swap settlement alike, and it evaluates in a fixed
order: blacklist first, then the restricted-denom rule. See
Transfers and compliance.
This is the single most important thing to understand about behaviour: there is no second, weaker path.
The other cross-cutting ideas
| Page | Covers |
|---|---|
| Glossary | Every term used across these docs |
| Ownership and authority | The three authority layers, and what each can do |
| Transfers and compliance | Blacklist, restriction, the send order, and the ante handler |
| Two-phase execution | Why an authorized move is an authorization plus a settlement, and the swap, pull, burn, mint, and send kinds |
| Claim permits | The single-transaction signature contract for mints, sends, NFT mints, NFT sends, and revocation |
| Holder asset protection | Why no role can burn or move a holder's asset without the holder's signature |
| Security and governance | Capabilities, invariants, alarms, and the limits that bound state |
Where the modules fit
| Module | Concept it implements |
|---|---|
| Token factory | Ownership and authority, transfers and compliance, two-phase execution, claim permits |
| Liquidity | Pool ownership, fees, and the swap fee split |
| NFT | Class issuer, metadata immutability, escrow |
| NFT market | Class-level secondary trading policy |
| Income | Streams, claimables, and the solvency invariant |
Accuracy
Everything on these pages is written from the code. Where the code does not do
something a reader might expect, the page says so rather than describing the
behaviour that was intended. Notable examples: there is no message that pays
out cumulative LP fees, there is no period model for NFT claimables,
MsgSetNFTMetadata emits no event, and since
v1.2 an authorization reserves no funds and locks no NFT.