The MetaFabric: A Commitment Fabric for Trustless Ordering and State Validation

Introduction

The first blockchains grew from a lack of trust. They solved this problem with consensus: rounds of voting, duplication, and majority rule. This worked, but it was heavy, fragile, and expensive to maintain.

MetaFabric chooses a different approach. It doesn't rely on groups of miners or validators, and it doesn't wait for votes. Instead, it works like natural structures: weak threads gain strength through interweaving. The system holds together because its structure leaves no room for failure.

This is how stability is achieved without consensus.

Time isn't decided by majority vote, but by proofs of publication and delay—unbreakable signals of when something occurred.

Validity isn't assumed through re-execution, but proven through zero-knowledge proofs—small evidence that rules were followed.

Data isn't trusted to one keeper, but spread across many providers—available wherever honesty exists.

Order isn't negotiated, but calculated from a deterministic function—every client computes the same result.

In this system, no voting is needed, no committee is trusted, no central gate exists. What keeps the system together isn't agreement, but inevitability. History stands because breaking it would require breaking mathematics itself.

MetaFabric isn't a parliament of nodes, but an architecture of proofs—built once, permanent by design.

---

0. Goals & Constraints

Goal: Without consensus voting (no committees), provide a global order and unchangeable history, sustain 100,000-1,000,000 transactions per second, and maintain strong decentralization and censorship resistance.

Constraints:

• No permissions or governance committees.
• Light clients verify validity with constant-time checks per batch; time proof verification grows slowly with log size, and data availability sampling uses a security parameter. Client work stays lightweight on consumer devices.
• Upgrades must be predictable, rollback-safe, and vote-free.
• Reduced external trust: While TTM uses multiple independent sources (transparency logs, VDFs, beacons), the system degrades gracefully if sources fail instead of stopping completely.

---

1. System Overview

Three independent proof spines work together:

1. Batch DAG – unchangeable cryptographic history skeleton;
2. TTM (Trustless Time Mesh) – unbreakable publication & time from multiple independent sources;
3. ZK Validity – recursive aggregation proofs for correctness.

Core idea: Ordering comes from CDO (Canonical Deterministic Ordering) using TTM proofs; validity from ZK proofs; data availability is BYO-DA (bring‑your‑own DA/storage); irreversibility comes from requiring all spines to be compromised simultaneously. MetaFabric doesn't run consensus protocols; agreement emerges from identical deterministic functions over public proofs (algorithmic agreement), rather than voting.

1.1 Assumptions & Threat Model

• Cryptography: Hashes, signatures, and SNARK soundness are reliable.
• Time/Publication: Multiple independent transparency logs provide inclusion and consistency proofs; VDFs retain sequential hardness; beacons provide unbiased rounds. System continues operating even if some sources become unreliable, using quality scoring and source substitution via parameter updates. .... Data Availability: For any batch reaching Hard finality, at least one chosen DA provider stays retrievable within the retention window; clients penalize unreliable providers via quality scoring.
• Network: Messages are eventually delivered; no reliable global synchrony is assumed.
• No committees: No miner/validator sets or stake-based trust; parameters change only by announcement + timelock.

1.2 Execution Engines

MetaFabric separates ordering/proof mechanisms from execution engines. The system supports pluggable execution models:

• UTXO-based execution (described in §15): Unspent Transaction Outputs with deterministic state transitions
• Account-based execution: Future compatibility for EVM-style accounts with nonce
• RGB-style execution: Asset-specific execution models

Each batch specifies its execution domain in meta.execution_type, allowing multiple execution models within the same MetaFabric instance.

---

2. Batch Object

Batch {
  parents[]          : Hash[BatchRoot];
  bundle_commitment  : Hash;            // commitment to all contained transfers/txs
  da_roots[]         : Hash;            // commitments from chosen DA providers
  zk_agg_proof       : Proof;           // recursive aggregated ZK proof
  publish_intent     : Hash;            // binds batch to external publication targets/windows
  postage            : {pow_stamp | fee_receipt};  // anti-spam (work stamp or storage fee receipt)
  meta               : {version, params_hash, qos, execution_type};
  state_root         : Hash;             // execution-domain state commitment (e.g., utxo_root)
}

Hash family: BLAKE3 for object hashing; Poseidon2/Keccak inside circuits.

---

3. DAG & Convergence

