What is Casper?
Casper is a public, permissionless Layer 1 blockchain secured by Proof-of-Stake. It is designed for real-world adoption: smart contracts that can be upgraded, accounts with flexible multi-key permissions, predictable costs and an energy-efficient consensus. The native token, CSPR, pays for transactions and secures the network through staking.
Live values via CSPR.cloud, refreshed every minute.
Proof-of-Stake & validators
Instead of miners, Casper is secured by validators — node operators who lock up (bond) CSPR as collateral and take part in consensus by proposing blocks and signing finality signatures. The more stake a validator represents, the more weight it has in consensus and the larger its share of rewards.
CSPR holders who don't run a node can delegate their tokens to a validator. The delegated stake adds to the validator's weight, and the delegator receives the rewards attributable to their stake, minus the validator's commission. Delegation is non-custodial: tokens never leave the delegator's account.
- Mainnet has a limited number of active validator slots (currently up to 100).
- Each validator can accept up to 1,200 delegators.
- The protocol minimum delegation is 500 CSPR; validators may set their own minimum and maximum.
- Slashing is not enabled on Mainnet. Misbehaving validators can be evicted from the validator set instead.
Read more: Staking concepts · Delegating tokens
Eras & the auction
Casper organizes time into eras of roughly 2 hours. The validator set is fixed within an era. Between eras, the system auction contract determines who validates next: bonded validators with the highest total stake (self-stake + delegations) win the available slots.
- Rewards are distributed at the end of every era — about 12 times per day.
- Unbonding (undelegating or withdrawing a bid) takes 7 eras, about 14 hours. This delay protects the network against long-range attacks.
- Bids remain in the auction until explicitly withdrawn, so validators can re-enter when slots open.
Zug consensus
With Casper 2.0 the network switched from the Highway protocol to Zug, a simpler and more efficient consensus protocol. Validators propose blocks as quickly as network conditions allow, and blocks are finalized by validator signatures. Block times are expected between a few seconds and about a minute.
Read more: Zug consensus
How rewards work (Casper 2.0)
Every era, a reward pot is created from the protocol's nominal issuance. It is distributed to validators based on three observable activities:
- Block proposal — proposing blocks when it is the validator's turn.
- Finality signature creation — signing finalized blocks.
- Finality signature publication — including other validators' signatures in blocks (a “finder's fee”), which aligns incentives: everyone benefits when others operate correctly.
Under normal conditions, each validator's rewards are proportional to its stake weight in the long run. But a validator that misses proposals or signatures simply earns less — and so do its delegators. Under the old Highway model, one weak validator could lower everyone's rewards; under Zug, performance is individual. That is why reliable infrastructure matters more than ever.
A validator's 30-day performance score is shown on CSPR.live and on our live dashboard. Above 99% is considered excellent. HC-CSPR right now: –.
Read more: Validator rewards in Casper 2.0
Tokenomics (live)
| Metric | Value | Meaning |
|---|---|---|
| Total supply | – CSPR | All CSPR in existence |
| Circulating supply | – CSPR | Not locked by vesting |
| Total staked | – CSPR | Bonded by validators & delegators |
| Annual issuance | – | New CSPR per year relative to supply |
| …of which staking rewards | – | Paid to validators & delegators |
| Network staking yield | – | Staking issuance ÷ share of supply staked (before commission) |
| CSPR price | $– | Reference rate via CSPR.cloud |
Because only part of the supply is staked, stakers receive a higher percentage than the raw issuance rate. CSPR can also be burned since Casper 2.0 via the mint contract.
Casper 2.0 features
Casper 2.0 (codename “Condor”) is the largest upgrade in the network's history. Highlights from the official documentation:
Zug consensus
Simpler, more efficient consensus with individual, performance-based rewards.
New transaction model
Replaces Deploys with a more efficient structure that supports Wasm-less interactions.
Multi-VM support
Transactions can specify which virtual machine they target.
Native events
Contracts emit events directly into Casper's event stream.
Delegation limits
Validators can set minimum and maximum delegation amounts.
Reserved slots
Validators can reserve delegator slots, optionally with custom fees.
Contract access to auction
Smart contracts can stake and interact with the auction directly.
CSPR burning
A burn function in the mint contract allows CSPR to be destroyed.
Read more: Casper 2.0 overview · Transactions · Block lanes
Accounts & keys
A Casper account is identified by a public key (Ed25519 keys start with 01, secp256k1 keys with 02) and an account hash derived from it. Accounts support associated keys with weights and thresholds, which enables native multi-signature setups — for example requiring two of three keys to transfer funds, while a single key may be enough to deploy contracts.
Smart contracts
Casper smart contracts compile to WebAssembly (Wasm) and are most commonly written in Rust, for example with the Odra framework. Contracts live in packages that can hold multiple versions, which makes them upgradable by design — a key requirement for enterprise use. Contract state is stored in named keys and dictionaries, and token standards such as CEP-18 (fungible) and CEP-78 (NFT) are widely used.
Read more: Developer documentation
Transactions & fees
Every transaction pays gas in CSPR. Common system operations have fixed, predictable costs — for example 2.5 CSPR for delegating, undelegating or redelegating. Casper 2.0 introduced a new Transaction type alongside the legacy Deploy format and organizes block space into lanes for different kinds of transactions.
The Account Info Standard
How does an explorer know that a validator is called “HC-CSPR” and what its logo looks like? Through the Casper Account Info Standard:
- The operator publishes a JSON file at
https://domain/.well-known/casper/account-info.casper.jsonwith name, logo (PNG 256×256, PNG 1024×1024, SVG), website, policies and node list. - The operator registers the domain on-chain by calling
set_urlon the Account Info contract, signed with the validator key. - Explorers like CSPR.live read the file and verify that the validator's public key appears in it.
HC-CSPR's file: account-info.casper.json.
Ecosystem tools
- CSPR.live — the main block explorer, also used for staking.
- Casper Wallet — the official browser-extension wallet.
- CSPR.cloud — indexed REST & streaming API (powers this website's live data).
- Casper Docs — the official documentation.
- casper-network on GitHub — node software and SDKs.
More in our resource directory.