Cosmos SDK application chain

A Cosmos SDK chain that decides every token transfer in one function.

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 does not model what an asset represents.

What the chain is responsible for

CenterChain is a Cosmos SDK application chain. 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.

That boundary is the design. 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. The chain responsibility ends at who holds what, who may move it, and what happens when they do.

So it does not know a product terms, maturity or coupon calendar, does not move fiat or settle anything off-chain, does not know the identity of a holder and does not compute a price. Each of those is listed with its source under what this page does not claim.

Five modules, five responsibilities

The modules sit on top of the standard Cosmos SDK modules, and several of them replace a stock behaviour.

What the chain enforces

No competitor chain site sells the rules that move a token. Here they are the main subject.

The decision path

Every send on CenterChain, bank, NFT, and swap settlement alike, passes through one function. The first rule that matches decides.

  1. 01

    Send kind

    Bank, NFT or swap settlement all reach the same function.

  2. 02

    Recipient blocked

    A per-denom blacklist entry rejects the send for anyone.

  3. 03

    Sender blocked

    A blacklist entry rejects the send for anyone, including an admin.

  4. 04

    Denom restricted

    The admin, a delegate or a swap leg may still pass.

  5. 05

    Recipient already holds it

    Existing holders keep trading. Everyone else is rejected.

  1. 01

    One send decision

    A bank send, an NFT send and a swap settlement all pass through one function, and the first rule that matches decides. For a bank denom there is no second, weaker path.

  2. 02

    The blacklist is per denom and absolute

    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.

  3. 03

    Circulation can be closed

    When the denom 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. This is the on-chain circulation control.

  4. 04

    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.

  5. 05

    The reservation is enforced in the store

    An open swap authorization reserves max_from against the holder balance. A wrapper around the bank key value store rejects any write that would drop a balance below the reservation. This holds whichever code path moved the funds: a pool withdrawal, a direct send or a staking unbonding.

  6. 06

    There is no separate account freeze

    The chain has no account level freeze. What exists is a per-denom blacklist, is_restricted across a whole denom, and an income blocklist check that rejects a claim. A transfer barrier is not immutability: the admin of a restricted denom can still burn, force transfer or hand the admin role on.

  7. 07

    Compliance is a balance check, not an identity check

    The restricted-denom rule tests a balance. The chain can prove that a recipient already holds the token and cannot prove who that recipient is. Calling it an identity check is wrong in both directions. It blocks nothing extra, and it claims an assurance the chain cannot make.

Network status

One public network exists today: centerchain-testnet-1, with four validators and public RPC and REST endpoints. Its tokens are valueless. The documentation network table has a third row whose value reads Does not exist, and that row is the honest answer to the question this page is usually asked.

centerchain-testnet-1 is running now. No public network for real value exists yet. Read Network status before you trust any endpoint.

Build on CenterChain

Three steps from a clone to a connected node. Nothing here is hidden behind a menu.

Step 1: install

Clone the repository, run make install, check the version.

Step 2: start a local chain

Run init.sh, then start.sh. The node comes up on centerchain-1.

Step 3: use the public testnet

One endpoint per node. RPC and REST share one base URL.

Go follows the toolchain directive in go.mod. Node.js 20 or above is needed only for the docs site and the frontend. Make is the primary build entry point, and Ignite is not required.

The two settings and the four endpoints

  • centerchaind config chain-id centerchain-testnet-1
  • centerchaind config node https://rpc0.test.centerchain.org
  • validator0 https://rpc0.test.centerchain.org
  • validator1 https://rpc1.test.centerchain.org
  • validator2 https://rpc2.test.centerchain.org
  • validator3 https://rpc3.test.centerchain.org

CometBFT RPC is 127.0.0.1:26657, Cosmos REST is 127.0.0.1:1317 and gRPC is 127.0.0.1:9090. The port values have a single source of truth in tests/devnet/ports.json, so confirm that /status reports centerchain-1 before you query or sign.

The four endpoints answer the same chain. Their tokens are valueless, and all four validators run on a single host, so read Network status before relying on any of them.

Test tokens

The public testnet publishes a faucet address. There is no HTTP faucet service, so tokens cannot be requested from this page. The faucet address and the four validator endpoints are both listed in Network status.

Explore the network

Read the network live from the public testnet node. The page is a route of this site, so the data is fetched from the node in your browser.

What loads from the node directly:

  • Network status and the latest block.
  • Account balances and the denom supply.
  • NFT classes, liquidity pools and income streams.

Two surfaces are not answering

  • The node transaction index answers with an empty result, so no transaction list is shown.
  • The token factory REST endpoints answer 501, so no denom or authority list is shown.
  • Module queries do answer over HTTP with real data, so the pages that work are not blank.

We would rather name the gap than fill it with a sample.

Chain identity

A technical record sheet, not a showcase.

Chain

CenterChain, a Cosmos SDK application chain.

Native coin

CEN. Base denom ucen, display denom cen, symbol CEN, exponent 6.

Account prefix

bech32 center.

Validator prefixes

centervaloper and centervalcons.

Consensus

CometBFT.

Cross-chain

IBC: cross-chain transfers, interchain accounts and light clients.

IBC setup

The transfer application, interchain accounts, and the 07-tendermint and 06-solomachine light clients. There is no CosmWasm module.

Core module

