Ledger & Consensus

The ledger provides a common record of accepted network state. Wallets create signed transactions, nodes validate them against protocol rules, and validators work toward agreement on the next state. The Version 0.1 architecture proposes stake-secured Byzantine Fault Tolerant consensus rather than proof-of-work.

The exact state model is not yet finalized. At minimum, the production design must be able to determine which accounts or ownership records exist, what value they control, which transaction sequence is valid, and which validator and protocol state applies at a given finalized point.

Applications should not infer ownership from an unverified API response when their security model requires independent verification.

This is a conceptual lifecycle. Exact proposer selection, voting rounds, quorum thresholds, timeout rules, block format, and commitment proofs remain protocol-design work.

The design targets deterministic or near-deterministic finality: once the protocol-defined validator threshold commits a block, applications should be able to treat the resulting state as finalized under the network’s security assumptions. Production software must expose finality as an explicit state rather than asking application developers to guess based only on elapsed time.

Consensus design must specify both safety—honest participants do not finalize conflicting states under stated assumptions—and liveness—the network can continue making progress when enough participating validators are available. The precise Byzantine fault threshold and recovery behavior are not yet final.

Significant protocol changes are proposed to use eCoin Improvement Proposals (ECIPs). A mature change process should document motivation, specification, security impact, compatibility, deployment, and alternatives; then move through review, testnet implementation, security evaluation, and announced activation.