# CenterChain, in full

The long form of `llms.txt`. Same rule: every claim carries the file and line of the canonical
documentation it came from, and every absence is a measurement. Nothing here is a forecast and
nothing here is a promise about what will be built.

Measured: 2026-09-30. Sources are `centerchain-docs/docs/**` unless another repository is named.

## 1. What CenterChain is

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 a two-phase swap authorization. It deliberately does not
model what an asset represents.

The last sentence is the one to keep: the chain stores what a token is called and who holds
it, and nothing about the asset behind the name.

Sources: `docs/start-here/introduction.md:10-13`, `docs/concepts/overview.md:29-31`

## 2. The five modules

Token factory (`tokenfactory`). The base layer. Any account creates and administers its own
bank denom, decides who may hold or receive it, and authorizes a swap between two denoms. A
denom is `factory/{creator}/{subdenom}`, and the creating account becomes its first admin. The
denom creation fee is `10000000ucen` by default and is burned unless community pool funding is
enabled. `factory/liquidity/pool/{pool_id}` is reserved, which is what stops an account from
minting a counterfeit LP share. Caps: subdenom 44 bytes, creator segment 75 bytes, 100,000
denoms and 100,000 blacklisted addresses.

Sources: `docs/start-here/introduction.md:22`,
`docs/modules/tokenfactory.md:31-33`, `:82`, `:125-127`

Liquidity (`liquidity`). A constant-product automated market maker holding two-denom pools. It
mints LP shares through the token factory, and the LP denom is always
`factory/liquidity/pool/{pool_id}`, administered only by the liquidity module account. Every
number is an integer and every division floors. The fee scale is 1,000,000 parts per million,
and a message that leaves the fee field empty defaults to a 3,000 ppm swap fee, 300,000 ppm to
LPs and 700,000 ppm to stakers. A swap too small to cover its own fee is rejected rather than
rounded to a zero output. There is no annualised or APY query.

Sources: `docs/start-here/introduction.md:23`, `docs/modules/liquidity.md:44`, `:206-207`,
`:225-229`

NFT (`nftrwa`). An overlay on the stock NFT store that adds the rules a real world asset
needs. A class id is `{issuer}/{product_ref}` and its first segment must be the signer's own
bech32 address. A token id is `{class_id}/{sequence}`, and the module assigns the sequence
rather than the sender choosing it. `token_metadata_immutable` is fixed when the class is
created. The lock is an escrow: the holder keeps ownership and nobody else can move or burn the
token until it is released.

Sources: `docs/start-here/introduction.md:24`, `docs/modules/nft.md:16-17`, `:25`, `:86`, `:98`

NFT market (`nftmarket`). A fixed-price secondary market for the tokens the NFT module
creates. It charges no protocol fee. The seller keeps ownership while the listing is live: the
token is locked under the order id `nftmarket/{listing_id}`. The listing deposit is
`1000000ucen` by default, must be denominated in `ucen`, and is backed by an invariant that the
module account balance equals the sum of active listing deposits. Every listing has an expiry
height; leaving it at zero substitutes 100,000 blocks, and no listing may be created further
ahead than 1,000,000 blocks. A purchase never burns: a royalty that consumes the whole price is
`ErrRoyaltyInvalid`, not a zero payment.

Sources: `docs/start-here/introduction.md:25`, `docs/modules/nftmarket.md:57`, `:64-66`, `:98`,
`:116-118`

Income (`income`). Distributes income to the holders of a denom and pays the claimable amounts
attached to individual NFTs. It stores distribution state, never a schedule: the chain does not
know a coupon calendar. Fungible balances use one global reward-per-share accumulator. NFTs use
an earmarked claimable pushed by an administrator and paid on claim. Accounting is lazy, so a
holder who never claims loses nothing. Every 10,000 blocks each yield pool is checked against
its total unpaid liability, and a violation raises an alarm event rather than failing the
block. Caps: 1,000 streams and 50 NFT claims per message.

Sources: `docs/start-here/introduction.md:26`, `docs/modules/income.md:12-15`, `:17`, `:22`,
`:121`, `:163-164`, `:188`

## 3. What the chain enforces

Every bank send, NFT send and swap settlement passes through one function, and the first rule
that matches decides.

1. Blacklist. A blacklist names denoms, not addresses. Blocking one token has no effect on any
   other. A denom with no authority record is never subject to it. The check is absolute: it
   applies under an open policy, to an admin, to a delegate and to a module authority.
2. Restricted denom. When the admin sets `is_restricted`, that denom can only be sent to an
   address that already holds it. The admin, a delegate and a swap leg are exempt. Existing
   holders keep trading among themselves.