There is no centerchain.v1 core module. Five directories live under proto/centerchain/.

Own modules

5: tokenfactory v2, liquidity v5, nftrwa v1, nftmarket v1, income v1.

NFT store

A vendored cosmossdk.io/x/nft fork holds the class and token store, with the nftrwa overlay on top.

Validator model

Four validators on the public testnet, all four of them on a single host.

All four public testnet validators run on a single host. The network exercises chain startup, transactions, module flows and four-validator consensus. It does not test host-to-host networking or resilience to a host outage.

Validators do not need an authz grant. Every privileged message compares the signer against a stored address, and no CenterChain module calls the authz keeper.

Evidence, and the limit of our support

Every claim on this page can be checked against a running node or a published document. Here is where, and here is what does not exist yet.

Source

Open source

Chain, site and docs in public repositories.

Status

Network status

What is deployed, and what is not available.

The API reference is generated from a pinned commit, so its pages name the tree they came from. Two explorer surfaces do not answer yet: the node transaction index returns an empty result and the token factory REST endpoints return 501.

What works today

Consensus, module queries and public endpoints answer.

  • The chain starts, accepts transactions and reaches four-validator consensus on the testnet.
  • Module queries answer over HTTP with real data: liquidity parameters and pools, income parameters and streams, and NFT classes.
  • A public RPC and REST endpoint exists per validator, and the browser can read them directly.
  • There is no main network. The only public chain is centerchain-testnet-1.
  • The node transaction index returns an empty result, so no transaction list is shown anywhere.
  • The token factory REST endpoints return 501, so no denom or authority list is published.
  • There is no HTTP faucet service. The testnet publishes a faucet address only.
  • All four testnet validators share one host, so the network does not prove host-to-host networking or host-outage resilience.

The evidence rail above lists only what a source exists for. A security review and a bug bounty program are absent from it for that reason, and the list of claims this page does not make says so.

Glossary

CenterChain

The Cosmos SDK application chain documented in the CenterChain documentation.

CEN

The native protocol coin, used for fees, staking and governance. Its base denom on chain is ucen and its display denom is cen.

Token factory denom

A denom created by an account, of the form factory/{creator}/{subdenom}.

Denom admin

The account that may mint, burn and change the policy of a token factory denom. The creator is the first admin.

Authority

The gov module address. Every module privileged operations are gated on it.

Technical issuer

The issuer of an NFT class. Its account address is the first segment of the class id, so a class is namespaced by its issuer.

Class id

{issuer}/{product_ref}, at most 256 bytes, printable ASCII, exactly one separator.

Lock

An escrow over an NFT. The holder keeps ownership, but nobody else can move or burn the token until the lock is released.

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.

Delegate

An address that bypasses the restricted-denom rule for one denom. It does not grant minting or burning.

LP share

The token representing a position in a pool. Its denom is always factory/liquidity/pool/{pool_id}.

Claimable

An amount earmarked for one specific NFT token, pushed by an administrator and paid on claim.

Authorization

A limited, single-use swap permission the holder signs in one transaction and a named executor settles against in the next.

Questions

What is CenterChain?
CenterChain is a Cosmos SDK application chain with five modules of its own.
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.
Which public network exists today?
One, centerchain-testnet-1, with four validators and public RPC and REST endpoints, and its tokens are valueless.
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.
Does the compliance check identify the holder?
No. It tests a balance, not an identity.
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.
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.
Does the chain compute prices?
No. It enforces the ceiling the holder set, and a better price is never rejected.

What this page does not claim

A list of what is missing on purpose. Each entry is absent because no source settles it, not because something is on its way.

Yield, annualised return or interest figures.
The income module stores distribution state and no coupon calendar, and the liquidity module has no annualised query.
Total value locked, transaction counts, user counts, prices or uptime.
No source states a measured value, and the node transaction index answers with an empty result.
A security review, an audit firm or a bug bounty program.
The audit fields in the content contract are still placeholders, and the published documentation names no firm, no audit date and no bounty program. Nothing here stands in for one.
Regulatory status, a licence, a registration or an authority.
The contract line for regulatory status is a placeholder and the published documentation has no counterpart to it.
Identity verification, KYC or personal data handling.
The chain does not know the identity of a holder, and the restriction it does apply is a balance check rather than an identity check.
Fiat movement, off-chain settlement or product maturity terms.
The chain states that it does none of the three.
A permission that expires.
The authorization message carries no deadline or expiry field, so a time-boxed permission is not something the message can express.
A block time as a figure.
The glossary says roughly one second. That is a description, not a measurement, so it is not used as a number here.
A promise that the validator set will grow or spread out.
The documentation states that move as a plan, so it stays a plan on this page and out of the capability list.
Sample data or a sample asset table.
The content contract requires sample data to carry a sample label and a date stamp. No source exists for one, so none is printed.
That REST is unavailable for the modules.
A generated coverage report lists no REST routes for them, but live measurement refuted that: those module queries answer over HTTP with real data. The gap is the transaction index and the token factory REST endpoints, and only those are named.
Compatibility with another chain, including a bridge or an ERC-20 representation.
The published documentation never mentions them. The only bridge text lives in an upstream design file whose own header marks it as a draft.
The corporate relationship between CenterNetwork and CenterChain.
That relationship is defined only in the same upstream design file, which is marked as a draft. The published documentation does not describe it.