Towards a Commitment Fabric for Deterministic Ordering and State Validation: A Research Note on Proof-Based Settlement
A speculative architectural note on whether one can construct a globally ordered, immutable transaction history without consensus voting — relying instead on cryptographic proofs of publication, verifiable delay, zero-knowledge validity, and pluggable data availability. We wish to be clear at the outset: nothing described here has been implemented. It is an exploration of a design space, and we are uncertain whether the central idea is sound.
1. The Question We Are Trying to Answer
Classical blockchains achieve global ordering through consensus: a set of validators (or miners) vote on the contents and sequence of each block. This works, and the theory is by now well-understood. But it carries costs. Consensus requires communication rounds, which bound throughput. It requires honest majorities, which concentrate power. And it requires re-execution of transactions by all validators, which is wasteful.
We set out to ask: can one do away with consensus voting entirely, and replace it with a combination of cryptographic primitives that, taken together, provide the same guarantees — global ordering, transaction validity, data availability, and eventual irreversibility?
The approach we explore rests on four pillars:
- A batch DAG that forms an append-only cryptographic history.
- A time and publication layer built from multiple independent external sources — transparency logs, verifiable delay functions, and public randomness beacons.
- Recursive zero-knowledge proofs that attest to the validity of state transitions without requiring re-execution.
- Pluggable data availability, where submitters choose their own storage providers rather than relying on a protocol-mandated network.
The ordering of batches is derived deterministically from the publication proofs — every client computes the same sequence from the same public data. There is no voting, no committee, and no leader election. Whether this actually works in an adversarial environment is, as we shall discuss, very much an open question.
flowchart TD
classDef core fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
classDef external fill:diagramSurfaceMuted,stroke:diagramBorderMuted,stroke-dasharray:4 2,color:diagramText
subgraph Pillars["The Four Pillars"]
direction LR
DAG["Batch DAG<br/>Cryptographic History"]
TTM["Publication & Time<br/>Multi-Source Proofs"]
ZK["ZK Validity<br/>Recursive Proofs"]
DA["Data Availability<br/>Pluggable Providers"]
end
CDO["Canonical Deterministic<br/>Ordering (CDO)"]
CLIENT["Light Client"]
DAG --> CDO
TTM --> CDO
ZK --> CLIENT
DA --> CLIENT
CDO --> CLIENT
class DAG,TTM,ZK,DA,CDO core
class CLIENT external2. What We Mean by “No Consensus”
We should be precise about the claim, because it is easy to overstate.
We do not mean that the system is trustless in the purest sense. The publication layer relies on external services — Certificate Transparency logs, for instance, are operated by Google and other large organisations; the drand randomness beacon is run by a fixed consortium of academic and industry nodes. These are not consensus within our protocol, but they are trusted infrastructure outside it. A more honest description might be “multi-sourced trust” rather than “no trust”. We are distributing trust across multiple independent parties, not eliminating it.
What we do mean is that the protocol itself does not run a consensus algorithm. There are no validator sets, no stake weights, no voting rounds. Ordering is derived from publication timestamps, which are provided by external services and verified cryptographically. If one is willing to accept the security assumptions of those external services — and this is a genuine “if” — then the protocol does not need its own consensus.
We think this distinction matters, but we do not wish to pretend it is stronger than it is.
3. System Overview
The system is organised around a Control Plane and a Data Plane, which are deliberately kept separate.
flowchart LR
classDef cp fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
classDef dp fill:diagramSurfaceMuted,stroke:diagramBorderMuted,stroke-width:1px,color:diagramText
subgraph CP["Control Plane -- Ordering & Governance"]
direction TB
TTM_CP["TTM Sources<br/>Logs + VDF + Beacon"]
CDO_CP["CDO<br/>Deterministic Ordering"]
PARAM["Parameter Timelock"]
QS["Quality Score Q"]
end
subgraph DP["Data Plane -- Throughput & Validity"]
direction TB
BYODA["DA Providers<br/>(pluggable)"]
PROVER["ZK Provers<br/>(open market)"]
BATCH["Batch Assembly"]
end
WALLET["Client / Wallet"]
LC["Light Client"]
WALLET --> BATCH
BATCH --> BYODA
BATCH --> PROVER
BYODA -. "availability" .-> QS
PROVER -. "validity" .-> QS
TTM_CP --> CDO_CP
PARAM --> CDO_CP
QS --> CDO_CP
CDO_CP --> LC
LC -.-> WALLET
class TTM_CP,CDO_CP,PARAM,QS cp
class BYODA,PROVER,BATCH dp
class WALLET,LC cpThe Control Plane is responsible for ordering and governance. It is deliberately slow-moving and stable. It consumes TTM publication proofs, applies the CDO ordering function, manages parameter updates via timelocks, and tracks quality scores for DA providers.
The Data Plane handles throughput and correctness. Submitters assemble batches, store data with their chosen DA providers, and obtain ZK validity proofs — either by producing them locally or by outsourcing to an open prover market.
The two planes communicate only through proofs and thresholds, not through organisations or trusted intermediaries. This separation is, we think, one of the more sensible aspects of the design, though we acknowledge that it introduces complexity in the interface between the two.
4. The Batch DAG
The fundamental data structure is a directed acyclic graph of batches. Each batch is an opaque container that carries:
- References to one or more parent batches, forming the DAG structure.
- A cryptographic commitment to the transactions it contains.
- Roots from one or more data availability providers.
- A recursive ZK validity proof.
- A commitment binding the batch to external publication targets.
- An anti-spam token (proof of work or fee receipt).
- Metadata including version, parameter hash, and execution domain.
- A state root representing the post-execution state commitment.
flowchart TD
classDef batch fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
B0["Batch 0<br/>(genesis)"]:::batch
B1["Batch 1"]:::batch
B2["Batch 2"]:::batch
B3["Batch 3"]:::batch
B4["Batch 4"]:::batch
B5["Batch 5"]:::batch
B0 --> B1
B0 --> B2
B1 --> B3
B2 --> B3
B2 --> B4
B3 --> B5
B4 --> B5The DAG is append-only. Anyone may publish a batch at any time, referencing any set of known parents. Natural concurrency is expected and welcomed — forks are not an error condition but a feature of the design. Convergence is achieved not by discarding forks but by ordering all batches deterministically via the CDO function.
Conflicts — double-spends, for instance — are resolved by the canonical ordering: the first valid spend (by CDO rank) consumes the output, and subsequent attempts fail circuit validation. This is similar in spirit to how Bitcoin resolves conflicts within a block, but extended across the entire DAG.
5. Publication and Time: The Multi-Source Model
Rather than a single clock or a single publication oracle, we use multiple independent sources, each of which provides evidence that a particular batch existed by a particular time.
flowchart TD
classDef source fill:diagramSurfaceMuted,stroke:diagramBorderMuted,stroke-width:1px,color:diagramText
classDef proof fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
subgraph Sources["External Time & Publication Sources"]
CT["Transparency Logs<br/>(CT / Rekor / Sigsum)"]:::source
VDF["Verifiable Delay<br/>Functions"]:::source
BEACON["Randomness Beacons<br/>(e.g. drand)"]:::source
end
BATCH_ROOT["batch_root"] --> CT
BATCH_ROOT --> VDF
BATCH_ROOT --> BEACON
CT --> INCL["Inclusion Proofs"]
VDF --> SEQ["Sequential Proofs"]
BEACON --> ROUND["Round Proofs"]
INCL --> CDO_IN["CDO Ordering<br/>Input"]
SEQ --> CDO_IN
ROUND --> CDO_IN
class INCL,SEQ,ROUND,CDO_IN proofThe three source types serve complementary roles:
Transparency logs (CT, Rekor, Sigsum, and similar) provide inclusion proofs — cryptographic evidence that a particular hash was appended to a public, append-only log. They also provide consistency proofs showing that the log has not been tampered with historically. These are mature, widely deployed, and reasonably well-understood.
Verifiable Delay Functions provide sequential time proofs. A VDF is a function that requires a prescribed number of sequential steps to evaluate, but whose output can be verified quickly. This gives us a notion of time that is not reliant on wall clocks or trusted timestamps — it is time measured in irreducible computational steps.
Public randomness beacons provide round proofs — verifiable, unpredictable round numbers that partition time into discrete epochs. These are used to prevent grinding attacks on the ordering function.
We must be candid about the trust assumptions. Each of these source types is operated by external parties. A transparency log maintained by a single operator is, in the worst case, censorable. The drand beacon is run by a fixed set of participants. We do not regard this as a fatal objection — the sources are diverse and independent, and compromising all of them simultaneously is harder than compromising any one — but it does mean that the system’s security is not purely self-contained. The trust is distributed, not eliminated.
6. Canonical Deterministic Ordering
The central algorithmic contribution — if it can be called that — is the CDO function, which maps each batch to a position in a total order:
CDO(batch) = (
min_ttm_round,
source_rank_vector,
leaf_index,
vdf_iters,
lex(batch_root)
)The tuple is compared lexicographically. The min_ttm_round is the earliest round across all accepted time sources at which the batch’s inclusion was provable. The source_rank_vector is a fixed priority ordering over sources, determined by the current parameter epoch. The remaining fields break ties.
The key property is determinism: given the same set of publication proofs and the same parameter epoch, every client computes the same total order. There is no voting, no leader election, no view-change protocol.
We should note some subtleties that the above description glosses over. The min_ttm_round is defined as the earliest round at which inclusion was provable, not merely the earliest round at which inclusion was *claimed`. A source might claim to have included a batch at round r, but if it cannot produce a valid inclusion proof, the claim is disregarded. This distinction matters because it prevents a malicious source from simply asserting favourable timestamps.
That said, the definition of “earliest” across multiple sources is not without its difficulties. If a submitter publishes the same batch root to several sources simultaneously, the min_ttm_round will be the minimum across all of them. This creates an incentive to publish broadly — which is desirable from a censorship-resistance perspective — but it also means that a submitter with access to faster publication channels might obtain an earlier round than a submitter who is being censored by some sources. We are not entirely satisfied with this property, and we think it deserves further analysis.
7. Zero-Knowledge Validity
Each batch carries a recursive ZK validity proof that attests to the correctness of all state transitions within the batch. The proof system is not fixed at the protocol level; we expect Plonky2, Nova, Halo2, or similar systems to be used, depending on the execution domain and the performance requirements.
flowchart LR
classDef circuit fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
TX1["Tx 1"] --> AGG["Recursive<br/>Aggregation"]
TX2["Tx 2"] --> AGG
TX3["Tx 3"] --> AGG
AGG --> SNARK["Constant-size<br/>SNARK"]
SNARK --> CLIENT["Light Client<br/>Verify in O(1)"]
class AGG,SNARK circuitThe key design choice is that validity is proven, not re-executed. A light client verifies a single, constant-size SNARK. It does not need to replay transactions, maintain a full state tree, or trust any particular execution environment. This is, we think, a genuine improvement over the classical model, and the one part of the design about which we are most confident.
The circuit layer is execution-domain-specific. A UTXO-based execution engine would enforce nullifier uniqueness, input-output conservation, and script satisfaction. An account-based engine would enforce nonce ordering and balance checks. The protocol is agnostic to the choice of engine; each batch specifies its execution domain, and the corresponding circuit constraints are applied.
We should mention one practical concern. Recursive proof composition is fast improving but remains computationally expensive. Producing a recursive SNARK for a batch of, say, a thousand transactions may take minutes to hours on consumer hardware. This is why the design includes an open prover market: submitters who lack the hardware to produce proofs themselves can outsource the task. Whether this market will function efficiently in practice is, of course, another matter.
8. Pluggable Data Availability
Perhaps the most unconventional design choice is the “bring your own data availability” model. Rather than mandating a specific DA network, submitters may choose any storage provider that exposes a minimal interface — commitment, sampling, retrieval, and audit.
flowchart TD
classDef provider fill:diagramSurfaceMuted,stroke:diagramBorderMuted,stroke-width:1px,color:diagramText
classDef protocol fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
SUB["Submitter"] --> P1["Celestia"]:::provider
SUB --> P2["EigenDA"]:::provider
SUB --> P3["Filecoin / IPFS"]:::provider
SUB --> P4["Arbitrary S3-compatible"]:::provider
P1 --> ROOTS["da_roots[]<br/>+ availability proofs"]
P2 --> ROOTS
P3 --> ROOTS
P4 --> ROOTS
ROOTS --> BATCH["Batch"]
BATCH --> Q["Quality Score Q"]
Q -->|"Q < Q_min"| BLOCK["Hard Finality<br/>Blocked"]
Q -->|"Q >= Q_min"| ALLOW["Hard Finality<br/>Allowed"]
class BATCH,Q,ROOTS protocol
class BLOCK,ALLOW protocolThere is no staking, no bonding, no slashing. A DA provider that drops data is not “punished” in the economic sense. Instead, the consequences are reputational and functional: batches whose data becomes unavailable cannot progress beyond “Soft” finality. Clients track a quality score Q for each provider, and Hard finality requires Q to exceed a minimum threshold.
We recognise that this is a weaker incentive than, say, Celestia’s staking-and-slashing model. A rational DA provider with no bonded capital has no direct economic incentive to store data reliably. The countervailing forces are: prepaid storage fees (the provider is paid upfront), the reputational cost of being marked unreliable (future submitters will avoid the provider), and the audit pool (a publicly funded pool that pays out to anyone who can prove that a provider failed to honour a retrieval commitment).
Whether these incentives are sufficient is, we confess, unclear to us. The honest answer is that we do not yet have a satisfactory economic model for a zero-staking DA regime, and this is one of the weakest points of the design.
9. Finality Tiers
Finality is not a binary state. A batch progresses through four tiers, each representing a stronger set of guarantees:
flowchart LR
classDef tier fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
OBS["Observed<br/>TTM proofs only<br/>DA not yet verified"]:::tier
SOFT["Soft<br/>DA retrievable<br/>Q >= Q_soft"]:::tier
HARD["Hard<br/>Q >= Q_min<br/>VDF thresholds met<br/>Irreversible"]:::tier
ETERNAL["Eternal<br/>Multi-archive<br/>Long-term attestations"]:::tier
OBS -->|"DA verified"| SOFT
SOFT -->|"Thresholds met"| HARD
HARD -->|"Archival"| ETERNAL
OBS -.->|"DA unavailable"| STALL["Stalled<br/>(waits for DA)"]
class STALL tierObserved. The batch has been published to the TTM and its inclusion proofs are verifiable. The ordering is known. However, the data has not yet been confirmed as retrievable from any DA provider. State is not applied.
Soft. DA sampling confirms that the data is retrievable, and the quality score exceeds Q_soft. The batch’s position in the canonical order is fixed. Clients may tentatively apply the state delta, but should be aware that reordering is theoretically possible if earlier batches are discovered.
Hard. The quality score exceeds Q_min, and the VDF-based timelocks have expired. At this point the batch is considered irreversible. Undoing it would require compromising multiple independent time sources simultaneously, which we regard as impractical but not, strictly speaking, impossible.
Eternal. The batch has been archived across multiple independent long-term storage systems. This is a belt-and-braces tier, providing defence in depth beyond what the protocol itself guarantees.
The progression through tiers is client-verified. A light client needs only a constant-size SNARK, polylogarithmic TTM proofs, and a small number of DA samples to advance a batch to Hard finality. It does not need to maintain a full state tree or replay any transactions.
10. A Transfer End-to-End
To make the preceding concrete, we trace the lifecycle of a single payment from creation to Hard finality.
sequenceDiagram
autonumber
participant U as Sender Wallet
participant TLE as Time-Lock Encryptor
participant DA as DA Provider(s)
participant PK as ZK Prover
participant LOG as Transparency Logs
participant VDF as VDF Chain
participant BCON as Beacon
participant R as Receiver Wallet
U->>TLE: Encrypt payload (optional)
TLE-->>U: Ciphertext + commitment
U->>DA: Store ciphertext / bundle
DA-->>U: da_roots
U->>PK: Request validity proof
PK-->>U: zk_agg_proof
U->>U: Assemble batch (parents, commitments, proof, postage)
U->>LOG: Publish batch_root
U->>BCON: Publish batch_root
LOG-->>U: Inclusion proofs
BCON-->>U: Round proof
Note over VDF: VDF delay elapses
Note over TLE: Time-lock decryptable
R->>DA: Sample / retrieve data
R->>R: Verify SNARK, TTM proofs, parents
R->>R: Advance to Hard finality
R->>R: Apply state deltaThe sender constructs a transaction, optionally encrypts it with a VDF-based time-lock to prevent MEV, stores the payload with one or more DA providers, obtains a ZK validity proof, and assembles the batch. The batch root is published to multiple time sources. After the VDF delay expires, the payload becomes decryptable. The receiver’s client samples the DA, verifies the SNARK, confirms the TTM proofs, and — if all thresholds are met — advances the batch to Hard finality and applies the state delta.
No committee approved the transaction. No validator voted on it. Whether this is a strength or a weakness depends, we suppose, on one’s attitude towards the reliability of the underlying time sources.
11. Parameter Governance Without Voting
Protocol parameters — source priority vectors, PoW difficulty, DA retention windows, ZK curve choices — must occasionally change. The challenge is to effect these changes without introducing a governance committee or a voting mechanism.
Our approach is deliberately simple. A special batch type, the ParamBatch, carries proposed parameter changes. It announces an activation time and is subject to a mandatory timelock delay. During the timelock, anyone may publish a competing ParamBatch. Clients deterministically resolve conflicts by preferring the ParamBatch with the earliest activation time; ties are broken by the lexicographic order of the batch hash.
sequenceDiagram
autonumber
participant P1 as Proposer A
participant P2 as Proposer B
participant TL as Timelock
participant NET as Network
P1->>NET: ParamBatch A (T_activate = 1000)
P2->>NET: ParamBatch B (T_activate = 999)
NET->>TL: Both enter timelock
Note over TL: ΔT_lock elapses
TL-->>NET: ParamBatch B activates first (earlier T_activate)
Note over NET: All clients adopt B deterministically
Note over NET: ParamBatch A is ignoredThis mechanism is “vote-free” in the narrow sense that there is no ballot, no quorum, and no tally. But we should be honest about what it is not. It is not a substitute for social consensus. The parameters that get proposed, and the incentives that drive proposal, are determined by the human community around the protocol. A plutarchic regime in which the wealthiest proposer always wins the speed game would be no healthier than a plutarchic voting system. We offer no solution to this problem; we merely observe that it exists.
12. Anti-Spam and Sybil Resistance
Without validators to reject invalid batches, the protocol needs an independent spam filter. We use a dual mechanism: submitters attach a “postage” token to each batch, which is either a memory-hard proof-of-work stamp or a fee receipt for prepaid DA storage.
For infrequent submitters, the PoW stamp is sufficient. For high-throughput operators, the fee receipt scales more naturally. The choice is left to the submitter.
We note that memory-hard PoW reduces but does not eliminate ASIC advantage. A determined adversary with custom silicon will always outperform commodity hardware. The goal is not to level the playing field perfectly — that may be impossible — but to raise the cost of spam sufficiently that it does not become a viable attack vector.
13. Censorship Resistance
Censorship can occur at several points in the pipeline: the time sources could refuse to include a batch, the DA providers could refuse to store it, and the network layer could refuse to relay it.
The design mitigates these through redundancy and diversity:
- Batches are published to multiple time sources simultaneously. A submitter who is censored by one source can prove inclusion via another.
- DA providers are chosen by the submitter, not by the protocol. If one provider censors, the submitter can use another.
- The network layer supports multi-path publication, address rotation, and first-class Tor/I2P integration.
flowchart TD
classDef submitter fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
classDef path fill:diagramSurfaceMuted,stroke:diagramBorderMuted,stroke-width:1px,color:diagramText
S["Submitter"]:::submitter
S -->|"Path 1"| L1["CT Log 1"]:::path
S -->|"Path 2"| L2["CT Log 2"]:::path
S -->|"Path 3"| SIG["Sigsum"]:::path
S -->|"Path 4"| DRAND["drand"]:::path
L1 --> MIN["min_ttm_round<br/>= earliest across all"]
L2 --> MIN
SIG --> MIN
DRAND --> MIN
MIN --> ORDER["CDO Ordering"]
class ORDER submitterThis is not a panacea. A sufficiently powerful adversary could censor across all time sources simultaneously. But the cost of doing so is substantially higher than the cost of censoring a single validator set.
14. Execution Model
The protocol is agnostic to the execution model. Each batch specifies its execution domain, and the corresponding ZK circuit enforces the appropriate constraints.
We envisage three primary domains, though others could be added:
flowchart LR
classDef domain fill:diagramSurface,stroke:diagramBorder,stroke-width:1.5px,color:diagramText
BATCH["Batch"] --> TYPE{"execution_type"}
TYPE -->|"utxo_v1"| UTXO["UTXO Engine<br/>Nullifiers + conservation<br/>Taproot-style scripts"]
TYPE -->|"account_v1"| ACCT["Account Engine<br/>Nonces + balance checks<br/>EVM-compatible"]
TYPE -->|"rgb_v1"| RGB["RGB Engine<br/>Asset-specific state<br/>Client-side validation"]
class UTXO,ACCT,RGB,BATCH,TYPE domainThe UTXO model is the most natural fit. Each input generates a nullifier (a unique identifier derived from the outpoint and a spending key), and the circuit enforces that no nullifier appears twice. Double-spends across batches are resolved by CDO ordering: the first spend wins, and subsequent attempts fail circuit validation. This is clean and well-understood.
The account model is included for compatibility with existing smart contract ecosystems, though we note that it introduces nonce-management complexity that the UTXO model avoids.
The RGB-style model supports asset-specific execution with client-side validation, which aligns with the broader design philosophy of pushing verification to the edges.
15. What We Are Unsure About
We wish to conclude the technical sections by enumerating the aspects of the design about which we are least confident.
The trust boundary around time sources. The system’s security depends on the honesty and availability of external time sources. We have argued that distributing trust across multiple independent sources is an improvement over a single consensus, but we have not formally analysed the failure modes. What happens if two major transparency logs collude? What if drand’s participant set is compromised? These scenarios deserve rigorous threat modelling that we have not yet performed.
The CDO ordering under adversarial publication. A submitter with low-latency access to multiple time sources can obtain an earlier min_ttm_round than a submitter who is geographically or politically disadvantaged. This creates an ordering bias that is not present in proof-of-work systems (where latency matters for block propagation but not for the proof-of-work itself). Whether this bias is exploitable in practice is unclear to us.
The economic sustainability of zero-staking DA. As discussed above, we lack a convincing economic argument for why DA providers would store data reliably without bonded capital. The reputation and prepaid-fee mechanisms may be sufficient, or they may not be. We genuinely do not know.
Recursive proof performance. The throughput targets we have in mind require recursive SNARKs to be produced at a rate that current hardware may not support. We are cautiously optimistic that prover hardware and proof systems will continue to improve, but optimism is not a sound engineering basis.
Parameter governance. The timelock-based governance mechanism avoids voting, but it replaces it with a speed game. We are not convinced that this is an improvement in all respects.
Concluding Remarks
We have described an architecture that attempts to replace consensus voting with a combination of cryptographic proofs: publication proofs for ordering, zero-knowledge proofs for validity, and pluggable storage for data availability. The design is modular, the individual components are well-understood, and the separation of control and data planes is, we think, sound.
But the whole remains greater than the sum of its parts, and it is the interaction between the components that concerns us. The system is only as strong as its weakest external dependency. The ordering is only as fair as the publication infrastructure allows. The data availability is only as reliable as the economic incentives of unbounded storage providers.
We share this not as a finished design, but as a snapshot of work in progress. We are reasonably confident in the individual cryptographic primitives. We are considerably less confident that they compose into a system that is secure, fair, and practical under adversarial conditions. We would welcome analysis — particularly from distributed systems researchers with more experience in consensus than we have.