CELR is a governance-and-security token before it is a “utility” token

Celer’s current product surface is interoperability: cross-chain asset transfer (cBridge) and cross-chain messaging (Celer IM). In both, the State Guardian Network (SGN) sits in the middle as the message router, producing stake-weighted attestations that destination-chain contracts will accept as “the message happened on the source chain,” as described on its technology page.

That design makes CELR’s real job simple and uncomfortable. CELR concentrates the right to sign, slash, and upgrade into whoever controls SGN voting power. In other words, CELR is a power-distribution token. The fee story comes later.

This governance-first framing is easier to see when you compare it with other ecosystems’ designs, like the 1inch tokenomics where voting power itself is the core asset.

Binance Research’s project report describes Celer as an interoperability protocol, with SGN (Tendermint PoS) as the staking-backed routing layer, plus cBridge and the Celer IM framework as the primary applications.

What the token does in the product: staking, message validity, and fee routing

Staking is the center of gravity. SGN is a delegated proof-of-stake system where CELR holders delegate to validators, and validator voting power is proportional to stake in their pools, as specified in the SGN architecture.

Operationally, SGN validators reach consensus and generate attestations for cross-chain messages. The documented flow is: a user submits a message to a MessageBus contract on the source chain, SGN validators reach consensus and generate a stake-weighted multi-signature attestation, then an executor relays it to the destination chain where the MessageBus verifies and triggers logic.

CELR is also explicitly positioned as the governance token for parameter change. Celer states that CELR is needed to update protocol parameters like supported chains and tokens, fee configurations, and new modules, and that SGN upgrades and parameter changes require governance through the SGN with the CELR token.

Fees are real, but they are downstream of SGN’s control plane. In the Celer IM docs, whoever calls sendMessageWithTransfer or sendMessage must include an SGN fee as msg.value, and that fee “will later be distributed to SGN validators and delegators,” per the fee mechanism.

cBridge’s documentation frames value capture similarly: users and LPs pay fees to the SGN, and those fees are distributed to CELR stakers of SGN nodes that generate a block.

Supply, allocations, and emissions: capped supply, heavy early allocations, and ongoing staking rewards

CELR has a maximum supply of 10,000,000,000. Major trackers and exchange research notes generally present total and max supply at 10,000,000,000.

Circulating supply is not presented consistently across major trackers. On March 4, 2026, CoinGecko shows 5,645,454,935 circulating supply, while CoinMarketCap shows 7,803,424,107 circulating supply. A Bithumb “token specification” document also records this same discrepancy (CoinMarketCap vs CoinGecko), which is a useful reminder that “circulating” is methodology, not physics.

Some trackers go further than a single number and list an “available supply” breakdown with specific labeled buckets and addresses (for example, foundation-locked amounts, a mining reserve, and a team/advisors bucket). Even if you treat those sites as indexers rather than “official,” the implication is straightforward: a large portion of supply is still associated with identifiable reserve-style wallets, which matters for both governance power and future sell pressure.

Allocations (per Binance Research)

Emissions and staking rewards have two “official-ish” narratives that should be read together, not blended into a single clean curve.

First, the SGN mainnet launch post (November 9, 2020) states that 20% of total supply (of 10 billion) is allocated to SGN block rewards, distributed over the next 8 years, and it publishes a tentative yearly reward pool (e.g., 300,000,000 in years 1 and 2, then declining).

Second, the Bithumb token document states an ongoing release schedule described as 12,000,000 CELR per month as “staking reward,” continuing until October 2027.

There is no clean way to reconcile those two schedules from public docs alone. They might reflect (a) different phases, (b) a later parameter change, or (c) differing categorization of “block rewards” vs other staking payouts. Treat the exact forward emissions curve as structurally uncertain unless you are also tracking the live SGN contracts on-chain.

On token destruction, the same Bithumb document reports “no burns” over the past year.

Fees and fiscal flows: who pays, who gets paid, what is enforced by protocol

