Public blockchains made a trade nobody fully priced in. To get verifiability — the property that anyone can check the chain is honest — they made everything public. Every balance. Every payment. Every position, strategy, payroll, and treasury move, forever, to anyone who cares to look. We normalized a level of financial exposure that no bank, brokerage, or payment network would ever accept, and called it transparency.
The industry's answer so far has been to bolt privacy on afterwards: mixer contracts, opt-in shielded apps, privacy layers rented from another chain. Bolted-on privacy inherits the platform it's bolted to — its public mempool, its MEV economy, its data assumptions. And it makes privacy the exception: a special thing you do, visible precisely because you did it.
Celar takes the other path. It is an EVM-equivalent Layer 1 where confidentiality is the protocol's data plane. Balances, transfer amounts, and contract state are encrypted by default — not by an app, but by the chain itself — while every state transition remains publicly verifiable.
01 /Three tiers, one chain
Privacy is not one thing; it's a set of adversaries you choose to defeat. Celar gives every transaction a choice of three tiers:
Contracts compute directly on encrypted values. Balances and amounts stay ciphertext — even to validators executing the code.
Every payment lands on a fresh one-time address. No address reuse, no public linkage between payments and payees.
Trustless privacy with 192-byte proofs — a tier that holds even if every validator and committee member colludes.
The first tier is the one most chains cannot offer at all. Zero-knowledge proofs let you prove statements about your own data; they cannot run a private orderbook, a sealed-bid auction, or a shared encrypted balance — state that someone computes on but nobody reads. That requires fully homomorphic encryption, and on Celar it is a protocol primitive, not a rented coprocessor.
02 /The key that never exists
Every encrypted system has to answer one question first: who can decrypt? Celar's answer is: no single party, ever. The network's decryption key is born distributed — it exists only as shares spread across a 100-seat key committee, and producing any plaintext requires 79 of those seats to cooperate. The full key is never assembled, anywhere, at any time.
P(capture) ≤ 10⁻⁴ // 10-year adversarial capture bound
shares refresh every epoch · partials signed, attributable, slashable
Committee seats are staked, share-refreshed every epoch, and every partial decryption is signed and attributable — so misbehavior isn't just detectable, it's slashable at protocol level. There is no hardware enclave in the trust root and no cloud vendor to subpoena. The capture bound above isn't marketing: it's derived from first principles, with its inputs published live on the health page, and it holds under an adversary controlling up to 55% of stake over a rolling ten-year campaign.
03 /A security metric you can falsify
Every chain claims to be secure. Celar publishes a number instead:
The cost to capture the committee — priced in staked $CELAR — must remain at least twice the value the shielded pool protects. Every input to that ratio is published on the live health page, and anyone can recompute it. If the ratio ever approaches the floor, protocol economics tighten automatically; governance cannot vote the floor away. We believe this is the first L1 security claim structured so that being wrong is publicly checkable.
The same philosophy runs through the whole design. Instead of adjectives, the whitepaper ships a leakage matrix: for each privacy tier, exactly what is hidden, from which adversary class, and what still leaks today — timing, gas tier, v1 call targets — with a mitigation roadmap. Privacy claims you can't falsify are indistinguishable from marketing.
04 /Nothing new to learn
Confidentiality that requires a new language never reaches most developers. Celar is EVM-equivalent with zero new opcodes: standard Solidity, standard tooling, standard JSON-RPC, standard wallets. Encrypted types — euint64, ConfidentialERC-20 — arrive through precompiles, and transfers compile to branchless, select-based circuits so even control flow reveals nothing.
The compiler is also the last line of defense: code whose information flow would leak encrypted data into public state is rejected at build time. A privacy leak on Celar is a compile error, not a post-mortem audit finding.
05 /No MEV economy
Front-running needs two ingredients: readable transactions and orderable blocks. Celar removes both — there is no public plaintext mempool, and ordering is content-blind and randomized. No sandwich attacks, no priority-fee auctions, no extraction supply chain to centralize around. Your trade can't be picked off if nobody can read it.
06 /Where we are, and what's next
Today we're opening the Celar documentation — the full protocol in plain language: the threshold key committee, the three privacy tiers, the fee and issuance design, and the health rule. The design has survived eight adversarial review rounds; all 34 findings raised have been closed, and the process is documented. The complete technical specification is shared with reviewers and investors under NDA in the data room.
Engineering is underway: the chain stack is locked, and the first verification spikes — precompile fit, coprocessor transport, stack maturity — are in flight. From here: testnet, the public repos, and the committee ceremony. If you build, trade, or research on-chain and believe finance needs a confidential settlement layer, we'd like to hear from you.
CONTACT — press@celar.network · LIVE METRIC — celar.network/health · $CELAR