Ledgera is a modular distributed ledger for organisations and devices that need to collaborate without relying on a central authority. A committee of nodes — the Ledgents — executes and certifies computations through threshold proofs, and a secure log anchors those proofs so they stay immutable, auditable, and reusable across parties. Each application configures only the certification and coordination it actually needs.
The Modular Distributed Ledger
Ledgera: Verifiable coordination — without the consensus overhead.
Ledgera is a distributed ledger designed for organizations and devices that need to collaborate without relying on a central trusted authority. A committee of nodes executes and certifies computations through threshold proofs, while anchoring them in a secure log makes those proofs immutable, auditable, and reusable across parties — without forcing every application into state-machine replication.
About Ledgera
Ledgera is not a monolithic state-machine blockchain that forces every application into a globally replicated world-state, nor a sequencer-based Layer-2 that re-imposes total order on workloads that don't need it. It is not anti-SMR either — applications that genuinely need state-machine replication can still use Ledgera's secure log as a total-ordering service. What Ledgera rejects is the assumption that every application must.
Not every distributed application requires the same form of coordination. Asset transfer, federated learning, multi-party computation, and access-control workflows can be made correct without total-order consensus — for them, consensus latency and message complexity are pure overhead. Ledgera treats cryptographic proofs as first-class output: verifiable and reusable across organisations, devices, and time, while auditability stays global and coordination becomes application-specific.
Architecture
Ledgera is built on a flexible pool of software nodes called Ledgents, each equipped with its own cryptographic identity. Ledgera decouples execution, proof production, storage, anchoring, and validation into five separable roles — so each application uses only the certification and coordination it actually requires. Each Ledgent could play any of these roles following specific deployment models.
Roles
Executors
Collectively execute application-declared Verifiable Functions and propose results to the Provers.
Provers
Run a Byzantine-quorum protocol to produce threshold-signatures: Proof of Computation certifying the result and Proof of Storage certifying the availability of stored data.
Storers
Persist results (and inputs, when needed) in a content-addressed replicated KVS, providing durable availability.
Loggers
Anchor proofs as transactions in the secure log — making them immutable, auditable, and reusable across parties.
Validators
Verify proofs presented as inputs and enforce application-level constraints over shared state (e.g. iteration counters, no double-spending).
Deployment models
A deployment model defines how many Ledgents are deployed and which of the five roles
each one plays — letting an application trade simplicity against per-role efficiency.
Throughout, f denotes the maximum number of Byzantine (faulty or malicious) Ledgents
the system is configured to tolerate, so each role's quorum bound is expressed in terms of it.
Fully Replicated
Every Ledgent plays all roles. Simple to reason about, but the whole pool inherits the strongest single-role bound — 3f + 1 from Loggers.
Role-specialised
Pools are dedicated to specific roles, each sized for its own Byzantine bound: 2f + 1 Provers, f + 1 Storers, 3f + 1 Loggers — optimal per role.
Compute–Persistence Split
The concrete role-specialised setup adopted in Fantastyc: one pool plays Executor, Prover, and Validator, while Loggers and Storers each form their own pool. Shipment-based Proofs of Storage keep KVS replication off the client's critical path.
For protocol details — proof construction, BFT thresholds, sequence flows, and deployment options — see the Yellow Paper.
Resources
Ledgera's own publications, together with the foundational research it builds on — so the design rationale can be traced all the way back to the literature.
From the Ledgera project
-
Ledgera Whitepaper
High-level introduction to Ledgera — vision, design rationale, and target use cases.
-
Ledgera Yellow Paper
Protocol-level specification — formal definitions, data structures, and the reference execution model.
-
Fantastyc — Blockchain-based federated learning made secure and practical
Boitier, W., et al. The precursor work that inspired Ledgera: a committee of nodes producing verifiable aggregation proofs, with the model stored off-chain.
Decentralized Applications
Many distributed workflows do not require a totally-ordered, replicated world state. Ledgera supports applications where coordination is configured to fit the workload — from oracle-like one-shot computations to multi-round federated learning and asset transfer.
Verifiable Storage
Content-addressed replicated KVS with explicit shipment evidence. Closest analogue: IPFS-like systems, but with first-class integrity and availability proofs.
Verifiable Compute (Oracle)
Stateless deterministic execution that returns a verifiable Proof of Computation — an externally checkable answer to a one-shot question, with no shared state required.
Composed Dataflows
Chain executions where one client consumes the certified result of another's computation — proofs become first-class composable inputs.
Federated Learning
Client model updates aggregation over multiple rounds. Validators track the iteration counter; Storers persist contributions; proofs certify that training followed the declared schedule.
Multi-Party Computation
Agreement on how input shares are distributed, while the rest of the computation remains private among the parties — without paying the full cost of consensus on every step.
Asset Transfer
Checking transactions for preventing double-spending and providing global auditability via the secure log.
Research Foundation
Ledgera challenges the assumption that every distributed application must adopt state machine replication. Our work explores when weaker coordination primitives suffice — and how to compose them safely.
- Beyond Total-Order Consensus — Byzantine quorum certification is strictly weaker than total-order consensus, and typically incurs lower latency and message complexity. For many applications Byzantine quorum certification is enough.
- Tunable Byzantine Resilience — Provers require
2f + 1nodes, Storersf + 1, and Loggers3f + 1. Role specialisation lets each pool be sized for its own threat model. - Proofs as First-Class Output — Ledgera Proofs of Computation (LPc) and Proofs of Storage (LPs) are threshold-signed Byzantine-quorum attestations: verifiable, reusable, and composable across organizations, devices, and time.
- Compute–Persistence Split — separating the Executor/Prover pool from Logger and Storer pools, with shipment-based Proofs of Storage that keep KVS replication off the critical latency path of client requests.
- Roots in Federated Learning — Ledgera generalises an architecture born from securing lightweight FL aggregation with a committee of nodes rather than a blockchain smart contract.
Features
Ledgera grows from a minimal certified-execution core toward full validation and shared-state coordination.
- Minimal core — certified execution of stateless Verifiable Functions with Executors, Provers, and Loggers; Proofs of Computation anchored in the Secure Log.
- Verifiable storage — Storers and shipment-based Proofs of Storage; Compute–Persistence Split deployment; content-addressed KVS persistence.
- Validation & shared state — Validators for proof-carrying composition, federated-learning iteration tracking, and asset-transfer double-spend prevention.
- Re-execution model & pipelines — stateful functions, stored artefacts as inputs to subsequent invocations, and richer application orchestration.
Team Expertise
Distributed Systems
Designs BFT protocols, deployment models, and the Ledgent role architecture.
Applied Cryptography
Threshold signatures, proof construction, and verifiability across organisations.
Applications & Pilots
Federated learning, multi-party computation, and asset-transfer use cases.
Releases
All Ledgera versions — what ships today, and what's on the way.
- v0.2.0 Jun 2026 Initial open-source release with Core functionality, its API, and a template for building Ledgera-based applications.
News
All Ledgera-related events — publications, demos, talks, and pilots.
-
2026 · June
DemoLedgera and its application to Decentralised Collaborative Fine-Tuning
An IEEE ICDCS 2026 Posters/Demonstration entry showing decentralised AI workflows in which multiple stakeholders jointly build training data and ML models — with verifiable execution, cryptographic proofs, and content-based auditability — delivering provenance, accountability and reproducibility without the overhead of a blockchain.
-
2026 · May 19
PaperLedgera Yellow Paper — revision 1 released
Protocol-level specification: role model, proof construction, BFT thresholds, and deployment options. Download (PDF).
-
2026 · February
PaperLedgera Whitepaper preprint published
Vision, design rationale, and the three flagship application patterns (federated learning, multi-party computation, asset transfer). Download (PDF).
-
2025 · June
TutorialTutorial: Decentralized Federated Learning — Enhancing Reliability with Blockchain
A structured look at when blockchain genuinely strengthens Federated Learning — its real strengths, trade-offs, and limits — and when alternative approaches can deliver similar reliability with fewer costs.
-
2024 · September
PaperFantastyc presented at SRDS 2024
Precursor work that inspired Ledgera: blockchain-backed federated learning aggregation made secure and practical (Boitier et al., IEEE SRDS).
-
Upcoming
EventPilot deployments & community updates
Industrial pilots and protocol updates will be announced here as they go live.