At the protocol level, SGN is built to accept fees on L1 and then enforce access control and rewards on the SGN sidechain. The SGN design describes users paying service fees to the mainchain contract, and the sidechain advertising subscription or pay-per-use models while tracking balances and service usage.

In Celer IM, the fee mechanism is explicit and developer-facing. A MessageBus caller includes the SGN fee as msg.value, and the fee is intended to be distributed to SGN validators and delegators, with the formula feeBase + message.length * feePerByte.

What is enforced, mechanically, is not “the foundation pays stakers” or “the bridge shares revenue.” What is enforced is the validator quorum gate. Reward distribution relies on a reward message that must be co-signed by validators representing more than 2/3 voting power before the SGN contract transfers service rewards and triggers mining reward transfers.

That same 2/3 voting power threshold appears again for penalties. Sidechain validators co-sign a penalty message, and on receiving a valid message co-signed by more than 2/3 voting power, the DPoS contract slashes penalized delegators.

cBridge’s docs present the economic story as “PoS-like”: users and LPs pay fees to SGN for SGN’s services, and fees are distributed to stakers corresponding to the SGN nodes that generate a block.

For a useful contrast in how cross-chain systems tie fees and staking together, compare with the Wanchain tokenomics.

Two practical consequences follow.

First, fee value capture is only as strong as fee volume, and fee volume is only as strong as demand for SGN-routed cross-chain actions. Celer’s own homepage claims cBridge has processed “more than $14B” in cross-chain volume and served “more than 540K” unique users. Those numbers can change, but the key point is that the protocol is explicitly arguing for a fee-based security budget.

Second, Celer IM does not enforce executor fee economics. Executor fees are “entirely decided at the application level,” and the framework does not enforce a mechanism. That is operationally flexible. It also means “the protocol fee model” is partly social and integrator-driven.

Governance and parameter control: decentralization claims meet validator-gated reality

CELR governance, per Celer’s own framing, covers high-impact parameters: supported chains and tokens, fee configuration per chain/token, new modules, and upgrades to SGN itself.

But the who matters more than the what. In the SGN design, the governance process is described as a mainchain proposal system where any validator can vote yes/no/abstain, with a two-thirds staking majority yes required to pass. Proposals require a deposit, and the proposer only recovers the deposit if the proposal passes.

If you’re used to validator-centric DPoS governance, the Harmony tokenomics is a helpful comparison point for how delegation and validator incentives shape practical control.

The same SGN description also says a “more comprehensive” governance mechanism will be introduced later to let delegators participate. Taken literally, that means the described governance surface is validator-centric, not tokenholder-direct. Delegators influence outcomes indirectly through delegation choices, but validators are the explicit voting actors in the documented flow.

Even outside formal governance, SGN’s operational control plane is validator-quorum gated. Reward and slashing messages require >2/3 voting power signatures to execute on-chain transfers and penalties. That is a practical concentration point. The validator set is the system’s administrative muscle.

Parameter control also shows up at the validator level. The SGN description lists validator parameters like min_self_stake and describes constraints on commission_rate changes, including a two-week advance announcement requirement for commission increases. Those are governance-adjacent power levers because they affect who can compete as a validator and how value is split between operators and delegators.

The SGN mainnet launch history makes the centralization trade-off explicit. The launch plan included phases where validators were whitelisted, and in Phase 1 (starting November 30, 2020) “all validators will be run by the Celer Foundation,” with a later phase introducing selected staking partners and only later enabling full public validator participation.

That rollout is not automatically “bad.” It is operationally coherent for a security-sensitive cross-chain system. But it should shape how you model parameter stability. If a small set of operators (even temporarily) can coordinate upgrades and configurations, the system is politically closer to a managed PoS router than a credibly neutral base layer. The upside is faster incident response. The downside is that governance power is meaningfully concentrated, and “community governance” is mainly delegation dynamics plus validator politics.

Risk analysis: power concentration is the dominant risk, not emissions

Celer’s token design tries to pay for security in the same unit that controls security. Stake more CELR, get more signing power, earn more fees, accept more slashing exposure. The model can work.