• Append‑only: Each batch references one or more known parents; multiple parents form a DAG.
• Natural forks: Anyone may publish concurrently; forks are expected.
• Convergence: CDO + TTM proofs yield a single deterministic order. Conflicts (like double‑spends) are resolved by order; later items revert or are constrained.

---

4. TTM: Trustless Time Mesh

• Transparency Logs (CT/Rekor/Sigsum‑like): provide inclusion and consistency proofs.
• VDFs (Verifiable Delay Functions): sequential, non‑parallelizable time.
• Public Randomness Beacons (like drand): unpredictable, verifiable rounds.

Decentralization boosts:

• Maintain a replaceable global priority vector over multiple sources; any source can be swapped via the parameter schedule (see §10) using announcement + timelock, not voter
• Anti‑censorship: publish the same batch_root to many sources; use the earliest provable min_ttm_round.

---

5. CDO: Canonical Deterministic Ordering

CDO(batch) = (
  min_ttm_round,       // earliest confirmed publication round across accepted sources
  source_rank_vector,  // epoch-scoped priority vector over time sources
  leaf_index,          // log leaf index or equivalent proof position
  vdf_iters,           // sequential VDF steps as tiebreaker
  lex(batch_root)      // final fallback
)

Stability & epochs. The source_rank_vector is fixed within a parameter epoch and only changes via a ParamBatch after its timelock activates. Ordering uses the vector in effect at the batch's _min_ttmround.
Earliest round. min_ttm_round is derived from inclusion/consistency proofs, not wall‑clock timestamps. When multiple TTM sources report different rounds for the same batch, clients use the lexicographically smallest value among sources to ensure global determinism.
Complexity. Light clients check a constant‑size SNARK and polylogarithmic‑size TTM proofs; VDF steps are only used as a tiebreaker and verified succinctly.

---

6. BYO‑DA: Zero‑Staking Data Availability

• Bring‑Your‑Own: Submitters choose any DA/storage network (Celestia/EigenDA/Filecoin/IPFS/S3‑compatible, etc.). The protocol doesn't bind to a single DA.
• Commitment & Minimal Proofs: Each batch supplies da_roots[] and the minimal sampling/availability proof interface defined by the DA‑ABI (see Glossary).
• Zero staking: No deposits to slash; no bonded roles. Misbehavior can't be "fined"—instead, it fails to reach Hard finality via quality gating and client downgrading.
• Incentives & funding: Prepaid storage fees to providers; a public audit pool is funded by a fixed fraction of per‑batch fees (optionally low inflation) and pays out for verifiable unavailability reports (with cryptographic proof requirements to prevent false claims). No allowlists.
• Redundancy norm: Submitters should include ≥2 DA providers in da_roots[]. Clients may discount single‑provider batches in the quality score.
• Degrade not break: If data isn't retrievable, clients mark the batch Observed (see §12) and block Hard finality until availability improves.

---

7. ZK Validity

• Circuit layer: Execution-domain-specific rules (UTXO/accounts/RGB), signatures, range/homomorphic checks, state transition validity.
• Proof systems: Plonky2/Nova (fast recursion) or Halo2/KZG (mature tooling). Export a small constant‑size SNARK for light clients.
• Open prover market: Anyone can prove; submitters may outsource proving via off‑chain bidding. No whitelists.
• Consistent security parameters: All active batches within the same parameter epoch use identical ZK curve and security settings to maintain O(1) aggregation efficiency.
• Multi-domain circuits: Different execution domains may use identical proof systems but different constraint sets, allowing unified aggregation of heterogeneous execution models.

---

8. Anti‑Spam & Fees

• Postage = PoW‑stamp ∥ Fee‑receipt:
  • small/low‑freq: PoW‑stamp using memory‑hard, parameter‑tunable puzzles to reduce (not eliminate) ASIC advantage;
  • large/high‑freq: DA storage fee receipts (per‑byte pricing; portion burned; portion to providers/archives).
• Congestion control: Ordering via CDO is fee‑agnostic. Admission thresholds gate entry, not relative order: once admitted, batches are ordered solely by CDO.
• Sybil resistance: PoW baseline plus ephemeral source reputations—algorithmic and forgettable; no accounts or allowlists.

---

9. Adopted Optimizations (Your Selected Set)

9.1 Control/Data Split (CP/DP)