3. No second path. For a bank denom there is no weaker fallback.

There is no separate account freeze. The admin of a restricted denom can still burn, force
transfer or hand the admin role on. A transfer barrier is not immutability.

Compliance here is a balance check, not an identity check. The chain can prove that a recipient
already holds a token and cannot prove who that recipient is.

Sources: `docs/concepts/transfers-and-compliance.md:10-11`, `:13-29`, `:31-51`, `:53-58`,
`:62-68`

Two-phase execution. Moving one CenterChain denom into another outside a pool takes two
transactions. The holder signs the first and grants a limited permission; a named executor
signs the second and settles inside the bounds the holder set. The chain enforces the ceiling,
not a price: a better price is never rejected, and the message definition carries no deadline
or expiry field.

Sources: `docs/concepts/two-phase-execution.md:10-13`, `:18-25`, `:54-61`, `:69-72`

Governance. Privileged operations are gated on an authority, and a capability is a separate,
narrower question: whether the action exists on this chain at all. The shipped chain enables
five capabilities: `enable_metadata`, `enable_force_transfer`, `enable_burn_from`,
`enable_admin_sudo_mint` and `enable_community_pool_fee_funding`. `enable_admin_sudo_mint` is
wired with a predicate that always returns false, so the sudo-mint path is not reachable in the
default build.

Sources: `docs/concepts/security-and-governance.md:12-13`, `:18-22`, `:24-26`

## 4. Glossary

Terms as the documentation defines them.

- CenterChain: the Cosmos SDK application chain documented at
  `docs.concepts/glossary.md:12`
- CEN: the native protocol coin for fees, staking and governance; base denom `ucen`, display
  denom `cen`. `glossary.md:13`
- Token factory denom: a denom of the form `factory/{creator}/{subdenom}`. `glossary.md:14`
- Denom admin: the account that may mint, burn and change the policy of a token factory denom.
  `glossary.md:15`
- Authority: the `gov` module address; every privileged module operation is gated on it.
  `glossary.md:16`
- Technical issuer: the issuer of an NFT class, whose account address is the first segment of
  the class id. `glossary.md:18`
- Class id: `{issuer}/{product_ref}`, at most 256 bytes, printable ASCII, exactly one separator.
  `glossary.md:19`
- Lock: an escrow over an NFT; the holder keeps ownership and nobody else can move or burn it.
  `glossary.md:22`
- Restricted denom: a denom whose transfers to addresses that do not already hold it are
  rejected, unless the sender is its admin or a delegate. `glossary.md:24`
- Delegate: an address that bypasses the restricted-denom rule for one denom; it does not grant
  minting or burning. `glossary.md:25`
- LP share: the token representing a position in a pool; its denom is always
  `factory/liquidity/pool/{pool_id}`. `glossary.md:28`
- Claimable: an amount earmarked for one specific NFT token, pushed by an administrator and paid
  on claim. `glossary.md:40`

## 5. Questions and answers

1. What is CenterChain? A Cosmos SDK application chain with five modules of its own.
   `docs/start-here/introduction.md:10-13`
2. Does the chain know what a token represents? No. An on-chain token is a representation, and
   what backs it is not enforced by the chain. `docs/start-here/introduction.md:12-13`,
   `docs/concepts/overview.md:29-31`
3. Which public network exists today? One: `centerchain-testnet-1`, with four validators and
   public RPC and REST endpoints, and its tokens are valueless.
   `docs/start-here/network-status.md:18`, `:92-93`
4. What can the chain enforce about a transfer? A per-denom blacklist and a restricted-denom
   rule, both decided in one function that bank sends, NFT sends and swap settlement all pass
   through. `docs/concepts/transfers-and-compliance.md:10-11`, `:31-51`
5. Does the compliance check identify the holder? No. It tests a balance, not an identity.
   `docs/concepts/transfers-and-compliance.md:53-58`
6. Can an issuer close a token to new holders without freezing existing ones? Yes. Setting
   `is_restricted` rejects transfers to addresses that do not already hold the denom, and
   existing holders keep trading among themselves.
   `docs/concepts/transfers-and-compliance.md:44-51`
7. How does a swap between two token factory denoms work outside a pool? In two transactions:
   the holder signs an authorization, then a named executor settles against it within the limits
   the holder set. `docs/concepts/two-phase-execution.md:10-13`, `:18-25`
8. Does the chain compute prices? No. It enforces the ceiling the holder set, and a better
   price is never rejected. `docs/start-here/introduction.md:59-60`,
   `docs/concepts/two-phase-execution.md:69-72`