Where it strains is when you ask a harder question: what happens when the system is under stress and governance becomes a contested resource rather than a civic process.

Top 3 risks

  1. Validator-quorum capture of message validity (dominant risk). Trigger: a coalition reaches >2/3 SGN voting power, or a small number of large delegators concentrate stake onto aligned validators. Mechanism: SGN attestations and critical state transitions rely on validator quorum behavior, including stake-weighted multi-signature attestations for cross-chain messages. Who bears it: cross-chain users, liquidity providers, and integrators whose destination-chain logic trusts SGN attestations. Measurable indicators: stake concentration across top validators, frequency of validator set changes, governance proposal passage rates, and any abnormal patterns in reward/penalty message signing which are gated by >2/3 voting power.
  2. Emission and circulating-supply uncertainty undermines pricing and security budgeting. Trigger: ongoing monthly staking rewards continue into a weak demand environment, or unlock schedules differ across indexers and venues, creating surprises. Mechanism: staking rewards expand supply while “circulating supply” is inconsistently reported across major trackers, complicating valuation of economic security. Who bears it: CELR holders (dilution) and users (security budget depends on staked value). Indicators: month-over-month circulating supply changes on multiple trackers, stated monthly release schedules like 12,000,000 CELR/month through October 2027, and any deviations from earlier published block reward schedules.
  3. Fee-demand fragility: security yield falls back to emissions if usage fees do not scale. Trigger: cBridge/IM usage stalls, integrators minimize SGN-paid actions, or fee configurations become politically constrained. Mechanism: IM requires SGN fees paid as msg.value and those fees are distributed to validators and delegators, but executor fees are not enforced at protocol level, making parts of the monetization layer optional or integrator-dependent. Who bears it: stakers (lower real yield), and users (weaker security incentives if fees shrink). Indicators: observed SGN fee levels (feeBase, feePerByte) in production contracts, staking APR composition (service fees vs block rewards), and cBridge/IM activity proxies such as reported bridge volume and user counts.

Dominant risk: validator-quorum capture is the systemic failure mode

This is the risk that matters because it subsumes the others. If a cross-chain router can be politically or economically captured, “token utility” becomes a distraction. The token’s primary utility is signing power, and signing power is what adversaries want.

Celer’s architecture is explicit about where authority lives. SGN validators generate stake-weighted multi-signature attestations used for cross-chain execution. On-chain, reward transfers and slashing execution depend on messages co-signed by validators representing more than 2/3 voting power. Governance proposals, as documented, are also validator-voted with a two-thirds staking majority threshold.

Those three elements together define the power map.

1) If you can assemble >2/3 voting power, you can (at minimum) control what the system considers valid for reward distribution and penalty execution, because the contracts explicitly accept those signed messages.

2) If you can assemble >2/3 voting power, you can pass governance proposals in the documented governance process. That includes contract upgrades and parameter updates, which Celer explicitly lists as governance-controlled surfaces.

3) Delegation makes this capture problem more political than it looks. The “tokenholder vote” is not a direct ballot in the documented governance. Validators are the explicit voters. Delegators influence validator voting power by moving stake, which means the largest delegators can credibly threaten validator revenue by reallocating stake.

None of this proves malicious behavior will happen. It does frame the system as a managed PoS router whose safety assumptions reduce to a single threshold: keep >1/3 voting power honest and independent, because the consensus design tolerates up to 1/3 Byzantine voting power.

That is the structural tension: operational flexibility versus governance centralization. Celer’s own launch history leaned into managed rollout for security reasons, with early phases run by the foundation and selected partners. If you accept that trade, you are betting on institutional trust and operator alignment as much as on cryptography.

If you need help pressure-testing this kind of “PoS router” token design, the work usually looks like governance power mapping, security-budget modeling, and emissions-to-fee transition analysis. Our tokenomics services tend to start from explicit control-surface mapping, guided by a set of design principles and backed by ongoing work in our research library.



This article is part of our Tokenomics Deep Dive series.