• Control Plane (CP): TTM + CDO + parameter timelock + quality score — handles only ordering & thresholds.
• Data Plane (DP): BYO‑DA + ZK prover market + batch assembly — handles throughput & correctness. DP supports self‑proving; the QoS module is optional and can be omitted in the MVP.
• Why it's elegant: CP is stable/slow‑moving; DP is autonomous/fast‑moving. Interfaces connect by proofs & thresholds, not organizations.

9.2 Anti‑MEV Privacy: VDF Time‑Lock Encryption (TLE)

• Submit: payload is encrypted with a VDF‑based TLE; only commitments are public.
• Open: ciphertext becomes decryptable after the preset delay—no threshold committees.
• Benefit: suppresses frontrunning/sandwiching while keeping the system fully permissionless.

9.3 ZK Prover Market QoS (Optional)

• Status: Optional enhancement; MVP can ship without it.
• Two pools: Spot (cheap/elastic) and Reserved (SLO‑backed).
• Payment: deliver a verifiable receipt (VC); release status via HTLC‑style conditions.
• Routing: match provers by historical SLO & price.

9.4 MVP vs Optional Enhancements (Six Metrics)

---

10. Upgrades & Parameterization (Vote‑Free)

• ParamBatch: carries changes to source ranks, PoW factors, DA retention, ZK curves/security levels.
• Activation: T_announce + ΔT_lock → T_activate; clients auto‑adopt at activation.
• Safety: During the timelock, if competing parameter packs exist, clients automatically adopt the one with the earliest activation time. If tied, clients deterministically choose based on the lexicographically smallest ParamBatch hash. This ensures algorithmic consistency without any voting mechanism or committee oversight.
• Client autonomy: Clients may continue using the current parameter set indefinitely without forced upgrades, maintaining system sovereignty.

---

11. Networking & Censorship Resistance

• P2P: libp2p / QUIC / GossipSub; messages carry minimal proof‑carrying data (PCD).
• Multi‑path publication: broadcast the same batch root across sources and regions.
• Anonymity: first‑class Tor/I2P support.
• Eclipse/DoS resilience: diverse bootstraps, frequent address churn, proof‑first forwarding, rate limiting by postage.

---

12. Light‑Client Verification (O(1))

1. Fetch TTM proofs and the CDO ordering tuple for the target batch.
2. Verify BYO‑DA availability (sampling/receipt). If insufficient, mark the batch Observed and stop.
3. Verify zk_agg_proof (constant‑size SNARK).
4. Verify parents[] continuity and bindings.
5. Apply state delta to the execution engine (section specified in meta.execution_type).

6. Mark finality tier:

   • Observed: batch published with TTM evidence but DA not yet retrievable or below Q_soft. State is not applied.
   • Soft: DA is retrievable and Q ≥ Q_soft; ordering is known; thresholds for Hard are not yet met.
   • Hard: Q ≥ Q_min and log + VDF thresholds are satisfied.
   • Eternal: archived across independent logs/offline attestations.

---

13. Comparison

---

14. UTXO Execution Engine

14.1 State Commitment Structure

UTXO Commitment: Each batch outputs an unspent transaction output set commitment (utxo_root) as a core public input to the ZK circuit.

Commitment Options:

• Utreexo: Light-client-optimized accumulator structure
• Merkle Forest: Branching tree for efficient sparsity
• Vector Commitments: KZG/Polynomial commitment scheme
• Sparse Merkle Tree: Classic sparse tree with lazy updates

State Transition Binding: parents_hash combined with prev_utxo_root → new_utxo_root creates cryptographic binding of parent-to-child state transitions within the circuit.

14.2 Transaction Structure

UTXOTransaction {
  inputs[]           : UTXOInput[];      // list of inputs consuming prev outputs
  outputs[]          : UTXOOutput[];     // list of newly created outputs  
  meta               : {version, locktime, fee_amount};
}

UTXOInput {
  prev_outpoint      : Hash[TxID || vout];
  inclusion_proof    : MerklePath;       // proof in prev_utxo_root
  nullifier_data     : Hash;             // witness for unique nullifier generation
  unlock_witness     : WitnessData;      // signatures/scripts/witnesses
}

UTXOOutput {
  value              : Integer;          // public amount or commitment
  asset_id           : Hash;             // optional asset identifier  
  script_commitment  : Hash;             // Taproot-style script tree root
}

14.3 Double Spend Prevention

Nullifier Computation: Each input generates a unique nullifier = H(prev_txid || vout || spend_pubkey || randomness). Circuit constraints ensure:

1. Batch-internal uniqueness: No duplicate nullifiers within a single batch
2. Cross-batch uniqueness: CDO ordering ensures deterministic resolution of opposing spends

Global Ordering Resolution: Multiple spends of the same prev_outpoint are resolved by deterministic CDO ordering—the first valid spend (by CDO) consumes the output; subsequent spends fail circuit validation.

14.4 Script System Integration

Lightweight Script Support (Recommended):

• Taproot/Tapscript-style commitment to output scripts
• Circuit verification of signature validation, time locks, multi-signature schemes
• No VM execution: Pure cryptographic constraints, SNARK-friendly primitives

Advanced Script Support (Optional):

• SNARK-friendly VM (R1CS ALU, Plonkish micro-VM) for program execution
• Public inputs bind script commitments to execution results
• TTM Integration: Time-lock scripts verify against TTM rounds instead of wall-clock time

14.5 Privacy & Multi-Asset Extensions

Confidential Amounts (Optional):

• Pedersen commitments for value hiding
• Range proofs (Bulletproofs/Halo2) in-circuit validation
• Conservation constraints verified on committed values

Multi-Asset Support:

• asset_id included in public inputs and conservation constraints
• Asset-specific parameters via special ParamBatch extensions
• Mint/Burn transactions with verifiable issuance policies

14.6 ZK Circuit Public Inputs

Core Data Bindings:

• parents_hash: Cryptographic binding to parent batches
• prev_state_root: Previous UTXO set commitment
• new_state_root: New UTXO set commitment after applying transactions
• da_roots_hash: Data availability commitments
• publish_intent_hash: External publication metadata
• params_hash: Parameter bundle hash for deterministic consensus

Optional Enhancements:

• nullifier_set_hash: Separate commitment to spent outputs set
• transaction_commitment_root: Merkle tree of transaction commitments

14.7 Light Client Verification

Minimal Sync Requirements:

• O(1) SNARK verification of batch validity
• Polylog TTM proofs for ordering confirmation
• O(k) DA sampling for data availability verification
• No full UTXO tree storage: Commitment-only verification

State Query Support: Individual UTXO inclusion/exclusion proofs against utxo_root for specific transaction validation without full node synchronization.

14.8 Parallel Processing Optimization

UTXO Parallelization Advantages:

• No shared state conflicts: Input-output independence enables natural batching
• Batch signature verification: Aggregated signature processing
• Membership proof aggregation: Multi-path Merkle proof batching
• SNARK-friendly operations: Addition circuits for UTXO accounting

Commitment Set Verifications: Batch-validate multiple UTXO inclusions against parent utxo_root using aggregated/folded membership proofs.

14.9 Data Structure Reference

message UTXOOutput {
  bytes asset_id = 1;
  uint64 value = 2;               // or commitment for privacy
  bytes script_commitment = 3;   // Taproot-style
}

message UTXOInput {
  bytes prev_outpoint = 1;        // txid || vout index
  bytes inclusion_proof = 2;     // Merkle path in prev_utxo_root
  bytes nullifier_witness = 3;   // witness material for nullifier
  bytes unlock_witness = 4;      // signatures/scripts/conditions
}

14.10 Migration & Coexistence

Namespace Isolation: UTXO domain transactions specify meta.execution_type = "utxo_v1", enabling coexistence with future account-based ("account_v1") or RGB-style ("rgb_v1") execution domains.

Cross-Domain Interoperability: CDO provides unified ordering across opposing execution models; batch-level isolation prevents domain-specific invalid states from affecting other execution engines.

---

15. Glossary of Core Terms

