What is vATOM

vATOM is a liquid staking token for ATOM. You deposit ATOM, the contract delegates it to a set of validators, and you get vATOM back. Your ATOM keeps earning staking rewards, but instead of being locked in a delegation, you hold a token you can move, trade, or use elsewhere.

When you want your ATOM back, you return the vATOM and wait out the Cosmos Hub's unbonding period — about 21 days.

The one thing to understand first

vATOM does not rebase. Your balance never changes on its own.

If you deposit 100 ATOM and receive 100 vATOM, you will still have 100 vATOM a year later. What changes is what each vATOM is worth:

	Day 1	Day 365
Your vATOM balance	100.00	100.00
Exchange rate	1.000000	1.150000
Redeemable for	100.00 ATOM	115.00 ATOM

This trips people up, because a wallet showing "100 vATOM" a year later looks like nothing happened. Rewards arrive as a rising exchange rate, not a rising balance. The dashboard shows that rate as its single headline number.

The reason for this design is that a non-rebasing token is far easier for other contracts to integrate — a balance that silently changes breaks accounting in pools and lending markets.

What makes this one different

Most liquid staking protocols for ATOM live on another chain and reach across to the Hub using interchain accounts (ICA) and interchain queries (ICQ). That machinery is a meaningful source of risk and delay: relayers, channel timeouts, proofs.

vATOM runs on the Cosmos Hub itself. It holds ordinary delegations, in its own name, on the same chain. It reads its own delegation balance back with a native query — no proofs, no relayers, no bridge.

Concretely, that removes an entire class of failure. There is no channel to get stuck, no relayer to go offline, no packet to time out. What remains is the Hub's own staking mechanics, which is the risk you already accept by staking at all — plus the contract's own correctness. See risks.

How your deposit is spread

Your ATOM is not delegated to one validator. The contract holds a configured set, each with a weight, and splits every deposit across them in those proportions.

Weights are basis points and always total 10,000 — so a validator on 6,000 takes 60% of each deposit, and one on 500 takes 5%. The app shows the live set and its percentages under Protocol details → Validator set, which is the authoritative answer for any deployment; this page cannot name the validators because different deployments configure different ones.

Four things follow from that, and they are easy to assume wrongly:

• Rewards are compounded on the same weights. When staking rewards are folded back into the pool, they are split exactly as a new deposit would be.
• Changing the weights does not move existing stake. They govern future delegations only. Stake already with a validator stays there until an unbonding batch happens to draw it down, or until an admin redelegates it deliberately.
• Removing a validator re-spreads its share proportionally across the ones that remain — the ratios you can see are preserved, rather than the removed share landing wherever somebody chose. New deposits stop until an admin sets a fresh allocation, because a smaller set is a more concentrated one.
• Rounding goes to the last validator in the set. Splitting an odd amount across weights leaves a few uatom; they are added to the final allocation rather than being dropped, so the full deposit is always delegated.

Slashing exposure follows the weights: a validator holding 60% of the pool can cost you six times what one holding 10% can. That is the trade-off any delegation involves, and it is why the set is worth looking at.

The set is capped at 20 by default, with a hard ceiling of 32. That ceiling is set by measurement, not preference. Each validator adds a delegate message on deposit and an undelegate message plus a reply on unbonding, and those have to fit in a Cosmos Hub block, which allows 75,000,000 gas. At 64 validators one routine unbonding transaction consumed 41% of a block; at 20 it consumes 10%. If that transaction ever failed to fit, unbonding could not be processed at all and redemptions would stall — so the limit is deliberately conservative.

Two contracts, not one

The system is two contracts working together:

• vatom — everything you interact with: staking, redeeming, claiming.
• rewards-vault — a small companion that receives all staking rewards.

The vault exists for a specific accounting reason. The main contract's bank balance is used to measure what actually came back from an unbonding, and that measurement only works if the balance contains nothing else. So rewards are pointed at a separate account. Without the separation, a reward payment arriving mid-unbonding would be misread as unbonded principal.

The vault's code is immutable — it is deployed with no migrate admin, and the main contract verifies that on chain before it will bind to it. It cannot be swapped later.

Keeping it running

Some of the protocol's routine work is not automatic. Collecting staking rewards, compounding them back into the pool, starting a batch's unbonding, and settling a matured batch are all permissionless — any address can trigger them, and no address is obliged to.

This matters to you in two ways:

• The exchange rate only rises when rewards are actually compounded. If nobody does it for a while, rewards accrue on chain but the rate flatlines. Nothing is lost — a later compounding picks it all up — but the number on the dashboard is stale until then.
• A matured redemption is not payable until someone settles its batch. Your ATOM can be back from unbonding and still not claimable. Anyone can settle it, including you, and the dashboard says when a batch is waiting.

In practice an operator runs these on a schedule. The protocol does not depend on any particular person doing so, which is the point of making them permissionless — but it does depend on somebody doing so, and that is a real operational assumption rather than a theoretical one. It is listed among the risks.

Two things stay privileged and are not open to anyone: pausing the contract, and changing the validator set or deposit cap. Those belong to the admin key, and what it can and cannot do is also on the risks page.

What it costs

Nothing, as a protocol fee. The fee is fixed at zero basis points and is not adjustable — the contract rejects any attempt to set it otherwise.

You still pay:

• Network gas on every transaction, like any Cosmos transaction.
• Validator commission, deducted from staking rewards before they ever reach the protocol. This is normal staking, and applies whether or not you use vATOM.

Next

• The exchange rate — how it is computed and why it sometimes stalls
• Redeeming takes 21 days — read before you redeem
• Risks — slashing, the admin key, and what depends on keepers