ProtoLedger Core (PLC)

ProtoLedger Core is a fully specified protocol for a distributed ledger that satisfies all ten canonical principles defined in the ProtoLedger Standard v1.0. It defines the consensus mechanism, cryptographic architecture, privacy system, scalability design, MEV resistance, identity layer, token economics, and governance model.

No existing production blockchain satisfies all ten principles. PLC is the specification of what one that did would look like. Every design decision in this document is traceable to a specific principle requirement. Every trade-off is documented. The specification is Apache 2.0 licensed — it exists to be built, forked, and challenged.

PLC uses a DAG-based BFT consensus protocol. The ledger is a directed acyclic graph where each vertex is a transaction batch and each edge is a causal reference. Validators propose vertices; the DAG structure provides total order without a single leader per round.

Byzantine fault tolerance. Safety holds when fewer than one-third of validators are Byzantine (f < n/3). This is the tightest achievable bound under asynchronous network assumptions. No trusted setup is required — validator set membership is determined entirely by stake and useful compute contribution.

Proof-of-Useful-Stake. Standard Proof-of-Stake ties consensus power to token holdings alone. PLC requires validators to contribute verifiable useful computation — specifically, zero-knowledge proof verification for pending transactions. Validators that fail to contribute useful work are slashed. This satisfies Principle 6 (energy proportionality) by ensuring energy expenditure produces verifiable output.

Finality. Deterministic BFT finality within 2 seconds. Once a transaction vertex is committed to the DAG, no reorganisation is possible under the Byzantine fault threshold. There is no longest-chain rule, no probabilistic finality, no confirmation waiting period.

Permissionless participation. Any entity may become a validator by locking stake above the minimum threshold. There is no whitelist, no foundation approval, and no delegated stake. Nakamoto Coefficient target: above 100 across all subsystems from genesis.

No ECDSA paths exist anywhere in PLC. There are no legacy key types, no compatibility shims, no planned migration periods. Every cryptographic primitive satisfies NIST PQC Level 3 or higher from genesis.

The ZK proving system uses recursive proofs to eliminate the trusted setup requirement. A one-time ceremony is not acceptable under Principle 1 (trustlessness) — if the ceremony is compromised, the entire privacy system is broken. Recursive proof composition removes this dependency entirely at the cost of larger proof sizes and higher proving time, which is the correct engineering trade-off.

All PLC transactions are shielded by default. Sender address, recipient address, and amount are never revealed on-chain. Transaction validity is proven via ZK-SNARK without revealing the underlying data.

Shielded pool. Every transaction joins the universal shielded pool. There is no "transparent pool" as a default — the pool that all transactions flow through is private. Transparent transactions are an explicit opt-in requiring the sender to attach a disclosure proof.

Viewing keys. Senders may generate viewing keys for voluntary disclosure to third parties (auditors, regulators, counterparties). A viewing key reveals the transaction details to the key holder without revealing the spending key. Disclosure is unilateral — the recipient does not need to consent.

Anonymity set. Because all transactions are shielded, every transaction contributes to every other transaction's anonymity set. This is qualitatively different from systems where privacy is optional — an optional privacy feature with 10% adoption provides near-zero privacy because the 10% are trivially distinguishable.

The DAG structure provides native parallelism. Independent transaction sub-graphs are processed concurrently without coordination. There is no leader bottleneck: multiple validators propose vertices simultaneously, and the DAG provides the causal ordering that a single-leader chain requires a sequential round-robin to achieve.

Target throughput. 100,000 transactions per second under adversarial conditions with f < n/3 Byzantine validators. This is not achieved by sacrificing decentralisation (Solana's approach) or finality (Bitcoin's approach) — it is a consequence of the DAG parallelism and the elimination of sequential leader rotation.

ZK proof overhead. Every transaction requires a ZK proof, which adds approximately 200ms of proving time on consumer hardware. This is a known cost accepted in exchange for default privacy. Hardware acceleration (FPGA/ASIC proving) reduces this to under 50ms. Client-side proving is the design choice — no centralised prover service is required or permitted.

MEV exists because validators see transaction content before ordering is finalised. PLC eliminates this structurally through content-metadata separation.

Encrypted mempool. Transactions are encrypted before broadcast. The mempool contains only commitment hashes and fees. Validators can order transactions — they cannot see what those transactions do. There is no profitable front-running strategy because there is no content to front-run.

Threshold decryption. After the DAG commits a vertex (ordering is finalised and irreversible), the validator set uses threshold decryption to reveal the transaction content. No individual validator can decrypt transactions unilaterally. Collusion to decrypt pre-ordering requires > 2/3 of validators, which is the Byzantine fault threshold — if they can collude to that degree, MEV is the least of the system's problems.

