Modules overview

CenterChain is a Cosmos SDK application chain with five modules of its own. They sit on top of the standard SDK modules, and several of them replace a stock behaviour: x/tokenfactory installs the bank send restriction, and it also owns the NFT transfer policy.

Module	On-chain name	What it owns
Token factory	tokenfactory	Denom creation and administration, compliance restrictions, two-phase authorizations, and single-transaction claim permits
Liquidity	liquidity	Constant-product pools, LP shares, LP farming, emission schedules, pool lifecycle
NFT	nftrwa	RWA classes, tokens, minting, burning, metadata immutability, escrowing
NFT market	nftmarket	Fixed-price secondary listings, royalties, listing deposits
Income	income	Reward-per-share distribution for fungible balances, per-token claimables for NFTs

:::note The module name is not the package name x/nft is the Go package, but the module, store key, and query prefix are nftrwa. Query the stock SDK module as nft and CenterChain's as nftrwa; the two are different modules over the same underlying store. :::

How they fit together

• tokenfactory is the base layer. Every other CenterChain module creates or administers a denom through it. It also gates sends: the blacklist and the restricted-denom rule are enforced in one place.
• liquidity mints LP shares through tokenfactory. A pool's LP denom is fixed to factory/liquidity/pool/{pool_id} and is only ever administered by the liquidity module account.
• nftmarket and income both hook NFT burns. When a token is burned, the market refunds the seller's listing deposit and income releases the token's earmarked claimable back into the shared yield pool.
• income settles on every bank send. It prepends its own send restriction so that a holder's accrual is checkpointed with the pre-transfer balance, before balances move.

Start with one

If you are integrating rather than reading the whole chain, this is the shortest path for each job:

Job	Read
Create and administer your own token	Token factory
Swap two denoms under a user-granted limit	Token factory
Let a counterparty pull or burn an asset the holder approved	Token factory
Mint or send from a signature without submitting a transaction	Claim permits
Provide liquidity or swap against a pool	Liquidity
Represent a position as a unique token	NFT
Sell an NFT on chain	NFT market
Distribute yield to holders	Income

Cross-cutting behaviour

Four rules apply across more than one module. They are written up in full in Concepts, and the short form is here:

1. A transfer is decided by one function. tokenfactory.CanSendTokens evaluates blacklist, then restriction, and it is called for bank sends, NFT sends, and swap settlement alike.
2. Authority is an address, not a role engine. Every privileged message compares the signer against a stored address: the denom admin, the class issuer, the pool owner, or the gov module address. There is no authz grant anywhere in these modules.
3. State growth is bounded. Every module enforces hard caps on collection sizes and refuses the write before any transfer happens.
4. Invariants are alarmed, not fatal. liquidity and income run invariant checks in EndBlock and emit an alarm event instead of returning an error, so a violation never halts block finalization.

Where the details live

• Application wiring — module registration order, block hooks, module accounts, and the ante handler.
• Concepts — the model the modules implement.
• API reference — the generated gRPC and REST contract.