Concept
Ownership & Authority Model
CenterChain uses three distinct authority layers, and confusing them is the most common integration mistake. Every privileged message compares the signer against a stored address -- no authz grants, no role engines, no ambiguity.
The three layers of authority
Denom Admin
Held by
The account that created a tokenfactory denom
Governs
- Minting / burning for that denom
- Restriction and delegates
- Blacklist management
- Swap authorization grants
Class Issuer
Held by
The account whose address prefixes an NFT class id ({issuer}/{product_ref})
Governs
- Minting / burning NFTs in that class
- Metadata (unless immutable)
- Market configuration (royalty, accepted denoms, enable/disable)
Pool Owner
Held by
The account that created a liquidity pool
Governs
- Pause / resume / close the pool
- Swap fee configuration
- Ownership transfer
- Emission schedules
Above all three: Module Authority (gov)
The gov module account is the only signer that can:
- Change module parameters
- Move a class issuer to another address
- Register an IBC denom
- Pause a pool in an emergency
- Close a pool
- 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.
Why this matters for you
No hidden permissions
Every privilege is an explicit address comparison. Audit by reading the code -- no hidden role engine.
Clear delegation
Delegation is explicit (MsgAddDelegate) and revocable. You always know who can do what.
Predictable boundaries
A denom admin cannot mint NFTs. A class issuer cannot pause a pool. Authority stays in its lane.
Read the full specification
The full authority model with message-by-message breakdown, delegation mechanics, and migration paths.