Base fee burned. All base fees are burned. Validators receive only the priority fee, which is fixed and visible pre-ordering. There is no fee-ordering incentive — transactions are sequenced in DAG topological order, not by fee.

Governance participation in PLC requires proof of unique human identity. Without this, quadratic voting collapses to plutocracy — a wealthy actor splits holdings across many identities and votes proportionally to wealth, not to person count.

DNA-anchored ZK identity. Each participant's identity is anchored to a unique biological signature processed entirely on-device. No biometric data ever leaves the device. The device generates a ZK proof that: (1) a valid biological sample was processed, (2) the sample corresponds to a unique nullifier not previously registered, and (3) two-factor liveness verification was completed. Only the nullifier is published on-chain.

Nullifier-only chain record. The chain stores only nullifiers — one per identity. A nullifier is a one-way cryptographic commitment that proves uniqueness without revealing the underlying identity. It is computationally infeasible to derive the identity from the nullifier.

Recovery. Identity recovery uses a Shamir secret sharing scheme distributed across the participant's own trusted contacts. No centralised recovery service exists. If the recovery shares are lost, the identity nullifier is permanently retired and a new registration is required.

Note: this is the most technically demanding component and the furthest from current production capability. It is included because its absence would make the Standard incomplete, not because it is solved.

Fixed issuance. PLC token issuance follows a fixed schedule defined in the genesis block and enforced by the state machine. No governance vote can alter total supply. Issuance goes entirely to validators as block rewards — there is no foundation allocation, no team vesting, no investor reserve.

Proof-of-Useful-Stake rewards. Validators earn rewards proportional to verified useful compute contributed (ZK proof verification) plus their stake weight. A validator that stakes the minimum and contributes maximum useful compute earns more than one that stakes the maximum and contributes minimum compute.

Fee burning. Base fees are burned. Priority fees go to validators. This creates deflationary pressure proportional to network usage without concentrating fee revenue in ways that distort validator incentives.

No pre-mine. The genesis block contains no pre-allocated tokens. Initial distribution is achieved through a provably fair public sale with a hard cap per identity (enforced by the ZK identity system). No entity may purchase more than 0.01% of the total supply in the initial distribution.

All protocol parameter changes in PLC are executed on-chain. There is no foundation, no core developer team with special upgrade authority, and no multisig with emergency powers. The upgrade path is encoded in the state machine and is subject to the same governance process as any other parameter change.

Identity-weighted quadratic voting. Votes are cast by verified identities (nullifiers) using quadratic weighting. Each identity may allocate vote credits; the vote weight is the square root of the credits allocated. This gives larger stakeholders proportionally more influence than in pure one-person-one-vote systems, while preventing plutocratic dominance.

Time-locked execution. Governance decisions are enacted after a mandatory delay of 30 days. This gives the community time to respond to decisions that pass with narrow margins. Any decision that passes with >80% supermajority may have its delay reduced to 7 days by a subsequent governance vote.

Emergency mechanism. There is none. Emergency powers are the mechanism by which governance is routinely captured. If a bug requires an immediate fix, the fix must pass the governance process. The 7-day minimum for supermajority decisions is the designed response speed for genuine emergencies.

DNA-anchored identity at scale. The identity system specified in Section 8 requires device-local DNA processing with sub-second ZK proof generation. Current consumer hardware cannot achieve this. FPGA-based proving reduces latency to approximately 2 seconds for current ZK proving systems, but on-device DNA processing remains a research problem. No commercial device performs DNA sequencing at the speed required without laboratory equipment.

Recursive ZK proofs without trusted setup. Eliminating the trusted setup from the ZK proving system via recursive proof composition is technically viable (see Halo2, Nova) but adds significant proof size and verification overhead. Verification on-chain within the 2-second finality window requires hardware that does not yet exist at the cost curves needed for permissionless participation.

Content-metadata separation without liveness risk. The encrypted mempool design requires validators to wait for threshold decryption after ordering. If a supermajority of validators are offline simultaneously, decryption stalls. The liveness design (timeout fallback to cleartext) reintroduces MEV risk during fallback. A liveness mechanism that does not reintroduce MEV is an open problem.

Build it. Fork it. Challenge it.

PLC is a specification, not a network. The gap between specification and production system is enormous — on the order of 5–10 years of engineering effort for a well-funded team. The open problems in Section 12 are genuine blockers, not implementation details.

If you are building a system that satisfies all ten principles, or working on research that addresses one of the open problems, the challenge process at /protoledger/challenges/ is the place to engage. The specification will be updated as the state of the art advances.