Consensus and finality
Validator groups certify transaction batches for account ranges. Global consensus then commits one deterministic transaction order that every validator executes.
Routing and ordering
For sender address a and N groups, routing uses floor(a * N / 2^160). The sender's own address determines its group, including policy accounts. Signer addresses do not change its routing.
Ordering respects sender nonce dependencies and fee priority, with deterministic conflict/tie handling. Declared gas and other resource bounds constrain inclusion. A certified group batch is input to global agreement; it does not guarantee that each transaction will succeed after earlier transactions change shared state.
Weighted certificates
A quorum requires strictly more than two-thirds of all assigned weight. Offline members remain in the denominator. BLS12-381 keys need proof of possession and must be distinct. Signatures bind their committee, epoch and proposal context.
Votes and locks are durable before signing authorization. An unavailable leader triggers bounded round change; timeout alone does not erase a lock or authorize a conflicting vote. Authenticated new-view evidence governs advancement.
What finality means to an application
The RPC serves committed state. latest, safe, finalized and pending block tags identify the committed head; pending nonce reads additionally consider consecutive pool transactions. Under the consensus fault assumptions below, committed blocks do not reorganize. A receipt still needs a success status.
A certificate authenticates agreement. It is not a guarantee that a remote server will keep the body available forever. Proof verification and history availability are distinct.
Slots and execution time
Each non-genesis block carries a signed, strictly increasing slot on a 500 ms clock relative to an immutable genesis time. Its execution timestamp is the slot's start rounded down to whole Unix seconds. Slots can be skipped, and consecutive blocks can share a timestamp. A proposer signs only once its slot starts, so the ledger produces at most two blocks per second.
The default devnet and deployment profile suppress empty blocks, so an idle head can remain unchanged. Order events by height and ordinal; use the committed block timestamp for execution deadlines rather than deriving elapsed time from block count. See the migration guide for application implications.
Development and production boundaries
The reference node supports authenticated epoch history and stake-selected transitions. Development beacon shares are operator-dealt; production DKG and withholding-resistant randomness across committee changes remain open. The slot clock and its safety rules are implemented as a development profile. Proposals and new-view reports bind a slot; proposers sign and voters prepare only once their own clock reaches that slot; voters hold a proposal that arrives up to 30 slots (15 s) early and drop later ones. If a validator's clock falls behind a slot it already signed, a clock-health fault stops it signing proposals, votes and reports until the clock catches up; commits and catch-up continue. Slots only add rejection conditions: they never advance rounds, unlock bodies or authorize votes.
Weighted per-slot proposer draws, their withholding-resistant seed and the 512-slot epoch cycle remain proposals. A reference draw exists in the node but schedules nothing; proposers still follow height and round. The 500 ms slot duration is not a public latency SLA.
Security assumptions
Ledger safety assumes Byzantine validators hold less than a third of the global committee's weight. A group that loses a third of its weight can stall, and under the default inclusion policy that stalls the ledger: Joltzu prefers halting to finalizing conflicting blocks. Clocks affect liveness, not agreement. A new client should start from a recent, independently obtained checkpoint rather than trusting a long history served by one peer. Joltzu claims no protection against front-running; users rely on the limits they sign. The 500 ms slot duration is not a public latency SLA.