• TTM (Trustless Time Mesh): A set of independent time/publication sources (transparency logs, VDFs, randomness beacons). Provides inclusion/consistency and irreversible time progression without authority. Clients maintain a replaceable priority vector across sources; replacements occur only at parameter activation points.
• CDO (Canonical Deterministic Ordering): The lexicographic tuple (min_ttm_round, source_rank_vector, leaf_index, vdf_iters, lex(batch_root)) that yields one global order without voting. Agreement is algorithmic, not interactive consensus. CDO is a term coined in this specification; it is not borrowed from a preexisting standard.
• ParamBatch: A special batch carrying parameter updates (source ranks, PoW targets, DA retention, ZK curves). Activated via announcement + timelock; no voting.
• BYO‑DA (Bring‑Your‑Own Data Availability): Submitters choose DA/storage networks. The protocol defines a minimal DA‑ABI (commit/sample/retrieve/audit). No staking; batches failing availability/quality thresholds cannot reach Hard finality.
• DA‑ABI: Minimal interface every DA must expose: commit(root), sample(proof), retrieve(pointer), audit(report). Provider attestations are non‑authoritative and MUST NOT be used for allowlisting; they serve only as verifiable receipts.
• TLE (Time‑Lock Encryption): VDF‑based encryption that becomes decryptable after a preset delay, reducing MEV without threshold committees.
• Soft/Hard/Eternal Finality: Four‑tier with Observed pre‑tier. Soft = retrievable & ordered; Hard = thresholds met; Eternal = multi‑archive attestation.
• Q (Quality Score): Client‑side DA reliability (retrieval latency, success, audit hits). Hard finality requires Q ≥ Q_min.
• ZK Prover Market (Optional): Open market for proof generation. Spot (cheap/elastic) and Reserved (SLO). Payments released via HTLC‑style conditions against verifiable receipts. Optional for MVP.

---

16. How a Single Transfer Runs to Completion

When a user sends a payment in MetaFabric, the process looks different from traditional blockchains. There is no miner race, no validator vote, and no hidden committee. Instead, the transfer passes through a sequence of mathematical guarantees until it becomes irreversible.

Step 1. Transaction Creation

The wallet constructs a transaction: inputs (what coins are being spent), outputs (who receives them), and metadata such as fees. Each input is signed with the sender’s private key and turned into a unique nullifier, which prevents double spending.

Step 2. Optional Privacy – Time-Lock Encryption (TLE)

Before publishing, the wallet may encrypt the transaction payload with a VDF-based time-lock. Only a public commitment is visible at first; the transaction contents become readable after a cryptographic delay. This prevents frontrunning and MEV attacks without relying on threshold committees.

Step 3. Data Availability Anchoring (BYO-DA)

The encrypted transaction (or bundle of transactions) is stored with one or more data availability providers chosen by the sender—e.g., Celestia, IPFS/Filecoin, or any S3-compatible store. Each provider issues a root hash (da_root) as a verifiable receipt. Redundancy ensures the data can be recovered even if some providers fail.

Step 4. Proof of Work or Fee Receipt (“Postage”)

To prevent spam, the sender attaches either:

• a small memory-hard proof of work, or
• a fee receipt showing prepaid storage costs.

This acts like a postage stamp—proof that the sender paid to send their message.

Step 5. Batch Assembly

Transactions are grouped into a Batch object. Each batch includes:

• parent references in the DAG,
• the commitment to all included transactions,
• DA roots,
• a recursive ZK validity proof,
• the postage, and
• a new state root (e.g., UTXO set commitment).

The zero-knowledge proof can be produced by the sender directly or outsourced to the open prover market, ensuring every included transaction is valid.

Step 6. Publication in the Trustless Time Mesh (TTM)

The batch root is published across multiple independent time sources: transparency logs, VDF chains, and randomness beacons. Each returns proofs of inclusion and consistency. Together, these serve as cryptographic timestamps—evidence that “this batch existed no later than this round.”

Step 7. Canonical Deterministic Ordering (CDO)

Every light client collects the TTM proofs and computes the Canonical Deterministic Order:

(min_ttm_round, source_rank_vector, leaf_index, vdf_iters, lex(batch_root))

Because this formula is purely deterministic, all clients arrive at the same global sequence without voting or gossip. At this point, the transfer reaches Soft Finality—its position in history is fixed.

Step 8. Data Recovery and Proof Checks

Once the VDF delay expires, the encrypted payload can be opened. Light clients then:

1. Fetch samples from DA providers to ensure the data is retrievable.
2. Verify the constant-size SNARK proof of validity.
3. Confirm continuity with parent batches in the DAG.

Step 9. Finality Tiers

• Observed: The batch is seen in TTM, but data is not yet accessible.
• Soft: Ordering and availability are proven; clients can prepare state updates.
• Hard: All thresholds are satisfied (TTM, DA quality score, VDF checks). At this stage, the transfer is irreversible.
• Eternal: Independent archives and long-term attestations cement the history permanently.

Step 10. Settlement

The recipient’s wallet now shows the received funds, backed by:

• a ZK proof of correctness,
• a DA receipt ensuring the data exists,
• and a deterministic ordering proof from TTM/CDO.

No committee approved it, no miner voted on it—history stands because it cannot be broken without breaking mathematics itself.