## 6. Network state

| Network | Chain id | Kind | Public endpoints |
| --- | --- | --- | --- |
| Local development | `centerchain-1` | Disposable single-node devnet | None, loopback only |
| Public testnet | `centerchain-testnet-1` | Four validators, public RPC and REST | Yes |
| Production | none | Does not exist | none |

The testnet is closed and unauthenticated, its tokens are valueless, and all four validators
run on a single host, so it exercises chain start, transactions, module flows and four
validator consensus, but not host to host networking or host outage resilience. Moving
validators to separate hosts is planned as a migration of this same chain, which is not a new
genesis.

Sources: `docs/start-here/network-status.md:15-19`, `:77`, `:83-88`, `:92-93`

## 7. Endpoints

Base URLs, one per node, shared by RPC and REST:

| Node | Base URL |
| --- | --- |
| validator0 | `https://rpc0.test.centerchain.org` |
| validator1 | `https://rpc1.test.centerchain.org` |
| validator2 | `https://rpc2.test.centerchain.org` |
| validator3 | `https://rpc3.test.centerchain.org` |

Source: `docs/start-here/network-status.md:59-64`

Answers today, measured 2026-09-30 on validator0:

| Path | Result |
| --- | --- |
| `/cosmos/base/tendermint/v1beta1/node_info` | 200, network `centerchain-testnet-1` |
| `/cosmos/base/tendermint/v1beta1/blocks/latest` | 200, a live block |
| `/cosmos/auth/v1beta1/params` | 200 |
| `/cosmos/bank/v1beta1/supply/by_denom?denom=ucen` | 200 |
| `/cosmos/nft/v1beta1/classes` | 200, empty |
| `/centerchain/liquidity/v1/params` | 200, real module parameters |
| `/centerchain/liquidity/v1/pools` | 200, empty |
| `/centerchain/income/v1/params` | 200 |
| `/centerchain/income/v1/streams` | 200, empty |
| `/cosmos/tx/v1beta1/txs?query=...` | 200 with `total: "0"`, so nothing to read |
| `/cosmos/tx/v1beta1/blocks/{height}` | 501 Not Implemented |
| `/centerchain/tokenfactory/v1/params` | 501 Not Implemented, `code 12` |
| `/cosmos/tokenfactory/v1/params` | 501 Not Implemented, `code 12` |
| gRPC-web POST | 404 |

CORS on `rpc0` is `access-control-allow-origin: *`, so a browser can read it directly without a
proxy. The site uses this only on `/explorer/`, only after a user action.

Sources: live measurement 2026-09-30; `centerchain-site/docs/acceptance/evidence.md:712-761`,
`centerchain-site/docs/project/status.md` RIT-029, RIT-030

## 8. Routes on centerchain.org

`/`, `/modules/`, `/how-it-works/`, `/security/`, `/explorer/`, `/glossary/`, `/faq/`,
`/blog/`, `/legal/`, `/privacy/`, `/terms/`, `/disclaimer/`. Agent files: `/llms.txt`,
`/llms-full.txt`, `/get-started.md`. The documentation map is in `llms.txt`.

## 9. Not published today

The same list as in `llms.txt`, in one place, because an agent that reads only this file must
still not claim any of it:

- No production network, no announced mainnet chain id, no genesis file, no validator set.
  `docs/start-here/network-status.md:19`, `:21-24`
- No readable transaction layer: empty transaction index, 501 on block transactions, 404 on
  gRPC-web.
- No tokenfactory REST: 501 on both tokenfactory parameter paths. The generated REST coverage
  page disagrees with the live gateway; the live measurement is the one to report.
- No HTTP faucet service; the faucet is an address only.
  `docs/start-here/network-status.md:81`
- No validator run guide, no grant page.
- No chain or token standard compatibility claim.
- No expiring or dated permission claim; the message has no deadline or expiry field.
- No audit firm, no audit date, no regulatory status, no licence number, no registered company
  address, no jurisdiction of law, no data controller. Searched 2026-09-30, 0 matches each.
- No yield, rate, total value locked, transaction count, user count, price or uptime figure.
  There is no measured source for any of them.
- `explorer.centerchain.org` and `censcan.com` do not resolve. Measured 2026-09-30.

## 10. Two lines that travel with every page

Tokens are not bank deposits and are not covered by deposit insurance.

Nothing on this site constitutes investment, legal or tax advice.

They are read from the content contract at render time, so the text on any page is the
contract's own. Source: `centerchain-site/src/data/constants.ts:172-175`