What this isClarity is a Proof of Rotating Authority (PoRA) consensus, a native currency, a general-purpose token system, an automated market maker, a limit-order book, and a validator reward model that includes a smoothing pot and automatic slashing for equivocation.
It is not a fork of anything. The block format, consensus protocol, state model, and reward math are original. It uses well-established cryptographic primitives — Ed25519, Blake2b, SHA-512, ChaCha20-Poly1305, Argon2id — but the protocol itself is not derived from an existing chain.
The project is code-complete and pre-launch.
There is no token sale, no presale, no ICO. This post is to put the work in front of people who might have useful things to say about it before a public testnet exists.
Current status- The daemon builds, and the full test suite passes with roughly 1,800 known tests today
- The end-to-end path has been exercised on a live two-validator regtest network: transaction submission through consensus through block application through state persistence through restart
- The RPC surface is complete and tested
- The wallet layer is complete and tested: encrypted keystores, mnemonic derivation, Ed25519 signing, human-readable addresses, and an interactive command-line client
- The P2P layer has authenticated peer handshakes, chain sync, block relay, transaction relay, proof serving, and per-peer rate limiting
- A block explorer is running against a live local chain
- Not deployed to a public network
What's different about itThree things, in order of how much I think they matter.
Immediate finality. One block per round, each committed block is final. There is no fork choice, no longest-chain rule, no reorganizations, and no confirmation counting. A block that reaches precommit quorum is the canonical block at that height. This is a different mental model from Bitcoin and Ethereum, and it's the property most of the rest of the design is built around.
Verifiable state, not trusted state. The chain state is committed to with a sparse Merkle tree. Any key can be proven against a state root, and the verification is a pure function — it performs no database access and no signature checks, and it doesn't trust the server that produced the proof. Proofs can be requested against historical versions, not just the current head. A client holding only a state root can verify a balance or any other value without syncing the chain. This is what makes a light client possible, and it's already exposed over both the RPC interface and the peer-to-peer protocol.
Rotating authority, not a rotating chain. Proposer selection rotates deterministically with every block height and every consensus round. The validator set itself rotates at epoch boundaries, but the rotation is sized so that it can never break the quorum needed to keep producing blocks. The chain doesn't reorganize. The authority to produce the next block does.
Technical summaryConsensus. A variant of Byzantine fault-tolerant consensus with three phases per round: propose, prevote, precommit. The protocol tolerates one-third of validators being faulty, with quorum requiring two-thirds plus one. Locking happens at precommit time rather than prevote — a variant of the standard Tendermint rule that is safe but has different liveness properties around the case where a validator crosses a round boundary while locked on a block. Emergency rotation exists for the case where the committed set can no longer form quorum: after thirty consecutive timeouts, the proposer can assemble a certificate of signed attestations from a sufficient subset of validators and stamp the block header with an emergency flag. Every verifier checks the certificate against the committed set before honoring the flag, which is what makes the flag non-arbitrary.
State. Storage is a memory-mapped key-value store. State commitments are a sparse Merkle tree. The tree root is written into every block header, and any two nodes with the same state produce the same root. Historical versions of every key are retained in a form that grows with state changes, not with block count, because unchanged subtrees are stored once and remain reachable from every later version's root.
Transactions. About fifteen transaction types, grouped by category: native transfers; token operations including create, mint, burn, transfer, and update metadata; staking operations including opt-in, opt-out, and claim rewards; validator operations including register, unregister, and update reward address; AMM operations including create pool, add liquidity, remove liquidity, and swap; limit-order operations including create and cancel; and three internal system transaction types for block rewards, expired orders, and slashing. Every user-submitted transaction is Ed25519-signed, carries a nonce for replay protection, a chain identifier, a fee, and a type-specific payload.
Economics. A fixed block reward is issued each block, split sixty percent to a validator pool and forty percent to a staker pool. The validator pool splits into a producer bonus for the block's proposer and a set share distributed across the active validator set. The staker pool accumulates in a smoothing pot and is distributed at epoch boundaries, currently every sixty blocks, at a target annual percentage yield. The target is composed of a base rate, a component that scales with transaction activity, and a component that scales with how full the pot is, capped at a maximum. Unallocated rewards from validator penalties, from unknown validator identifiers in the active set, from seed-only distribution, and from slashing all route to the pot. If the pot exceeds a configured maximum, the excess is burned.
Validator identity. Every validator has two keys with independent lifecycles, both derived from one mnemonic. The reward address is user-facing, mutable, and receives block rewards. The consensus key is the validator's signing identity for BFT purposes and is immutable after registration. They can be the same value — a validator registered with a single key uses it for both roles — but they don't have to be, and the point of the split is that changing where rewards are paid does not affect the validator's ability to sign consensus messages.
Slashing. Automatic, not voted. When a validator signs two conflicting votes at the same height and round, both signatures are verified and the conflict is recorded as evidence. The next block proposer includes a slash transaction carrying the proof, and every node independently verifies the proof during block application. A validator that equivocates loses a percentage of its stake, and its reward multiplier is reduced permanently. The slashed stake routes to the staker pot. A validator that has requested unregistration remains slashable for the full unbonding window, so an equivocation immediately followed by an exit is still penalized. Seed validators are exempt. Signatures are verified against the validator's effective consensus key, so a validator that has split its reward address from its consensus key remains slashable for any vote signed under the consensus key.
What I'm looking forHonest technical feedback, primarily on two things:
- The economic model. The pot mechanism is a smoothing buffer for staker rewards, and the seed-only distribution rule is unusual. I'm interested in whether the incentives actually work out the way the design intends.
- The light-client story. Proof-based verification is well-understood in isolation, but the mechanism for obtaining a trusted state root without syncing the chain is not fully closed. Currently the wallet fetches the root from one or two RPC endpoints and verifies proofs locally against it. The next step is fetching headers over the peer-to-peer protocol and following the header chain independently. If anyone has done this before and has opinions on the right way to structure it, I'd appreciate pointers.
I'm not looking for investors or validators just yet, only test users and early members with time on their hands. This is a technical pre-announcement. When there's a public testnet, I'll post about that separately.
LinksDocumentation, and a live explorer demo will eventually be linked when ready. This post is to gauge interest in the design before the infrastructure exists.
Discord:
discord.gg/gGjnyvxwFpGitHub Repo:
nullcryptodev/clarityTwitter/X:
@_nullcrypto
