Introduction
CenterChain is a Cosmos SDK application chain with five modules of its own. It records token and NFT ownership, the rules that govern moving them, liquidity pools, an NFT secondary market, income distribution, and two-phase authorizations plus single-transaction claim permits. It deliberately does not model what an asset represents.
That single sentence is the most important thing to understand before reading anything else.
The modules
| Module | What it owns |
|---|---|
| Token factory | Denom creation and administration, the compliance send restriction, two-phase authorizations, and single-transaction claim permits |
| Liquidity | Constant-product pools, LP shares, LP farming, emission schedules, pool lifecycle |
| NFT | RWA classes and tokens, issuer-scoped class ids, metadata immutability, escrowing |
| NFT market | Fixed-price secondary listings, royalties, refundable deposits |
| Income | Reward-per-share distribution for fungible balances, per-token claimables for NFTs |
Modules overview maps them out and shows how they depend on each other. Application wiring covers registration order, block hooks, and module accounts.
The boundary
The chain's responsibility ends at who holds what, who may move it, and what happens when they do.
An on-chain token is a representation. What backs it, and who owes what, is not enforced by the chain and is not modelled by it. If your integration depends on the legal relationship between a token and an underlying asset, that dependency lives outside CenterChain, and the chain will not resolve it for you.
The chain is equally firm about what it will not do:
- It does not know a product's terms, maturity, or coupon calendar.
- It does not move fiat or settle anything off-chain.
- It does not know the identity of a holder. Its circulation control is a balance check, not a KYC list.
- It does not compute a price. Pool reserves price a pool trade; a swap authorization carries the holder's own ceiling, not a quote.
What the modules share
Four rules run across all five modules, and they are worth knowing before reading any single module's page.
- One send decision.
tokenfactory.CanSendTokensevaluates the blacklist and the restricted-denom rule for bank sends, NFT sends, and swap settlement alike. - Authority is an address. Every privileged message compares the signer
against a stored address. There is no
authzgrant in these modules. - State growth is bounded. Every collection has a hard cap, checked before any transfer happens.
- Invariants are alarmed, not fatal. A failed check emits an event and the block still finalizes.
Built on
| Component | Role |
|---|---|
| Cosmos SDK | Application and module framework |
| CometBFT | Consensus |
| IBC | Cross-chain transfers, interchain accounts, light clients |
A vendored cosmossdk.io/x/nft fork | The underlying class and token store |
The SDK concepts are documented upstream. Start with the Cosmos SDK concepts if you need the framework rather than the chain.
Where to go next
- Modules overview — the five modules and how they fit.
- Concepts overview — the model they implement.
- Quickstart — run a local chain.
- Network status — which networks exist today.