If you have worked with SNARKs or zkVMs, you have probably heard of Poseidon. The reason behind is simple: traditional cryptographic hash functions like SHA256 are catastrophically expensive to compute inside arithmetic circuits. Every bitwise operation, every XOR, every rotation translates to thousands of constraints in the proof system. Poseidon solves this by redesigning the hash function from the ground up to work natively in finite fields.

The core insight behind this design is that proof systems like Groth16, Plonk, or STARKs all work over finite fields (arithmetic modulo some large prime). So instead of bit-level operations in this setting, Poseidon operates directly on field elements. As such, the state is no longer a sequence of bits, but rather a vector of elements in F_p (for example p is 2²⁵⁴ for BN254 curves).

Sponge Construction

Poseidon uses the sponge construction. The idea is to maintain an internal state larger than both the input and output, then squeeze entropy through it. You have a state of width t field elements, and it is partitioned into a rate r and a capacity c where t = r + c. The rate is how many field elements you can absorb per iteration, while the capacity provides a security margin.

For instance, assume the case of Poseidon with t=3, so the state is three field elements. Setting r=2 and c=1 (absorb two field elements per round while one element stays as the capacity), and suppose we want to hash four field elements: [a, b, c, d]. The state starts at [0, 0, 0].

During absorption, we take the first chunk [a, b] and add it into the rate portion: state becomes [0+a, 0+b, 0] = [a, b, 0]. Then we apply the permutation function P to mix everything: state becomes [P₀, P₁, P₂] where those values depend on the complex mixing of a and b. Now we absorb the second chunk [c, d]: state becomes [P₀+c, P₁+d, P₂]. Apply the permutation again to get [Q₀, Q₁, Q₂].

Once everything is absorbed, we switch to squeezing. We output the first r=2 elements [Q₀, Q₁] as the hash. If we needed more output (say for a 3-element hash), we would apply the permutation again and output another r elements. The capacity c never gets directly exposed, which is what gives resistance to length extension attacks and maintains collision resistance. An attacker cannot efficiently reconstruct the internal state from the output because they could only see r out of t elements.

The Permutation Function

The heart of Poseidon is its permutation function, which gets applied repeatedly during both absorption and squeezing. Each round of the permutation consists of three layers. First is AddRoundConstants, where we add a predetermined constant to each state element. This breaks symmetry and prevents slide attacks. Second is SubWords, which applies a power map (S-box) to each element: we compute x^α where α is typically 5 or 7. This provides the only nonlinear component and is where most of the constraint cost comes from. Third is the MixLayer, which multiplies the state vector by a chosen MDS (Maximum Distance Separable) matrix to ensure that changes diffuse across the entire state.

Here’s what a full round actually looks like with numbers. Let’s say the state is [100, 200, 300] and α=5.

AddRoundConstants: Add predetermined constants, say C = [42, 17, 99]. The state becomes [100+42, 200+17, 300+99] = [142, 217, 399].

SubWords: Apply the S-box to each element. State becomes [142⁵, 217⁵, 399⁵]. These are huge numbers but remember everything is mod p. This is the nonlinear layer and costs one constraint per element in most SNARK systems.

MixLayer: Multiply by an MDS matrix M. For t=3, this might look like: M = [[2, 1, 1], [1, 2, 1], [1, 1, 2]]. If the state after SubWords was [s_0, s_1, s_2], the new state becomes: [2*s_0 + 1*s_1 + 1*s_2, 1*s_0 + 2*s_1 + 1*s_2, 1*s_0 + 1*s_1 + 2*s_2]. Each output element is a weighted sum of all input elements, ensuring complete diffusion.

The breakthrough in the original Poseidon design was the concept of partial rounds. Instead of applying the expensive S-box to all t state elements in every round, we can apply it to just one element for most rounds while still maintaining security. The structure is R_f/2 full rounds at the beginning, then R_p partial rounds in the middle where only the first state element gets the S-box, then R_f/2 full rounds at the end. (R_f refers to the total number of full rounds, where R_p refers to partial rounds)

For a typical configuration we might have 8 full rounds total (4 at the start, 4 at the end) and 56 partial rounds in the middle. So a partial round would look the same except in SubWords, we only compute state[0]^5 and leave state[1] and state[2] unchanged. This approximately halves the constraint count because the S-box is where all the cost is (80 S-box operations instead of 192 if all rounds were full).

The initial 4 full rounds ensure that by the time we hit the partial rounds, every state element is already a highly nonlinear function of the inputs. Each partial round then adds one more layer of nonlinearity to state[0], with the MDS matrix spreading that change across all positions. By the time of 56 partial rounds, the S-box has been applied 56 times to state[0], with the MDS matrix diffusing that nonlinearity to state[1] and state[2]. The final 4 full rounds then add another complete layer of mixing.

Poseidon2 Improvements

Poseidon2, published in 2023, takes this further with several optimizations. The main innovation is how the MDS matrix is constructed. The original Poseidon used a single MDS matrix throughout, but this matrix multiplication is actually pretty expensive in constraints because we need t² multiplications per round. Poseidon2 splits this into internal and external diffusion layers.

For the external rounds (the full rounds at the beginning and end), Poseidon2 uses a matrix M_E that is relatively dense but only applied infrequently. For the internal rounds, it uses a much sparser matrix M_I that is often circulant or nearly circulant, such that the matrix-vector product can be computed with far fewer field multiplications. Security analyses show that it is viable to use these cheaper matrices for the partial rounds because the full rounds at the boundaries provide enough mixing to prevent attacks.

The round constants are also generated differently in Poseidon2, using a more robust method that eliminates potential biases. Combined with improved cryptanalysis that allows for fewer total rounds while maintaining 128-bit security, Poseidon2 typically gives us 2-4x speedup in proving time compared to original Poseidon.

Barretenberg and Noir

Barretenberg is Aztec’s proving backend, it is a C++ library that implements various proof systems with custom gates and lookup tables. At this level, we are thinking about representing field operations as polynomial constraints.

For Poseidon2 in Barretenberg, each S-box operation can be done in a single custom gate that handles the multiplication chain efficiently. The matrix multiplications get compiled into linear combinations which are significantly cheaper in the constraint system. The result is that hashing 2 field elements with Poseidon2 might cost around 150-200 constraints total, whereas implementing SHA256 over the same field would cost hundreds of thousands.

Noir is the high-level language that compiles down to Barretenberg circuits. At the Noir level, we are not thinking about constraints directly but instead writing what looks like normal Rust code. But under the hood, the Noir compiler is making choices about how to represent them as arithmetic circuits. When we call the standard library’s Poseidon2 hash function, the compiler emits the optimized Barretenberg-specific implementation.

The great thing about this is that we can call std::hash::poseidon2::hash([x, y]) and get a cryptographically secure hash that is practical to prove. This enables things like Merkle trees in zkVMs, making the difference between a proof that takes seconds versus hours.

Why Poseidon2 is Secure

The security of Poseidon2 rests on a fundamentally different hardness assumption than traditional hash functions like SHA256. When you try to break Poseidon2 (finding two inputs that produce the same hash, or computing an input that hashes to a specific value) you end up needing to solve a system of multivariate polynomial equations over a finite field. This is the MQ problem (Multivariate Quadratic), which is NP-hard in the general case. The S-box operation raising elements to the 5th or 7th power creates these high-degree polynomial relationships. After just 8 full rounds, the output is a polynomial of degree 5⁸ = 390625 in terms of the input. Even with quantum computers and Grover’s algorithm, solving these systems at the scale of Poseidon would take far longer than the available time.

The MDS matrix plays a crucial role with its Maximum Distance Separable property guaranteeing that if you change k input positions, at least t-k+1 output positions must change. For the t=3 case, changing even one input element forces all three state elements to change after the MDS layer. This prevents differential cryptanalysis, where an attacker tries to track how specific input differences propagate through the function. With Poseidon, a single field element difference in your input affects all state elements after just one round, and the probability of finding a differential characteristic that holds through all rounds drops exponentially.

The partial round structure might seem like it would weaken security, but the sandwich design is what makes it work. An attacker trying to find a collision or preimage would need to simultaneously solve through the initial full rounds, track 56 rounds of partial-round diffusion, and invert through the final full rounds. The combined complexity of this meets the 128-bit security target.

The sponge construction adds another layer of security through the capacity. When you squeeze out the hash, you are only seeing r out of t state elements with the remaining c elements staying hidden. An attacker who wants to forge a hash or extend it would need to guess the capacity elements, with c around 254 bits (one field element), that’s 2¹²⁷ operations.

The specific attacks that cryptographers worry about for Poseidon include Gröbner basis attacks (trying to solve the polynomial system directly), algebraic attacks (looking for low-degree relationships), differential cryptanalysis (tracking how differences propagate), and invariant subspace attacks (finding symmetries in the permutation). The round constants are specifically chosen to break symmetries, the degree growth from the S-boxes makes Gröbner basis methods infeasible at 128-bit complexity, and the MDS diffusion kills differential characteristics. The original Poseidon paper included extensive cryptanalysis and added a security margin with the recommended parameters being stronger than the bare minimum needed.

Poseidon2’s security level is calibrated to 128 bits, which means an attacker with unlimited classical computing power would need about 2¹²⁸ operations to break it. That’s the same security level as AES128. With quantum computers, Grover’s algorithm could reduce this to 2⁶⁴, which is why some protocols are already planning for 256-bit security parameters for post-quantum resistance. But for current applications, 128 bits is considered the minimum acceptable security level for financial and cryptographic systems.

The Ecosystem

Poseidon2 is becoming a default zk-friendly hash in many modern zkVM/proving stacks, especially where Merkleization and recursion dominate runtime. SP1 uses Poseidon2 over the BabyBear field (with Plonky3-aligned parameters), and RISC Zero has adopted Poseidon2 in parts of its recursion pipeline. Plonky2 uses a Goldilocks-field Poseidon variant, while Plonky3 commonly uses Poseidon2 and supports multiple field/hash configurations. The exact parameters and optimizations differ, but the core idea remains the same.

The standardization around Poseidon2 is one of those quiet infrastructure wins that makes the entire ZK ecosystem viable. Without SNARK-friendly hash functions, you simply couldn’t build practical zkVMs or zkRollups. With them, you can prove execution of millions of instructions in reasonable time.

Lighter is an application-specific zk-rollup built on Ethereum for perp trading. Unlike general-purpose Layer 2 solutions, Lighter generates SNARK proofs for every order match and liquidation event, claiming to deliver centralized-exchange-level performance with millisecond level latency while maintaining cryptographic verifiability.

Architecture Overview

At the heart of the architecture sits the sequencer that consumes transactions from the mempool and executes them sequentially against the orderbook state. The sequencer determines transaction ordering, integrates with oracle networks for price feeds, and structures executed transactions into blocks and batches. The sequencer provides “soft finality” within milliseconds, but true settlement only occurs after proof verification on Ethereum.

The prover receives execution data from parallelized witness generator services, which transform sequencer output into circuit-friendly inputs. The proving system employs a multi-layer aggregation approach where hundreds of thousands of individual execution proofs are combined into a single batch proof.

This aggregation is what makes verification on Ethereum economically feasible. Once the Ethereum smart contracts verify the batch proof against the stored commitment, the canonical state root advances and any onchain messages like withdrawal transfers would execute. The sequencer also posts compressed state deltas to Ethereum blobs, ensuring sufficient data exists onchain for users to reconstruct their state and exit independently if necessary.

State Tree Structure

The entire Lighter state is encapsulated in a merkleized data structure, using Poseidon2 for hashing. The root hash of this tree serves as a cryptographic commitment to the complete protocol state. This is what gets stored and verified on Ethereum. When a proof “verifies”, it demonstrates that a claimed state transition correctly transforms one valid root into another according to the protocol rules.

The tree contains several specialized sub-trees optimized for different operations. The account tree stores all user-related data, with each account leaf containing enough information to reconstruct a user’s complete state for exit purposes.

Another subtree is the orderbook tree which directly enables the price-time priority guarantee by encoding both price and time-priority into the leaf index itself. The encoding means that traversing the tree naturally encounters orders in price-time order. This design enables O(log N) operations for order insertion, removal, and quote retrieval while requiring only a single leaf access for matching operations. When a taker order arrives, the circuit can prove the correct maker was selected by verifying the Merkle path to that specific leaf.

Transaction Flow

When a user submits an order through the API, it enters the Sequencer’s mempool. The sequencer then determines the ordering of transactions.

After ordering, the sequencer executes transactions against the current orderbook state, generating execution receipts broadcast back to users via the API within approximately 5 milliseconds. However, this confirmation is not yet settled on Ethereum. The sequencer has committed to a particular execution, but that commitment is not yet cryptographically bound.

In parallel, execution data flows to the witness generator services, which prepare inputs for the Prover. The Prover generates SNARK proofs for the batch execution. Once the proof is ready, it is submitted to Ethereum smart contracts along with the batch commitment. The contracts verify the proof and, if valid, update the canonical state root. At this point, and only at this point, is the execution truly final in the Ethereum security model.

What Lighter’s ZK Proofs Actually Guarantee

The cryptographic guarantees provided by Lighter’s SNARK proofs are real and significant, but they have precise boundaries that are often misunderstood.

Execution Integrity

The most fundamental guarantee is execution integrity: given a sequence of transactions and oracle inputs, the resulting state is computed correctly according to the protocol rules. The prover cannot produce a valid proof for an arbitrary state transition. If the protocol specifies that a limit order at price P should execute against the best available counterparty, the proof ensures this actually happened. This ensures that the sequencer cannot modify account balances arbitrarily, or fabricate positions out of thin air.

This guarantee extends to all protocol operations encoded in the circuits. The circuits effectively act as a deterministic state machine where the sequencer provides the input ordering and oracle data, and the output state is uniquely determined. Any deviation from correct execution will cause proof generation to fail or produce an invalid proof that Ethereum contracts will reject. This is what “verifiable execution” actually means—not that the inputs are fair, but that the computation on those inputs is correct.

Price-Time Priority Within Batches

Lighter’s matching engine enforces price-time priority at the proof level, which is a stronger guarantee than most competing designs. To understand why this matters, consider how many zk-rollup orderbooks work: the sequencer performs matching offchain and the proof merely confirms that two orders intersected at a valid price. In such designs, when multiple makers have orders at the same price level, the sequencer can choose which maker gets the fill. As such, a sequencer could systematically favor a market maker, and the proof would still verify since “maker A and taker B traded at price P” is a true statement regardless of whether maker A was first in line.

Lighter’s circuit actually verifies that the correct maker determined by time priority was selected. By encoding time priority into the leaf index alongside price, the tree naturally orders makers at each price level. The matching operation requires accessing only a single leaf to find the best counterparty, and the circuit verifies that this leaf was correctly identified given the tree structure. This means within a given batch, once orders are included, a friendly market maker cannot be secretly prioritized over an older order at the same price.

However, the limitation that “within a given batch, once orders are included” is crucial. The proof verifies correct matching against the orderbook state at proof time, but the sequencer controls which orders enter that state and when.

Data Sufficiency for Self-Custodial Exits

The proofs attest that the data posted to Ethereum blobs is sufficient to reconstruct user states, which can be cryptographically verified. The account delta tree tracks all state changes during a batch, and its serialization to blobs is part of what the proof verifies. A valid proof cannot be generated if the blob data is incomplete or inconsistent with the state transition.

This guarantee underpins the escape hatch mechanism. If the sequencer fails to process priority transactions within 14 days, the rollup freezes and users can exit by proving their balance against the frozen state root using only Ethereum-posted data. The exit circuit verifies Merkle membership proofs against the state root, allowing users to withdraw without any cooperation from the sequencer. This is a meaningful improvement over other designs which lack a forced withdrawal path entirely. In those scenarios the users would have no onchain recourse if the validators stopped cooperating.

What Lighter’s ZK Proofs Do NOT Guarantee

The Ordering Problem

The Lighter whitepaper explicitly states that the sequencer’s core function is to determine transaction ordering. The proofs verify that execution was correct given the ordering, not that the ordering itself was fair. This is a crucial distinction.

Consider a concrete attack scenario. A user submits a large market buy order. The sequencer observes this order in its mempool before deciding on transaction ordering. Nothing prevents the sequencer from: (1) inserting its own buy order first at a lower price, (2) including the user’s order next, which moves the price up due to its size, and (3) inserting its own sell order at the higher price. This is a classic sandwich attack.

Every individual execution in this sequence is “correct” and will produce a valid proof. The user received correct execution at the price available after the sequencer’s front-running order, but that price just happened to be worse because the sequencer moved it. The proof verifies exactly what it claims: correct execution of the ordered transactions. It says nothing about whether that ordering was fair or whether the sequencer extracted value from the user.

Preventing this type of MEV extraction would require additional mechanisms entirely outside the proof system. Threshold encryption could commit orders before their contents are revealed to the sequencer. Commit-reveal schemes could separate order submission from execution. Enforced arrival-time ordering based on external timestamps could constrain sequencer discretion. The claim that “ZK makes front-running cryptographically impossible” is factually false. The proofs guarantee execution integrity, not ordering fairness.

The Inclusion Problem

The proofs verify correctness for transactions that are included in a batch. They cannot prove anything about transactions that were not included. If a user submits an order and the sequencer simply doesn’t include it in the current batch, no proof violation occurs. The sequencer might delay an order for seconds, minutes, or indefinitely. It might drop the order entirely.

The priority transaction queue and escape hatch mechanism address a specific subset of this problem in censorship of exit operations. Users can submit withdrawals, position closures, and other priority operations directly on Ethereum L1, and the sequencer must process them within 14 days or the rollup freezes. This provides exit liveness, such that users can always get your money out eventually. But it does not address general trading inclusion since there is no mechanism forcing the sequencer to include your limit order within any particular timeframe.

This creates a form of soft censorship that doesn’t trigger the escape hatch. A sequencer could systematically delay orders from certain addresses, or orders above certain sizes, or orders that would move the market against the sequencer’s own positions. Users would experience poor execution without any protocol-level recourse, because their orders are eventually included and all included executions verified correctly.

The Oracle Problem

Another subtle limitation concern comes from oracle data. The circuits prove that liquidations, funding calculations, and mark price applications were computed correctly using the supplied oracle data. They cannot prove that the oracle data reflects actual market conditions.

If the sequencer supplies a mark price of $100 when the true market price is $95, and this causes a user to be liquidated, the proof will verify that the liquidation was correctly executed at the supplied price. The liquidation was “correct” in the cryptographic sense where the circuit logic for liquidations was faithfully executed. But it was economically unjust because the input was wrong.

Lighter uses Stork as the primary oracle provider and constructs mark prices as a median of three values: orderbook impact prices, EMA-capped premiums, and CEX median marks. This is more robust than single-source oracles, but each input has potential manipulation vectors, and the median requires corrupting only two out of three sources.

Conclusion

Lighter represents an advancement in verifiable exchange design. The ZK architecture provides genuine guarantees absent in most competitors. These properties are cryptographically enforced and represent real security improvements over trust-based alternatives.

However, engineers and traders must understand the precise fine prints. The ZK proofs do not prevent MEV extraction since the sequencer controls ordering and can front-run at will. They do not guarantee prompt order inclusion with soft censorship through selective delay produces valid proofs. They do not verify oracle accuracy and they do not provide privacy with orderflow being visible to the sequencer.

Stanford Blockchain Review
Volume 8, Article No. 6

📚 Guest: Prof. Dan Boneh — Stanford University
✍🏻 Author: Yavor — Cryptography at Stanford

⭐️ Technical Prerequisite: Advanced

Introduction

Folding has emerged as a practical way to scale proof systems: instead of proving every step of a large computation independently, or embedding full verifiers inside circuits, folding incrementally compresses many steps into a single accumulator that can be proved succinctly. Conventional schemes largely rely on discrete-log commitments, which are efficient today but not post-quantum and often force large field arithmetic that complicates implementations at scale. LatticeFold takes a different path: it seeks to bring plausible post-quantum security and hardware-friendly arithmetic to folding by building on lattice assumptions and Ajtai-style linear commitments.

In this article, we will first provide a concise crash course on folding, its relationship to zero-knowledge proof systems, and why folding matters for blockchains and rollups. We then develop a technical overview of the LatticeFold family (LatticeFold, LatticeFold+, and Neo), highlighting how their design choices aim to control norm growth while retaining succinctness. Finally, we discuss emerging deployments and an Ethereum-oriented outlook, including the role of folding in aggregating post-quantum signatures and how a Beam-style vision might benefit from these techniques. We would like to acknowledge Dan Boneh and Binyi Chen for authoring LatticeFold and LatticeFold+, and Wilson Nguyen and Srinath Setty for authoring Neo: these works collectively advance lattice-based folding and are the focus of what follows.

1 - A Crash Course on Folding and LatticeFold Preliminaries

Succinct proof systems (SNARKs) let verifiers check quickly that large computations have been performed accurately, but constructing a single “monolithic” proof of a massive workload can exhaust memory and time. A classic workaround is recursion: break the computation into chunks and prove each chunk, then prove the verifier of the previous proof, and so on. Folding offers a lighter alternative to running full verifiers inside circuits: it merges two instances into one accumulator instance while preserving correctness, so a long sequence of steps can be collapsed and proved once at the end. Formally, a folding scheme gives a reduction of knowledge from R_acc×R_comp​ to R_acc (R_comp being a single step of a computation, and R_acc relation that accumulates multiple computation steps), enabling many steps to be aggregated into a single statement about R_acc. This viewpoint underlies modern systems like HyperNova for customizable constraint systems (CCS)1.

An overview of folding, both the proving and verification stage, source

As to how this relates to existing zero-knowledge systems, zero-knowledge (ZK) and folding are complementary. ZK governs privacy, where one can prove correctness of a statement while hiding why the statement is correct (the witness)2, whereas folding governs scalability of recursion, that is accumulating many steps into one succinct object to be proved. A pipeline can therefore use folding to compress a long computation trace and then apply any desired SNARK/STARK (with or without ZK) to the final accumulator. This separation is valuable when moving from toy examples to real blockchain workloads (e.g., verifying an entire block or rollup batch).

Folding is important for blockchain systems since onchain and Layer 2 (L2) systems routinely confront proofs over billions of machine instructions or tens of thousands of signatures. Decomposing these tasks into chunks is natural, but repeatedly verifying full proofs inside circuits is expensive. Folding replaces those inner verifiers with simple linear updates to an accumulator, cutting prover memory and often reducing end-to-end proving time. In our interview, the authors emphasize precisely this pipeline: fold a large number of sub-statements (e.g., batches of signatures or trace segments) into one statement and prove that single accumulator at the end.

Most prior folding schemes use additively homomorphic commitments derived from discrete log (e.g., Pedersen). That choice has two ramifications. First, these constructions are not secure against large, fault-tolerant quantum computers. Second, they typically operate over large (≈256-bit) fields and require non-native arithmetic or elliptic-curve operations inside circuits, which inflates prover complexity. These issues show up in comparative analyses against schemes like HyperNova and Protostar3.

Given these problems, LatticeFold enters the picture to replace discrete-log commitments with Ajtai commitments over rings R_q, and bases security on the Module-SIS (MSIS) assumption, which is widely studied and believed post-quantum. Working directly in rings enables arithmetic over small moduli (e.g., 64-bit primes) that align well with modern CPUs/GPUs, avoiding heavy elliptic-curve work and non-native field emulation. The paper’s evaluation targets both low-degree relations (like R1CS) and higher-degree CCS, with an aim of maintaining competitiveness with leading pre-quantum schemes while adding plausible post-quantum security.

Ajtai commitments are succinct and linearly homomorphic, but they are binding only for low-norm messages. Naïvely folding by taking random linear combinations would cause witness norms to grow over many steps, eventually exceeding the binding bound B. This undermines soundness if left unchecked. LatticeFold tackles this by structuring each fold so that witnesses remain provably within a low-norm range throughout long folding chains.

At the high level, LatticeFold organizes each step into three phases, expansion, decomposition, and folding, and buttresses them with a compact range proof built from the sum-check protocol:

• Expansion reshapes the per-step relation so the accumulator and the next step can be combined without introducing problematic cross terms. For high-degree CCS, a preliminary linearization via sum-check avoids multiplicative blowups.

• Decomposition writes each committed vector in a small base b so that it splits into several low-norm “digits.” Instead of combining two large-norm vectors directly, the scheme works with many small-norm fragments, making subsequent linear combinations safe with respect to the required norm bound.

• Folding then aggregates those fragments using small-norm challenges drawn from a carefully chosen sampling set, preserving the low-norm invariant of the accumulator. A sum-check-based range proof certifies that all fragments truly lie in the claimed range, ensuring extractability remains compatible with the Ajtai binding guarantee.

At a conceptual level, readers can think of Ajtai commitments as matrix–vector products in a ring: public parameters define a random rectangular matrix A over R_q, and committing to a vector x amounts to computing Ax. Linearity gives the homomorphism needed for folding, while MSIS underpins binding for low-norm openings. The combinatorial work of LatticeFold is to make sure the running “sum” of many steps never escapes the allowed range, even when we fold thousands of times.

Because LatticeFold operates over 64-bit moduli, it aligns with commodity hardware and lends itself to GPU acceleration, an angle the interview highlights explicitly. This hardware fit is particularly relevant for blockchain pipelines that must process high-volume batches under tight latency and cost constraints. Moreover, folding can play a central role in Ethereum’s prospective migration to post-quantum signatures: many hash-based signatures could be folded into a single accumulator and then proved succinctly, providing the aggregation properties that BLS gives today in the pre-quantum world. These themes, GPU friendliness and signature aggregation, emerge repeatedly in ongoing experimentation the authors mention.

We have sketched folding’s motivation and the LatticeFold intuition without the algebra. In the next section, we will unpack how LatticeFold, LatticeFold+, and Neo instantiate these ideas, how expansion, decomposition, and folding are realized over Ajtai commitments; how sum-check certifies range constraints; and how higher-degree CCS is linearized for efficient accumulation.

2 - A Technical Deep Dive into the LatticeFold Architecture

In order to cover the LatticeFold algorithm completely, we must first precisely describe various cryptographic ideas that will be used for the larger scheme. The key contribution of LatticeFold is that it swaps the usual discrete-log (elliptic-curve) commitments used by prior folding schemes for Ajtai commitments built from lattices. Concretely, the public key is a random matrix , and to commit to a vector , one must compute . This commitment is binding (one can’t open it two different ways) as long as the committed vector is “small”, i.e., its entries have bounded size (more on “size” below). The binding guarantee relies on the Module-SIS (MSIS) hardness assumption, which is believed to be post-quantum secure.

A review of Ajtai commitments, source

If one wished to read the LatticeFold paper in detail, one would repeatedly see the word “norm” and its importance for it to be small. What does this mean? When we say an entry is “small,” we measure it with the ℓ∞ norm: this should be thought of as “the largest absolute coefficient you see.” Here, a “coefficient” means the integer coefficients of a ring element (a polynomial modulo X_d ⁣+ ⁣1) after reducing into [−q/2,q/2). For a vector of ring elements, ∥x∥∞ is the largest absolute coefficient appearing anywhere in the vector. Ajtai commitments are binding for vectors whose ℓ∞ norm is below a threshold B. If, during folding, our vectors grow beyond B, binding can break, and therefore LatticeFold is engineered to keep norms small at every step.

Additionally, LatticeFold works over a cyclotomic ring R=Z[X]/(Xd+1) and its mod-q version

Rq=R/qR. The relevance is that these rings (a set of elements where one can perform addition and multiplication) support fast number-theoretic transforms and are standard in lattice cryptography. Using such rings also makes 64-bit arithmetic feasible in practice.

Furthermore, both R1CS and CCS (terms used frequently in LatticeFold and other literature relating to folding) are ways to encode a computation trace (such as a program execution) as algebraic constraints. This “arithmetization” is what proof systems operate on, as they lend themselves to various algebraic cryptographic operations. R1CS uses only quadratic (degree-2) constraints, whereas CCS (customizable constraint systems) allows higher-degree gates, which can be more compact for some workloads. Folding schemes like HyperNova and LatticeFold target CCS so they can handle both low- and high-degree circuits efficiently.

Given all of this, LatticeFold turns each fold into three steps: expansion, then decomposition, then finally folding. There is also a lightweight range proof ensuring every committed vector really is low-norm.

Expansion: The purpose of this step is to make folding algebraically simple: before we combine “the accumulator” with “the next step,” we rewrite the step’s CCS relation into a linearized form that is easy to add up. This mirrors HyperNova’s linearization (done there over fields), adapted here to rings. One can think of it as moving to a representation where “adding instances” corresponds to “adding their commitments and claims” without creating hard cross-terms.

Decomposition: Here, we wish to break apart big numbers into smaller, more manageable digits. If we combined two witnesses directly, their entries would grow and eventually exceed the binding bound B. LatticeFold avoids this by writing each vector f in base b so all pieces are tiny:

Here, b is a small base (e.g., 2 or 4), k is the number of digits, and B=b^k is the overall bound we’re willing to allow. After decomposing two witnesses, we have 2k low-norm fragments instead of two large-norm vectors. (A standard “gadget” map makes this decomposition deterministic and efficient).

Folding: Finally, we wish to combine many small pieces safely. To fold, the verifier samples small-norm challenges ρ_1,…,ρ_2k from a strong sampling set, a set of ring elements whose pairwise differences are invertible and whose coefficients are tiny enough that multiplying by them doesn’t blow up norms too much. The prover forms one folded witness:

Because each f_i​ has tiny entries and each ρ_i​ has tiny coefficients, the key bound holds:

where c is a constant capturing the “expansion factor” of the challenge set (how much norms can grow when we multiply by a challenge). This inequality says the folded witness still lives inside the binding range, so we can keep folding. The “invertible differences” property guarantees the knowledge extractor (used in the security proof) can safely undo combinations.

A precise diagram of the Decomposition and Folding stages (a_1, .. , a_k are equivalent to f_0, … f_k-1), source

All this only works if the prover proves its digits f_i are genuinely small and within the promised range (e.g., [−b,b]). LatticeFold encodes “u is in range” as a small polynomial identity whose zeros are exactly the allowed values, then uses sum-check over the ring to verify it for all positions at once. Sum-check is a classic subprotocol that lets a verifier check “the sum of many polynomial evaluations equals T” by interacting over a few rounds with much smaller polynomials. In short, one proves that the pieces are small, then small challenges keep them small when combined.

As to how the parameters b and k are selected, a tiny base (2 or 4) is used in practice for b. Larger bases make range proofs heavier without enough payoff. k is chosen so that the safety inequality 2k c (b−1)  <  B  <  q/2 holds comfortably, where the left side is “worst-case growth per fold,” and the right side keeps it below the modulus’s halfway point (a standard safety margin). Larger k increases B exponentially but makes decomposition produce more pieces per fold, thus implementations tune k for their workload and challenge-set constant c.

Why does the above scheme work? Well, the Ajtai commitment is linear (which means A(x+y)=Ax+Ay) and binding for low-norm messages under MSIS. This linear structure allows for commitments to be added during folding, and binding is preserved by staying below B. Decomposition works because the extractor for security reasons may need to divide by a random difference like (ρi−ρj). Doing everything at the tiny-digit level ensures that even after algebraic manipulations, the extracted pieces remain within range.

As monumental as the LatticeFold paper is, subsequent iterations and modifications have come out that have presented updates and optimizations. One such paper is LatticeFold+, which addresses the fact that LatticeFold’s heaviest subroutine is the range proof (checking that all digits lie in range), which in the original protocol used bit-decomposition and many commitments. LatticeFold+ replaces this with a purely algebraic range proof:

• The prover commits to monomials m_i=X^(f_i) (one per entry) and proves two things: (i) each m_i is indeed a monomial, and (ii) a simple algebraic relation holds between mi and the original fi. From these two facts, it follows that every fi lies in (−d/2,d/2). This avoids committing to bits entirely and dramatically shrinks the work.

• To keep transcripts short when vectors have d coefficient “slices,” LatticeFold+ introduces double commitments, “commitments of commitments”, so the verifier receives one compact object instead of d separate commitments. A commitment transformation step (checked by sum-check) then maps this object back into an ordinary linear commitment that the folding machinery can handle. Net effect: shorter proofs and a simpler recursive verifier.

• Structurally, LatticeFold+ folds L>2 linear instances into one instance with a temporarily larger bound B^2, then uses a high/low split (a mini-decomposition) to return to two instances with bound B. This two-step trick achieves lower overall cost than doing many bit-based range proofs.

In short, LatticeFold+ keeps the LatticeFold backbone but removes the bit-decomposition tax and compresses the recursion layer. That means faster provers and a smaller verifier circuit in practice4.

Neo, another paper that builds on LatticeFold, keeps the lattice security foundation but designs the commitments and reductions so that folding can run over small prime fields (e.g., Mersenne-61 or Goldilocks) and, crucially, the cost to commit scales with bit-width (“pay-per-bit”), similar to what Pedersen/KZG do, something LatticeFold’s ring embedding did not achieve5.

• Why pay-per-bit matters: Many witnesses are mostly small values or bits (flags, Merkle checks). Neo’s commitment maps field vectors into ring elements so that multiplying by a binary “mask” only adds a few columns, hence cost scales with the number of 1-bits. The mapping retains the linearity needed for folding evaluation claims.

• Strong sampling and invertibility: As in LatticeFold, challenges come from a strong sampling set whose differences are invertible; Neo leverages explicit low-norm invertibility bounds to pick these safely in small fields.

• Three reductions, field-first. Neo composes: (i) CCS → (partial) evaluations via sum-check; (ii) random linear combination of k+1 claims into one B=bk claim; (iii) decomposition to keep norms under the binding threshold. It’s the same general algorithm (linearize, combine, keep small) but engineered for small-field arithmetic and “pay-per-bit” commitments.

Taken together: LatticeFold gives the first lattice-based folding with disciplined norm control over rings, LatticeFold+ streamlines range proofs and shrinks recursion artifacts, and Neo unlocks small-field performance and pay-per-bit costs while staying plausibly post-quantum. The architectural through-line, decompose into small pieces, combine with small challenges, certify with sum-check, is what makes the whole family practical.

3 – Latticefold’s deployments and its future with Etherium

Early implementations are underway. In our interview, the authors noted that NetherMind is actively prototyping both LatticeFold and LatticeFold+, with performance numbers expected from that effort; other groups are experimenting as well. While results are still being finalized, the direction of travel is clear: evaluate LatticeFold’s recursion in real proving pipelines and compare it to pre-quantum baselines.

Two engineering properties make these prototypes attractive. First, LatticeFold works over small (≈64-bit) moduli and a single module structure, avoiding heavy elliptic-curve arithmetic and non-native field emulation inside the accumulator relation. That tends to simplify implementations relative to group-based folding. Second, 64-bit rings map cleanly to GPUs, and even to prospective FHE accelerators that operate over similar number-theoretic rings, so hardware built for FHE may also accelerate lattice-based folding. These factors are explicitly highlighted by the authors as reasons implementers expect good constant factors once code paths are tuned.

As to what earlier adopters are likely to try first, short-term experiments are natural where (i) workloads are embarrassingly parallel (e.g., batched signature checks, Merkle membership checks, or trace segments), and (ii) the folding verifier must stay small for recursion. The LatticeFold paper reports performance that is comparable to HyperNova for degree-2 relations and better for high-degree CCS, suggesting that CCS-heavy zkVM circuits, rollup state transitions, or hash-heavy workloads may be a good initial fit. Fold many sub-instances to a single accumulator; then produce one succinct proof at the end.

There are many possible future research directions, but as is described by the authors, LatticeFold+ shows that purely algebraic range proofs and a commitment-to-commitments “compression” step can shorten proofs and reduce the recursive verifier (fewer hashes in the Fiat–Shamir circuit), aiming for a faster prover than HyperNova while retaining plausible post-quantum security. The paper emphasizes that folding proofs act as recursive witnesses, they do not appear on chain, so shrinking them chiefly reduces the recursive verifier cost, not the final on-chain proof size. The authors also flag two open avenues: (1) re-working the analysis and subprotocols in ℓ₂ (which can improve MSIS parameters), and (2) generalizing beyond prime moduli (e.g., powers of two) for implementability

Neo pushes in a complementary direction: preserve lattice assumptions but fold over small prime fields (e.g., Mersenne-61 or Goldilocks), avoid costly cyclotomic-ring sum-checks, and restore “pay-per-bit” commitment costs so committing to bits is far cheaper than to 64-bit words. That unlocks fast arithmetic and a single sum-check invocation, two practical wins for real systems, while staying plausibly post-quantum.

Finally, it is critical to discuss Etherium’s BeamChain vision and how LatticeFold might contribute to this ecosystem. At a high level, BeamChain is a conceptual direction for Ethereum that simplifies the consensus layer and moves succinct proofs to the center of the protocol. A concrete driver is post-quantum migration: Ethereum today relies on BLS for validator signatures (aggregation and thresholding are essential to PoS), but there is no drop-in post-quantum scheme with the same aggregation properties. The working plan is to adopt hash-based signatures for security, and then recover aggregation-like compression by SNARK-ifying many signatures into a single succinct proof6. The authors underscore that this can be done monolithically, that is fold first, then prove once. Folding promises to reduce prover memory and latency by replacing “verifying a full proof inside a circuit” with lightweight accumulator updates over the epoch.

An overview of the BeamChain Vision, source

For BeamChain-style consensus, validators produce large batches of post-quantum signatures (e.g., per-slot attestations). Instead of building one giant monolithic proof per slot or per epoch, the pipeline can: (1) verify a chunk of signatures, (2) fold the resulting statements into the epoch’s accumulator using Ajtai commitments and small-norm challenges, and (3) repeat across slots; at epoch end, produce one succinct proof of the accumulator’s validity. Folding keeps the recursive verifier small and uniform, and the arithmetic (64-bit rings) maps to commodity hardware and GPUs. In effect, LatticeFold gives consensus designers a recursion substrate that is plausibly post-quantum secure and tuned for high-throughput batch workloads.

In our interview, the authors suggested evaluating a folding-first approach against a STARK-first or monolithic baseline along common KPIs: proof size (for on-chain verification and propagation), end-to-end latency (time to finality), and decentralization (hardware requirements for home validators and community provers). Folding contributes by lowering prover memory and allowing work to be pipelined through slots into a single epoch-level statement. The on-chain interface would still verify a single succinct proof; folding lives off-chain as part of the recursive construction, so the on-chain verifier does not need to check intermediate folding proofs. (LatticeFold+ explicitly notes that folding proofs are recursive witnesses, not part of the final proof object.)

Hash-based signatures are robust and simple, but they are large and numerous. Folding converts “verify N big signatures” into “update an accumulator N times,” which is fundamentally cheaper to express than re-verifying a full proof N times in-circuit. The authors argue this may “dramatically speed things up,” pending experimental confirmation from NetherMind and others. In other words, if Ethereum’s post-quantum path is “hash-based signatures + succinct aggregation,” a lattice-based folding substrate provides the missing accumulation primitive with post-quantum plausibility.

The 64-bit arithmetic in LatticeFold is a pragmatic match for GPU vector units; implementers are already targeting GPU folding. Longer-term, specialized FHE ASICs (designed for similar ring operations) could double as folding accelerators, aligning consensus-critical proving with a broader hardware roadmap. That is an unusual and promising alignment: investment in FHE hardware can amortize to proving infrastructure.

LatticeFold+ trims the recursive verifier and speeds the prover via algebraic range proofs and double-commitment compression. In a BeamChain pipeline this reduces the cost of the recursion layer, making per-slot updates cheaper and shrinking the accumulator circuit budget. Neo complements this by allowing folding directly over fast small fields (M61, Goldilocks), restoring pay-per-bit commitment costs and eliminating the 10–100× overheads associated with cyclotomic ring sum-checks, useful when the workload is bit-heavy (hashes, flags, Merkle checks). Together, they suggest a migration path from “LatticeFold as first prototype” to “LatticeFold+ for practical recursion” to “Neo for small-field, bit-efficient deployments.”

Some protocol engineering remains. Neo documents constraints on LatticeFold’s ring choices (full splitting can harm security), motivating its shift to small fields; compatibility and parameterization across clients need careful study. More broadly, the community will want head-to-head measurements of end-to-end latency, GPU utilization, and operator costs under production loads, and a clear story for proving service decentralization. Finally, formalizing ℓ₂-based analyses and supporting non-prime moduli (both flagged by LatticeFold+) would broaden parameter choices and simplify implementations.

BeamChain’s post-quantum vision, hash-based signatures plus succinct aggregation, pairs naturally with lattice-based folding. LatticeFold provides the core reduction-of-knowledge machinery over 64-bit rings; LatticeFold+ makes the recursion layer slimmer and faster; Neo opens small-field routes with pay-per-bit commitments. If experiments from NetherMind and others validate the anticipated gains, Ethereum can plausibly adopt a folding-first accumulation layer for post-quantum consensus, with a familiar on-chain footprint (one succinct proof per epoch) and a flexible, hardware-friendly off-chain pipeline.

Conclusion

Folding is emerging as the practical engine of scalable, recursive proving: it aggregates long computations into a compact accumulator, leaving privacy to the underlying proof system and shifting the performance focus to efficient, repeatable updates. LatticeFold shows how to realize this paradigm on lattice assumptions: replacing discrete-log commitments with Ajtai commitments, operating over 64-bit rings, and, crucially, controlling norm growth via base-b decomposition, carefully sampled challenges, and sum-check–based range arguments. LatticeFold+ refines the recursion layer with algebraic range proofs and double-commitment compression, substantially reducing prover work and the size of the recursive verifier. Neo pushes further by enabling small-field, “pay-per-bit” commitments while preserving a post-quantum foundation.

These advances are not merely theoretical. Early implementations are exploring performance on real pipelines, and the Ethereum-facing BeamChain vision highlights a compelling application: aggregating large volumes of post-quantum signatures by folding per-slot statements into a single epoch-level proof. The hardware fit, 64-bit arithmetic and GPU-friendliness, strengthens the case for practical adoption.

We would like to acknowledge Dan Boneh and Binyi Chen for LatticeFold and LatticeFold+, and Wilson Nguyen and Srinath Setty for Neo. Together, these works chart a credible path from post-quantum security assumptions to deployable, high-throughput recursion, an essential ingredient for next-generation rollups, consensus, and verifiable computation at blockchain scale.

About the Interviewees

Prof. Dan Boneh

Professor Boneh heads the applied cryptography group and co-directs the computer security lab. Professor Boneh’s research focuses on applications of cryptography to computer security. His work includes cryptosystems with novel properties, web security, security for mobile devices, and cryptanalysis. He is the author of over a hundred publications in the field and is a Packard and Alfred P. Sloan fellow. He is a recipient of the 2014 ACM prize and the 2013 Godel prize. In 2011 Dr. Boneh received the Ishii award for industry education innovation. Professor Boneh received his Ph.D from Princeton University and joined Stanford in 1997.

Yavor Litchev

Yavor is an undergrad at Stanford pursuing a degree in computer science with a focus on cybersecurity and cryptography. He has previously engaged in research projects relating to secure machine learning and digital signatures with more flexible access structures at MIT PRIMES. More recently, he is researching secure systems and program execution using software fault isolation through the CURIS program. He is currently the cryptography research lead and Financial Officer for the Stanford Blockchain Club.

Everyone talks about rollups as the future of Ethereum, but what does it really take to run one, but does the math make sense for businesses to launch their own rollup? The space is moving faster than anyone expected, yet it’s still unclear how these chains make money or cover their costs.

This piece dives into how rollups actually make money, the cost of running a rollup, the different revenue streams, and whether the model is truly sustainable. We’ll also look at how architecture and design choices shape these economics and what it all means for developers and infra teams building in the modular stack.

Key takeaways of the rollup business model:

• The business model of a rollup ultimately comes down to three levers: how it earns, where it can add upside, and what it costs to operate.

• Rollups core revenue = core per-tx fees (base fees + tips) and optional operator surcharge.

• Add-on revenue: rollups can earn additional revenue through MEV, hosting L3s and DA resale, and stablecoin rev-share.

• The main costs of running a rollup are data availability, validation (fraud infra or ZK proving), infra/RPC/monitoring/storage, ecosystem incentives, and any platform/licensing cut.

In short, you can think of these takeaways as a simple monthly P&L equation to understand a rollup’s business model:

Protocol surplus = core fees + add-on revenues − cost

Let’s break down the business model of a rollup in greater detail.

Core Revenue of a Rollup

Core revenue for a rollup comes from the L2 fee market the rollup sequencer controls. The sequencer executes transactions on the rollup and periodically posts their data to a data-availability layer. Revenue from sequencers primarily comes from transaction fees paid by users.

Each transaction pays an L2 execution fee (an EIP-1559 style base fee, plus an optional priority tip), a DA fee that reflects the bytes to publish upstream, and, if the rollup provider chooses, an operator surcharge embedded in the fee policy. Those fees accrue to a rollup’s fee vault, the data component largely passes through to pay your DA bill, so the real margin driver is execution gas plus any operator surcharge after data availability fees and operations costs.

For reference, in OP stack chains, there is a specific Sequencer fee vault which collects and holds transaction fees paid to the sequencer during block production.

Example: World is one of the largest onchain apps in the world, with over 30M users, and is powered by Alchemy rollups.

Additional Revenue Sources for Rollups

MEV / Ordering Revenue

With the right sequencing and ordering policy, a rollup can capture MEV as transparent chain revenue. MEV capture is a design choice & isn’t guaranteed income.

Example: Arbitrum Orbit recently launched Timeboost which replaces naive FCFS with an express-lane auction each round. Traders bid off-chain, proceeds go on-chain. The auction fees go to the Arbitrum sequencer, and are then distributed to the Arbitrum DAO and Developer Guild.

Timeboost crossed $3M+ in fees collected post-launch and has continued to ramp. If you run an Arbitrum chain, you can enable Timeboost and keep your chain’s auction revenue.

OP-Stack chains don’t have Timeboost, but you can still capture priority fees. The OP Mainnet sequencer will prioritize transactions with a higher priority fee and execute them before any transactions with a lower priority fee.

Stablecoin Economics (Yield/RevShare)

Treasury yields are 4–5% in 2025 across the short end, and issuers earn interest on reserves and often share it with distribution partners. Examples include:

• Circle shares revenue with partners (e.g., Coinbase historically, Bybit reported), though terms vary and are not chain-wide by default.

• Paxos ↔ PayPal (PYUSD) explicitly allows issuer → PayPal sharing of reserve earnings; users do not get the interest. That’s precedent for B2B rev-share on stablecoin programs.

If your chain becomes the home for a big stablecoin footprint, a negotiated rev-share can dwarf sequencer fees. For example, a $1B average stable float × 4% translates to $40M/yr. Even a more conservative 50/50 split between the stablecoin issuer and the ecosystem operator leads to $20M/yr for each party. It’s worth noting though that feasibility here depends on regulation and legal restrictions as well as distribution power.

L3 Chain Hosting & DA Resale

If an L3 settles to your L2 (parent chain), the L3 pays the parent-chain DA fees. For example, Arbitrum Orbit L3 pays fees to Arbitrum One, and an OP-Stack L3 pays DA fees to an OP L2.

As a rollup provider, you can sell DA and charge network fees - a “wholesale blockspace” business.

Owning the L2 means you own ordering economics (priority fees, auctions, flow partnerships). This is a big motivator for consumer fintechs to launch L2s - see Robinhood’s plan to spin up an L2 (Arbitrum stack) to bring its order flow onchain.

Costs of a Rollup

Data availability (DA)

DA is usually the biggest variable cost for running a rollup. On Ethereum, this is paid through blobs. The Pectra upgrade doubled the blob target from 3 → 6 per block and the roadmap pushes further via PeerDAS starting with Fusaka. (next upgrade)

Alt-DA (e.g., Celestia, EigenDA) can be cheaper per MB for many workloads while you still settle on Ethereum if your stack supports it. Celestia is a modular blockchain purpose-built for DA - it scales throughput while keeping verification lightweight through data availability sampling (anyone can check validity with a light node). EigenDA, built on EigenLayer, lets rollups outsource DA to Ethereum’s restaked validator set, offering Ethereum-aligned security with flexible bandwidth guarantees.

Model it simply: DA_cost ≈ MB_posted × $/MB

State Validation / Proofs

Optimistic. In the happy path you post outputs to the L1 and pay little gas. The real cost is operational: keep a proposer and a challenger online and tie up bonds during the ~7-day window. Disputes are rare, but when they happen you pay the L1 for the fraud-proof step.

ZK: You drop the challenge window and bonds, and instead pay a proving bill. Most spend is off-chain GPU/prover time; the on-chain verify is a single cheap call per batch.

If you’re on OP-Stack, projects like OP Succinct let you upgrade to a type-1 zkEVM rollup.

Infra & Operations

Running a rollup is running a 24/7 production system. Beyond the sequencer, you’re paying for batchers, RPC gateways, archive/state nodes, indexers, explorers, bridge, key management, storage, and multi-region failover. You also need observability (logs/metrics/traces), monitoring for both on-chain and off-chain signals, DDoS/rate-limit protections, rollback pipelines, and real incident response with on-call & shipping new features regularly.

Rollup service providers like Alchemy allow virtually any team to run their own chain regardless of their technical expertise, at a low upfront cost. With Alchemy Rollups you can just offload all of that infra and operational overhead and focus on providing a better UX & growing your community of onchain builders and users.

License / RevShare to Your Stack

OP Stack is MIT open-source, with fees only applying when joining the Superchain (2.5% of revenue or 15% of onchain profit). Arbitrum Orbit uses a Business Source License with an ‘Additional Use Grant’ allowing free L3s on Arbitrum One while requiring a 10% profit share for independent chains.

Go-to-Market Incentives & Developer Tooling

Ecosystem grants, airdrops, liquidity, developer tooling. These aren’t “unit costs,” but they’re very real cash/token outlays in year 0–2.

Sample Calculations for a New Rollup

If you’re looking for a back-of-the napkin way to approach the rollup business model, here’s a sample calculation you can use to think through whether the business model makes sense.

Core Costs:

Fixed Cost (per month, testnet + mainnet)

• Fixed costs include sequencer, RPC, block explorer, bridge infra → $3,000–$3,500/mo

Total fixed costs: ~$3,000–$3,500/mo

Variables:

• Variable costs include L1 settlement + DA fees + misc. These costs are typically low at early volumes → usually $100–$500/mo total

Total variable costs: ~ $100–$500/mo for small chains

If we set the total monthly cost (including fixed and variable) at $3,400, and if we anchor the net capture per tx (what the chain actually keeps) at $0.0012-$0.0020/tx, here is what a rollup’s monthly profit looks like as it scales onchain activity:

Notes:

• You can have high chain revenue but low/negative onchain profit if DA costs are high or fees are underpriced.

• You can improve onchain profit by (a) raising net capture per tx (fee policy, operator surcharge, ordering auctions), or (b) lowering onchain costs (cheaper DA, better compression, bigger batches, lower infra cost).

Conclusion

Rollups can be sustainable businesses, and they give teams the chance to stop paying rent to other chains and start capturing value directly. Instead of watching fees, MEV, and ecosystem activity flow upward to an L1, projects that run their own rollup get to own those economics and reinvest them back into their users and ecosystem.

If you’re a planning to launch a rollup or if you deployed a rollup yourself and you want to migrate to a true white-glove, experienced rollup service provider, we’d love to speak with you! Learn more here.

Author

Uttam Singh is a Senior Developer Relations Engineer at Alchemy, where he helps builders ship faster with onchain infrastructure. Before joining Alchemy, he worked with Flare and Polygon. Uttam has spoken at major conferences including ETHCC, ETHOxford, and ETHPrague, as well as at several universities, and regularly publishes deep-dives, tutorials, and educational content for the onchain developer community. He completed his research on blockchain at the University of Montreal under the prestigious Mitacs research program.

Stanford Blockchain Review
Volume 8, Article No. 4

📚 Guest: Prof. Fan Zhang — Yale University
📚 Hosts: Jay Yu — Pantera Capital and Yavor Litchev — SBC

🌟 Technical Prerequisite: Intermediate

Key Takeaways:

• TLS secures the Internet, but lacks exportable provenance: TLS protects data in transit, but can’t prove where it came from. zkTLS (as implemented in DECO) fixes that with verifiable, cryptographic proof without needing server changes.

• DECO combines MPC and ZKPs: DECO uses a three-party handshake to split TLS session keys via multi-party computation, preventing session forgery. It then adds zero-knowledge proofs so users can prove facts (“I'm over 21”) without exposing raw data.

• zkTLS is fast, private, and verifiable: Techniques like selective disclosure and context-aware parsing reduce ZK proof costs while maintaining semantic integrity. Hash-based MPC and 2PC optimizations keep protocol performance within practical bounds.

• DECO has inspired multiple practical instantiations of zkTLS: Opacity and Reclaim are leading implementations of zkTLS inspired by DECO with different architectures. Opacity uses MPC, TEEs, and slashing for stronger security. Reclaim trades that for speed, with faster attestations via proxy attestors.

• zkTLS powers real-world apps: Applications include decentralized KYC, credit-based DeFi lending (3Jane), automated background checks (TransCrypts), and loyalty credentialing (e.g., Reclaim + Marriott). zkTLS also unlocks new AI applications, by creating a pipeline for models to safely ingest private user data. It creates a new trust layer for the web, independent of APIs or server cooperation.

Subscribe now

Introduction

Transport Layer Security (TLS) is the cryptographic backbone of the modern internet, securing billions of web sessions daily. It guarantees confidentiality and integrity between clients and servers, ensuring that users can safely exchange data with websites. However, TLS has a critical shortcoming: it does not enable users to cryptographically prove to third parties that the data they accessed genuinely came from a specific website. While data is encrypted and authenticated in transit, it lacks exportable provenance: a way to vouch for the authenticity of data after the session ends.

This limitation has stymied applications like private age verification, authenticated financial disclosures, or fair pricing enforcement, especially in contexts like blockchain smart contracts, which require verifiable, third-party data. Existing solutions like trusted hardware (e.g., Intel SGX) or server-side modifications break legacy compatibility or introduce new trust assumptions.

zkTLS, exemplified by DECO1, solves this by allowing users to generate zero-knowledge proofs about data retrieved over TLS without modifying servers or relying on trusted hardware. In this article, we will first explore the cryptographic foundations of zkTLS, including TLS internals, secure multiparty computation, and zero-knowledge proofs. From there, we will provide a technical walkthrough of zkTLS as envisioned by the DECO protocol, and finally survey real-world use cases and practical deployments that demonstrate the transformative potential of zkTLS.

1 - A Crash Course on the Fundamentals of zkTLS

At its core, zkTLS (Zero-Knowledge TLS) aims to bridge the gap between secure data access and verifiable data provenance. While TLS ensures that communication between a client and server is secure, it does not leave behind cryptographic evidence that the data came from the claimed server. As a result, users are unable to export trustworthy, privacy-preserving attestations of online data, which is a major limitation in an era where data portability and trust minimization are paramount.

Imagine Alice wants to prove to Bob that she is over 18, based on a date of birth retrieved from a government portal. While Alice could show Bob a screenshot or forward the data, Bob cannot verify whether this information truly originated from the government’s website, since TLS protects data in transit but does not sign the content. The same challenge arises in proving financial solvency from a bank account or contesting discriminatory pricing. Screenshots can be forged, and server cooperation is often unavailable or insufficiently trustworthy. zkTLS, specifically through the DECO protocol, tackles this by enabling users to interact with any standard TLS-enabled website, extract data privately, and prove statements about that data to a verifier, all without altering the website or involving trusted execution environments (TEEs).

TLS Protocol ²

Before we examine the protocol details, it is prudent to first understand TLS as it currently exists, along with some other important cryptographic primitives. TLS is a cryptographic protocol that ensures confidentiality and authenticity during web communications2. It consists of two main phases, one of them being a handshake protocol to establish a secure session using asymmetric cryptography and performs key exchange (e.g., via ephemeral Diffie-Hellman). The second main phase is the record protocol, which uses the shared symmetric keys derived from the handshake to encrypt and authenticate subsequent data transmissions. While TLS ensures that Alice receives data from the server securely, it does not provide her with a way to prove to Bob that the data truly originated from the server. Both Alice and the server possess the same symmetric keys, which means Alice can forge TLS messages after the fact, thereby breaking any notion of post hoc authenticity.

Prior approaches to TLS provenance typically fall into two categories: Trusted Hardware Solutions (e.g., Town Crier relies on Intel SGX to sign TLS data)3, or Server-Side Modifications, where TLS is modified to include signatures on data or enable verifiable logging. The problem with the former solution is that SGX (and TEEs in general) introduce new trust and security risks (e.g., side-channel attacks), whereas the issue with the latter solution is that it requires changes to the server software stack, which greatly limits deployability. DECO, and zkTLS generally, distinguishes itself by being legacy compatible, operating with any TLS server without cooperation or modification.

One of the cryptographic primitives that allows for DECO to function on legacy systems is Multiparty Computation (MPC). Secure Multiparty Computation (MPC) allows two or more parties to jointly compute a function over their inputs without revealing them. In the context of zkTLS, MPC is used to establish shared secrets (specifically, the session keys used in the TLS protocol such that neither party has access to the complete key, and the client (i.e., the prover) cannot forge or tamper with TLS records. DECO achieves this through a three-party handshake in which the prover (Alice) and the verifier (Bob) cooperate to jointly act as a TLS client. They run a two-party protocol to split the session keys between them. For instance, Alice and Bob compute additive shares of the MAC key such that neither knows the full key, but together they enable a valid TLS session. This ensures Alice cannot forge valid TLS traffic after the fact.

Zero-Knowledge Proofs (ZKPs).

Zero-knowledge proofs, another critical cryptographic primitive used in DECO, allow one party (the prover) to convince another (the verifier) that a certain statement is true, without revealing why it’s true or leaking any other information. In DECO, once Alice (the prover) has obtained a response from the server, she generates a cryptographic commitment to the session data. She then uses a zero-knowledge proof to prove the data she received satisfies a desired predicate (e.g., “I am over 18”) without revealing the underlying data (e.g., her birthdate). This allows for privacy-preserving attestations of sensitive information, a fundamental breakthrough for applications like identity verification or decentralized finance.

zkTLS combines these elements as follows:

1. Three-Party Handshake (TLS + MPC): Alice and Bob engage in a handshake with the server, producing shared keys such that Alice alone cannot forge session data. This maintains TLS compatibility.

2. Query Execution and Commitment (TLS + MPC): Alice constructs a TLS query (e.g., an HTTP request) using her private data (like a login credential), and sends it to the server. She commits to the resulting session transcript.

3. Proof Generation (ZKPs): Alice proves in zero knowledge that the session data satisfies a predicate (e.g., account balance > $1000), and that it was obtained from the correct source via a proper TLS session.

This architecture avoids the need for trusted hardware, works with existing web infrastructure, and enables selective disclosure, for instance, revealing that a condition is met without disclosing the underlying data.

The next section of the article will dive deeper into how these components are technically realized in DECO’s protocol, including the construction of the three-party handshake, optimized MPC protocols for query execution, and efficient techniques for generating zero-knowledge proofs on TLS transcripts.

2 - A Technical Deep Dive into the DECO Protocol for zkTLS

At the heart of DECO’s architecture is a clever synthesis of classic TLS security with modern cryptographic techniques such as secure multiparty computation (MPC) and zero-knowledge proofs (ZKPs). This section unpacks each of DECO’s core protocol phases in detail, examining how cryptographic primitives are tailored to preserve data provenance while maintaining compatibility with the existing TLS ecosystem.

A fundamental innovation of DECO is the three-party handshake between the prover (Alice), the verifier (Bob), and an unmodified TLS server. This handshake allows Alice and Bob to jointly participate in a TLS connection to a server such that neither party knows the full cryptographic keys used to authenticate the session. This eliminates the ability of Alice to forge or manipulate TLS session data after the fact, the key foundation for proving provenance.

TLS typically establishes a symmetric session key via an ephemeral Diffie-Hellman key exchange. In DECO, this handshake is modified such that the session key — specifically the MAC key (k_MAC) — is additively shared between Alice and Bob:

Here, k_P​ and k_V​ are shares held respectively by Alice (the prover) and Bob (the verifier), with the server S receiving the full key k_MAC​ for encryption and authentication. The process involves two major steps:

1. Ephemeral Diffie-Hellman Key Exchange (ECDHE): Alice and Bob contribute public keys to derive a common secret g^x, without either party learning the full exponent. The server contributes its own ephemeral key g^s, completing the key exchange.

2. Key Derivation via MPC: Since TLS session keys are derived via a pseudorandom function (PRF) over the Diffie-Hellman output, DECO uses two-party computation (2PC) to compute this derivation jointly. This is a non-trivial task because TLS-PRF is hash-based and lacks algebraic structure, requiring MPC to handle bitwise operations securely.

By ensuring neither party has full control over the MAC key until the session is cryptographically committed, the handshake defends against forgery: Alice cannot modify session content post-hoc without breaking the MAC.

Once the handshake is complete, Alice must construct a valid query to the server and receive the response, all under TLS. The key challenge is that the session keys are now split between Alice and Bob. Hence, even basic TLS operations like MAC generation (in CBC-HMAC) or authenticated encryption (in AES-GCM) must be computed via secure 2PC protocols. For cipher suites using CBC-HMAC (common in TLS 1.2), the record protocol operates by first computing a MAC over the plaintext and then encrypting the message plus MAC. To generate the MAC securely, Alice and Bob compute the inner hash locally on Alice’s side, enabled by giving her a hash of the padded MAC key (i.e., H(k⊕ipad)), which does not leak the key itself due to the one way properties of cryptographic hash functions. They then perform 2PC only for the outer hash, which is short. This reduces the MPC burden significantly, as without this optimization computing HMAC over a large query in MPC would be prohibitively expensive.

For AES-GCM mode, encryption and authentication are combined into a single operation. However, unlike CBC-HMAC, it lacks a commitment property, the ciphertext does not bind to a unique plaintext, which complicates provenance guarantees. DECO supports AES-GCM by using optimized 2PC protocols for AES encryption and polynomial evaluation in Galois fields (for GCM authentication tags).

For performance-critical deployments, DECO also introduces a proxy mode, which is particularly useful for GCM. In this mode, Bob acts as a passive network proxy who relays and logs the traffic between Alice and the server. This simplifies provenance, as Bob witnesses the session directly. However, the security guarantees differ, it shifts trust toward the verifier's honest behavior and is best suited to settings where Bob is semi-trusted.

For the proof generation phase of the protocol that occurs after the server respond to Alice, she wishes to prove to Bob that the data:

1. Came from the server (provenance)

2. Satisfies a desired predicate (e.g., over 18)

3. Without revealing the data itself (privacy)

This is where zero-knowledge proofs (zkPs) come into play. Alice commits to the TLS transcript and proves a statement of the form:

Where:

• k_Enc​ is the encryption key,

• X is the decrypted TLS record,

• Verify ensures MAC correctness,

• Stmt(X) evaluates the predicate.

Generating such proofs over entire transcripts could be computationally prohibitive. DECO addresses this with two optimizations: Selective opening, and two-stage parsing for context integrity. Selective opening means the following: instead of revealing or proving over full session data, Alice can reveal substrings of the TLS response, or redact portions of the message to preserve privacy. For example, she might reveal only a checking account balance, not the full bank statement. This selective opening is proven in zero knowledge using optimized circuits that process only the revealed parts, reducing proof size and cost. However, selective disclosure introduces a risk: Alice could quote a snippet out of context (e.g., showing a $5000 value from a message to customer service rather than the actual bank balance) and therefore prove faulty statements. To prevent such context integrity attacks, DECO introduces two-stage parsing:Local parsing and zero-knowledge proof. In local parsing, Alice parses the full session response to identify where her substring appears within a structured format (e.g., JSON). As for the zero-knowledge proof portion, she proves in ZK that the substring came from the correct structural location in the original document. This is formalized by reasoning over the structure using context-free grammars (the same way in which a compiler reasons if some piece of Python or C code is actually valid code), ensuring that any disclosed fragment is bound to the intended semantic structure.

While the main DECO protocol is ZKP-based, the original paper and interview also discuss a variant based on Trusted Execution Environments (TEEs) like Intel SGX (as was briefly mentioned in Section 1). In this mode, a TLS client runs entirely inside the TEE so as to guarantee that the prover has no access to the session keys. Provenance is thus established by logging or signing the session inside the enclave. This approach benefits from lower computational overhead (only 10–20% slower than native TLS) compared to the orders-of-magnitude cost of ZK proofs. However, it introduces reliance on hardware trust, including vulnerability to side-channel attacks, as well as vendor trust, including firmware, microcode, and remote attestation. While not mutually exclusive, the choice between ZKP-based and TEE-based deployments reflects a tradeoff between performance and trust minimization.

Now that we have a detailed understanding of how DECO functions, it is critical to analyze performance bottlenecks and potential optimizations. Despite the elegance of the construction, DECO’s most significant cost comes during proof generation, especially for complex predicates or long transcripts. The authors of the original paper report 2.85 seconds for the three-party handshake, 2.52 seconds for query execution (2PC), 3-13 seconds for ZKP generation (depending on complexity). As discussed in the interview, DECO uses several clever tricks to keep performance practical. For example, in hash-based MPC, the system doesn’t re-evaluate entire hash chains. Instead, it computes the final compression step and verifies its correctness, saving computation while preserving security. Further improvements may come from faster proof systems (e.g., STARKs, zk-SNARKs with pre-processing), as well as hardware acceleration for the 2PC steps.

3 - Implementations and Applications of zkTLS

DECO Sandbox by Chainlink ⁴

The DECO protocol provided us with a foundational architecture for zkTLS. Since then, zkTLS has quickly become a popular concept with many real world applications. At its core, zkTLS enables users to prove facts about their interactions with websites over HTTPS without revealing the full content of the interaction and without server cooperation. For developers, this unlocks a new design space of privacy-preserving authentication, decentralized identity, and verifiable web data extraction. In this section, we explore how zkTLS is currently being deployed, what the developer experience looks like, and how two of the leading providers of zkTLS, Opacity and Reclaim, differ in architecture and trust assumptions, as well as take a look at some of the user-facing applications using zkTLS under the hood.

The original architecture proposed in DECO has been licensed by Chainlink, which has since made a developer sandbox interface for the protocol4. This sandbox provides developers with the ability to experiment with DECO-style TLS transcript proofs and witness how multiparty computation and zero-knowledge proofs interact in the context of real HTTPS sessions. Today, a developer interested in building on top of DECO can work with lower-level cryptographic libraries and frameworks such as:

• Rust and C++ for performance-critical MPC operations

• zk-SNARK/STARK systems (like libsnark, circom, or R1CS toolchains) for proving validity over TLS data

• WebAssembly or trusted runtime containers for deployment on consumer devices or smart contract VMs

The long-term vision is to abstract away much of this complexity via SDKs that expose simple APIs like prove_from_website(url, predicate) or verify_proof(proof). While still early, progress is being made toward streamlining these interactions, particularly in industry deployments.

As for practical, commercial implementations, one prominent example is the Opacity Network.5 Opacity represents one of the most robust and comprehensive deployments of a zkTLS architecture in the wild, as it builds upon the TLSNotary framework and significantly enhances it with a blend of cryptographic techniques,6 including garbled circuits, oblivious transfer, proof by committee, and on-chain verification and slashing mechanisms. Opacity focuses primarily on web2 account attestations, enabling users to prove ownership over accounts on platforms like LinkedIn, Twitter, or a traditional bank, and linking these to a web3 identity, such as an Ethereum wallet. The user doesn’t need the cooperation of the web2 service to do this. Instead, the Opacity network conducts a verifiable TLS session using secure MPC between the user and a notary node. The result is a signed transcript, which is then verified by smart contracts onchain. To mitigate the risk of collusion between a user and a notary, Opacity employs several layers of defense:

• Commit-and-reveal: Users must commit to the value (e.g., account balance) before a notary is assigned.

• Proof by committee: Multiple notaries independently compute identical proofs.

• On-chain logging: Every attempt to prove a value is logged publicly, discouraging manipulation.

• TEE isolation: All notaries must run within Intel SGX secure enclaves.

• Restaking and slashing: Notaries are economically incentivized to behave correctly via Eigenlayer’s AVS, which slashes misbehaving nodes in real time.

• Whistleblowing: Any user who can prove a notary misbehaved gets a share of their slashed stake.

This layered architecture makes Opacity one of the most secure zkTLS systems currently deployed. It excels in environments where users need to prove private attributes from private accounts — for example, demonstrating that they are a verified university student, without revealing their name or email.

However, Opacity's heavy reliance on TEEs introduces some caveats. While SGX helps reduce computational overhead, its side-channel vulnerability remains a known concern. Opacity mitigates this by not solely depending on SGX — instead, SGX is used in tandem with cryptographic and economic safeguards.

Reclaim, another prominent implementation of zkTLS, takes a different approach. Rather than relying on MPC between notaries and users, it leverages a proxy witness model.7 The core idea is to insert an attestor node as a passive observer during a user’s TLS session. This attestor conducts the TLS handshake on the user’s behalf and then signs a verifiable statement about the session's content, with the result being a portable claim that can be presented to third parties.

Whereas Opacity prioritizes complex multi-party MPC and TEEs, Reclaim’s architecture emphasizes lightweight performance and fast attestations.8 This makes it especially attractive for verifying public-facing web data (e.g., whether a page includes a particular element), Fast KYC workflows where a single attestor's word is sufficient, and applications where the attestor is semi-trusted (e.g., a government authority or major exchange). To avoid giving the attestor full access to sensitive content like session tokens, Reclaim uses a key-upgrade mechanism where:

1. The user discloses temporary TLS keys to the attestor (without revealing cookies or long-term credentials)

2. The attestor reconstructs the transcript and issues a signed claim

3. The proof is bounded to this ephemeral session and doesn’t grant replay or access

Reclaim acknowledges that collusion between user and attestor is a risk, if they cooperate, they can forge transcripts. To mitigate this, Reclaim suggests the use of subset sampling, where a random group of attestors must validate a claim. However, unlike Opacity, Reclaim does not rely on economic slashing or proof-by-committee by default.

One operational challenge for Reclaim lies in IP-based attestor identification: since servers may notice repeated connections from known attestor IPs, they could rate-limit or block these addresses. This limits the scale at which Reclaim can operate in adversarial environments.

Nonetheless, Reclaim's simplicity and ease of integration make it a compelling zkTLS solution in controlled settings, particularly when the attestor is not adversarial, for instance, a court officer validating a digital document or a bank verifying a certificate of funds.

While Opacity and Reclaim differ in architecture and trust assumptions, they both exemplify the power of zkTLS to turn private TLS sessions into verifiable public claims. Opacity favors a maximalist security model, layering cryptography, TEEs, economic incentives, and redundant computation. Reclaim emphasizes fast attestations, minimal overhead, and real-world pragmatism. Both platforms share the same philosophical foundation: to liberate user data from platform lock-in, empower self-sovereign identity, and eliminate the need for APIs and server-side cooperation.

Reclaim’s Verifiable Loyalty Platform

Today, zkTLS enables a new generation of verifiable, consumer-focused applications ranging from custom-built loyalty programs, on-chain credit scores, to identity verification and automated background checks. Reclaim, for example, has created a prototype demo of how zkTLS can be used to create verifiable loyalty programs. For example, suppose Marriott wants to give a special discount voucher for Star Alliance Gold members. By using Reclaim’s loyalty toolkit,9 users can log into their airline account, and Reclaim will use zkTLS to automatically confirm their membership status, frequent flyer points, and more, and attach these attributes as credentials to the user’s Marriott account. This process thus allows Marriott to verify that users are Star Alliance Gold members and in turn give more targeted discounts.

3Jane Protocol using zkTLS for credit scores ⁹

Another use case is using zkTLS to “export” traditional credit scores into the world of DeFi. By default, when a user wants to use an on-chain lending platform such as Aave or Morpho, these loans need to be over-collateralized, as there is no way of knowing ahead of time if the actual user is honest or not. 3Jane, however, creates a credit-based lending platform that pulls a user’s real-world credit score (such as a FICO score) to create undercollateralized loans based on credit, just like a traditional bank loan.10 Under the hood, 3Jane leverages Reclaim’s zkTLS system to export credit scores, income statements, and bank assets via a Plaid authentication.

Similarly, we can use zkTLS to automate identity verification and background checks. TransCrypts, for example, uses zkTLS to automate the background check process by aggregating information from many different sources into a single platform, accelerating the hiring process without compromising user privacy. With zkTLS, TransCrypts can verify attributes like employment history, educational credentials, or legal clearances by establishing TLS sessions with official data providers (e.g., payroll services, universities, or government databases) and generating attestations without requiring direct API access or data dumps.

With its lightweight yet versatile protocol design, zkTLS can also be integrated with social media platforms. Fan Zhang’s zkLabeler tool provides a lightweight way to add custom, verifiable labels to Bluesky handles.11 This process can power rich credentialing frameworks, connecting an ORCID ID to a decentralized social media handle, proving voting eligibility without doxxing your address, or verifying financial solvency without exposing transaction history.

Finally, zkTLS can also be used in “protected pipelines” (props) for private data for LLMs and machine learning. A privacy preserving oracle such as DECO can be used to export sensitive personal data – such as electronic health records and financial data – into private models for a more personalized experience.12 In the “props” framework, zkTLS serves as the secure data sourcing mechanism, allowing ML training and inference pipelines to ingest sensitive deep-web datasets with both privacy and authenticity guarantees, mitigating the risks of fabricated inputs, adversarial manipulation, and direct exposure of personal information.

Conclusion

Throughout this article, we’ve presented an in-depth dive into the conceptual innovations behind zkTLS, the instantiation of the DECO protocol, as well as its wider influence on production-grade zkTLS systems and applications we see today. DECO’s architecture exemplifies a new generation of cryptographic protocols that combine usability, legacy compatibility, and privacy. Through layered security, MPC for integrity, ZKP for privacy, and optionally TEEs for performance, DECO provides a blueprint for authenticated, privacy-preserving data portability across the web.

Fundamentally, zkTLS as pioneered by the DECO protocol provides a simple, intuitive, and versatile way for “exporting” data from one website or application or another. By leveraging the in-built cryptographic security and pervasive adoption of the TLS standard, zkTLS provides a framework to free the Internet from isolated data silos and convoluted APIs, ultimately building a unified access layer for our digital data.

About the Interviewees

Fan Zhang

Fan Zhang is an Assistant Professor at Yale CS and runs the Decentralized Systems Group. He is broadly interested in computer security and applied cryptography, especially problems in blockchains and smart contracts, user authentication, anonymity, and hardware-assisted trusted execution environments. Fan received his Ph.D. in Computer Science from Cornell University, advised by Prof. Ari Juels, and his bachelor’s degree from Tsinghua University. Fan is also a faculty affiliate of IC3.

Yavor Litchev

Yavor is an undergrad at Stanford pursuing a degree in computer science with a focus on cybersecurity and cryptography. He has previously engaged in research projects relating to secure machine learning and digital signatures with more flexible access structures at MIT PRIMES. More recently, he is researching secure systems and program execution using software fault isolation through the CURIS program. He is currently the cryptography research lead and Financial Officer for the Stanford Blockchain Club.

Jay Yu

Jay is a Junior Partner at Pantera focusing on investments and research, and a Research Advisor to IC3. Previously, he served as President of the Stanford Blockchain Club, and founded the Stanford Blockchain Review. He conducted research on DAOs and trusted execution environments (TEEs) with faculty from Stanford Law and IC3, and was a delegate for Uniswap DAO. Jay graduated from Stanford with a double major in Computer Science and Philosophy, and a minor in French.

Blockchain enforces strict global consensus, which means everyone running the network, anywhere in the world, agrees on the same set of objective outcomes.

But how does a distributed system reach agreement even when some participants are lying, offline, or actively trying to subvert the process?

This is where consensus protocol comes in. It is a set of rules that allow a network of independent and potentially dishonest participants to agree on the order and contents of transactions.

Once you have this ‘strict global consensus’, blockchain unlocks wonderful properties like digital property rights, monetary hardness, and social scalability. But all of that rests on a protocol’s ability to maintain safety (no two conflicting blocks are finalized) and liveness (the network keeps making progress).

This article explores MonadBFT, which builds on the HotStuff lineage. We’ll examine how it solves persistent issues like tail-forking, achieves speculative finality in a single round, and enables optimistic responsiveness. Together, these properties make MonadBFT a foundational advancement for high-performance blockchains.

Subscribe now

A brief recap on past consensus mechanisms

The field of consensus mechanisms has evolved over decades. Early protocols like PBFT [1] (Practical Byzantine Fault Tolerance) showed that agreement was possible even when up to f nodes (out of 3f+1) were malicious. These classical designs work by electing a leader who coordinates multiple rounds of voting among validators.

In each phase (e.g. pre-prepare, prepare, commit, reply), every validator must communicate with every other validator. This leads to quadratic message complexity (a full mesh of communication): if there are n validators, you need roughly n² messages per round. That’s manageable in small networks but becomes unworkable as the validator set grows.

Source: https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

Quadratic messaging is inefficient. In a network with 100 validators, you have to process tens of thousands of messages per round. For global, permissionless systems, that’s too heavy. As a result, early BFT protocols like PBFT and Tendermint were often deployed in permissioned systems or small validator sets where performance constraints were tolerable.

To scale BFT for permissionless environments, newer protocols opt for linear communication: every validator talks only to the leader, reducing message complexity from n² to n.

Hotstuff was first introduced in 2018 and it pushed BFT consensus forward by introducing a streamlined, leader-centric communication pattern.

HotStuff features linear communication. Instead of the quadratic explosion of messages in PBFT, in HotStuff all validators just send their vote to the next leader. That leader combines them into a single, compact proof called a Quorum Certificate (QC). The QC is proof to anyone observing it that ‘most nodes agreed with the proposal.’ Unlike PBFT where everyone checks with everyone (causing messaging overload), HotStuff is ‘vote once, bundle once’, meaning the network stays fast even as it grows.

Notice the fan-out fan in structure and difference with the ‘mesh’ pattern of PBFT

Source: https://www.mdpi.com/1424-8220/24/16/5417

Further, HotStuff may be pipelined for additional efficiency. In the original HotStuff protocol, the same validator serves as the leader through each round of communication until the block is finalized, and only one block is worked on at a time. In Pipelined HotStuff, each round of communication has a new leader, who is responsible both for assembling/propagating the Quorum Certificate from the previous round’s votes and also for proposing a new block.

In Pipelined HotStuff, instead of waiting for a single leader to do everything needed to finalize a block, each leader in a sequence plays a role. Leader 1 proposes a block, then Leader 2 assembles and shares a QC for Leader 1’s block while also proposing a new block, and so on. This setup forms a chain, where each new leader helps confirm the block that came before. Pipelining really just means overlapping these steps (i.e. while one block is being finalized, the next is already being proposed).

In short, HotStuff-based protocols achieved much better decentralization and performance: they can include more validators and finalize blocks with fewer messages and rounds. These properties have made HotStuff the template for many modern PoS consensus implementations. However, as we’ll see next, the pipelined design also introduces a subtle vulnerability that wasn’t immediately apparent.

​The Problem of Tail-Forking

While HotStuff (more specifically pipelined HotStuff) addressed scalability issues, new challenges come with its design. A major issue for pipelined protocols is tail forking.

Tail forking can be understood as a chain reorganization at the ‘tail’ of the chain. It occurs when a block that is valid and correctly propagated to other validators should become a part of the chain (it received the required votes) but ends up getting abandoned (orphaned) due to the behavior of the next leader.

Essentially, a block is proposed and validated by a supermajority but still fails to commit and is replaced by a different block at the same block height (very unfair right?!).

Why would this happen? In pipelined HotStuff, each leader has two jobs: A. propose a new block, and B. gather votes (form a QC) for the previous leader’s block.

For example, suppose validator Alice proposes block B_n and a supermajority of validators voted for it (enough to eventually form a QC). Normally, the next leader Bob (working on block B_n+1) should include that QC in his proposal.

But if Bob is offline or intentionally misses his slot, the QC for B_n won’t be propagated, and B_n will be abandoned.

Why does tail forking matter?

Tail-forking is 1) economically unfair and 2) potentially dangerous for liveness.

First is the issue of lost rewards: When a block is abandoned, the proposer loses any block rewards or fees. In our example, Alice gets nothing because Bob failed to finalize her block. This creates unfair incentives—malicious leaders can sabotage others’ rewards. Even honest validators might get penalized due to bad luck or misbehavior, discouraging participation or encouraging collusion.

Second is the issue of MEV exploitation. If Alice’s block contains valuable arbitrage, Bob can collude with Carol to discard it and insert a new block capturing the same MEV. This kind of cross-slot reordering attack undermines fairness and encourages validator collusion.

Third is the issue of UX and finality guarantees. BFT protocols promise deterministic finality, but tail-forking breaks this at the chain tip. Some dapps rely on pre-finality execution to reduce latency. If a voted block is dropped, users might see state reversals which means missing trades, incorrect balances, or broken game logic.

Fourth is cascading failure. While a one-block delay is the most common, repeated forks by multiple faulty leaders can stall the chain entirely until someone commits a block that sticks.

Tail forking is a real, not just theoretical, issue. All pre-MonadBFT pipelined BFT protocols are vulnerable to it, since they rely on the next leader to finalize the previous block. Some solutions exist, like BeeGees [2], but they reintroduce costly trade-offs such as quadratic communication.

What is MonadBFT?

MonadBFT was created to directly address tail-forking vulnerability while preserving the performance gains. It builds on the HotStuff framework, which means 1) having rotating leaders, 2) pipelined commits, and 3) linear messaging, but introduces mechanisms to improve safety and liveness without sacrificing throughput.

The first priority for MonadBFT is to guarantee that any block proposed by an honest leader (that gathered a supermajority vote) will not get abandoned​. The desired outcome here is that if a block gets a supermajority support, the protocol ensures that block will eventually be finalized and included in the chain​ (cannot be orphaned or skipped). The mechanism to enforce this is twofold: 1) mandatory reproposal and 2) the No-Endorsement Certificate (NEC).

1. Re-proposals

In a BFT protocol, time is divided into rounds called “views.” Each view has a designated leader responsible for proposing a new block. If that leader fails, which means they 1) did not send a proposal on time or 2) sent an invalid one, the protocol moves to the next view with a new leader. MonadBFT includes a mechanism that ensures no honest block gets abandoned during this transition.

When the current leader fails, validators trigger a view change by broadcasting a signed message indicating that the round has timed out. Importantly, these messages also include some other information beyond just ‘hey there’s a failure’.

Each one must also include a reference to the most recent block that the validator saw and voted for. Think of it as saying: “I attest to not receiving a proper proposal this round, and here’s the latest block I have seen.”

The new leader then collects these timeout messages from a supermajority of validators (2f+1) of them and combines them into what’s called a Timeout Certificate (TC). The TC provides a snapshot of the best-known blocks across the network when the last round failed. Among these, the leader identifies the most advanced block (based on block height or view number, which is labelled “high_tip”).

MonadBFT requires the new leader’s proposal to include a TC formed from 2f+1 validators’ timeout messages, and to re-propose the highest-known pending block referenced in the TC , giving that block another chance to gather enough votes and be finalized. Why? Recall our intention earlier. This will ensure that blocks which were nearly finalized before the failure don’t simply vanish.

To illustrate: suppose Alice is the leader in view 5 and proposes a valid block that receives many votes. In view 6, Bob (the next leader) goes offline, so the block doesn’t get finalized. When Carol becomes leader in view 7, MonadBFT requires her to include a Timeout Certificate (TC) and re-propose the highest-voted block from the previous view—Alice’s block.

If Carol doesn’t have Alice’s block, she asks the network. Validators either send the block or, if they don’t have it, respond with a signed No-Endorsement message. If enough validators lack the block, Carol can construct a No-Endorsement Certificate (NEC) to justify skipping it.

After re-proposing Alice’s block, Carol is also given an extra slot to ensure she’s not penalized for Bob’s failure. This reproposal mechanism ensures the chain progresses fairly, and no valid block is discarded due to faults or bad actors.

2. No-Endorsement Certificate (NEC)

As mentioned above, when a timeout occurs at Bob’s slot, Carol asks everyone for the high_tip block (Alice’s block), and at least 2f+1 validators will respond with either Alice’s block or with a signed No-Endorsement message.

If anyone responds with Alice’s block, Carol has the information and justification needed to re-propose it. Furthermore, Carol is expected to re-propose Alice’s block – the only way she is not allowed to is if at least f+1 people sign NE messages (allowing Carol to construct a No-Endorsement Certificate).

Why f+1? In any BFT system with 3f+1 validators, at most f can be malicious. If Alice’s block should persist, then at least 2f+1 honest nodes have received it. In order to skip Alice’s block and propose a new one at the same height, Carol needs f+1 validators to sign off on not receiving Alice’s block, but by assumption only f validators are Byzantine.

The NEC is the leader’s proof that skipping the reproposal is safe and justified. It is a receipt that says: “Here’s verifiable evidence that the previous block wasn’t ready to be finalized, so I’m not just ignoring it maliciously.”

Re-proposal + NEC = Tail Forking Resistance

To recap, combining re-proposal and NEC mechanism give MonadBFT a clear rulebook: either finalize what almost made it, or prove it wasn’t ready and move on. Nothing falls through the cracks.

This design guarantees tail-forking resistance: an honest leader’s block that garnered a supermajority of votes will eventually be committed. A leader cannot selfishly fork away their predecessor’s block without leaving a cryptographic trail because the absence of an NEC would expose them.

Economically, this protects validators: your block and rewards won’t be lost due to the next leader’s failure. Even if Bob skips his slot to help Carol steal Alice’s block, MonadBFT forces Carol to repropose Alice’s block first, nullifying any MEV gain.

The breakthrough here is that MonadBFT achieves this without heavy communication. Previous approaches to solve tail-forkings (like BeeGees) imposed quadratic communication in every round. MonadBFT relaxes those conditions by only invoking the broader communication (collecting lots of messages) when a failure happens, not every round. Thus, in the normal case of steady honest leaders, it still operates efficiently (more on happy vs unhappy path later).

Implications of MonadBFT for developers

So far, we examined how classic PBFT consensus works and how earlier versions of HotStuff operate. We also looked at how MonadBFT solves HotStuff’s tail-forking issue which is a problem where valid blocks sometimes get left behind in pipelined systems.

This tail-forking problem creates two big issues: 1) it messes up the rewards for honest block builders and 2) can potentially stall the network.

MonadBFT introduces Reproposal rule and No-Endorsement vote mechanisms to eliminate the tail-forking problem, ensuring that any properly approved block from an honest proposer will always make it into the chain.

In the following sections, we explore the other two characteristics of MonadBFT which are 1) speculative finality and 2) optimistic responsiveness. We will also explore the implications of MonadBFT for validators and developers.

One-round speculative finality

Besides tail-fork resistance, another major feature of MonadBFT is speculative finality within a single round.

In practical terms, this means clients can receive confirmation for their transaction immediately after a block gets a supermajority of votes, even before the next round completes.

Recall that in protocols like PBFT or baseline HotStuff, a block usually isn’t considered final (irreversible) until it has gone through at least two phases (e.g. Fast-Hotstuff & Diem-BFT): one phase to get a Quorum Certificate (lock the block with ≥2f+1 votes), and a second phase where the next leader builds on that QC and commits the block.

This two-phase commit is needed to ensure safety: once enough honest nodes have locked a block, no conflicting block can gather a quorum, and the commit in the next round makes it permanent. So normally, a client might have to wait for the next block or next round to be produced before they know the previous transaction is final.

MonadBFT basically allows a transaction to be considered final enough (safe to act on) after just one round of voting. This is called speculative finality.

When a leader proposes a block and the validators vote to form a QC for that block, that block is now in a Voted state (it’s locked by a quorum). In MonadBFT, validators will execute the block’s transactions as soon as they form the QC and even send a preliminary confirmation to clients indicating the block is (speculatively) accepted. This is like saying: “We have a supermajority agreeing on this block. Unless something very unexpected happens, consider this block confirmed.”

This immediate confirmation is optimistic. The block hasn’t been committed in the ledger yet. That will happen when the next proposal comes and finalizes it (QC-on QC), but under normal conditions, nothing will revoke it. The only scenario that can revert a speculatively executed block is if the leader equivocated (i.e. proposed two different blocks at the same height to split the vote)​.

You can think of speculative finality as a nice by-product of tail-forking resistance. The tail-forking resistance guarantees that even if the next leader crashes, the current proposal won’t be abandoned (thanks to reproposal and NEC rules). So the only time a speculatively executed block gets dropped is if the original proposer equivocated (double-signing fault that is provably malicious), which is: 1) detectable via conflicting QCs, 2) slashable and 3) extremely rare.

In previous protocols, they didn’t guarantee that the next leader would repropose the previous block, so tail-forking was possible, breaking speculation assumptions.

Optimistic Responsiveness

In most consensus protocols, there’s a built-in wait after each round like a buffer period or timeout. This is to make sure all messages have arrived before moving forward. It is a protective mechanism meant to handle the worst-case scenario like when a leader crashes or sends nothing at all.

These timeouts are often overly conservative. If the network is functioning normally and all validators are behaving correctly, that fixed wait becomes unnecessary overhead. Blocks could have been finalized faster, but the protocol held back just in case.

MonadBFT introduces optimistic responsiveness which means the protocol can advance immediately based on network messages, instead of always relying on fixed timers. The design principle here can be summarized as “fast when it can, patient when it must.” MonadBFT is designed such that in both the normal case and even in recovery from a fault, it does not pause for a predetermined timeout if it doesn’t have to​.

• In the happy path (means we have an honest leader): There is no built-in delay in proposing or voting. As soon as a leader has the turn, it proposes a block. As soon as validators receive a valid proposal, they vote. The moment the leader (or rather, the next leader, since votes go to the next proposer in pipelined HotStuff) collects 2f+1 votes, QC is formed and can be disseminated. In an optimistically responsive design, this triggers the next phase immediately.

In practice, this means if network latency between nodes is, say, 100ms, the consensus can potentially finish a round in just a couple of hundred milliseconds (plus computation and aggregation overhead). It doesn’t wait, for example, a full second “slot time” if it doesn’t need to. This is in contrast with Ethereum mainnet which follows a slot-and-epoch model [3]. On Ethereum, block production is fixed at 12-second intervals. Even if everyone is ready earlier, the protocol waits.

MonadBFT’s approach eliminates unnecessary delay. It retains the pipelined HotStuff structure but removes the rigid “you must wait Δ seconds” rule in the normal case. This means it can outperform time-bound systems in responsiveness without sacrificing safety.

• In the unhappy path (leader failure): In many consensus protocols, when a leader fails to propose a block, other nodes only realize this after a timeout Δ has passed. If Δ is, for example, 1 second, that time is essentially lost. MonadBFT handles this differently. When validators detect a missing proposal, they immediately broadcast timeout messages (TC or Timeout Certificate). As soon as 2f+1 of these timeouts are seen, the next leader takes over. The transition to the new view is triggered by quorum-based evidence, not by the clock.

Comparison with hotstuff-family consensus

MonadBFT builds on the lineage of HotStuff-family consensus protocols, but stands out by achieving a combination of desirable properties that no previous design has been able to fully integrate without trade-offs.

Earlier protocols were often optimized for some dimensions like pipelined throughput or linear communication but had to sacrifice others. MonadBFT uniquely manages to combine linear messaging complexity, pipelined commits, strong tail-forking resistance, instant responsiveness without fixed delays, and efficient recovery mechanisms, all while preserving fast finality and high liveness guarantees. The table below summarizes how MonadBFT compares to other rotating-leader BFT protocols across these critical dimensions:

What does this mean for Developers?

For Developers, MonadBFT means a couple of things:

• Simpler Finality Model: With MonadBFT, you can treat a block that has a QC (supermajority vote) as effectively finalized for most purposes, because the protocol will finalize it or slash if not. Developers can safely act on 1-block confirmations with high confidence.

• Improved UX for Apps: If you’re building a high-throughput application (exchange, game, etc.), MonadBFT’s low latency and fork-resistance translate to smoother UX. Users see their actions confirmed almost instantly and won’t commonly encounter confusing reorgs or rollbacks.

• Deterministic Behavior: MonadBFT’s stricter rules (like reproposal requirement) reduce the non-determinism in block inclusion. There are fewer “corner-case” scenarios where a block might be included or skipped depending on subtle timing such as whether a vote or a timeout reached the leader first. MonadBFT replaces such ambiguity with explicit rules and verifiable evidence. This makes it easier to reason about the protocol’s correctness and to test it.

• Scalability Headroom: If you are a developer concerned with scaling, MonadBFT gives you more headroom before hitting bottlenecks. And features like erasure-coded block dissemination [4] mean that you can push lots of data through the network without overtaxing individual nodes. This makes it possible to aim for higher throughput which opens up design space for more ambitious on-chain applications

For End-Users. A normie user won’t know about any of the stuff we discussed here, but they feel its effects. With MonadBFT underpinning Monad the chain, users can expect all the nice qualities below without sacrificing on decentralization and censorship resistance.

• Faster Confirmations: Transactions (like sending tokens, swapping assets, minting NFTs, executing trades) will confirm very quickly.

• Fewer Surprises: The consistency of the chain state is higher as stuff like tail-forking, which is an re-org essentially, gets eliminated

• Fairness and Transparency: Improvements in consensus indirectly mean that the chain’s operation is fairer. No single validator can easily censor transactions or play games with ordering across blocks.

Conclusion

To recap, MonadBFT introduces four core innovations on top of pipelined HotStuff-style consensus:

Tail-Forking Resistance: MonadBFT is the first pipelined BFT protocol to eliminate tail-forking attacks​ by requiring the next leader to repropose the last voted block if the previous leader failed, or otherwise show a No-Endorsement Certificate (NEC) as proof that the block lacked support. This guarantees that no block endorsed by a supermajority will be abandoned, protecting honest leaders’ rewards and preventing malicious reorgs and cross-block MEV extraction.

Speculative Finality in One Round: Validators can confirm a block after a single round of communication (one leader proposal and votes), giving clients an immediate assurance of inclusion​. This speculative confirmation will only revert if the leader equivocates (an act that can be proven and punished), making it a safe assumption in practice.

Optimistic Responsiveness: The protocol operates at network speed without inherent delays​. Leaders advance the consensus as soon as the necessary votes are received, and view changes occur as soon as a quorum of timeouts is observed, rather than waiting for a fixed interval. This optimistically responsive design minimizes wait times, while still handling asynchrony and faults robustly when they occur.

Linear Communication: On the happy path (meaning leader is honest), message and authentication complexity is linear in the number of validators​. MonadBFT retains HotStuff’s efficient communication pattern, using aggregated signatures and simple leader-to-validators broadcasts, which enables the protocol to scale to 100s of validators without performance bottlenecks.

Works Cited

Read the full MonadBFT Whitepaper here [5].

[1] https://pmg.csail.mit.edu/papers/osdi99.pdf

[2] https://arxiv.org/abs/2205.11652

[3] https://ethos.dev/beacon-chain

[4] https://www.category.xyz/blogs/raptorcast-designing-a-messaging-layer

[5] https://arxiv.org/abs/2502.20692

About the Author

Michael is an Ecosystem Associate at Monad Foundation. Prior to joining Monad, he worked as a strategy associate at a global cryptocurrency exchange. He also writes about crypto, economics, and policy. Connect with him on Twitter: @michael_lwy.

Introduction

Blind signing, the practice of signing cryptocurrency transactions without understanding the contents of what is being signed, has long plagued the ecosystem and been the root cause of many thefts. Even sophisticated users are vulnerable, such as Chris Larsen, chairman of Ripple, who lost $150 million in January 2024 [2]. Of the $2.2 billion stolen assets in 2024, some $500 million in thefts were directly attributable to blind signing [7]. These risky signing practices have become an unavoidable part of crypto interactions, affecting even the most sophisticated users. A decentralized Fraud Prevention Network (FPN) incentivizes security validators to identify and block fraudulent transactions before they reach the blockchain.

This article examines notable cryptocurrency hacks stemming from blind signing vulnerabilities, analyzes security systems in traditional finance that fight fraud, and demonstrates how a decentralized FPN creates an economic framework that makes security profitable while protecting users' assets.

A Long History of Previous Hacks

Blind signing vulnerabilities have enabled some of the largest cryptocurrency thefts in history, with three recent attacks highlighting how easily security measures fail when users cannot verify what they are signing.

The ByBit Attack

On February 21, 2025, North Korea’s Lazarus Group stole $1.46 billion from ByBit by exploiting Gnosis Safe, the largest multi-sig wallet provider [3, 4]. They first compromised a Gnosis developer’s laptop to harvest AWS credentials, then injected malicious JavaScript into the Safe’s web UI that was prepared to activate on only one routine transaction ByBit had scheduled. They tricked the users into approving unauthorized withdrawals while displaying their expected transactions on the UI. Two minutes after the theft, they erased their code and funneled the proceeds through hundreds of addresses; @ZachXBT later published over 920 of them on ChainAbuse to help trace the funds.

A History of Similar Attacks

Before ByBit, Lazarus targeted two other high-profile players: WazirX, a prominent Indian exchange, and Radiant Capital, a cross-chain lending protocol.

On WazirX (July 18, 2024): Hackers exploited mismatches in how Liminal (WazirX’s custody UI) displayed transactions, tricking signatories into approving a malicious Gnosis Safe withdrawal, stealing $230 million in customer funds [5].

On Radiant Capital (Oct 16, 2024): Hackers disguised themselves as a former contractor of the company, sending a trojan‐laden ZIP of their “recent projects” by Telegram to multiple developers. Once the malware was installed, they waited for Radiant’s team to initiate Gnosis Safe transactions—then silently swapped them to drain lending-pool contracts. They lay dormant for one month, and once the team went to sign a normal protocol operation, changed the payload sent to their ledgers from the correct one to a malicious version. Within three minutes of the team signing, the attackers broadcast the transactions, stole $50m in user funds and scrubbed forensic evidence of the machine’s compromise [1].

Both heists relied on Gnosis Safe multisigs and succeeded by targeting the human element: users who trust the UI and blind sign on hardware wallets. Even an 11-signer, 3-signature threshold Safe is useless if attackers can easily deceive all active signers. Rather than increasing signer counts, a more effective solution could involve introducing an additional transaction veto mechanism.

North Korea's state-backed operations present a persistent threat because they operate with impunity. On the other hand, independent hackers are subject to international litigation and can rarely enjoy their proceeds. Many successful independent hackers end up returning most of the proceeds in exchange for their freedom [8, 12].

Cryptocurrency companies continue to be targeted by North Korean linked groups. In 2024, Lazarus-linked hacks are estimated to have netted their country approximately $1.3 billion [7], representing approximately 4.3% of annual GDP [9]. For a country mostly cut off from the outside world by sanctions, cryptocurrency theft represents a significant windfall for their nation. Insider compromise remains sufficient to defeat multisignature controls. To close this gap, security layers need to not only harden their code, but stop fraudulent transactions from confirming on-chain. Each of these heists appears to exploit the difficulty of payload verification. Many indicators point to blind signing as the root cause, as the user is unable to verify their intent matches what they sign.

Traditional Finance Fraud Prevention Systems

Credit cards power close to a third of all consumer spending in the United States. These cards rely on sophisticated risk management networks that have evolved over decades. Between the card issuer and merchant is a shield activated on each transaction, protecting all parties against fraud while enabling consumers to roll back fraudulent transactions.

When a credit card is used, a defense algorithm activates, checking the transaction against the consumer’s spending history, looking through spending velocity, seasonal habits, implying their current location, and running probabilistic models on their identity. After this review, payment processors then choose to accept or reject transactions.

This system is in place because merchants and card issuers are both incentivized to prevent fraud. If a merchant accepts a fraudulent payment, they lose both their merchandise and the payment when it's charged back. If an issuer misses fraud, they bear costs from dispute resolution and often cover the losses. This incentivizes both parties to stop fraudulent transactions, as 80% of fraud losses are shared between them [10] rather than falling on consumers [6].

Bringing Active Fraud Prevention Onchain

Infrastructure providers currently lack direct economic incentives to prevent fraudulent transactions. Since there is no reason to, wallets, node providers, and validators all disclaim liability from fraud, so the consequences fall on the end user. Unlike credit card networks, where issuers and merchants share the majority of losses to fraud, transactions on public blockchains are final, without mechanisms to intervene and protect users. To fix this, automated security reviews must be embedded directly into the transaction supply chain. By rewarding security validators for preventing hacks and penalizing them for false flags, infrastructure providers are financially motivated to host and run programs to protect users in real time.

To align the incentives of users and infrastructure providers against fraud, a stake-backed, decentralized Fraud Prevention Network (FPN) will review every transaction in real time. The network will reward accurate fraud detection, penalize false flags, and block any transfer that deviates from a user’s normal patterns, stopping unauthorized transactions without slowing legitimate activity.

Transaction Review by a Decentralized Validator Network

While waiting for inclusion in the mempool, a network of security nodes analyzes the transaction for potential threats, looking for unusual destination addresses, atypical transaction amounts, malicious contract interactions and deviations from the user's standard transaction patterns.

Transactions routed through this network have independent validators with staked collateral analyze the transaction. These validators are financially motivated to identify and flag suspicious transactions, as they earn rewards for correctly identifying fraud and face slashing for false positives.

Network Overview and Operating Principles

This network employs an optimistic approval model where transactions are assumed to be legitimate unless explicitly flagged. Account Abstraction wallets allow for the programmability of wallets, per the ERC-4337 specification [11]. Once flagged, execution is blocked, pending further review. The network leverages account abstraction's programmable nature, adding programmable transaction validation, allowing user operations to be intercepted and reviewed by specialized bundlers that query the FPN before block inclusion.

To understand how this network works in practice, consider user Alice's experience. Alice uses an account abstraction wallet to interact with what she believes is a legitimate dApp, unaware it's actually a phishing site crafting a transaction to transfer all her tokens to an attacker's address. When she initiates the transaction, her signed UserOp (User Operation, the transaction format used in account abstraction wallets) is routed through the FPN for validator review rather than immediate broadcast. Within seconds, FPN validators analyze the pending operation and identify several red flags: the recipient address was created by a known threat actor, and the transaction attempts to transfer an unusually large amount of assets to a new, unverified contract. A validator immediately flags the transaction as fraudulent, and other validators independently reach the same conclusion. Once the required quorum is met, the transaction is marked as fraudulent onchain, and the network instructs the bundler not to include it in a block. Alice's transaction never reaches the chain since it was blocked.

Alice then receives a notification explaining why her transaction was blocked, with details "The destination address is flagged as a known scam address." Her funds never leave her wallet, and she pays a small fee, 1% of the amount saved. The validators who correctly flagged the transaction receive proportional payouts from this reward. The entire process completes within three seconds, a minimal delay justified by the funds saved. Should Alice believe the transaction was actually legitimate, she has a window to open a dispute by posting a bond as collateral. A decentralized review council would then examine her case and, if they determine the transaction was indeed legitimate, her bond and reward would be refunded.

Looking Forward: Incentive Alignment at Scale

This network will be wrapped in a simple interface and mostly invisible to users, abstracting away the complexity, risk models, and the entire supply chain underwriting this risk. When an FPN becomes a standard layer of the transaction supply chain, scams and thefts will become significantly harder to execute as attackers know a group of guardians with veto capabilities stands between them and users' funds.

Conclusion

Blind signing in cryptocurrency presents a security challenge: the blockchain recognizes only what users sign, regardless of their intent. This reality has led to billions in losses as sophisticated attackers exploit the gap between interfaces and intent. When frontends or personal computers are compromised, the signed transaction serves as the authoritative record of the user’s intent.

A decentralized Fraud Prevention Network doesn’t just improve security, it transforms the users’ relationship with these systems by adding a safety net to catch them. Routing transactions through security specialists with a financial stake in outcomes converts security from recurring SaaS spend for wallets into a self-sustaining ecosystem of security providers each protecting users. Had institutions like ByBit, WazirX or Radiant Capital used this network, their funds could have been saved, with malicious transactions stopped before reaching the blockchain.

The implementation of economic reward structures for security experts transforms fraud prevention from an externality to a core economic function within the blockchain ecosystem. Through the integration of a continuously operational security validation layer with financial compensation proportional to successful threat mitigation, a foundation for enhanced trust in transaction integrity is established. The proposed Fraud Prevention Network architecture would facilitate an environment where transaction execution more reliably reflects users' intents.

About the Authors

Elliot Friedman is a smart-contract engineer and founder of Kleidi, a decentralized Fraud Prevention Network. Prior to Kleidi, Elliot founded Solidity Labs, a boutique consulting firm that built leading DeFi protocols, hardened the largest organizations in crypto against the toughest threat actors, and created open source tools to help secure governance systems.

Tesvara Jiang is a sophomore at Stanford studying CS.

Works Cited

1. Bitcoin.com News. (n.d.). Radiant Capital hack: How hackers used a PDF to steal $50 million. Retrieved May 16, 2025, from https://news.bitcoin.com/radiant-capital-hack-how-hackers-used-a-pdf-to-steal-50-million/.

2. Blockworks. (n.d.). Ripple co-founder hack. Retrieved May 16, 2025, from https://blockworks.co/news/ripple-co-founder-hack.

3. Sygnia. (n.d.). Sygnia investigation: Bybit hack. Retrieved May 16, 2025, from https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/.

4. Cointelegraph. (n.d.). Lazarus Group 2024 pause & repositioning $1.4 B Bybit hack. Retrieved May 16, 2025, from https://cointelegraph.com/news/lazarus-group-2024-pause-repositioning-1-4-b-bybit-hack.

5. Unchained Crypto. (n.d.). $230 million WazirX hack potentially linked to Lazarus Group, say blockchain researchers. Retrieved May 16, 2025, from https://unchainedcrypto.com/230-million-wazirx-hack-potentially-linked-to-lazarus-group-say-blockchain-researchers.

6. NerdWallet. (n.d.). Merchants & victims of credit-card fraud. Retrieved May 16, 2025, from https://www.nerdwallet.com/article/credit-cards/merchants-victims-credit-card-fraud.

7. Chainalysis. (2025). Crypto hacking and stolen funds in 2025. Retrieved May 16, 2025, from https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2025/.

8. Wikipedia. (n.d.). Poly Network exploit. Retrieved May 16, 2025, from https://en.wikipedia.org/wiki/Poly_Network_exploit.

9. Wikipedia. (n.d.). Economy of North Korea: Size of the North Korean economy. Retrieved May 16, 2025, from https://en.wikipedia.org/wiki/Economy_of_North_Korea#Size_of_the_North_Korean_economy.

10. Federal Reserve. (2021). 2021 Interchange Fee Revenue, Covered Issuer Costs, and Covered Issuer and Merchant Fraud Losses Related to Debit Card Transactions. Retrieved May 16, 2025, from https://www.federalreserve.gov/paymentsystems/2021-Interchange-Fee.htm.

11. Ethereum Foundation. (n.d.). EIP-4337: Account Abstraction via EntryPoint Contract Specification. Retrieved May 16, 2025, from https://eips.ethereum.org/EIPS/eip-4337.

12. Bitdefender. (2023, March 16). Lending Protocol Announces Recovery of Some Funds After $200 Million Euler Crypto Heist. Retrieved May 20, 2025, from https://www.bitdefender.com/en-us/blog/hotforsecurity/lending-protocol-announces-recovery-of-some-funds-after-200-million-euler-crypto-heist

Stanford Blockchain Review
Volume 8, Article No. 1

📚 Author: Jeremy Bruestle — RISC Zero
Yavor Litchev — Stanford Blockchain
Jay Yu — Stanford Blockchain

🌟 Technical Prerequisite: Intermediate

This article is a long-form breakdown of the interview discussion and ideas with Yavor Litchev and Jay Yu, both from Stanford Blockchain Club during an interview conducted in March 2025. Full Video here.

Introduction

Zero Knowledge Proofs (ZKPs) are an area of cryptography which have seen a recent explosion of growth and adoption within the blockchain space. One of the most interesting applications of ZKPs is in building ZK Virtual Machines (ZKVMs), or computers that can prove that they correctly executed code on some secret input without revealing the inputs themselves.

RISC Zero is one of the leading companies within the ZKVM space, building provable computers based on the open-source RISC-V architecture. Within this article, we will first provide a primer on ZKVMs and RISC Zero’s overarching goal, before diving into the architectural design of RISC Zero’s 0STARK prover and the various architectural choices that they have made, and finally discussing some of the real-world use cases that RISC Zero unlocks, both in the blockchain space and beyond.

1 - An Introduction to ZKVMs and RISC Zero’s Prover

Imagine a computer that could print out a receipt, proving that you spent money at a coffee shop, without revealing what items you actually bought. This is the operating principle of a ZKVM, or a Zero Knowledge Virtual Machine.

ZKVMs are a virtual machine that runs trusted code and generates proofs. Developers can write arbitrary code in a language like Rust, have the code compile down to binary, and send it to the ZKVM to both execute the code and verify its execution [1]. The verification of the executable relies on Zero Knowledge Proofs, which allow for the cryptographic proof of a statement without revealing what the statement actually is. Let’s suppose I’m at a bar, and want to issue a proof to the bartender that I am over 21 without revealing what my actual age is. I can first “commit” my age (a secret number) by putting it inside of a cryptographically sealed envelope. The bartender will then challenge me to prove that the number is greater than 21, without actually opening the envelope itself. I provide some cryptographic proof using a “Prover” algorithm, and send this proof along to the bartender. The bartender will then run a “Verifier” algorithm, and either accept or reject the proof.

This is a classic example of a zero knowledge proof between a “Prover” and a “Verifier.” ZKVMs such as RISC Zero do something similar to this, but for arbitrary computation. Instead of creating zero knowledge proofs of simple statements, such as whether my age is greater than 21, ZKVMs use zero knowledge proofs to prove the correct execution of some “guest code” that the user provides it. To do this, they essentially compile down programs to polynomials (which are a mathematical object that can contain an unbounded amount of information) and then run proofs over all of these polynomials. Compiling arbitrary programs down to polynomials is a challenging and computationally expensive operation, as even the most trivial program needs to be represented as an “arithmetic circuits” [2], a nested tree-structure where each intermediary node is either an addition or a multiplication operation, and each leaf node is an input to the program (and the constant 1).

Many early projects in the space have sought to optimize for performance and stay close to the mathematical circuit layer. Circom, for example, is an early domain specific language used to define arithmetic circuits [3]. This, however, requires a high-level of expertise on the part of the developer, as developing in Circom can feel like developing in a low-level assembly language, optimized for performance but without any abstraction features or pre-built elements. Other projects, such as Aztec’s Noir language and Starkware’s Cairo language, seek to use a higher-level Domain Specific Language (DSL) to aid developers to easily create arithmetic circuits with a better developer experience. However, introducing a completely new programming language optimized for proving may hinder developer adoption, especially in an era of AI-assisted coding, as there is far less tooling, documentation, and existing repositories available to reference.

RISC Zero, however, takes a different approach. As its name suggests, one of the company’s defining choices was to based their ZKVM on the open-source RISC-V instruction set architecture (ISA), rather than create their own DSL [1]. RISC-V is a simple, minimal, and modern ISA that is much easier to arithmetic compared to other standard instruction sets such as x86 or MIPS. At the same time, it is a standard target for the LLVM compiler, so many mainstream languages, such as Rust and Go, can run directly in RISC Zero’s ZKVM and developers do not need to learn a new language from scratch. Furthermore, because RISC-V is an open ISA, it comes with a complete set of conformance tests and a formal model of the ISA [4]. RISC Zero could leverage these to ensure their ZKVM implementation exactly matches the RISC-V spec – crucial for security (no hidden undefined behaviors) and determinism. In fact, RISC Zero is working with formal verification tools (like Veridise’s Picus) to mathematically prove their ZKVM’s correctness against the RISC-V spec [4].

Thus, RISC-V represents the perfect balance between the compiler maturity, ZK performance, and semantic security. Developers can thus write code in familiar languages such as Rust, and enjoy existing infrastructure, tooling, and language support, while also leveraging the RISC Zero ZKVM to create secure, provable programs.

From a developer perspective, at a high level, RISC Zero’s ZKVM works as follows [1]:

1. A developer writes a “guest program” in Rust, that gets compiled down to a standard ELF binary

2. The executor executes the binary, and produces an execution trace of the “session”, or a complete record of the computation

3. The prover will take in session, and use that to generate a ZK proof as a receipt.

Under the hood, RISC Zero’s prover splits the process into several steps [5]:

1. Execution. The program is executed, generating a number of “segments.”

2. RISC-V Proving. Each segment is proven separately using FRI-based 0STARK Prover

3. Aggregation Proving. All the segment proofs are aggregated into a single proof, using a FRI-based 0STARK Prover

4. STARK-to-SNARK Proving. In order to output a proof that’s small enough to verify on-chain, the last step in the proving system relies on an elliptic-curve based Groth16 prover for a smaller on-chain footprint

As we can see, the majority of the proving, including the individual proving of the segments and the aggregation of these segment proofs relies on RISC Zero’s own proof system, the FRI-based 0STARK Prover. In Section 2, we will dive deeper into how this 0STARK Prover works, and the different architectural choices that the 0STARK system makes, and in Section 3, we’ll talk about what developers may be able to build using this system.

2 - A Technical Deep Dive into 0STARK Prover Architecture

The 0STARK Prover’s goal is to couple a RISC-V execution engine and session trace with a transparent, post-quantum secure STARK-based proof system. In this section, we will first dive into the reasoning for RISC Zero’s choice of STARKs, before discussing the three key parts to the 0STARK prover system: (1) randomized AIR arithmetization, (2) DEEP-ALI + FRI STARK instantiation for RISC-V proving, and (3) Merkle-based trace commitment scheme [6].

The 0STARK prover system relies on a zk-STARK foundation, eschewing SNARK-based architectures like Plonk or Marlin for several reasons. Firstly, STARKs allow working over small base fields without requiring trusted setups, and their polynomial IOPs naturally express repeated state‐transition constraints in hardware-inspired traces [6]. Secondly, STARKs scale nearly linearly with execution size and avoid pairing‐based cryptography, making them well-suited for VMs with millions of clock‐cycles. Moreover, unlike SNARKs, STARKs require no trusted setup, which simplifies tooling for developers and reduces operational risk. Verification remains efficient, on the order of milliseconds, even for large traces.

Nonetheless, the final step of the RISC Zero process relies on a “STARK to SNARK” process, where RISC Zero wraps the STARK transcript in a Groth 16-style succinct SNARK, yielding short on-chain proofs. This hybrid approach balances the efficient, transparent prover properties of STARKs with the minimal proof sizes enabled by Groth16 SNARKs.

Thus, this architecture is designed for recursive proofs, where one ZKVM proof can be verified inside another. While the current system uses a sequential (non-recursive) composition, RISC Zero engineers are exploring witness folding and proof‐system modularity to eventually enable on-chain recursive rollups without compromising the core AIR structure.

Now that we have discussed why RISC Zero chose to use STARKs over SNARKs as the foundation for its 0STARK system, we can now describe the interlocking components to the 0STARK system: a randomized AIR arithmetization, a DEEP-ALI + FRI STARK instantiation for RISC-V proving, and a Merkle-based trace commitment scheme. At a high level, the 0STARK protocol runs as follows [6]:

1. Setup: Public parameters –trace size, tapset definitions, AIR constraints – are derived from the RISC-V binary

2. Randomized Preprocessing: The prover executes the program, records control and data columns, encodes them via Reed-Solomon, and commits to Merkle caps. A verifier-randomness seeds the generation of memory and byte accumulators, which are also committed

3. Main Phase (DEEP-ALI + FRI): All constraints are linked into a combined constraint polynomial. The prover computes the validity witness, commits its low-degree segments, and responds to a DEEP query point. A batched FRI then checks proximity of the mixed R ap witness to the RS code, with query rounds verifying the integrity of the split and mix operations across multiple cosets

4. Verification: The verifier recomputes the combined constraint at the DEEP point, checks DEEPAnswerSequence consistency, and validates the FRI queries – all in polylogarithmic time relative to trace size

Throughout this model, 0STARK makes several cryptographic design decisions including [6]:

• AIR over R1CS or CCS – In the setup process, Arithmetic Intermediate Representation (AIR) was chosen over R1CS or CCS because AIR naturally captures the time‐sequential, repeating structure of a CPU trace. Each AIR constraint enforces a low-degree polynomial relation between taps (field evaluations of registers or memory at nearby cycles). This leads to fewer and simpler constraints than an R1CS encoding, which would require auxiliary variables and more complex gate wiring for each instruction. While R1CS is more general, AIR yields better prover performance for deterministic, cycle-based computations, and directly leverages fast FFT and FRI operations. RISC Zero is also experimenting with the M³ arithmetization from the Irreducible team for further efficiency gains.

• Handling large programs – Long execution traces from large programs can, in theory, lower the soundness margin if all cycles were checked naively. RISC Zero mitigates this by segmenting programs into smaller chunks, generating partial witnesses for each segment, and then composing them in a final DEEP-ALI step. This segmentation bounds the length of individual AIR checks, preventing an attacker from easily sampling invalid witnesses in a huge trace. The segments are merged using the same mixing and quotienting techniques present in the main STARK loop, ensuring end-to-end integrity.

• Randomized Preprocessing and Constraint Batching Innovations – RISC Zero’s soundness analysis diverges from ethSTARK primarily in its use of randomized preprocessing to instantiate PLONK-style permutation and PLOOKUP-based range arguments for memory consistency. In this phase, accumulators for memory and byte-lookup are computed and committed alongside the trace, enabling a single AIR to enforce both permutation and lookup in one shot.
  
  During DEEP-ALI, all AIR constraints are batched parametrically into a single combined polynomial using powers of a single random field element, rather than multiple independent randomness values. This parametric batching reduces round-trip complexity and improved prover efficiency compared to affine batching in ethSTARK. Similarly, the batched FRI protocol compresses multiple FRI instances into one using a single random challenge, further streamlining proof generation.

• Optimizing Validity Polynomials – Standard STARK constructions yield separate FRI checks for the trace and for the validity polynomial. 0STARK moves beyond this by splitting the high-degree validity quotient into four low-degree “segment” polynomials, each of which is folded into the main FRI invocation. This degree reduction both lowers FRI complexity and unifies the FRI checks into a single proximity argument, tightening the overall soundness bound.

Through its combination of STARK transparency, parametric batching, AIR efficiency, and FRI folding, RISC Zero delivers a high-throughput, developer-friendly ZKVM capable of proving arbitrary Rust programs compiled to RISC-V. This architecture balances practical prover performance with small, fast proofs, and lays the groundwork for recursive proof composition and integration with broader cryptographic protocols.

RISC Zero’s ZKVM is inherently generic: any computation expressible in RISC-V can be proven. This opens the door to running operations on data encrypted via Fully Homomorphic Encryption (FHE), yielding proofs of correct decryption or transformation without revealing secrets. Similarly, ZKVMs can host multi-party computations by encoding MPC protocols as RISC-V code. Many in the community are exploring MPC + ZKVM hybrids, where parties jointly compute on secret data and produce a single succinct proof of correctness. RISC Zero’s flexible proof architecture is well positioned to serve as the trustless foundation for these advanced cryptographic stacks.

3 - Performance and Applications of RISC Zero in Practice

RISC Zero’s ZKVM is not just an academic exercise. In this section, we survey the RISC Zero ZKVM’s performance and its potential applications and developer tooling ecosystem.

There are many methods of benchmarking the performance of a system, however one important metric is quite simply the execution speed of the system. While traditional VMs are measured in billions of instructions per second, zkVMs report throughput in megahertz of proof‐checked execution. RISC Zero currently sustains around 60 MHz of effective execution throughput on a single GPU-enabled prover, meaning it can validate 60 million RISC-V clock cycles per second in zero knowledge, around the computation speed of a 1990s computer [7].

While this may be much less performant than modern CPUs in isolation, the computational cost of ZK proving is already orders of magnitude cheaper than execution on the Ethereum L1. The proof-generation process can be highly parallelizable: by distributing AIR constraint evaluations and FRI folds across multiple GPUs, provers can proportionally increase throughput.

Moreover, just as Moore’s Law once captured the rapid scaling of transistor density, we’re witnessing a ZK Moore’s Law in cryptographic proof systems, where the growth is rapidly accelerating thanks to several simultaneous scaling laws [8]. These include optimizations in arithmetization logic, such as AIR batching, FFT implementations, as well as GPU-friendly FRI algorithms that are delivering year-over-year prover speed improvements that outpace hardware transistor scaling. There have also been proposals for the development of SNARK proving ASICs [9] and other hardware level acceleration tactics for ZK. Similar to the early days of deep learning, where algorithmic advances and parallel hardware yielded exponential gains, ZKVM performance is hyperscaling, with practical prover throughput doubling (or better) each cycle. Over the next few years, ZKVM prover speed is expected to converge towards native RISC-V speeds, closing the gap between proof-checked and regular code execution.

Having ZKVMs available to provide this verifiable computation unlocks many different use cases both within the blockchain world and beyond. In the blockchain world, ZKVMs enhance scaling and privacy by shifting heavy computation off-chain and verifying results with succinct proofs – an idea known as ZK Coprocessors. ZKVMs can also work with components of the existing blockchain scaling stack. For example, RISC Zero has worked with Optimism to add ZK fraud proofs to their optimistic rollup using the Kailua ecosystem, improving finality delays in the optimistic rollup process and reducing rollup collateral costs [10]. Furthermore, RISC Zero also allows for the proving of an entire Ethereum block, including verifying transaction signatures, account and state storage, applying transactions, and updating the state root by taking existing Rust implementations of the Ethereum such as revm and running RISC Zero’s prover [11].

On the application layer, RISC Zero’s ZKVM has also enabled many innovative use-cases. For example, an early demo application was Bonsai-Pay, which allowed users to send Ethereum to others’ Gmail addresses and was based on the RISC Zero Bonsai prover system [12]. The Hashflow Exchange is also launching an off-chain exchange engine called xOS that uses RISC Zero to prove the matching and risk calculations of a high-performance trading engine, with proofs posted to a Celestia-based chain [13]. By separating the fast “service layer” (running off-chain with normal performance) from the verifiable “settlement layer,” Hashflow can give users the best of both worlds: CEX-like speed with DEX-like trustlessness.

RISC Zero’s ZKVM also has further applications in the social and identity realm outside of web3, such as the example mentioned at the start of proving someone’s age without revealing the age itself. In fact, RISC Zero has shown how it can be used to prove that a JSON file contains a specific field and value without revealing the full file [14]. This could be especially useful in selectively proving sensitive information like photo metadata – we may want to prove that a photo was taken by a certain device (such as a Canon 5D Mark IV) without revealing other sensitive information such as the location of the photo.

Crucially, developers can write all of these applications using the familiar language of Rust, rather than have to learn a low-level ZK circuit language like Circom or a DSL such as Noir or Cairo. If you know Rust, or any other language that can compile to RISC-V, you can simply write your logic, compile with cargo risc0 to a RISC-V binary, and the toolchain emits a provable artifact in minutes. And in the process, you can leverage the power of all existing Rust sources, from language documentation to debuggers like GDB to AI-assisted coding tools like Copilot or Cursor. For example, our example at the beginning of proving a person’s age is over 21, we can simply write as our guest function:

// ----
// check_age.rs:

#![no_main]
risc0_zkvm::guest::entry!(main);

pub fn main() {
    let age: u32 = 25;

    let is_over_21 = age >= 21;

    risc0_zkvm::guest::env::commit(&is_over_21);
}

// -----
// main.rs:
use methods::CHECK_AGE_ELF;
use risc0_zkvm::default_prover;

fn main() {
    let prover = default_prover();
    let receipt = prover.prove(CHECK_AGE_ELF).unwrap();

    let is_over_21: bool = receipt.journal.decode().unwrap();

    println!("Proof generated. Over 21: {}", is_over_21);
}

Conclusion

In conclusion, RISC Zero represents a major leap in the evolution of zero-knowledge computing, offering a practical, performant, and developer-friendly ZKVM built on top of the open RISC-V architecture. By combining a transparent STARK-based proof system with a familiar Rust-based development experience, RISC Zero bridges the gap between cryptographic rigor and real-world usability. Its architectural innovations – such as the 0STARK prover, recursive-proof readiness, and hybrid STARK-to-SNARK compression – position it at the forefront of verifiable computation, unlocking a new generation of applications from scalable blockchain rollups to high-performant trading engines to privacy-preserving identity and social proofs.

Looking ahead, RISC Zero is building toward a future where zero-knowledge computing is universal, scalable, and developer-friendly. By standardizing proof APIs, enabling recursive proofs, accelerating performance with hardware, expanding language and tooling support, and streamlining the developer experience, RISC Zero aims to make ZKVMs a core primitive across blockchains and beyond.

References

[1] https://dev.risczero.com/api/zkvm/

[2] https://en.wikipedia.org/wiki/Arithmetic_circuit_complexity

[3] https://docs.circom.io/

[4] https://risczero.com/blog/RISCZero-formally-verified-zkvm

[5] https://risczero.com/blog/designing-high-performance-zkVMs

[6] See details of 0STARK technical paper: https://dev.risczero.com/proof-system-in-detail.pdf

[7] High-end 1990s computers like the Pentium operated at 60 MHz: https://en.wikipedia.org/wiki/Pentium_(original)

[8] See ZK Moore’s Law: https://review.stanfordblockchain.xyz/p/22-moores-law-for-zero-knowledge

[9] ZK11: SNARK proving ASICs - Justin Drake

[10] https://risczero.com/blog/kailua-how-it-works

[11] Zeth: https://risczero.com/blog/zeth-release

[12] Bonsai Pay: https://risczero.com/blog/bonsai-pay

[13] HashFlow: https://medium.com/@hashflowdex/introducing-xos-the-provable-exchange-e875f4e6b30e

[14] RISC Zero JSON Example: https://github.com/risc0/risc0/tree/release-2.0/examples/json

[15] Image Metadata: https://libguides.graduateinstitute.ch/rdm/image-metadata

About the Interviewees

Jeremy Bruestle

Jeremy Bruestle is the co-founder and CEO of RISC Zero, a company pioneering general-purpose zero-knowledge virtual machines (zkVMs). With over two decades of experience in cryptography, distributed computing, and software engineering, Jeremy has consistently focused on bridging emerging mathematical research with real-world applications. Prior to RISC Zero, he co-founded Spiral Genetics, where he served as CTO, developing cloud-based bioinformatics platforms for rapid genome analysis. He also held roles such as Principal Engineer at Intel and Chief Scientist at Vertex.AI, contributing to advancements in mathematical models and algorithms.

Yavor Litchev

Yavor is an undergrad at Stanford pursuing a degree in computer science with a focus on cybersecurity and cryptography. He has previously engaged in research projects relating to secure machine learning and digital signatures with more flexible access structures at MIT PRIMES. More recently, he is researching secure systems and program execution using software fault isolation through the CURIS program. He is currently the cryptography research lead for the Stanford Blockchain Club.

Jay Yu

Jay is an undergrad at Stanford pursuing a double major in Computer Science and Philosophy. He is President of the Stanford Blockchain Club and founder of the Stanford Blockchain Review. He researches designs for Decentralized Autonomous Organizations (DAOs) and blockchain governance with Stanford Law School faculty and as a Research Fellow for IC3. He also works on the investments team at Pantera Capital.

In the blockchain ecosystem, Injective has emerged as a notable implementation of onchain finance. As a high-performance Layer-1 blockchain optimized specifically for financial applications, Injective distinguishes itself through its token economics, approach to asset tokenization, and long-term technical architecture. This article explores three key elements that define Injective's unique position in the blockchain ecosystem: its deflationary model centered around the burn auction mechanism, the revolutionary iAssets framework, and the chain’s technical roadmap.

Injective's Deflationary Model: An Alternative Approach to Tokenomics

The Mechanics of INJ's Deflationary System

Injective implements a deflationary model through its Burn Auction mechanism. Rather than relying on traditional fee burns — which often create friction between network scalability and deflationary goals — Injective hosts weekly auctions where participants bid with INJ tokens for a basket of assets generated from application revenue across the ecosystem. The winning bid is permanently burned, reducing the supply of INJ.

This design fundamentally reshapes INJ’s tokenomics by introducing a deflationary system that scales horizontally with the growth of the broader ecosystem.

The Burn Auction is enabled by two core native modules on Injective: the exchange module and the auction module. These are available out-of-the-box for anyone building on Injective, forming part of its suite of plug-and-play financial primitives. Auctions are held weekly and can be accessed via the Injective Hub or directly on-chain.

The Burn Auction follows a clear and repeatable cycle:

• Fee Collection: 60% of revenue (typically in stablecoins) from applications using the exchange module is pooled into an Auction Fund.

• Bidding Process: Users bid on the collected assets using INJ in an English auction format.

• Burning Mechanism: The winning bidder receives the full basket of assets, and the winning INJ bid is burned, permanently removing it from the total supply.

This cyclical process creates an economic feedback loop. As ecosystem revenue increases, so does the size and impact of each Burn Auction — amplifying deflationary pressure on INJ and driving greater on-chain economic activity. The mechanism forms a central component of Injective's economic architecture.

Mint Module & Dynamic Supply Mechanics

While the Burn Auction reduces supply through market-based burns, Injective’s mint module offers the counterpart: a dynamic, programmable supply system that adapts in real time. The Supply Rate automatically adjusts on a block-by-block basis, calculated based on the network's targeted bonded-stake ratio (Goal Bonded Percentage), Supply Rate Change parameter, lower/upper bounds on token Supply Rate, and Blocks Per Year.

This Moving Change Rate Mechanism is designed to engineer network activity that is responsive and adaptable. When more INJ is minted per block as the block reward, participants are incentivized to stake more INJ to benefit from increased rewards. Conversely, when the block reward decreases, stakers are incentivized to unbond staked INJ due to decreased rewards.

Programmable Token Economy

What distinguishes INJ from other Layer-1 tokens is its programmable economic model built around two complementary mechanisms:

1. Dynamic Supply Mechanism: A programmatic approach to token issuance through the Moving Change Rate Mechanism, which automatically adjusts supply rates in real-time every block. This mechanism operates within predetermined bounds that decrease quarterly through 2026.

2. Burn Auction Mechanism: An innovative mechanism that decouples deflationary pressure from network usage. Rather than burning transaction fees, which creates tension between scalability and value accrual, participants bid with INJ tokens for a basket of assets generated from ecosystem revenue. This aligns network value accrual with ecosystem growth rather than network congestion.

Evolution of the Burn Auction

Injective's burn mechanism has evolved significantly since its inception:

• INJ 2.0 (2023): Expanded the burn auction by allowing any application to contribute to the Auction Fund, not just those using the exchange module.

• INJ 3.0 (2024): Significantly enhanced the deflationary model by increasing the deflation rate 400%, raising the Supply Rate Change from 10% to 50%, and implementing a schedule for quarterly decreases in Supply Rate bounds. Over two years, the lower bound will decrease by 25% (from 5% to 4%), and the upper bound will decrease by 30% (from 10% to 7%).

• INJ Burn Upgrade (2024): Expanded access to allow individual users to make contributions, enabling any project or user to directly contribute to the Injective Burn Auction.

Comparative Advantage Over Other L1s

Injective's tokenomics model differs from traditional approaches used by most Layer-1 blockchains, particularly in how deflationary pressure is applied and how communities engage with the token economics:

1. Active Community Participation: Unlike most L1s where token burns are automatic and passive (e.g., fee burning on Ethereum), Injective’s Burn Auction requires active participation. Users bid with INJ to acquire protocol-generated assets, making the deflationary mechanism inherently community-driven. This transforms token burning from a background process into a direct form of engagement and value expression.

2. Ecosystem-Wide Contribution: The 2024 INJ Burn Upgrade expanded the mechanism to allow any project or user, not just exchange module-based applications, to contribute revenue to the auction pool. This inclusive design ensures that value from across the entire ecosystem contributes to INJ’s deflationary model, not just a subset of protocol activity.

3. Transparent, Decentralized Design: The Burn Auction is fully on-chain and open to all. Its transparent mechanics and public visibility reinforce Injective’s commitment to decentralization. Participants can track each auction, verify the burn, and witness real-time reduction in circulating supply, a level of clarity rarely offered by other L1s.

4. Scalability Without Congestion: Most L1s rely on burning gas fees, which scale with network congestion — a model that can disincentivize growth. Injective decouples deflation from congestion. Because burn volume is tied to ecosystem revenue, not block space, Injective’s model scales linearly with ecosystem expansion, not transaction load.

Scalability of the Deflationary Model

As more applications are built on Injective and ecosystem revenue increases, the size of each burn auction naturally scales upward. This continuous cycle ensures an ongoing reduction in INJ supply that is not directly tied to network congestion, unlike methods most major L1s employ.

The scalability of this model creates a virtuous economic flywheel:

The introduction of INJ 3.0 in 2024marked a major inflection point, increasing the deflation rate by 400% and tightening supply bounds through a scheduled reduction mechanism that continues through 2026.

In a low inflation or deflationary environment, economic activity tends to increase. This is rooted in basic economic principles: as the value of money or assets appreciates over time, participants are incentivized to engage in trade, investment, and productivity to maximize their benefits within the system.

As economic activity on the network rises, two things occur:

1. Applications generate more revenue.

2. New applications are created to capitalize on the thriving ecosystem, further boosting overall revenue.

This creates compounding growth, strengthening the flywheel with every turn.

The Burn Auction collects a portion of protocol-generated revenue and auctions it in exchange for INJ, which is then burned. As ecosystem revenue increases, the size of the INJ Burn Auction grows, further accelerating INJ's deflation rate.

iAssets: Revolutionizing On-Chain Asset Tokenization

What Are iAssets?

Injective’s iAssets represent a paradigm shift in how real-world assets are integrated into the blockchain. Far beyond static tokenized representations, iAssets are programmable financial primitives that enable dynamic liquidity allocation, position-based exposure, and seamless cross-market composability.

Each iAsset functions as an on-chain instrument with second-order utility and zero pre-funding constraints — enabling any stock, bond, or ETF to be launched not as a synthetic stand-in, but as a fully programmable, capital-efficient financial instrument. This unlocks an entirely new design space for tokenized markets.

Market Performance and Adoption

Since launch, iAssets have rapidly gained traction in both adoption and usage:

• Trading Volume: Over $200 million

• Market Share: 78% weekly market share across all chains (year-to-date)

• First Implementation: TRADFI, an index of 500 U.S. stocks, deployed as the first iAsset

These metrics highlight not only demand for on-chain real-world assets (RWAs), but also the effectiveness of Injective’s infrastructure in delivering institutional-grade performance.

The Technical Innovation Behind iAssets

Traditional financial markets remain defined by rigid contracts, intermediary dependence, and exclusionary practices. While DeFi introduced programmability and permissionless access, its early models, most notably overcollateralized synthetic assets, were capital-inefficient and failed to deliver true composability.

iAssets address these shortcomings through a modular framework powered by Injective’s specialized financial infrastructure:

• No Pre-Funding or Over-Collateralization: Unlike synthetic assets requiring 150%+ collateral, iAssets do not require user capital lock-ups, immediately freeing liquidity and improving capital efficiency.

• Oracle-Based Price Sourcing: iAssets derive real-time value from off-chain assets (e.g., stocks, commodities) via Injective’s Oracle Module, enabling accurate, tamper-resistant pricing.

• Permissionless Market Creation: The Exchange Module allows any iAsset to launch as a tradable market using Injective’s on-chain CLOB, ensuring deep liquidity and fast execution.

• Dynamic Liquidity Management: Market makers and institutions supply liquidity to iAsset markets without needing pre-funded collateral pools. Liquidity dynamically adjusts to market demand, creating efficient price discovery and execution.

This architecture ensures that iAssets are not only more flexible than traditional tokenization methods, but also more usable from day one.

Comparison with Other Tokenization Approaches

iAssets represent a significant advancement over existing tokenization methods across both traditional finance and other blockchain platforms:

Legacy Finance Limitations

• Settlement delays (T+1 or T+2) restrict capital mobility

• Clearinghouses (e.g., DTCC, LCH) introduce bottlenecks and lock-ups

• Legal agreements (e.g., ISDAs) limit derivatives access to large institutions

• Fixed trading hours exclude global retail participation

Early DeFi Synthetic Assets

• Required excessive collateral (150%+), reducing capital efficiency

• Collateral drawdowns led to liquidation cascades and systemic fragility

• Isolated liquidity pools limited flexibility and composability

By contrast, iAssets are designed to maximize usability, efficiency, and programmability from launch — with no barriers to global participation or protocol composability.

Key Advantages of iAssets

• Capital Efficiency: No collateral requirements for users

• Programmability: iAssets can power lending, hedging, and complex strategies

• Liquidity: Benefit from Injective’s shared liquidity layer and on-chain order book

• Accessibility: 24/7 trading with global access and instant settlement

Multipurpose Utility and Composability

iAssets integrate directly into Injective’s financial infrastructure, making them deployable across spot markets, derivatives, lending platforms, and structured products, without needing separate liquidity pools or asset silos.

Because of Injective’s architecture, iAssets can also support native rehypothecation with full transparency, enabling advanced capital efficiency without sacrificing security.

For example, a theoretical iAsset like iAAPL (Apple Inc.) could:

• Be traded 24/7 globally

• Serve as margin for leveraged trades

• Be used in algorithmic yield strategies

• Remain auditable and traceable across all rehypothecated uses

This opens up a new category of dynamic financial instruments, where assets aren’t just held — they actively contribute to composable, multi-purpose financial activity.

How Injective's Infrastructure Enables iAssets Without Collateral

Injective’s approach to iAssets is powered by its specialized financial infrastructure, highlighted by its modular liquidity architecture and Exchange Module, which features an on-chain order book for efficient price discovery and trade execution.

Unlike traditional synthetic assets that rely on pre-funded collateral pools, iAssets tap into Injective’s shared liquidity environment. A decentralized network of institutions supplies liquidity to each newly created market, treating iAssets like any other trading pair and dynamically adjusting liquidity provisioning in response to market demand.

This infrastructure allows iAssets to operate as fully tradable, composable instruments from day one, eliminating the need for user collateral and enabling a more open, programmable, and capital-efficient financial system.

Long-Term Vision

Network-Level Liquidity Architectures in Financial Blockchains

One of Injective’s innovations designed to solve the problem of application-specific liquidity is called Liquidity Availability. Rather than requiring each application to silo its own liquidity, Injective transforms liquidity into a shared, network-level resource. This decouples liquidity provisioning from individual dApps, enabling the network to dynamically allocate capital wherever it’s needed most, at any given moment.

Core components of Liquidity Availability include:

• Just-in-Time (JIT) Actions: Autonomous actions triggered by specific on-chain conditions to reallocate resources and fulfill liquidity demands in real time.

• Liquidity Proving: A verification layer that allows dApps to cryptographically prove they possess the liquidity necessary to meet transaction obligations.

• Solver & Routing Layer: A decision-making engine that intelligently routes liquidity across the network, optimizing for execution efficiency and capital utilization.

While iAssets eliminate liquidity fragmentation at the asset level, Liquidity Availability removes it at the intra-application and network level. Together, they create a fully composable financial layer where capital is constantly in motion: adaptive, efficient, and accessible to all.

Expanding the iAssets Ecosystem

The long-term vision for iAssets is to build a comprehensive, programmable financial system that unites real-world assets with blockchain-native functionality. This vision includes:

• Deeper Market Coverage: Expansion into new asset classes such as global equities, ETFs, commodities, and forex pairs, each represented as capital-efficient iAssets.

• Plug-and-Play Financial Products: Structured products, index strategies, and algorithmic portfolios built natively on iAssets, offering institutional-grade tooling for DeFi and TradFi participants alike.

• Scaling Global Market Access: Building on Injective’s existing 24/7, permissionless trading framework, future iterations of iAssets will expand support for additional regions, asset types, and fiat onramps — removing the final frictions that still exist between global TradFi participants and real-time decentralized markets.

Each new iAsset adds composability to the ecosystem, enabling developers and protocols to build higher-order financial primitives without needing to re-engineer core infrastructure.

Network Effects and Market Potential

As the iAssets ecosystem expands, it reinforces Injective’s role as the base layer for capital-efficient finance. By removing collateral constraints and liquidity silos, Injective attracts liquidity providers and developers looking to build in a system where assets can be deployed multifunctionally and reused intelligently.

According to market estimates, the tokenized asset market could reach $30 trillion by 2030. iAssets are uniquely positioned to capture this momentum, offering a live, performant, and composable framework that meets the needs of both retail and institutional players.

Injective is not just building new financial instruments. It is building a new financial system, with iAssets and Liquidity Availability as foundational primitives. This system is decentralized, scalable, and architected for global adoption.

Conclusion

Injective offers a specialized approach to financial blockchain infrastructure. Through its programmable tokenomics, asset frameworks, and modular infrastructure built for financial applications, Injective represents a distinct implementation in onchain finance.

Where most Layer-1s offer general-purpose platforms, Injective delivers a specialized financial operating system: one designed to scale capital markets on-chain with efficiency, composability, and transparency. Its novel auction-based supply reduction mechanism aligns protocol-level activity with supply dynamics, creating a deflationary architecture that evolves in tandem with ecosystem growth. Meanwhile, iAssets break from legacy tokenization models, enabling real-world financial instruments to function as natively digital, composable building blocks across trading, lending, and structured products.

With innovations like Liquidity Availability, Injective is transforming liquidity into a network-wide resource, dissolving the silos that have long fragmented both DeFi and traditional finance. The result is more than a blockchain; it’s a high-performance financial infrastructure layer capable of supporting everything from global equities to algorithmic structured products. All composable, all on-chain.

As the industry accelerates toward mass adoption of tokenized assets and blockchain-native finance, Injective is positioned not just to participate — but to lead.

About the Author

Brandon Goss is the Head of Research at Injective Labs, leading research and market intelligence across decentralized finance and blockchain technologies. Before joining Injective, he was a researcher at Messari and an enginner in the defense industry.

Thanks to Carson, Ekram and Ishaan for their thoughtful feedback on this piece.

With more than $200B in circulating supply, stablecoins have undoubtedly become the most significant sector within crypto today. One could even argue that the stablecoin sector has decoupled itself from the volatile crypto market—stablecoins have proved resiliency despite the crypto market's downturn in 2025, with more TradFi institutions actively integrating DeFi into their solutions.

Specifically, stablecoins have mastered two functions today: settlement for fiat and store of value (SoV). Daily transaction volume for stablecoins is at all-time highs, at $81B, with USDT and USDC capturing more than 95% in both mature economies and emerging markets. They represent not only simple transactions but also financial inclusion and access to a less volatile currency.

However, unlike SoV, yield for stablecoins is in a very different state of adoption. Despite all the innovation in DeFi, yield-bearing stablecoins have remained a niche use case for stablecoins. The total market cap of yield-bearing stablecoins remains at around 10% of USDT and USDC's combined market cap.

Why do such discrepancies exist? More importantly, what can we do to improve where yield-bearing stablecoins are today?

In this piece, we will examine the evolution of yield-bearing stablecoins, the different enforcement rules for yield, and finally, how Cap strives to solve their scalability and safety issues.

Evolution of Yield-Bearing Stablecoins: Endogenous to Exogenous Yield

During the early years, the sources of yield for stablecoins were endogenous; yield stemmed purely from within DeFi platforms. In particular, the yield was generated via liquidity provisioning and platform incentives, meaning the money flow was circular and self-contained. Accordingly, users were jumping from one protocol to another to speculate on the next high APR; thus, yield could only scale as much as the platform.

The most prominent example is crypto-overcollateralized stablecoins or Collateral Debt Positions (CDPs). CDPs are best exemplified by the early days of MakerDAO, where DAI was minted by lending ETH as collateral. CDPs generate yield through interest rates charged to borrowers who use their collateral to mint stablecoins. This interest is then shared with protocol participants, and the mechanism operates entirely within the DeFi ecosystem. Vanilla CDPs could only scale as much as the demand to lever ETH.

Another widely popular model relied on vote-escrow tokens (veTokens), where locking these tokens allowed protocols to direct incentive emissions to certain liquidity pools. These tokens led to what is known as veToken wars, where stablecoin protocols would maximize their ability to control a large percentage of liquidity pools to capture these DEX emissions. These token wars, such as with CRV and BAL, involved yield schemes that relied on external parties purchasing DEX tokens to fuel flywheels.

While both models grew to billions of dollars in TVL, their yields were volatile and speculative. Most importantly, they were limited by the considerably small demand for these platforms, especially compared to the context outside DeFi mechanisms.

Accordingly, founders have made industry-wide efforts to scale stablecoins beyond the ceiling set by endogenous yield models. Acknowledging that most yield for US Dollars can be found outside crypto-specific use cases, strategy-backed synthetic dollars backed by either fiat or other assets have been gaining popularity. From vanilla T-Bill wrappers to experimental hedge fund strategy wrappers, there is now an abundance (as well as fragmentation of liquidity) of stablecoins attempting to address the scalability of yield-bearing stablecoins.

The question then becomes, what lens should we use to analyze these new stablecoins?

Regulating yield-bearing stablecoins

The idea behind yield-bearing stablecoins is simple: a reserve issues new money by lending highly liquid assets to execute an investment strategy.

Beyond the logistical decision of which assets are backing and what lending parameters are used, what fundamentally differentiates a yield-bearing stablecoin is its method for enforcing yield: Who decides who runs what strategies? What recourse do users have in case of bankruptcy?

In other words, the frameworks we use to evaluate enforcement are capital allocation mechanisms and safety guarantees. In DeFi today, there are two prevailing enforcement styles: authoritarian and committee-based. We introduce a third type, self-enforcing yield, that the Cap team is actively pioneering.

The following section is a deep dive into each stablecoin type. Specifically, we will examine the incentives for capital allocation and safety and the corresponding trade-offs.

Type I Stablecoins: Authoritarian

Type I stablecoins are one-sided marketplaces where a single entity utilizes depositor capital to generate yield. They function as hedge funds, where the dApp team handpicks and executes a single (in some cases, few) strategy themselves. As the name suggests, Type 1 stablecoins are centralized, as the team gets the final say over capital allocation and recourse provision. Depending on the team, they can decide to provide safety guarantees, including over-collateralization, decentralization, and transparency, but it is up to the team’s discretion and hence risk is inherently more centralized.

The primary motivations for adopting this model are low development costs for teams and user agency. Low development costs arise from the ease of designing and operating protocols tailored explicitly for a single strategy, such as the basis trade. Additionally, users have the agency to switch between Type I stablecoins to gain exposure to specific strategies.

Examples of Type I stablecoins include Ondo, Ethena, Usual, Agora, Resolv, and other team-run strategy-backed synthetic assets.

Incentive alignment

The decision maker in this model is the dApp team. Naturally, they optimize for higher yield and safety to attract more users. If yield is not competitive or users lose funds, projects quickly become obsolete as more and more projects launch. As such, teams focus on continually growing TVL and maintaining competitive yields.

In theory, it is true that teams should ensure that their strategy has low risk. However, given that most of these stablecoins are incorporated in bankruptcy-remote entities, users have little regulatory or law-enforcement recourse. As such, teams do not have to prioritize optimizing user protections and transparency to the level favored by highly regulated financial institutions.

Trade-offs

The main reason that teams choose Type I stablecoin designs is simplicity. These models have low startup costs because they can focus the engineering effort on implementing a single strategy. This can also reduce the attack surface for potential exploits. Another benefit is user agency. By focusing on one or two strategies, teams return the decision-making power to users - who can move their deposits between applications as market conditions affect yields.

Unfortunately, as mentioned above, Type I stablecoins usually lack recourse. They behave like unsecured loans to application teams. If strategies result in losses, custodians blow up, or teams walk away with user deposits, users have no concrete means to recuperate their funds. Regulations are not present to protect applications if teams decide to hide behind legal structures.

Yet another essential consideration is obsolescence—no strategy can indefinitely generate above-market returns at scale. When a team decides on a particular strategy suitable to the current market condition, they can generate an extraordinary yield of over 30%. Eventually, regardless of the team's competency, market conditions erode the alpha generated by teams, or scale dilutes their yield. This results in teams constantly searching for alternative strategies whenever market conditions change.

Type II Stablecoins: Committee-Based

One obvious solution to the problem of obsolescence is to have multiple strategies that could be run concurrently. Type II stablecoins introduce a governance dimension by establishing committees or decentralized autonomous organizations (DAOs) to delegate user deposits to various yield strategies, including Type I teams but also beyond crypto, including banks and market makers. Rather than internalizing yield generation, these DAOs collectively authorize which external parties can access the pooled capital. Compared to Type I stablecoins, this model shifts the burden of enforcement from a team to a collective.

The primary motivation for adopting this model is scalability. If the current strategy becomes unprofitable or deemed too risky, DAOs can decide to switch to a better strategy. This allows Type II stablecoins to have a stronger robustness guarantee.

Examples of Type II stablecoins include Maple and Sky (formerly MakerDAO).

Incentive alignment

Broadly, three parties can allocate capital: governance token holders, delegates, and committees.

Governance token holders are incentivized to vote to deploy capital to the most performant and scalable third-party strategies. Like Type I stablecoin teams, DAOs want their governance tokens to accrue value. Whereas governance tokens in Type I stablecoins have limited utility and thus function more like equity, Type II governance token holders can exercise more power to have a meaningful impact on the protocol. This leads them to participate in discourse in an open forum that allows DAOs to make more robust, albeit slower, decisions than a single team. Yet, we note that the governance token holders are not necessarily the most knowledgeable in risk management.

Delegates are actors who do not hold governance tokens but are instead allocated voting power by governance token holders. Large token holders like investors and founders typically delegate their voting power to professional delegates, DAO service providers, and university blockchain clubs. Delegates are bound to the best wishes of depositors only by the payments they receive for being delegates, if any. We note that no concrete alignment angles exist between delegates and dApp depositors. Delegates do not have fiduciary duties to depositors, nor do they provide legal warranties to users.

Committees are decision makers within a project assigned to a finite set of decisions. These decisions can include onboarding new collaterals, managing marketing narratives, and other core functionalities of a project. For the purpose of this analysis, we look at committees tasked with allocating user collateral for yield generation. Committees, similarly to delegates, are aligned with depositors by the monetary remuneration they receive from projects. In contrast to delegates, committees tend to have more thorough onboarding requirements. Members of these committees are typically doxxed - this adds an extra layer of protection to the extent that members value their public brands.

Trade-offs

A notable characteristic of Type II stablecoins is scalability via outsourcing. They are a layer on top of professional yield generators, including Type I stablecoins. Because markets always outperform individual teams, Type II stablecoins can harness this market-driven power to achieve yield at scale. The strategies/teams they deploy capital to change as market conditions change, with governing bodies reallocating capital based on performance and safety. In other words, Type II stablecoins have a stronger robustness guarantee than Type I stablecoins.

However, much like Type I stablecoins, recourse is not guaranteed for Type II stablecoins. If third-party teams lose funds, end users cannot recuperate funds. Given the decentralized nature of these organizations, legal recourse is also inviable.

Another important consideration for users is the corruption of groups. As seen throughout the years of DAO experiments, it is relatively straightforward to bribe and corrupt delegates, DAO voters, and committees. Special advisors positions, regular payments, and token allocations are some ways that group decision makers have been successfully corrupted in the past. This directly impacts the safety of Type II stablecoins, as corrupted decision makers can allocate capital to unsafe or malicious actors.

Type III Stablecoins: Self-Enforcing

Type III stablecoins represent a move away from subjective human decision making and towards an autonomously enforced system of common rewards and penalties. In this sense, they resemble more of a protocol than a hedge fund, as seen in other types. Immutable rules set by smart contracts replace the human decision-making process of capital allocation and recourse provision.

The primary motivations for adopting a Type III stablecoin model are safety and latency. Users are protected at the smart contract level, where they can verify the recourse if a strategy fails. Instead of relying on the good faith of dApp teams/committees or obscure legal structures, users can inspect the code to verify the safety guarantees. The latency to switch strategies is significantly reduced in open marketplaces, as they respond rapidly to shifting market dynamics without the delays inherent in governance. This allows Type III stablecoins to fully utilize the power of markets to swiftly identify and deploy multiple concurrent yield strategies.

Today, there are no Type III stablecoins - Cap is the first stablecoin to pioneer this category.

Cap is innovating on the first Type III stablecoin by utilizing the power of lending markets and shared security models (SSMs) to provide efficient capital allocation and credible financial guarantees. The protocol regulates the ability of third-party operators to generate yield by issuing smart contract-level rules of engagement. We recommend interested readers read the introduction article for an overview of the mechanics.

Cap is a three-sided marketplace that combines operators, restakers, and end users.

Operators are financial institutions tasked with generating yield. Their participation is regulated via smart contracts and market dynamics. Before operators can borrow any asset, the protocol first checks if they are over-collateralized as commonly seen in crypto lending markets. The difference here is that rather than the operators putting up the capital themselves, which would be capital inefficient, operators receive delegations from restakers to use locked crypto assets as collateral. This restaked collateral was previously idle, and earns yield via this new use case. It is up to the operators to convince restakers to delegate stake to them.

Capital allocation to operators is economically regulated via the interest rate set by the lending market mechanism. Rather than the team deciding how much each operator should get, operators themselves self-select in and out of the protocol based on whether they can deliver yield at the current benchmark rate. The benchmark rate is also programmatically determined- it is the sum of the deposit rate at major lending markets, plus the added utilization premium at Cap. This utilization premium is calculated as a percentage of capital borrowed, indicating the competitiveness of capital provisioning at a given market condition.

Restakers are rewarded for delegating to an operator. The rate is determined as an agreement via the restaker and operator. Similarly, end users are rewarded for providing capital, where the rate is determined by the benchmark yield. The amount they receive is recorded and distributed onchain, providing transparency to the protocol.

If operators act maliciously or a black swan event occurs, such that the borrowed amount is lost, restakers are slashed. Slashing removes cryptocurrencies held as bonds by retakers to compensate end users. The slashed funds are redistributed to the end users, ensuring recourse is always available and verifiable via code.

Incentive alignment

Since third party operators cannot borrow unless they secure delegations from restakers, the decision makers in Cap are the restakers. They have the final say over which third parties can enter the protocol to generate yield.

Restakers are incentivized to make decisions because of delegation premiums provided by operators. Restaked assets have low opportunity costs and low capital premiums because they are locked crypto assets. In other words, unlike the US Dollar that is being borrowed by the operators, these assets cannot be used to generate significant returns. Hence, they are motivated to delegate to operators on SSMs to create use out of this idle value. With the power to make decisions also comes direct exposure to the outcomes of the decisions. As such, restakers are incentivized to prioritize safety over every other metric.

We note that the north star for Cap is to become a fully permissionless, governance-minimized protocol where operators and restakers can freely participate. Yet, acknowledging that the novelty of the design, in the initial phases of the protocol, both restakers and operators would be accredited institutions and whitelisted. This functions as a safety mechanism for restakers as they would have means to enter into agreements and enforce legal recourse with their counterparty.

Trade offs

The key benefit of this model is safety. Given that decision makers maintain full exposure to their decisions, retail stablecoin holders are shielded from the risk of yield generation. All rules are enforced by smart contracts, removing the need for human arbitration between those that generate yield and those that consume it. This is a notable improvement to the regulatory protections retail investors usually enjoy in traditional finance.

Much like Type II stablecoins, latency is lowered when identifying and adopting new strategies. The system has no switching costs for reallocating capital. Unlike in Type II stablecoins, no lengthy DAO and committee deliberation are needed to allocate capital. Each restaker has the power to separately allocate capital to operators concurrently.

However, we note that this model is far more complex than previous types of stablecoins. These complexities can introduce smart contract risks borne from the reliance on code to regulate the system.

Mass adoption of interest-bearing stablecoins

Yield is far from where it needs to be in order to unlock the potential DeFi has to offer. As the stablecoin market continues to grow, there will be more and more strategy backed interest-bearing stablecoins. But unless a paradigm shift happens in the fundamental design of these stablecoins, we are again bound to face the same risks and fatigue that have prevented us from scaling in the first place. Thus, it is time to grow beyond the limitations of having human judgment in the capital allocation process and create an incentive-aligned system that is more efficient, scalable, and safe.

Introduction: The Foundation of Trust in Decentralized AI

Trust is the foundation of artificial intelligence. Without it, even the most powerful AI models are just black boxes generating unreliable outputs. At Hyperbolic, we are champions of decentralized AI infrastructure. This truth becomes even more critical when we adopt decentralization for AI—a move that promises greater accessibility and lower costs, but introduces new challenges in ensuring reliable results.

At Hyperbolic, we’re building a decentralized AI Cloud to democratize access to AI and push AI’s evolution forward. Today, we power 100,000+ developers with compute and inference. We are solving three pain points in AI today: Access to compute, Verifiability of AI Outputs, and Privacy of user data in decentralized AI systems.

The AI Accessibility Paradox

The acceleration of AI development has created an unfortunate paradox: while open-source AI models are theoretically available to everyone, actually using and implementing them remains out of reach for most. In today's rapidly evolving AI landscape, startups, developers, and researchers face significant challenges accessing the compute they need from traditional cloud providers to keep pace with their ideas.

Currently, sources of compute are centralized with companies such as AWS, Azure, and Google Cloud, creating an impression of scarcity of this valuable resource and allowing these providers to charge inflated prices. The cost of inference is becoming prohibitive as centralized inference platforms charge premium rates that can quickly drain development budgets, forcing teams to limit their experimentation or abandon promising projects entirely. The current pricing is heavily subsidized, but if inference is only controlled by centralized platforms, they will have the control to raise prices and trap developers.

Further, should a developer be able to afford compute from these sources, the inflexibility and complexity of implementing these solutions also serve as prohibitive barriers to innovation and scalability. Meanwhile, the growing gap between model release and availability has become an ever-widening chasm, difficult to cross.

A vast amount of GPU resources in data centers, mining farms, and individual machines worldwide remain underutilized while 2 billion computers around the world sit idle for over 19 hours a day. A common situation has also emerged where companies reserve machines from data centers for years, only to abandon strategies that leave their purchased resources unused. These scenarios all represent missed opportunities for monetization and efficient utilization.

Clearly GPU resources are not scarce, just uncoordinated. Without a way to connect those in need with those sitting on this golden resource, global GPU usage remains exceedingly inefficient and limits productivity in the field of AI.

These challenges make it clear that while a select few large organizations have the resources to leverage AI's full potential, the broader AI community remains constrained by accessibility barriers.

Hyperbolic's Integrated Solution Stack

Hyperbolic is creating an open and accessible AI ecosystem, where AI inference is available to all, democratizing this paradigm-shifting technology. Today, our solution stack consists of three core components that work seamlessly together:

1. Hyper-dOS: Our decentralized operating system that coordinates globally distributed GPU resources.

2. GPU Marketplace: Our platform connecting GPU suppliers with those who need compute resources.

3. Inference Service: Access the latest open-source models, at a fraction of the cost.

4. Agent Framework: Tools powered by Hyperbolic which allows for autonomous intelligence allowing agents to tap into our network, enabling them to evolve, self-replicate, and scale beyond limitations.

In the future, we will implement our groundbreaking Proof of Sampling (PoSP) protocol—the gold standard for verifying AI outputs. Developed in collaboration with researchers from UC Berkeley and Columbia University, PoSP addresses the trust problem in decentralized AI while preserving the cost advantages of decentralization.

We will also introduce a privacy layer for confidential computing, leveraging advanced cryptographic techniques to safeguard data and computations. This ensures strict confidentiality and privacy, allowing even Web2 enterprises with stringent data policies to securely utilize our network with the necessary security and privacy protections.

Let's dive deeper into each component to understand how Hyperbolic is systematically dismantling the barriers to AI accessibility.

Hyper-dOS: The Backbone of Decentralized Compute

The Hyperbolic Decentralized Operating System (Hyper-dOS) was developed to provide a robust and scalable backend architecture to efficiently manage a vast network of globally distributed GPUs. These compute resources are organized into a solar system-like network as independent planets coordinated by a sun cluster that governs and sustains each planetary cluster. This central cluster provides essential services and support to ensure the stability and efficiency of the overall system.

Hyper-dOS is so easy to use that, once installed on an underutilized machine, its compute power is seamlessly integrated with our distributed network in minutes for AI builders to quickly and easily rent scalable and cost-effective compute.

Hyperbolic’s GPU Marketplace: AI Compute at Global Scale

Compute is the limiting factor of AI. The more intelligence scales, the more power it demands. And yet, access remains locked in the hands of a few. AWS, Google, and OpenAI dictate availability, throttle supply, and extract value from the very builders driving innovation. It is a system built on scarcity, and it will not last.

Hyperbolic’s GPU Marketplace is changing that. We coordinate a globally distributed compute network that removes the artificial constraints imposed by cloud monopolies.

• Permissionless access—anyone can contribute or utilize compute resources in under a minute.

• Cost reductions of up to 75%—because AI should not be priced out of reach.

• A network already running at scale—powering Stanford, NYU, Cornell, and the most advanced AI startups today.

This is not an experiment. It is not a testnet. Hyperbolic is live, in production, and expanding. If you are building AI, you will need compute, and if you need compute, you will end up here.

Hyperbolic’s Inference Service: Open-Source Intelligence at a Fraction of the Cost

AI is only as good as the models that power it. But those models remain locked behind restrictive APIs, inaccessible infrastructure, and corporate gatekeeping. Open-source AI should not be an afterthought—it should be the foundation.

Hyperbolic’s Inference Service gives developers frictionless access to cutting-edge models, without compromising privacy or control. With Hyperbolic you get access to:

• The latest open-source models—served on a decentralized network, optimized for efficiency.

• Absolute privacy—no prompt or output data is ever stored on our servers.

• A cost model built for builders—because experimentation should not be a luxury.

We are already powering Andrej Karpathy, former director of AI at Tesla and OpenAI founding member. We support 38+ models, with 100,000+ developers building on our platform today.

AI is moving too fast to be waiting for permission. With Hyperbolic, you don’t have to.

Proof of Sampling (PoSP): The Gold Standard in Decentralized Verification

The Decentralized AI Verification Problem

Trusting the behavior of third party nodes poses a different challenge. How can one be certain that their inference output from a third-party node is valid?

Verification has been a challenge for decentralized technologies for a long time, with just a few methodologies emerging to address the issue. These traditional verification methods often rely on redundant computation or complex cryptographic proofs, which can introduce significant computational overhead to the system.

While such time and computation-heavy methods may have worked for the cryptographic use cases required in decentralized finance, they do not present as a practical solution for verification in decentralized AI inference. It isn't realistic to expect users of AI to wait for 10 days as the generated result of their request is verified. Further, current verification best practices can increase the cost of inference by up to 300%, negating any previously held cost advantage of decentralized GPU networks.

While decentralization promises to democratize access to AI, solutions often lack robust verification mechanisms, leaving developers uncertain about the reliability and consistency of their results. In the absence of trusted verification mechanisms, many remain hesitant to build on decentralized infrastructure—so does it really democratize access?

Trust in decentralized systems requires more than promises.

Hyperbolic's Game-Theoretical Approach to Verification

Hyperbolic's novel Proof of Sampling (PoSP) takes a fundamentally different approach to verification. Developed by our co-founder and CEO Jasper Zhang in collaboration with researchers from UC Berkeley and Columbia University, it secures the decentralized network by relying on a Nash Equilibrium-like approach to verifying outputs.

A Nash Equilibrium can be easily understood in the context of a train ticket verification system. Say a ticket costs $10, and to increase efficiency by reducing the number of train conductors that are required on each train, tickets are checked via a random sample of travelers with a $100 fine if a traveler is found to be without a ticket. One would think that this would open the door for grifters to feel more confident boarding the train without a ticket and thus getting a free ride. Logically, however, if the train conductors check just 1 in 10 tickets, there is a 10% chance that a grifter would need to pay a $100 fine, which works out to $10 for every ride in 10 rides, the same cost as the ticket. The optimized random sampling rate removes any incentive for a rider to act dishonestly while allowing for greatest possible efficiency for the train conductors.

Just as the train conductors don't have to check 100% of the tickets and are still able to ensure that 100% of the riders pay for their tickets, PoSP saves the computational time and energy of checking outputs from all nodes, and instead verifies a strategic proportion of outputs.

How PoSP Works in Practice

When implemented, the verification process begins when a client submits an inference request to the Hyperbolic network. The request is assigned to available third-party nodes based on computational requirements. Meanwhile, the system computes the appropriate verification sampling rate based on node reputation and stake, increasing for newer nodes in the network and decreasing for more nodes that have been proven reliable.

If an output is selected for verification, the system duplicates the work on trusted validator nodes. Should a validator find that the output is invalid, it will send the computation back through the orchestrator to trigger an arbitration process.

Because the cost of arbitration and the probability of validation are established to remain as a Nash Equilibrium, we have created a system where honest computation is the dominant strategy for participating GPUs. We have thus avoided having to spend the computational energy on checking every single result from our decentralized network, maintaining cost efficiency and ensuring practical usability.

PoSP ensures that every inference run on our network is verified without the significant computational overhead of other verification mechanisms, combining the benefits of decentralization with the reliability of traditional centralized systems. This represents a fundamental breakthrough in making the utilization of coordinated decentralized GPU resources both trustworthy and cost-effective.

Hyperbolic’s Agent Framework: The Future of Autonomous Intelligence

AI is evolving. It is moving beyond static models, beyond single-use applications. Autonomous intelligence is emerging—agents that act, adapt, and evolve without human intervention. But without infrastructure to support them, they remain locked in research papers and theoretical discussions.

Hyperbolic’s Agent Framework is designed for this future.

• Self-evolving intelligence—AI that adapts in real time, without retraining.

• Scalable AI agents—capable of operating autonomously across distributed networks.

• A foundation for collective intelligence—where AI collaborates beyond human-defined constraints.

The Future of AI with Hyperbolic

As we continue to push the boundaries of what's possible in AI infrastructure, our commitment to empowering developers with the tools they need to build the future of AI remains consistent. The combination of our rapid model deployment, superior precision, comprehensive model selection, and groundbreaking cost efficiency creates an environment where innovation can flourish.

At Hyperbolic, our mission is to build an open and accessible AI ecosystem. With our integrated solution stack—Hyper-dOS, Proof of Sampling, GPU Marketplace, Inference Service, and Agent Framework—we are empowering AI builders looking to shape the future of AI by making resources available to all.

At MegaETH, performance isn’t an afterthought— it’s the bedrock of what we’re building. Our blockchain is designed from the ground up with the north stars of providing high throughput and more importantly, low latency, to enable apps that were previously impossible. In this article, we’ll explore our design philosophy, the approaches we’ve taken, the tradeoffs we embrace and the benchmarking to support our claims— all of which we wear proudly and unapologetically.

Understanding Latency

Let’s begin with an overview of the lifecycle of end-to-end latency. A given transaction will begin in your browser at home and needs to travel to the block producer. This first step, often referred to as the ‘speed-of-light propagation delay’, takes ~100ms for most city pairs. Short of colocating with the block producer—which may only be necessary for latency-critical applications such as on-chain CLOBS—there isn’t much that can physically be done to optimize this stage.

Once a transaction arrives at a block producer, we enter the domain of block time, where the transaction will likely wait in a memory pool before it is batched, sequenced, and executed. On Ethereum mainnet, this process takes around 12s, whereas performance focused blockchains bring it down to 1-2s.

Lastly, a receipt needs to travel back to the user, adding another ~100ms. Given that the propagation delays are a physical limit, and relatively insignificant, this article will focus on the part that can be optimized— block times.

Sequencing & DA

Above, I mentioned that a transaction must wait in a memory pool before being sequenced— that’s not strictly true and is a byproduct of batched sequencing. Conventional sequencing is done via a consensus algorithm, which, no matter how optimized, requires sending messages at least twice around the world (here we’re not allowed to relinquish responsibility for speed of light delays).

By replacing the consensus algorithm with centralized block production, we eliminate the need for coordination between multiple parties to produce blocks. This allows the active server to process transactions as a continuous stream, rather than having them queue to be batched, minimizing the idle time between blocks.

Here we introduce a key tradeoff—centralized block production. Simply removing consensus and expecting a chain to remain secure is absurd, unless you build it on top of a properly decentralized Layer 1. This architecture was actually proposed by Vitalik Buterin in a 2021 blogpost titled Endgame (https://vitalik.eth.limo/general/2021/12/06/endgame.html), where he concludes that all solutions to scale a blockchain inevitably lead to centralized block production.

But this illustrates something important that sets us apart: we don’t believe in reinventing the wheel, nor are we so arrogant as to think we can do everything best. Instead, we defer security to proven decentralized systems like Ethereum mainnet and EigenDA, allowing us to focus on performance.

Measure, Then Build

The next thing that sets us apart from other blockchains is the initial approach we took to designing our execution layer. Rather than making assumptions or guessing where improvements can be made, we decided to really understand the existing state of the art first. Unfortunately, finding up-to-date performance data proved to be difficult, which explains why the limitations of current systems are often poorly understood by most outside of their core engineering teams.

To address this, we took a methodical approach to experimentation (i.e. started from the ground up (i.e. i.e. decided to measure, then build)). This level of control and granularity allowed us to isolate and analyze specific bottlenecks.

— skip if not interested —

Test configuration:

CPU: Intel Xeon w5-2465X (16 core @ 3.1GHz)

RAM: Samsung 512G DDR5-4800

Disk: Intel SSD D7-P5510 7.68 TB (NVMe PCIe 4.0)

We started by using the Linux cgroup command to simulate machines with varying memory sizes. This allowed us to test cases such as limited memory and high-load. Then, we performed both historical sync and live sync experiments under various memory scenarios to attain a clear understanding of the limiting factors of execution clients, and how they evolve with different modes.

— come back! —

Important to know:

• Historical Sync refers to syncing past blocks on a blockchain, without the need for real-time updates of state changes.

• Live Sync is the process of syncing the blockchain while it is actively being updated, requiring continuous state updates and writing to the database after each block.

EVM Overhead

To isolate execution layer performance without database I/O distorting results, we ran a historical sync using 512GB memory, persisting changes every 500k blocks.

Looking at the transactions per second (TPS) of the first 18 million Ethereum mainnet blocks, we see that TPS averages at ~14,000 in the last million blocks. The TPS volatility preceding this can be attributed to transactions being less complex closer to genesis.

Now, is 14k TPS slow? Of course not. But is it fast enough for the World Computer? Unfortunately not. (Also, consider that this is not true TPS— it’s artificially high as disk I/O overhead is omitted).

To understand this constraint, we analyzed the time breakdown of a common smart contract when it is interpreted by the EVM. We then compared this to the same smart contract, but with its bytecode precompiled to native instructions before execution.

This highlighted a significant bottleneck in the EVM’s real-time translation of bytecode into CPU instructions, which occurs because smart contracts are compiled into bytecode and interpreted during execution. To alleviate this, we implemented Just-In-Time (JIT) compilation, which automatically translates the EVM bytecode into native machine code before execution. Testing against the most recent historic transactions from the ETH mainnet (as of January 2025) has resulted in substantial performance boosts for both average and compute-intensive applications.

State Update Overhead

In Figure 3 we found that the historical sync of the last million blocks achieved 14,000 TPS. When we transition this to live sync—which requires the update of the state root after each block—the average TPS for the same million blocks drops down to around 1000 TPS.

The 14x slowdown between historical sync and live sync can be attributed to two primary factors:

1. Merkleization Cost: Updating the state root through merkleization causes a 9.3x slowdown, even when the entire Merkle Patricia Trie (MPT) fits in memory. This is due to the need for extensive tree traversals to locate and modify nodes, and the fact that numerous nodes must be read before they can be modified.

2. State Writing: Writing the state changes to the database after each block incurs an additional 1.5x slowdown.

To minimize the number of database I/Os required during state updates, we replaced the traditional MPT with a newly designed state trie which significantly reduces disk I/O when updating the state. Additionally, due to the write-intensive nature of the application, we opted for a database optimized for writes.

Further analysis presented a fundamental problem with state access during the execution layer: over 80% of the time is spent on database I/O, with less than 20% on actual transaction execution. By moving the entire state into memory—effectively caching all state data—we were able to minimize disk access to just ~10% of the block assembly time.

A Real-Time Blockchain

Today, through the optimizations outlined above (along with many others), we’re able to reach 10ms block times, even under extreme loads (think 100k TPS). This level of performance empowers developers to build the apps that, they were previously told, are impossible on-chain.

A real-time blockchain will only be realized if we don’t apologize for putting performance first.

Author

Sami Muduroglu leads Developer Relations at MegaETH, overseeing developer onboarding and optimizing the developer experience. He has a keen interest in applied cryptography and high-performance systems. He is currently on leave from Brown University, where he studies Applied Mathematics and Computer Science. He has previously conducted research on how cloud contamination biases satellite observations of Arctic sea ice and worked in industry designing aerial radar-based landmine detection systems.

Huge thanks to Yilong Li for spearheading the research and Lei Yang for guidance and countless contributions.

Bitcoin is digital gold. This idea has been widely embraced by crypto industry leaders for years, and recently respected by mainstream financial figures and institutions. As the first cryptocurrency, Bitcoin laid the foundation for the rapidly evolving ecosystem we have today. But while its reputation as a store of value is well-established, Bitcoin has recently proved itself to be far more than just a hedge against inflation. The future of Bitcoin, and the broader crypto landscape, lies in developing Bitcoin’s untapped potential as a canvas for alternative assets, digital art & media, & the cornerstone of decentralized finance. At Magic Eden, we’re at the forefront of this revolution, building new meaning directly on the Bitcoin blockchain.

Unlocking Bitcoin’s Potential

For years within the crytpo community, Bitcoin has been referred to as digital gold, a label that is now gaining broader acceptance across global financial and economic sectors. Many high-profile individuals, such as BlackRock CEO Larry Fink and President Donald Trump, have voiced their belief in Bitcoin as a store of value. Even Jerome Powell, the chair of the US Federal Reserve, has acknowledged Bitcoin akin to digital gold and encouraged banks to service crypto companies.

This acceptance has led to an increasing number of corporations and nation-states “stacking sats” by holding Bitcoin on their balance sheets as a store of wealth and to hedge against inflation and de-dollarization. This broader recognition is a testament to Bitcoin’s durability and growing influence in the global financial system.

But what if Bitcoin can be more than just digital gold?

When Bitcoin was created as the first cryptocurrency in 2009, the Bitcoin blockchain itself served simply as a means to store and transfer Bitcoin in a peer-to-peer decentralized network. Over time however, builders and cryptocurrency enthusiasts recognized the potential of blockchain technology outside of a store of value. Other blockchains such as Ethereum and Solana, emerged to introduce new capabilities and features that the Bitcoin blockchain was not able to support. These capabilities include decentralized finance (DeFi), non-fungible tokens (NFTs), decentralized applications (dApps), smart contracts, and new fungible tokens. These chains gained value over the years by fostering innovation and enabling new use cases, with their native tokens serving as the currency, and deriving value from, each individual blockchain economy.

Over the past few years however, builders like Magic Eden have started figuring out how to reverse engineer these capabilities on the Bitcoin blockchain itself. The opportunity of these efforts is immense; if builders are successful, they can create a crypto economy backed by digital gold and secured by the most decentralized blockchain network. This may one day allow people around the world without access to banking infrastructure the ability to use a permissionless, free, and fair financial system that goes far beyond simply storing value, and to do it all on a single blockchain network.

At Magic Eden, we’ve been at the forefront of building on Bitcoin, having helped launch and build social consensus towards fungible and non-fungible token standards on Bitcoin. Looking ahead, we anticipate potential programmability upgrades and the integration of smart contracts. These advancements will allow Bitcoin to unlock its full potential and bring the entire on-chain economy home to Bitcoin.

Bitcoin’s Development: Playing Catch-Up

To understand the trajectory of Bitcoin’s evolution, it’s helpful to view it in the context of other blockchains. While other blockchains have been innovating with smart contracts and DeFi applications for years, Bitcoin is steadily catching up.

The most direct comparison can be made to the Ethereum blockchain. In 2017, Ethereum faced its first major congestion crisis due the the abundance of ICOs and the viral onchain game CryptoKitties. This lead to research and development of Layer Two scaling solutions which launched into the market in the coming years.

Bitcoin is just a few years behind. In January 2023, the Ordinals protocol released, making it possible to inscribe digital media directly into individual Satoshis on the Bitcoin blockchain. This advent of a non-fungible token standard quickly took hold, resulting in massive fee spikes that congested the network and renewed research into Bitcoin scaling solutions.

The Ordinals protocol went on to achieve social consensus, becoming one of the top NFT protocols and driving over $2 billion in trading volume in just two years. Following Ordinals, the Runes Protocol released in April 2024, establishing a means to inscribe fungible tokens directly into the Bitcoin blockchain. In 2024, over 50% of transactions on the Bitcoin blockchain involved either an Ordinal or Rune transfer, highlighting both the opportunity and interest in Bitcoin native assets.

As these new protocols gain traction, they are paving the way for a more dynamic Bitcoin economy, where Bitcoin is no longer just digital gold, but a thriving platform for innovation. Additionally, this new network activity plays a crucial role in the future of Bitcoin’s security. During the launch of the Runes protocol, Bitcoin transaction fees surpassed the value of miner rewards for the first time ever. In a future with diminishing miner rewards reliant upon Bitcoin’s price appreciation to make mining economically profitable, transaction fees offer a net new revenue stream that incentivizes participation in mining and network security.

The Challenge of Building on Bitcoin

Building on Bitcoin presents unique challenges, particularly due to its technical constraints and the need to maintain its core principles of decentralization and self-custody. For developers, this means tackling the complexities of Bitcoin’s infrastructure while ensuring a seamless user experience.

There are two key challenges that Bitcoin builders must address:

1. Building the Rails: Creating infrastructure for trading assets on the Bitcoin network is more complex than on other blockchains. Unlike Ethereum or Solana, Bitcoin’s UTXO (Unspent Transaction Output) model and long block confirmation times present significant hurdles for developers. Additionally, Bitcoin’s lack of native smart contract support means that developers must reverse-engineer solutions using simple peer-to-peer transactions.

2. Simplifying the User Experience (UX): Bitcoin’s technical complexities make it difficult for users to interact with the blockchain. To scale Bitcoin’s onchain economy, developers must push the technology to the background, allowing users to engage without being overwhelmed by its intricacies.

A Real-World Example: Solving Mempool Sniping

As the Bitcoin onchain economy grows, we at Magic Eden have played a significant role in developing new, open-source solutions for building applications and facilitating transactions on the Bitcoin blockchain. Most recently, our team successfully developed a solution for the highly technical challenge of Mempool Sniping, which is the practice of “replacing” someone else’s Bitcoin transaction.

Due to Bitcoin’s lengthy block times, unconfirmed transactions in the Bitcoin mempool can be "replaced" with a different version of that transaction, utilizing a higher fee to "jump" the original transaction in line. Though this does not result in any economic loss for those who are “jumped” in line, it significantly hurts the viability of trading alternative assets on the Bitcoin blockchain given that buyers cannot be certain of asset delivery. Additionally, this phenomenon results in sellers accruing less profit from their assets at the point of sale, as value is “discovered” in the mempool through fee escalations realized as revenue by Bitcoin miners.

To solve this problem, while maintaining a fully decentralized marketplace with no asset custody, we at Magic Eden built an intricate solution using Tapscript to encode an allowlist merkle tree of users that facilitates peer-to-peer Bitcoin transactions with minimal trust assumptions. We hope this invention plays a fundamental role in the development of Bitcoin and the Bitcoin economy in years to come. A deep dive on the technicalities of this solution can be found here: https://x.com/MakeTokensFun/status/1853472486597509208, in addition to a video overview of the build here:

Author

Matthew Swetz is the head of Bitcoin Product at Magic Eden, the number one onchain Bitcoin marketplace by transaction volume and users. Prior to joining Magic Eden, Matthew worked in product management and corporate strategy across the crypto and digital gaming industries.

Building a new Web3 service comes with significant challenges: bootstrapping crypto-economic security and assembling a reliable network of operators. Meanwhile, the Web3 ecosystem is rich with opportunities, including a surplus of asset holders eager to earn rewards and skilled Operators seeking to expand into new, value-driven services. EigenLayer bridges this gap, aligning incentives and unlocking untapped potential for both builders and the broader community.

EigenLayer is a protocol built on Ethereum that introduces Restaking, a new primitive for Web3 builders that provides a "marketplace for trust" bringing together restakers, operators, and actively validated services (AVSs). It allows users to stake assets such as Native ETH, Liquid Staking Tokens (LSTs), the EIGEN token, or any ERC20 token into EigenLayer smart contracts, thereby extending Ethereum's crypto-economic security to additional applications on the network. It fosters innovation by enabling newer projects to benefit from Ethereum’s robust security guarantees without the need to replicate the costly process of securing their own network.

Introduction

The original EigenLayer security model had the following structure: each operator can opt into a subset of AVSs, and the entire stake delegated to that operator could be slashed by any of those AVSs, which meant:

1. Less control over slashing risk: An AVS sharing slashable stake could be inadvertently exposed to the risks of slashing by other AVSs. Additionally, the entirety of an operator’s delegated stake is at risk of being slashed by any AVS it opted into.

2. No slashable stake assurances for AVSs: AVSs had no assurance that they would have access to slashable stake when needed.

3. Needs a common slashing veto committee: The system needed a common veto committee to buffer slashing events from becoming systemic.

4. Permissioned onboarding of AVSs: Because of the need for a common veto committee, AVS onboarding needed to be permissioned otherwise the veto committee would be taking on uncalibrated risks.

Eigen Labs is excited to introduce the latest iteration of the EigenLayer Security Model which has been specifically designed to address these shortcomings by offering greater flexibility and control. This blog post is a simple description of how EigenLayer empowers AVSs to operate more efficiently and create economically aligned incentives using three foundational concepts: Operator Sets, Total Stake, and Unique Stake. In upcoming articles, we will dive deeper into the technical details of the planned protocol updates, uncovering the full potential and advantages of EigenLayer’s innovative design.

Operator Sets

An Operator Set is a group of operators who have been delegated ETH by stakers and are assigned certain tasks by an AVS. Although EigenLayer accepts many different types of tokens, and multiple tokens can be used in a single Operator Set, for simplicity, we will proceed using only staked ETH, which we will refer to simply as ETH.

Stakers delegate ETH to operators who participate in various Operator Sets created by AVSs.² To join Operator Sets, operators send requests to the respective AVSs for inclusion. AVSs can reward operators within an Operator Set if they perform their assigned tasks correctly and impose penalties if they do not. An AVS can create as many different Operator Sets as it wants.

Total Stake

The total amount of ETH delegated to an operator is the Total Stake of that operator. An Operator Set’s Total Stake is the sum of all its operators Total Stake. For example, if there are 3 operators in an Operator Set and each has 100 ETH delegated to them, then the Total Stake for each operator is 100 ETH, and the Total Stake for that Operator Set is 300 ETH.

Unique Stake

Operators allocate a percentage of their ETH that an Operator Set is permitted to slash. An operator’s total allocation across Operator Sets must be between 0% and 100%. In other words, a unit of ETH can only be slashed by a single Operator Set at any given time. The allocated amount of ETH is called the operator's Unique Stake for that Operator Set.

If a task is performed incorrectly, the Operator Set may choose to slash an operator for up to that amount as defined by the AVS. The Unique Stake of an Operator Set is the amount of ETH exclusively slashable by that Operator Set.

Building on our previous example, if an AVS has one Operator Set and the three operators allocate 0%, 10%, and 20% of their ETH to it, their Unique Stake would be 0, 10 and 20 ETH, respectively, totaling 30 ETH in Unique Stake for the Operator Set.

Attack Mitigation Using Total and Unique Stake

AVSs can use the Total Stake and Unique Stake of an Operator Set for security. For example, consider an AVS creates a single Operator Set which has operators perform a task and vote on its output. The output that receives more than 50% of the stake-weighted vote is deemed correct. We assume that all pre-existing operators are honest and cannot be bribed to corrupt the task.

Using the numbers from our previous example, if the Operator Set weighs votes solely by Total Stake, a new malicious operator could manipulate the task’s result (attack) by allocating slightly more than 300 ETH in Total Stake (eg. 301 ETH). Without the ability to slash, no penal action can be taken against this operator besides ejection from the Operator Set.

To use slashing as a punitive disincentive for misbehavior, the Operator Set can instead weigh votes by Unique Stake. In this case, the malicious operator would need to allocate just over 30 ETH in Unique Stake to carry out an attack (e.g. 30.1 ETH). Afterward, the Operator Set can slash the malicious operator for 30.1 ETH. While this imposes a tangible economic penalty, it significantly lowers the capital requirement from 301 ETH to 30.1 ETH.

An Operator Set could also require agreement between votes based on both Total Stake and Unique Stake, effectively balancing their weaknesses and leveraging their strengths. This approach forces a new malicious operator to meet the higher threshold of 301 ETH in Total Stake to compromise the task’s result while committing 30.1 ETH in Unique Stake that can be slashed after the attack. Thus, the Total Stake raises the capital required to corrupt the task, while the Unique Stake ensures an economic penalty for the malicious operator.

Operator Sets are Versatile and Extensible

Thus far, we have provided a simplified demonstration of how this security model works. In reality, Operator Sets are far more versatile. For example, an Operator Set can include multiple tasks and tokens, none of which need to be ETH. It can specify slashing conditions for different types of tokens, tasks, and infractions, as well as define confirmation rules for the set of tasks. An Operator Set can determine which tokens will be used to reward operators and how these rewards will be distributed. This model is also extensible to accommodate various preferences for handling slashed stake, including burning or redistribution (see StakeSure), although redistribution will not be available in the initial slashing release. Finally, because an Operator Set’s Unique Stake is only slashable by that specific Operator Set, slashing is localized, eliminating the need for a common veto committee.

Recent Developments

Since publication of the new security model, the team has put out three EigenLayer Improvement Proposals (ELIPs) which are documents proposing changes to the core EigenLayer contracts. They outline the motivation, technical specification, rationale, implementation path, and impact of each upgrade, providing the EigenLayer community with transparency and clarity on upcoming features. ELIP-001 introduces operator-directed rewards, variable operator fees, and batch claiming, giving AVSs more flexibility in distributing and claiming rewards. ELIP-002, now live on testnet, enables the logic of the new security model with slashing via Unique Stake and Operator Sets. Finally, ELIP-003 implements secure key rotation, revocation, and recovery at the protocol level, leading to a more modular AVS architecture and robust key management for upstream contracts integrating with EigenLayer. For the latest updates and discourse, please see our blog and forum.

Conclusion

In future articles we will delve into the nuances of the security model, why it is an improvement over other models, and other components that are actively being researched.

Appendix

¹ Stakers can delegate to only one operator per address. For example, as shown in Figure 1, stakers collectively have delegated 100 ETH to each of the three operators. However, behind the scenes, each staker uses three separate addresses, with each one delegating to a specific operator.

Consider Figure 5 below in the context of Figure 1:

About the Authors

Brett Palatiello is the Head of Economic Research at Eigen Labs, a core contributor to EigenLayer, an Ethereum-based restaking protocol. He brings expertise from a career in finance, software, quant, and his studies at Columbia.

Stanford Blockchain Review
Volume 7, Article No. 4

📚 Author: Ekrem Bal, Hakan, and Yusuf - Citrea

🌟 Technical Prerequisite: Intermediate

While Bitcoin core values lie in security and decentralization, these strengths create inherent limitations in scalability and programmability. Various scaling solutions like the Lightning Network and side chains tried to overcome these constraints, but none have successfully enabled complex applications without sacrificing Bitcoin's security or modifying its consensus rules.

Citrea introduces a new approach to Bitcoin scalability through a zero-knowledge (ZK) rollup architecture. Zero-knowledge proofs (ZKPs) use cryptography to allow one party to prove to another that a statement is true without revealing the statement. With ZK technology, Citrea enhances the capabilities of Bitcoin’s blockspace, transforming it into a fully programmable financial system while inheriting the network’s core values: security, decentralization, and censorship resistance.

Citrea also inherits validity from Bitcoin through its BitVM-based Bitcoin bridge, Clementine. By combining BitVM, zero-knowledge proofs, and Bitcoin as a data availability layer, Clementine enables the safest and most-trust minimized way to bridge BTC and extend its utility. This article focuses specifically on the workings of Citrea’s BitVM-based Bitcoin bridge, Clementine, discussing its peg-in and peg-out mechanisms and how it optimistically verifies ZKPs.

Clementine: Citrea’s BitVM-Based Bitcoin Bridge

Note that Clementine’s design is not final and is subject to change.

In the past, State Channels and Sidechains were seen by the Bitcoin community as the only viable scaling solutions. However, the lack of programmability in the State Channels and the insecurity of Sidechains led researchers to seek alternative ways to scale Bitcoin. In this search, Citrea emphasized that scaling Bitcoin blockspace is the only way to transact with Bitcoin security, therefore proposed rollups as the most secure and incentive-aligned way to scale Bitcoin blocks. Considering Bitcoin’s block-size limitations, Citrea chose to leverage ZKPs over fraud proofs since they are the most efficient way to verify the validity of execution inside Bitcoin within the block size limit.

ZK Rollups collect thousands of transactions, generate a ZKP to ensure their validity and inscribe the ZKP to Bitcoin alongside the data that can restore the rollups’ state. However, the verification of ZKPs on Bitcoin presents a significant challenge due to Bitcoin’s limited programmability.

An emerging solution to this challenge is BitVM, a computing paradigm for expressing Turing-Complete contracts on Bitcoin without changing its consensus rules. BitVM allows anyone to challenge the execution of a contract if the computation is incorrect, making it an optimistic scheme.

Clementine is a BitVM based trust-minimized two-way peg mechanism between Citrea and Bitcoin that optimistically verifies ZKPs to extend BTC’s utility in the most secure and efficient way. The following sections will cover how Clementine handles peg-in and peg-outs and how it optimistically verifies ZKPs.

Peg-in and Peg-outs

Traditional Bitcoin scaling solutions rely on trusted entities for peg-ins and peg-outs, risking fund loss and censorship. Clementine mitigates these risks through its BitVM-based two-way peg mechanism.

Clementine’s architecture relies on three distinct roles, consisting of signers, operators, and watchtowers. Each performs a different functionality. N entities, each one is called a signer, forms a federation by setting up an N-of-N multisig to collectively decide how funds are going to be spent. Operators are another set of entities that front-covers users’ withdrawals, and later get repaid with a reimbursement process. Watchtowers are responsible for challenging the operator in the case of a malicious act, and gets rewarded if challenge is valid.

Here is an example of how this works. To initiate the deposit process, Alice, the depositor, sends 10 BTC to a predefined Taproot address, shown in Image 1. The bridge signers accept, hence sign, the deposit only if it equals to a predefined fixed amount of 10 BTC. Once all signers approve the transaction, Alice’s deposit is transferred to the multisig, and her corresponding cBTC is minted on Citrea. If the signers reject, Alice gets her deposit back trustlessly using timelocks 200 Bitcoin blocks later.

Before accepting the deposit, each signer pre-signs a set of transactions which will be used to punish the operator in case of a malicious act. These pre-signed transactions include timeout transactions and disprove transactions. Timeout transactions will be used if the operator does not send the given transaction, namely kickoff transactions and assert transactions, within a predefined time period.

Peg-ins can be handled using an N-of-N multisig because signers are not incentived to reject a valid deposit. However, this is not the case when it comes to peg-outs because if multisig handles peg-outs, then any signer will be able to censor them and might have an incentive to censor the withdrawal request. To address this, Clementine uses multiple operators to compete with each other for front-covering withdrawals.

Bob, the person who wants to peg-out, initiates a cBTC burn transaction on Citrea, along with a Partially Signed Bitcoin Transaction. Partially Signed Bitcoin Transaction is initiated by Bob, for an operator to front-cover his peg-out. Bob gradually decreases the amount he will get on Bitcoin by initiating new Partially Signed Bitcoin transactions, incentivizing operators to front-cover his withdrawal. Once front-covering Bob’s withdrawal becomes profitable for an operator, Bob’s peg-out will be fulfilled. Bridge operators later get repaid for the peg-outs they front-covered through a reimbursement process.

To handle the reimbursement process, each operator manages a chain of transactions called Collateral Time Transactions, involving Time Transaction 1, Kickoff Transaction, Time2 Transaction and Timeout Transaction. These transactions allow an operator to reuse their collateral by restricting them to cover 1 withdrawal per 2 weeks. Time Transaction 1, shown in Image 2, is a requirement for the operator to initiate a Kickoff Transaction. A Kickoff Transaction involves the operator's commitment to the transaction ID of the deposit they intend to claim reimbursement for. The operator's commitment will be used in the reimbursement process.

The reimbursement process works optimistically, meaning that as long as watchtowers do not challenge, the operator can continue to cover 1 withdrawal per 2 weeks. If watchtowers do not challenge, the operator gets 10 BTC back by using the reimburse connector output in the Time2 Transaction. Later, the operator covers another withdrawal, initiates a new Time Transaction 2 and the cycle continues as long as the operator behaves honestly. Watchtowers challenge an operator if they’re convinced that an operator is malicious, i.e., tries to claim BTC from the bridge without paying for a user’s peg-out. To challenge an operator, each watchtower generates a succinct longest chain proof of Bitcoin, ensuring that they’re following the Bitcoin blockchain. Along with the longest chain proof, the challenging watchtower also provides 2 BTC to the operator to compensate for the Assert Transaction.

After the longest chain proof is submitted, the operator generates a zero-knowledge proof that asserts the validity of Citrea’s Light Client Proof, SPV proof the withdrawal operator has front-covered, see section 8 for SPV, and the validity of all longest chain proofs submitted by the watchtowers.

Operators’ proof is considered to be valid if not challenged by any watchtower for a week. If unchallenged, the operator is reimbursed with the 10 BTC they front-covered. Image 2 below illustrates the entire reimbursement process, which involves Collateral Time Transactions.

Optimistically Verifying ZKPs

Validity inheritance from Bitcoin is one of Citrea’s most crucial attributes, ensuring that the system maintains Bitcoin’s security guarantees. However, achieving validity inheritance is particularly challenging because it requires the verification of ZKPs on Bitcoin, a difficult task due to Bitcoin’s block size limitation.

What makes Bitcoin’s programmability limited is actually its limited blocksize. In theory, a ZKP can be verified directly via Bitcoin Script. However, the ZK verifier function requires around 1.2 GB of Script to execute, while Bitcoin blocks are capped at 4 MB.

Clementine addresses this challenge using BitVM2, an upgraded version of BitVM. BitVM2 enables optimistic verification of ZKPs, meaning a proof is assumed valid unless challenged. This approach relies on a 1-of-N trust assumption, where as long as at least one honest actor exists within the set of watchtowers, any invalid proof will be detected, and the rollup will remain secure.

Challengers are entities that can challenge the given ZKP and punish the prover. To give challengers the ability to challenge a ZKP, the ZK verifier is shredded into functions and each function is small enough to fit into a Bitcoin block. Each functions’ output is called an intermediate state and these functions are chained by their inputs and outputs, shown in the Image 3.

Watchtowers challenge the operator's withdrawal claim by providing the longest chain proof and paying 2 BTC directly to the operator as compensation for the assert transaction. In an assert transaction, the Prover reveals the intermediate states, which must be submitted whenever there is a challenge. If the Operator does not submit the assert transaction, it then gets punished with 2 BTC.

The Operator reveals the intermediate states by signing them with the Winternitz One-Time Signature Scheme and submits the signatures to Bitcoin. Later, the challenger provides the Script of the intermediate state that he believes is invalid. If the challenger’s claim is correct, then he’s rewarded.

Winternitz One-Time Signature Scheme

Winternitz is a hash-based signature scheme that is used in BitVM to ensure the authenticity of input(s) and output(s) of each function. The operator signs each function's input(s) and output(s) with the Winternitz One-Time Signature Scheme and commits to both the proof and the intermediate states which are the outputs of functions, namely Z0, Z1 … Zn.

Before signing, the message is split into 8 bit chunks, and a checksum is calculated to ensure that no other signature can be formed from a given signature. The operator generates a random secret key for each chunk and the checksum, which will later be used to sign them. The operator computes the corresponding public keys by hashing each secret key 256 times and distributes it amongst watchtowers.

To sign the message, each chunk is represented as a digit, which is a value between 0 and 255(let that be equal to N), and the secret key is hashed 256 - N times. To verify the signature, the watchtower hashes the data N times more. If the output is equal to the public key, then the signature is valid. A more detailed explanation of Winternitz One-Time Signature Scheme is represented in the Image 4 below.

The prover splits the intermediate states into 8 bit chunks and signs each chunk using the Winternitz Signature Scheme. These signatures are then submitted to Bitcoin. Watchtowers use these signatures to authenticate the intermediate states. If the signatures are valid, the watchtower moves the signed values to an alt stack to re-execute that function.

If the output of the re-executed function does not match the signed value, the proof is invalid. In this case, anyone can disprove the prover with a single transaction by revealing the script of that function and Bitcoin checks whether the challenge is valid or not. If the challenger is correct, prover is slashed, and the challenger receives a reward. An example disproving is shown in the Image 5 below.

Conclusion

Citrea demonstrates that Bitcoin blockspace can be scaled without compromising the network’s core values of security and decentralization. Its trust-minimized, BitVM-based bridge, Clementine, inherits Bitcoin’s validity and provides one of the most secure ways to use BTC in decentralized finance, without altering Bitcoin’s consensus rules.

Clementine’s design continues to evolve, with ongoing improvements to enhance both efficiency and security. This article features the current design which reduces the complexity around the zero-knowledge proof verifier and improves security. The challenge process is reduced to 2 weeks which was 40 weeks in the old Clementine design. The new version also allows extending the signer and watchtower set and introduces multiple operators to compete.

About the Authors

Ekrem Bal is the Co-founder and Chief Scientist at Chainway Labs,1 where he focuses on privacy and zero-knowledge research. He spearheaded the development of Proof of Innocence and is currently leading efforts to build Bitcoin's first trust-minimized bridge using BitVM on Citrea.

Hakan Karakus is a Software Engineer at Chainway Labs and a recent graduate from Bogazici University with a double major in Computer Engineering and Mathematics. He is a ZK enthusiast and loves the mathematical aspects of important protocols. As a part of the BitVM Alliance, he leads the efforts for BitVM development in Chainway Labs.

Yusuf Ozmiş is an undergraduate student at Yıldız Technical University, majoring in Mathematical Engineering. He works as a Researcher at Chainway Labs, where his research primarily focuses on rollups and their applications in emerging technologies.

Stanford Blockchain Review
Volume 7, Article No. 3

📚 Interview Guests: Avichal Garg and Maria Shen — Electric Capital
✍🏻 Author: Tesvara Jiang — Stanford Blockchain Club

⭐️ Technical Prerequisite: Low

Following SBR’s annual tradition, I sat down (virtually) with Electric Capital's Avichal Garg and Maria Shen to discuss the happenings of crypto in 2024 and explore what we expect to see going forward. This article is a long-form exploration of our discussions, drawing upon their experience in crypto and their research on developer activity to understand what’s coming for crypto this year.

This article focuses on 3 major themes from our discussion: the state of global developer activity, NFT trends, and some of Electric Capital’s latest investments.

Global Shift in Developer Activity

Each year, Electric Capital publishes an Annual Developer Report,1 which is read by hundreds of thousands seeking the most meaningful insights into crypto developer activity across various ecosystems. To compile this year’s report, Electric fingerprinted over 902 million code commits across 1.7 million repositories.[1]

The very first edition of this report was written in 2018. Each following year, Electric Capital is at it again because they believe—and I do too—that the only metric that truly matters to the future of crypto is developer engagement. We need developers to build apps that deliver value to users, to draw customers and, in turn, bring more developers into the scene.

For our interview, I brought Avichal and Maria the following questions and summarized the insights they provided:

1. Could you both briefly introduce yourselves and share how you first got into crypto?

Maria - Maria was first drawn to crypto due to cross-border payment solutions, but only dove into it more after Ethereum launched. She was interested in programmable money, which she thought could solve issues she was facing with her startup in the supply chain space. Specifically, she was interested in using Ethereum to create lightweight and cheap escrow systems. At the time, in 2016, she found that the infrastructure wasn’t ready for real-world use cases, but this exploration led her down the “crypto rabbit hole” and she realized the potential of the technology, even if it was still immature.

Avichal - Avichal first stumbled into crypto around 2010-2011 while working on his second startup, Spool, which focused on mobile content caching for offline reading. During this time, he and his co-founder Curtis became acquainted with several Bitcoin miners and considered doing mining. After selling Spool to Facebook in 2012, Avichal stayed in the space as a hobbyist.

His involvement deepened during the 2017 Bitcoin bull run, where he immersed himself in Bitcoin, Ethereum, and ICOs and conducted educational sessions for curious venture capitalists. By 2018, recognizing that traditional VCs weren’t as knowledgeable about crypto assets, several VCs approached Avichal to manage their crypto investments.

Avichal’s background in distributed systems and security naturally led him to explore privacy-preserving technologies in the blockchain space. His interest in crypto privacy stems from the unique challenges of blockchain technology, particularly in areas like custody and security.

2. The report mentioned that despite all-time highs in new developers, experienced devs are still contributing 70% of code. What does this say about the maturity of the crypto space?

Maria - The space is much more accessible now with numerous options to explore, unlike the early days where we just had Bitcoin and Ethereum and experimenting was costly. Today, developers can easily build on new chains with extensive documentation and supportive communities of mentors. However, there's churnamong newcomers. While onboarding is easier than ever, true commitment requires a significant mindset shift from traditional development. Once developers make it past this initial hurdle though, retention rates are notably high. This dynamic explains why experienced developers still drive the majority of contributions.

3. Asia has overtaken North America as the leading continent for crypto developers. How has this affected your investment thesis?

Maria - The biggest growth in new crypto developers came from India in 2024. However, we also see developer activity increasing from regions like Nigeria, Southeast Asia, and more. I’ve spoken to some developers from these areas who use crypto and stablecoin and then decide to build better applications for it because they know best how to improve the product for their needs.

Avichal - Avichal mentioned later on, something that is also relevant here, that building core infrastructure requires larger dev teams and funding. But countries in Asia and Africa generally have less of both the technical expertise and access to capital to enable this. This reinforces the division.

4. One in three developers now works across multiple chains, with EVM chains leading this trend. How do you see this multi-chain ethos evolving, especially with the rise of ecosystems like Base and Solana?

Avichal - Each chain has carved out its own niche. Ethereum is used for high-value, high-security operations, while Solana and Base are used for speed and price-focused applications like NFT minting and gaming. They are super-fast and low-cost compared to what Ethereum is providing today, so we see that as long as community and affordability are there, most of the activity will follow.

Solana has become the leading ecosystem for new developers in 2024. It’s attracting developers with its high-performance architecture and growing ecosystem. Another key player is Base. Base has the advantage of being EVM-compatible and backed by Coinbase, which makes it easy for Ethereum developers to move their applications there. It became the most popular chain among EVM multi-chain deployers in 2024, now taking 25% of the original on-chain code logic on all EVM chains.

NFT Adoption

5. You mentioned NFT action expanding beyond artwork, what are some examples that you are following?

Maria - NFTs and blockchain ledgers have the ability to accurately assign ownership. One example is BasePaint. BasePaint is a crypto collaborative art project on Base where artists create digital art together on a shared set of pixels. After each 24-hour creation period, the artwork is turned into an open edition NFT, with 90% of the profits distributed to contributing artists based on their pixel contributions. IP on chain is straightforward. Digitalized contributions and smart contract governance over profits ensures that everyone is rewarded proportionately to the number of pixels they contributed.

Avichal - In blockchain things are either fungible or non-fungible. Most things are non-fungible—unique and irreplaceable. They are NFTs, which are their digital representations on the blockchain.

One of the first applications of NFTs is PFPs. It's a way to signal to others that you have excess capital if you can buy a $100k NFT or to display that you are an early adopter. Both of these are a means to signal social fitness. Humans as primates have a deep seeded desire and need to signal fitness to each other. In a digital realm, with people spending 12+ hours a day online, this will happen primarily online and through digitally scarce goods. For example, if you are in a video meeting on Zoom, most people don’t care what shoes you’re wearing. You may care because you are into shoes and craftsmanship. But a huge portion of the world buys nice shoes so that others can see it. In that environment, what you are wearing above the shoulder matters most.

NFTs are just the natural mechanism by which humans will socially signal to each other in a digital world. Knowing that something is cryptographically verifiable as scarce drives value, and this value drives social signaling. Instead of buying expensive shoes or an expensive watch or an expensive purse, people will buy expensive digital goods.

This reminds me of the early Internet where time spent had shifted online, but advertising dollars were still primarily spent on television and newspapers. Social time and work time has shifted online, but luxury goods spending and spend directed towards social signaling has not yet shifted online.

As a result, we have invested in many investments in the NFT space, like Magic Eden, the largest NFT marketplace across chains. When Electric first met the Magic Eden team, it was clear that they were one of the best in crypto and they understood the value of NFTs, memes, and digital culture.

Magic Eden is a leading multi-chain NFT marketplace that supports trading on Solana, Ethereum, Polygon, and Bitcoin Ordinals, known for low fees and user-friendly platform. Electric Capital led the last round and was an investor in the seed round. Other investors include Sequoia, Greylock, and Paradigm. The company’s most recent round valued them at $1.6 billion.

7. Have you heard of NFT-compatible credit cards from Mastercard?

Maria - No!

Tesvara - I had a dinner with our president of SBC, Jay, where I learned of it for the first time. There’s an NFT Customizable Mastercard made by hi, a crypto & fiat financial app. You use the card to spend fiat, stablecoins and other cryptos on products worldwide, and customize the cover with an NFT avatar that you verifiably own.

I think these kinds of real-world integrated initiatives are really good for helping conversion of people into crypto, or at least expose more people to it. And also being able to spend crypto from a card increases the utility of having crypto. And third, having something flashy like this is also a natural product to sell to online people, who by definition are already interested in these types of community signaling, and would be interested in more ways to show that they are part of some group.

Electric Capital’s 2024 Investments

8. The report highlights your investment in EigenLayer which introduced re-staking as a service, adding $30B+ in Total Value Locked (TVL) to Ethereum this year. How do you evaluate its impact on Ethereum and DeFi, and what’s next for EigenLayer?

EigenLayer offers “re-staking as a service” It is a middleware protocol on Ethereum that allows ETH validators to re-stake their tokens to secure additional protocols. Electric Capital participated in EigenLayer’s $14.5 million seed round in August 2022 and $50.8 million in a Series A round in February 2023.

Maria - EigenLayer introduced Liquid Re-staking Tokens (LRTs) as a new sector, which added over $30B TVL to the Ethereum mainnet. EigenLayer is a great example of the developer flywheel. EigenLayer began with a small group of dedicated developers who unlocked a new use case. This new use case attracted capital, users, and new products. As TVL grew, more developers began to build AVSes for Eigenlayer, creating even more utility and attracting more capital, users, and developers.

9. Why did you invest in Monad?

Monad is an EVM-compatible Layer 1 blockchain designed to achieve high performance without sacrificing decentralization or security. Electric Capital participated in Monad’s $225 million in a Series A round in April 2024, led by Paradigm.

Tesvara - Monad’s approach to achieving high performance while maintaining EVM compatibility bridges the gap between Ethereum’s robust developer ecosystem and the speed and efficiency needs of consumer applications.

Avichal - The founders Eunice Giarta, Keone Hon and James Hunsaker are past big-tech managers, and Jump Trading alumni with expertise building high-frequency trading systems. Their experience translates well to creating a fast and scalable blockchain infrastructure.

Both Maria and Avichal stressed the potential of Monad to enable new use cases that require both Ethereum compatibility and high transaction throughput, such as on-chain order books and complex DeFi protocols. They view Monad as a potential catalyst for the next wave of blockchain application development.

Conclusion

10. Many of our club members new to crypto often ask “What should I work on?” As someone deeply involved in the space as VCs, what gaps do you see that our devs at Stanford could fulfill?

“Go build weirder applications.” - Maria

Stability in the Best of Times vs the Worst of Times

With the advent of a new federal regime, the crypto market has been more optimistic than ever. At the time of writing, Bitcoin is pushing $100,000 per token and altcoins have risen over 50% in a week.1 Despite these gains, however, some top coins have held constant in their price – and that’s a very good thing.

While speculating on the value of cryptocurrencies can generate excitement in the space, the volatility associated with it serves as a major barrier to adoption. Cryptocurrencies are transacted quickly, but when trading pairs fluctuate by more than 1% in an hour, the result is an unstable medium of exchange. Users seek decentralization, but not at the cost of a potential default. Stablecoins may be the solution – providing order in a market that’s rife with uncertainty.

A stablecoin is a cryptocurrency that attempts to fix its value in line with some underlying asset, be it a fiat currency, like US Dollars, or a commodity, like gold. By pegging their value to another asset, these tokens stabilize transactions by removing the incentive to speculate on their value. Using them is analogous to putting assets in a blockchain bank: you gain access to its fast, decentralized financial infrastructure, but still maintain a redeemable digital representation of them as a store of value.

Though what makes a stablecoin, stable? How do stablecoins keep their value? And to what extent should we be using stablecoins? I sat down with Dr. Gordon Liao, the Chief Economist of a major stablecoin provider, Circle, to learn a little bit more.

All Dollars May Be Equal, but their Stablecoins Are Not

While the Department of the Treasury reports stablecoin usage has increased dramatically in the past few years,2 their presence in the crypto market is longstanding. Because they resist price fluctuations, stablecoins like Tether, USDC, and Dai are popular choices for transacting cryptocurrencies both with exchanges and on-chain. They all seek to hold a peg at a US Dollar, but their mechanisms for doing so vary dramatically.

Depending on their construction, some stablecoins prioritize decentralization, while others prioritize regulatory compliance. Although they may be pegged to the same asset, they have different processes for obtaining the tokens and may even require different kinds of assets to mint them. Clearly, designing a stablecoin is no easy feat – though according to Dr. Liao, much of the work has already been done.

He mentioned that asset-backed stablecoins are well studied, so their risks are relatively known. In particular, he mentioned that it’s important to have a highly liquid asset backing the stablecoin as well as ensure that the backing assets are segregated for the benefit of the stablecoin holders. Additionally, providers need to manage issues outside of the stablecoins themselves, such as credit, market, and operational risks. Given this large set of issues, Dr. Liao’s team recently published the Token Capital Adequacy Framework3 to help synthesize all of these complicated metrics into one place. In doing so, he hopes to help create industry standards for stablecoins, so that users can make an informed choice about their provider.

Stability in Different States

Circle, for example, emphasizes transparency and stability. Unlike its peers, Circle publishes both their Reserves Composition4 as well as advertises third-party daily reporting on the Circle Reserve Fund.5 Dr. Liao further explained that due to these reserves, a user should always be able to redeem their USDC for an equivalent fiat value in the long term. The assets backing the USDC stablecoins, themselves, are segregated; and therefore, offer strong assurance to Stablecoin users.

In the short-term, however, spot market prices for USDC can still be slightly different than a dollar. This is because tokens like USDC are traded on a secondary market, so short-term inefficiencies in trading pairs can cause the price of USDC to diverge slightly from its dollar peg. Usually, this is due to the liquidity of market makers. He gave the example of a crashing Bitcoin price, where traders will rush into USDC as a “safer” asset. In doing so, they can artificially inflate the value of USDC to be slightly over a dollar, before it quickly moves back to its pegged value.

Circle, however, doesn’t see much secondary market conversion against fiat. Dr. Liao noted that approximately 95% of the USDC redemptions occur on the primary market, directly through Circle as the issuer. This has held even in cases of uncertainty, such as the collapse of Silicon Valley Bank,6 which led to billions in USDC redemptions.7 Thus, while the spot price of USDC may be slightly different at times, it doesn’t necessarily mean that USDC has lost its peg. It’s often just a matter of temporary market inefficiency.

On the other hand, cases like the SVB crash could provide evidence that transparency in assets backing a stablecoin may sometimes be a double-edged sword. While transparency is a highly desirable trait in a stablecoin, especially one with a multi-billion dollar company behind it,8 listing the location of assets could certainly stoke fears in the market. That being said, one would be hard-pressed to find a crypto advocate who believes that absconding financial information is the best method of financial security. Blockchains are built on truth; and even if it sometimes hurts, it’s best that the public is well informed of the issues.

Stablecoins and Decentralized Finance

Beyond serving as a store of value, stablecoins have a long found utility as a method of powering Decentralized Finance (DeFi) applications. In fact, MakerDAO, one of the first major DeFi protocols, is a decentralized stablecoin provider that mints the popular US Dollar stablecoin, Dai, in exchange for an Ethereum lockup.9 Despite Circle’s existence as a centralized financial institution, Dr. Liao recognizes the importance of the DeFi ecosystem, claiming that it’s central to the blockchain and web3 space.

Unfortunately, much like the broader crypto market, the DeFi ecosystem is marred by a history of volatility. For example, consider the spectacular collapse of UST, an algorithmic US Dollar stablecoin managed by the Terra Blockchain.10 Instead of relying on equivalent backing in fiat funds, UST derived its value in part from its governance token, LUNA. Given their symbiotic relationship, when both tokens suddenly collapsed, it wiped out billions of dollars in value. For this reason, Dr. Liao argues that we should “want the safest form of a store of value and a unit of account to be the bedrock of DeFi.” By this criteria, USDC is certainly a strong contender to underpin the ecosystem.

At the same time, however, DeFi advocates could argue that there’s something inherently contradictory with using a centralized stablecoin, like USDC, to power DeFi infrastructure. While perhaps less secure, if we seek to truly embody the ethos of decentralized finance we may want stablecoins run through DAO Governance, such as MakerDAO’s Dai, Under this argument, however, one could reasonably argue that underpinning the global DeFi with a stablecoin tied to a national currency is centralized for the same reason – yet this hasn’t stopped the US Dollar from serving as a stablecoin gold standard.

Dr. Liao has a different perspective on what DeFi really means: “DeFi, overall, is not necessarily about decentralizing governance or decentralizing permissioning even, it’s about decentralizing balance sheet capacity.” From the failures he’s seen in the legacy financial system, he explains that he believes “the biggest innovation is the ability for you to really decentralize risk-taking to a greater set of participants that otherwise wouldn’t have the technology to participate.”

He offers the example of market making, where he claims that historically we’ve needed “highly sophisticated technology and highly sophisticated capital to participate”; thereby, leading to a highly concentrated market structure with high frequency trading firms running the show. Dr. Liao claims that “the difference with DeFi is that you can harness the technology to use a broader set of participants – it’s not just specialized firms, but also just everyday capital owners.”

Perhaps the best example of this collective impact are on Decentralized Exchanges (DEXs). Besides serving as an oasis for meme coins, DEXs democratize the traditional order book in a way that’s fast and easy-to-use. As a course assistant for the new Stanford GSB Pathfinder course, BUSGEN 102, I saw this first-hand. Students with no prior experience suddenly became traders and liquidity providers for our fictitious “Red” and “Blue” tokens on Uniswap’s Sepolia Testnet. No longer were they bound to centralized exchange to trade – they could do it with each other.

When DeFi provides this level of access, the issue of stablecoin centralization might be moot. After all, if our goal is to truly achieve a truly decentralized financial infrastructure then we should be able to work with all stablecoins without consequence – be it USDC, Tether, or Dai – bearing in mind that DeFi protocols may choose the same. There may not be a one-size-fits-all stablecoin, but the other ones are always just a swap away.

Stablecoins in the Modern Era

Recognizing these various preferences within the crypto community, Circle has also taken major steps to make USDC interoperable across a variety of chains. Dr. Liao discusses Circle’s software that allows users to burn USDC tokens across one chain and mint an equivalent amount on another chain. He claims this functionality is a major benefit of USDC, as it’s relatively seamless compared to using a bridge to move assets between blockchains, which historically are quite bug-prone. Dr. Liao acknowledged that while Circle’s trust–based intermediation is centralized, as DeFi continues to expand the need for these platforms will grow to prevent the space from becoming too fragmented.

Finding the right amount of centralization, if any, within blockchains has also gathered a substantial amount of regulatory interest. In addition to litigation, governments have experimented with a controversial new class of stablecoins known as Central Bank Digital Currencies (CBDCs). Usually issued by a central bank, these cryptocurrencies can be thought of as a stablecoin representation of a national currency. Given their blockchain-based implementations, they offer significant advantages over legacy banking systems with respect to efficiency; but at the same time, the transparency that makes crypto projects successful might be exactly what makes them dangerous.

While CBDCs may leverage blockchain technology, current implementations offer a marked departure from the stablecoin structures we know today. Perhaps the most well known implementation of a CBDC is the e-CNY, a stablecoin pegged to the Chinese Yuan organized by the People’s Bank of China. As of July 2024, the token has been piloted inside 29 pilot areas with personal identifiers being needed to access the token.11 Given its lukewarm reception, however, the Chinese government has become more aggressive with their adoption efforts with some cities mandating that public sector employees receive their salary in the token.12

Dr. Liao noted that the places where CBDCs have been launched in beta modes, tend to be more controlling. Indeed, the Royal Bank of Canada recently confirmed to CBC that they’ve shifted focus away from CBDC development and Jerome Powell,13 Chairman of the Federal Reserve, has claimed that the creation of a US Dollar CBDC would require congressional approval.14 That being said, we may see the first government sponsored US dollar stablecoin in the Wyoming State Token,15 which is set to launch in 2025.16 Regardless of the token provider, however, Dr. Liao still emphasizes that high standards are needed in terms of reserve backing.

Whether operated by a government entity, private corporation, or smart contract, the future of stablecoins remains an exciting prospect. Grounding the blockchain space in real-world assets may just bridge the gap between our banking institutions and a future of decentralized finance; but at the same time, we must remain vigilant to ensure this balance is properly struck. Without sufficiently decentralized stablecoin infrastructure, we risk losing Satoshi’s vision. Blockchains may devolve to the very centralized institutions they were created to avoid. Though, without proper stablecoin backing, our tokens may have no teeth. There’s no value to rely upon and no one to shoot if it all goes wrong.

About the Authors

Gordon Liao

Gordon Liao is the Chief Economist and Head of Research at Circle International Financial, a leading financial services firm building payment infrastructure for the internet. He is also a Research Fellow at the Cornell Fintech Initiative and a co-chair of the National Association for Business Economics Finance Roundtable. Gordon’s career has encompassed diverse areas within finance and technology, including fixed income relative value trading at the Harvard endowment, machine learning and AI at Kensho, policy advising on short-term funding markets at the Federal Reserve Board of Governors, and leading research and development in decentralized finance and tokenization. His research contributions have been published in respected journals such as the Review of Financial Studies and Journal of Financial Economics. His work has been featured in Bloomberg, WSJ, Barrons, PYMNTS, among others. Gordon holds a Ph.D. in Economics from Harvard University. He received his Bachelor’s degree in Applied Mathematics from Harvard College.

Austin Bennett

Austin Bennett is the VP of Finance at Stanford Blockchain, pursuing a triple major in Data Science, Economics, and Public Policy as well as a Master’s in Computer Science. At Stanford, he works as a researcher for Stanford CodeX, the Computational Law Center, as well as the Finance Department at the Graduate School of Business. There, he helped create a GSB class on stablecoins called “BUSGEN 102: The Future of Money and Payments”, for which he serves as a course assistant. Beyond these pursuits, Austin is passionate about Blockchain Governance, Crypto Law, and his hometown Boston Bruins.

Many thanks to Andy Hung from Stanford Blockchain Club for reviewing and editing this article!

Science today sits on top of a paradox: on the one hand, scientific innovation thrives on open borders, open communication, and international collaboration. On the other hand, opaque and convoluted funding mechanisms, drawn-out research processes, and the uncertainty of breakthrough success forces scientists to fight for funding and mindshare from a handful of ivory-tower institutions and donors.

But what if, instead of having to seek funding and prestige from gatekeeper organizations, scientists could bootstrap their wildest ideas from a decentralized community? This is the promise of decentralized science: a paradigm shift in the way science is produced, accessed, and monetized. In this article, we will discuss how we might be able to use crypto rails to address three core issues in academic research: the accessibility of science, the funding of science, and the productionization of science.

1 - The Accessibility of Science

The History of Open Science

The concept of “open science” has a long history, and one that has been greatly intertwined with the development of the Internet [1]. The World Wide Web, for example, was originally conceived and developed as a tool for information-sharing between different universities around the world [2], and the idea of “open source software” also has its roots in an academic and research setting.

Open science is fundamentally about accessibility – of papers, data, and methodologies. Today, renting a single research paper for 48 hours from an academic publisher can cost over $30 – something completely unsustainable for scientists with a budget constraint and not affiliated with wealthy universities or research institutions [3]. Journal publishers have built billion-dollar businesses with profit margins that dwarf even those of the most successful tech companies, largely by positioning themselves as intermediaries using prestige. Critics argue that this publishing model diverts valuable resources away from productive research [4].

Within the “open science” movement, perhaps one of the most interesting and controversial projects is Sci-Hub, a “shadow library” that provides direct access to millions of research papers and journals, regardless of copyright. Unsurprisingly, Sci-Hub, like many other open-access “shadow libraries,” have faced a lot of criticism over the ethical considerations, and in 2022, the head librarians of Z-Lib were arrested for copyright infringement and other charges [5]. These arrests sparked some alarm from the research community, with some calling this a modern day “burning of the Library of Alexandria” [6] – a testament to the vital role that open access plays in the process of academic research.

Today, in many fields of academic research, researchers often share their latest work via online “preprint servers” such as ArXiv, before submitting their work to journals for peer review. Unlike shadow libraries such as Sci-Hub, which operate outside of the process of academic publishing, preprint journals are an integral part of the multi-year academic process. However, many of the popular preprint servers today rely on legacy infrastructure from over 30 years ago, and are hosted by centralized university servers. ArXiv, for example, was created by Cornell University researchers in 1991 [7]. Papers are usually directed and shared as PDFs, with no way for others to rate, comment, or otherwise interact with the content.

Creating A Crypto-Based Preprint Server

One of the most interesting ideas within the “decentralized science” movement is the creation of a modern, crypto-based preprint server. ResearchHub, for example, is a DeSci project led by Brian Armstrong, the founder and CEO of Coinbase [8]. In November 2024, it announced the ResearchHub journal [9], an open-access journal with immediate preprint publication services and a 21-day peer review. In line with crypto ethos, ResearchHub is attempting to challenge the status quo of intermediaries in the realm of scientific publishing.

ResearchHub Preprint Server. Source [10]

In its preprint server, ResearchHub augments the PDF hosting of traditional preprint servers with a modern, Reddit-like discussion forum, allowing researchers to receive instant feedback and discussion. This brings transparency into the traditionally opaque peer review process and opens a research article to the wider community for scientific discourse. Perhaps one of the most interesting aspects of ResearchHub is its use of the ResearchCoin token to create a novel incentivization system. ResearchHub incentivizes publication, reviewing, and collaboration using RSC, and allows users to create grants, tip other users, and gain voting rights using their tokens [11]. Peer reviewers, for example, are awarded 1000 USD worth of ResearchCoin each month [12].

ResearchHub is a great case study for how token incentives can be used to reimagine the publication process. Accessibility is fundamentally a financial problem – and by offering financial incentives for open-source work, ResearchHub may be able to create a compliant, open-access alternative not only to paywall publications, but also existing open-access services such as shadow libraries and preprint servers.

Open Questions for Open Access

Nonetheless, ResearchHub and other open-access DeSci platforms remain in an experimental stage, and there remain several open questions that still need to be addressed, including but not limited to:

• Tokenomics Design: As mentioned previously, RSC tokens act as a core way to incentivize open science work on the platform, and can be used on the platform itself – in governance, research requests, and tips. But to what extent are recipients of RSC actually spending on-platform versus converting to fiat? Are these token incentives sustainable and effective in driving quality research? To what extent is on-platform research quality affected by market fluctuations? This question of tokenomics design is perhaps the core question at stake for ResearchCoin and other token-based preprint servers.

• Disciplinary Fragmentation: The scientific process today is highly specialized, and there is no monolithic process of publication. Even within a single discipline, such as biology or computer science, there are numerous subfields, each with their own publications, conventions, and timelines. Today, many DeSci projects tend to focus on a single discipline or research area. ResearchHub’s journal, for example, focuses only on biomedical topics and publications. This fragmentation potentially limits the scale and market for each individual project – after all, there are only so many professional endocrinologists in the world. As DeSci projects develop, one likely scenario is that they will develop a federated structure, similar to professional organizations such as IEEE (Institute of Electronics and Electrical Engineers), containing numerous subcommittees and different conference conventions for each subtopic.

• Quality Control: Another key question for an open-access journal and preprint platform such as ResearchHub is quality control. Compared to a traditional journal, a fully open-source platform may have a lower mean but higher variance in the quality of publication. For every outstanding paper published on these platforms that is blocked on traditional venues, there are perhaps thousands of other papers inferior in quality. Although identity and authorship verification, token rewards, and reputational scores may help, they still don’t fully address the question of quality control. The effectiveness of all these metrics are also limited by the expertise of the community, and could potentially even be compromised by those farming for reputational points and token allocations.

• Association of Prestige: In science, as in many places, scarcity creates prestige. Publications such as Nature are coveted precisely because there is a rigorous selection process and low acceptance rate – the opposite of an open-access process. Since prestige requires a continuous process of curation, open-access journals where all articles are accepted run the risk of being seen as inferior in quality and content to traditional venues. This sense of conventional prestige is perhaps the strongest moat for traditional processes for scientific publication, and makes it uniquely difficult for a decentralized platform to disrupt.

• Community Accessibility: Finally, there is the question of audience. Are these open-access platforms such as ResearchHub aimed at an audience of professional scientists, or that of a wider, science-curious audience? At the moment, there does not seem to be a clear answer on either side, as some features – such as article publication and peer reviewing – seem to be geared towards professionals, whereas others, such as question posting and commenting seem geared towards a wider audience. This question of audience is important due to the differing incentives and levels of understanding that professionals and hobbyists have. One interesting idea could be for these decentralized science platforms to act as places for scientific communication and “technical translation” – to transform dense, jargon-ridden research papers into easily understandable ideas.

2 - The Funding of Science

Decentralized Incubation of Science

Today, researchers can spend as much as half their time writing grant proposals for their work, and this vicious competition for funding can impact the quality of research work that they produce [13]. The current funding model leaves a gap for non-mainstream ideas, replication efforts, and early-stage applied research. One of the core missions of DeSci is to reform the funding process, and allow scientists to directly bootstrap their work from a decentralized community interested in their work.

One of the early pioneers in this space is Molecule Protocol, which provides biology researchers with a platform to create funding proposals for their research projects. For each project, Molecule will mint an IP NFT that represents the patentable research output. Ownership of this NFT is then fractionalized into “IP tokens” that are given to all of the participants that provided funding to the research project through “crowdsales” [14]. If the funding is successful and reaches its goal, the project then enters a negotiation phase, where the researcher, their research organization, and the funders will reach a licensing and revenue sharing agreement.

Molecule DAO Projects [15]

Molecule’s IP NFT infrastructure underlies many of the popular DeSci protocols today. VitaDAO, for example, is a DeSci project focusing on accelerating research in the longevity space to provide tangible, usable research. Similarly, HairDAO is a DeSci organization aimed at creating hair loss solutions, while CerebrumDAO seeks to tackle Alzheimers and advance brain health.

Recently, Molecule has also introduced pump.science, a DeSci funding platform on Solana inspired by memecoin launch platforms such as pump.fun. On pump.science, anyone can submit experiments with drug regimens for C. elegans worms, trying to create a regimen that will extend the lifespan of the worm [16]. Users can try to predict the success or failure of the various regimens, and the token liquidity can be used to fund the ongoing research. The data from the research will then be streamed back to users, who will have a stake in the success of the project.

The core observation in pump.science is that memecoins can be more than just for capturing the social media zeitgeist – they can be used to bootstrap attention for socially productive ideas such as scientific experiments. In December of 2024, Siqi Chen, the founder of Runway, shared on X (fka. Twitter) his daughter Mira’s battle with a rare brain tumour. This prompted an X user to launch a memecoin named MIRA with half the supply dedicated to Siqi [17]. The token eventually allowed Siqi to donate over a million dollars towards a research study for his daughter’s rare brain cancer at the Hankinson Lab at the University of Colorado – showcasing the potential for memecoins to direct attention and capital to good causes [17].

Another prominent project working on this funding and bootstrapping aspect of decentralized science is BIO protocol. Building off of the success of Molecule and early DeSci DAOs such as VitaDAO, BIO protocol is a “financial layer” for DeSci, aiming to incubate a new generation of BioDAOs that provide researchers with community-sourced funding and resources to conduct pharmaceutical research and pharma products [16]. Some of the the latest projects in BIO protocol’s cohort include Long Covid Labs, aiming to provide a cure for long COVID patients, Curetopia, creating a space to unite families suffering from rare diseases, and Quantum Biology DAO, aiming to build a quantum biology microscope [18].

Evaluating Science DAOs and Community Ownership of Science

Interestingly, many DeSci projects today take shape in the format of a DAO, emphasizing the communal ownership of science and IPs. Aside from the historical reason that many early experiments in the DeSci space took shape as DAOs or DAO-launching platforms, there may be several reasons behind this. Firstly, launching a DAO token allows for a simple, straightforward way of crowdsourcing funding via a publicly tradable token. Secondly, this token creates a community of engaged stakeholders within a project that a researcher can communicate their findings with.

However, DAOs as an organizational form have faced many unique challenges in their development. One of the most prevalent is the question of community engagement and voter apathy – a problem systemic to the vast majority of DAOs. Even in popular DeSci DAOs, such as VitaDAO, voting quorum for any given proposal is around 10% of the total supply, and there are sometimes less than 10 votes for a proposal [18]. In VitaDAO’s recent VDP-157, for example, which introduces the concept of pump.science, the vote, which has only around 2M votes, is dominated by a single voter with 1.2M VITA tokens [19]. This poses centralization risks to the voting process.

Furthermore, unlike some of the largest protocol DAOs today, such as Uniswap, Arbitrum, or Optimism, the governance of VitaDAO and other BioDAOs occur entirely offchain, relying on Snapshot as a centralized service provider. Moreover, unlike protocol DAOs that use smart contracts to manage a “tangible” on-chain treasury, it is not immediately clear how precisely a decentralized organization would govern an “intangible” asset of an IP NFT. Compared to their centralized counterparts, decentralized governance could add a lot more latency and coordination problems to the research process, not to mention potential regulatory hurdles within the space.

Perhaps one of the core issues that decentralized funding and governance bring to this process of scientific research is the question of audience. Although the token-buying stakeholders may be interested in a project, they may not necessarily be fully aware of the research norms, context, and specialized knowledge of academic research. This would push researchers to have to do much more technical communication and “translate” their research to a generalist audience, a burden that may slow down frontier research efforts.

Moreover, for projects like pump.science that have adopted a memecoin launchpad model, it is unclear if the short attention cycles and reflexive market behaviour of memecoins would be able to uphold a multi-year, or oftentimes multi-decade process of biomedical research. Crypto and academic science simply operate on two different timescales. The average time to market for a new drug is 10-15 years, which is about as long as the entire history of blockchains [20]. If these protocols seek to return tangible products back to their stakeholders, they will likely only be able to tackle products in the late phases research productionization, rather than contribute to the cutting edge discovery process that many DeSci evangelists envision.

Finally, deploying new funding into science does not address the complex issues funders face to meaningfully define success. Researchers and funders have become dependent on publication and citation counts as metrics, but this incentive system has contributed to a reproducibility crisis, undermining public trust and impeding genuine progress [21]. Merely diversifying the sources of funding fails to address the underlying inefficiencies inherent in current research institutions.

3 - The Productionization of Science

From DeSci to DePIN: Productionizing Research IP

As mentioned above, one of the core problems for DeSci is the timescale mismatch between crypto attention span and the time it takes to develop a wholly new scientific project. This means that as opposed to helping scientists do groundbreaking foundational research, perhaps DeSci’s edge and primary use case will be in the productionization of science – turning proven research into a specific consumer product. In this way, DeSci’s future can be seen as a domain-specific extension of DePIN – combining physical consumer products with tokenomics design to incentivize user behavior and aid researchers with data collection.

Many of the major existing DeSci projects seem to recognize this “productionization” angle. Molecule’s Catalyze platform, for example, emphasizes that it is for “translational research” that will directly result in an IP that can be productionized, rather than for fundamental research [22]. Moreover, it has several restrictions on project size, asking scientists to raise each round of funding with <$50k of funding and taking less than 12 months to complete [22]. Compared to traditional science, DeSci’s capacity for permissionless contributions is particularly well-suited to product translation. Motivated patients and users can act as citizen scientists, giving a project instant access to real-world feedback and expertise.

Introduction of Lushair device [23]

So what might these “productionization” projects for DeSci actually look like? Recently, HairDAO has also partnered with Genpulse to create Lushair, the world’s first at-home AI-powered scalp analysis solution that provides data analysis on metrics including hair density, follicle activity, and oil state [23] [24]. Lushair, as a physical product, may provide us with some hints of what “productionized research” may look like in the future via DeSci:

• Crowdsourced funding from a widespread, known consumer pain point

• Productionization of patents and analysis from existing, well-established scientific literature

• Creation of physical products, such as detector devices, designed for everyday consumer use

• Using DePIN-like tokenomics structures to crowdsource consumer data and provide real-world data for further medical literature

As DeSci DAOs continue to develop these consumer-grade physical devices for their members, we can see a path for a business model for DeSci that looks similar to existing decentralized physical infrastructure networks (DePIN) such as Helium and Hivemapper.

Crypto as a Distribution Channel for Evangelizing Research

Aside from the creation of physical consumer products such as Lushair, one of decentralized science’s most promising aspects is the ability to allow existing but niche areas of research to be popularized into the mainstream. As we’ve mentioned before, the token holders within these DeSci communities are more likely to be generalist users with interest in a specific scientific problem, rather than being academic scientists themselves. This may present an “audience problem” for some of the previously mentioned projects that try to create a platform intended for academic scientists.

Rather than trying to bootstrap an audience of academic researchers or converting a generalist audience into research scientists, perhaps DeSci DAOs should lean into the “technical communication” part of science and actively engage their audience with digestible summaries and takeaways from research that can be applicable to their daily lives. Thus, it is possible that DeSci DAOs will act as “research amplifiers,” with products and educational programs that popularize science for a generalist audience.

Recently, we’ve seen how platforms such as pump.science have been inspired by the rise of memecoins. The attention-grabbing economics of memecoins could be particularly interesting in creating educational channels and awareness campaigns for science projects. However, memecoins only represent a top-of-funnel attention; the core challenge for a DeSci DAO is to optimize for retention, and transform this top-of-funnel attention into long term holders and stakeholders of these research projects.

These education products can take place in many different ways. For example, these DeSci communities could create AI agents that are able to translate academic papers into attention-grabbing short videos, tweets, and other forms of media for a mass audience. We could also potentially see the development of “Masterclass-style” platforms that allow for the decentralized education of science. By developing these education-based products, DeSci projects can use a wider crypto community as a distribution channel and carve out another path to allow these communities to stay relevant, both within a crypto context as well as in the scientific community.

Disciplinary Limitations for DeSci: The Lifestyle Relevance Test

Throughout our discussion of DeSci, we’ve pretty much only focused on a single discipline – biology – that is not necessarily representative of research in other scientific disciplines. As we’ve suggested above, this may be because there are certain disciplinary limitations for DeSci. In other words, DeSci works far better for some scientific disciplines than for others.

But what characterizes these disciplines with DeSci potential? I believe that the most important litmus test for DeSci is the “lifestyle relevance” test – does the science being conducted actually affect my day-to-day lifestyle?

This litmus test, derived from the observation that most DeSci community members are an interested, informed public, explains why many of the DeSci projects we see today – from VitaDAO to HairDAO to CereberumDAO – focus on biology and medicine. The findings from these research projects could actually affect the day-to-day lifestyle of many consumers. Thus, in the productionization of existing research, DeSci organizations will likely prioritize projects that can create tangible products that create lifestyle changes for a mass consumer audience.

Conclusion

Throughout this article, we’ve examined three key aspects of science that the DeSci movement aims to tackle – the accessibility of science, the funding of science, and the productionization of science. While projects like ResearchHub and Molecule Protocol demonstrate promising innovations in open access publishing and research funding, many of these existing DeSci models face significant challenges around tokenomics, governance, and audience.

Because of the fundamental timescale mismatch between academic science and crypto, perhaps the future of DeSci will be in the productionization and distribution of research-proven solutions. Moreover, DeSci seems to be much more suitable for certain types of scientific problems – those that can affect behavioral and lifestyle changes – rather than covering all research in all disciplines. Thus, in the long term, DeSci’s future likely lies not in replacing the traditional scientific research process, but in complementing them by creating new funding vehicles, new publication channels, and new productionization venues that allow theoretical results to quickly translate into tangible consumer products. This perhaps is the ultimate goal of DeSci, translating abstract scientific advances into concrete, everyday products that can benefit humanity at large.

About the Author

Jay, or 0xFishylosopher, is a senior at Stanford pursuing a double major in Computer Science and Philosophy. He is President of the Stanford Blockchain Club and founder of the Stanford Blockchain Review. He researches designs for Decentralized Autonomous Organizations (DAOs) and blockchain governance with Stanford Law School faculty and as a Research Fellow for IC3. He also works on the investments team at Pantera Capital.

References

[1] https://en.wikipedia.org/wiki/Open_science

[2] https://home.web.cern.ch/science/computing/birth-web

[3] https://www.forbes.com/sites/johncumbers/2023/04/28/the-desci-movement-will-crypto-really-solve-sciences-biggest-problems/

[4] https://www.theguardian.com/science/2017/jun/27/profitable-business-scientific-publishing-bad-for-science

[5] https://www.vice.com/en/article/shadow-libraries-are-moving-their-pirated-books-to-the-dark-web-after-fed-crackdowns/

[6] https://seattlespectator.com/2022/11/16/z-library-shutdown-raises-questions-about-educational-accessibility/

[7] https://info.arxiv.org/about/index.html

[8] https://www.researchhub.com/team

[9] https://www.researchhub.com/researchhub-journal

[10] https://www.researchhub.com/paper/1299036/biomedical-publishing-past-historic-present-continuous-future-conditional

[11] https://docs.researchhub.com/welcome/what-is-researchhub

[12] https://docs.researchhub.com/researchcoin/rsc-tokenomics

[13] https://www.vox.com/2016/7/14/12016710/science-challeges-research-funding-peer-review-process#1

[14] https://docs.molecule.to/documentation/ip-tokens/what-is-a-crowdsale-of-ipts

[15]

https://www.molecule.xyz/

[16] https://www.molecule.xyz/blog/solana-foundation-awards-grant-to-molecule-for-building-solana-native-desci-funding-platform-pump-science

[17] https://www.coindesk.com/markets/2024/12/27/memecoin-degens-raise-millions-for-rare-cancer-research-after-a-father-s-plea

[18] https://www.bio.xyz/blog-posts/desci-2-0-how-bio-will-unleash-biotech-revolution

[19] VitaDAO VDP-157 Snapshot vote:

https://snapshot.box/#/s:vote.vitadao.eth/proposal/0x01fdb4f1a1fa5dfbca0cd3a046740e752f05c221ae01be543987ad639988aeec/votes

[20] https://pharmaoffer.com/blog/how-long-does-it-take-to-bring-new-medicines-to-the-market

[21] https://www.nature.com/articles/483531a

[22] https://docs.molecule.to/documentation/catalyst/submit-a-project

[23] https://x.com/GenpulseAI/status/1865976938663428461

[24] https://www.lushair.net/about

Stanford Blockchain Review
Volume 6, Article No. 10

✍🏻 Author: Billy Gao — Stanford Blockchain Club & Pantera Capital

⭐️ Technical Prerequisite: Intermediate

The rise of interconnected blockchains has unleashed a powerful new form of value extraction, the cross-chain MEV. Cross chain MEV refers to the profits that can be extracted by exploiting inefficiencies, price discrepancies, or transaction dynamics across multiple blockchain networks. With the rise of cross-chain bridges and multi-chain protocols, MEV has grown from a single-chain concept into a multi-chain opportunity that reshapes how liquidity and assets flow within DeFi. To grasp its full potential and implications, we must delve deeper into what cross-chain MEV is, how it works, and the challenges and opportunities it presents.

A glossary below provides definitions to assist in understanding this article! For our readers new to blockchain, please use it as a resource.

Understanding Cross-Chain MEV

At its simplest, cross-chain MEV builds on MEV as it was first understood in single-blockchain environments like Ethereum. Initially, MEV—short for Miner Extractable Value—described profits miners could earn by reordering, including, or excluding transactions within a block to maximize their gains. Over time, as validators replaced miners and the term evolved to Maximal Extractable Value, the scope expanded to include strategies such as front-running, back-running, and arbitrage.

Cross-chain MEV extends these opportunities to a multi-chain context. When interconnected blockchains facilitate the movement of assets and liquidity between them, they create inefficiencies, which would be price differences for the same asset on different chains, imbalanced liquidity pools, or gaps in transaction ordering. Cross-chain MEV capitalizes on these inefficiencies, allowing traders, liquidators, and arbitrageurs to profit by executing strategies that span multiple blockchains. As a simple example, if a token trades for $10 on Ethereum but $9.50 on Polygon, a trader can buy the token on Polygon, bridge it to Ethereum, and sell it there for a profit.

This interconnected nature of blockchains means that cross-chain MEV is no longer limited to isolated opportunities on a single network. It's about identifying and exploiting inefficiencies across a web of blockchains while managing the complexities of bridging delays, transaction fees, and security vulnerabilities.

The Role and Benefits of Cross-Chain MEV

Cross-chain MEV plays a crucial role in enhancing market efficiency, especially within the DeFi ecosystem. By capitalizing on price discrepancies and liquidity imbalances, arbitrageurs help align prices and redistribute liquidity across chains. For instance, without arbitrage, a token might remain overvalued on one chain and undervalued on another, creating fragmented markets. Cross-chain MEV resolves these inefficiencies, ensuring that prices converge and liquidity flows where it is needed most. This alignment benefits not only traders but also DeFi protocols and their users, as it fosters a more stable and predictable financial environment.

It is this exact competitive nature of cross-chain MEV that drives innovation in the blockchain space. Traders, developers, and protocol designers are constantly pushing the boundaries of technology to identify opportunities, optimize execution, and mitigate risks. For example, advanced algorithms, real-time analytics tools, and automated bots are being developed to detect and act on cross-chain MEV opportunities. Additionally, protocols are integrating MEV-aware features to enhance user experience and security. This continuous pursuit of efficiency and innovation benefits the broader blockchain ecosystem, as the tools and techniques developed for cross-chain MEV often have wider applications.

Certain forms of cross-chain MEV, such as liquidations, are vital for the stability of DeFi protocols. When a borrower's collateral falls below the required threshold on a lending platform, liquidators step in to repay the loan and claim the collateral. In a multi-chain context, liquidators may need to bridge assets from one chain to another to complete this process. By enabling these activities, cross-chain MEV helps prevent bad debt from accumulating and ensures that lending platforms remain solvent.

Key Challenges

Despite its potential, cross-chain MEV introduces numerous challenges. One of the most critical challenges in cross-chain MEV is transaction latency. Unlike single-chain operations that execute near-instantaneously, cross-chain transactions often require bridging mechanisms that introduce significant delays. These delays can span several minutes to hours, creating substantial risks in fast-moving markets. For instance, a trader identifying a price discrepancy between Ethereum and Polygon might initiate an arbitrage strategy using a cross-chain bridge. However, by the time the transaction is finalized, market conditions may shift, erasing the profit margin or even resulting in a loss. This unpredictability makes cross-chain MEV inherently risky and often inaccessible to those without precise timing tools and real-time data. Moreover, high latency discourages smaller participants from engaging in cross-chain MEV, as they lack the resources to mitigate timing risks effectively. Larger players with access to private bridging solutions or faster infrastructure gain a disproportionate advantage, exacerbating centralization risks.

Another significant issue is the lack of atomicity in cross-chain operations. Atomicity ensures that a transaction either executes completely or fails entirely. In cross-chain MEV, this is crucial for preventing partial execution, where one leg of a transaction completes, but another fails. For example, a trader might buy an asset on one blockchain but be unable to sell it on another due to delays or errors in the bridging process. This creates stranded transactions where assets are locked in a bridge or on a destination chain, resulting in financial losses. The inherent differences in block times, consensus mechanisms, and transaction ordering rules between blockchains make achieving atomicity challenging. While atomic swaps provide some solutions, their scope is limited, and implementing them across heterogeneous blockchain networks remains complex.

Security vulnerabilities also plague cross-chain MEV, particularly due to the reliance on cross-chain bridges. These bridges, which enable interoperability between blockchains, are often the weakest link in the ecosystem and frequent targets for hackers. Bridge exploits have led to billions of dollars in losses, shaking trust in cross-chain operations. In 2022, bridge exploits accounted for approximately 69% of all cryptocurrencies stolen, amounting to nearly $2 billion across 13 separate incidents. Notable examples include the Ronin Bridge hack, where attackers stole $622 million, and the Wormhole Bridge exploit, resulting in a $320 million loss. The vulnerabilities arise from several factors, including smart contract bugs, centralized control, and consensus conflicts between connected blockchains. For example, poorly coded bridge contracts can be exploited to drain funds, while bridges controlled by a small group of validators create single points of failure. Differences in consensus mechanisms can also introduce inconsistencies that attackers can exploit. These vulnerabilities deter participants from engaging in cross-chain MEV strategies reliant on bridges, limiting the potential of multi-chain operations.

The issue of centralization risks further complicates cross-chain MEV. Large trading firms, institutional investors, and specialized MEV extraction platforms dominate the space, leveraging their advanced tools, substantial capital, and sophisticated infrastructure to gain a competitive edge. This creates an uneven playing field, where smaller participants are unable to compete effectively. Centralized entities may exploit their position to influence transaction ordering, fee structures, or even bridge operations, undermining the fairness of the ecosystem. This concentration of power contradicts the decentralized ethos of blockchain technology and raises concerns about equity and accessibility. Addressing these risks is critical to ensuring that cross-chain MEV opportunities remain inclusive and do not lead to systemic imbalances.

Fragmented infrastructure across blockchain networks presents another hurdle. Each blockchain operates with its own protocols, consensus mechanisms, and fee structures, creating a fragmented environment that complicates cross-chain MEV strategies. Traders must navigate these differences to execute their strategies effectively, which adds complexity and increases the likelihood of errors. For instance, a trader attempting a multi-chain arbitrage strategy may encounter inconsistent fee structures, divergent block times, and protocol-specific rules. These challenges require significant time and resources to overcome, limiting the scalability of cross-chain MEV and reducing its accessibility to smaller participants.

Additionally, ethical and regulatory concerns are increasingly relevant in the context of cross-chain MEV. While certain forms of MEV, such as arbitrage, contribute to market efficiency, others—like front-running and sandwich attacks—are seen as exploitative and detrimental to fairness. From a regulatory perspective, some MEV activities may be viewed as akin to insider trading or market manipulation, particularly in jurisdictions with strict financial regulations. This uncertainty creates additional risks for participants, who must navigate a shifting legal landscape while engaging in cross-chain MEV. Ethically, the concentration of MEV opportunities among a few large players exacerbates inequities within the DeFi ecosystem, undermining the principles of inclusivity and fairness that underpin blockchain technology.

The accumulation of noise and errors adds yet another layer of complexity. In cross-chain MEV strategies, each bridging operation or transaction introduces potential rounding errors, slippage, or discrepancies in token valuations. Over time, these inaccuracies can accumulate, eroding profit margins and creating inconsistent outcomes. Mitigating these issues requires robust risk management frameworks and precise execution, which are challenging to implement in the fragmented and volatile multi-chain environment.

These challenges collectively underscore the complexity of cross-chain MEV and its impact on the broader DeFi ecosystem. Addressing these obstacles is essential to ensure that cross-chain MEV evolves into a force for innovation and efficiency, rather than a source of instability or inequality. To unlock the full potential of cross-chain MEV while addressing its challenges, the community has developed and continues to refine innovative solutions. These advancements focus on improving speed, security, and fairness, making cross-chain MEV more sustainable and accessible.

Emerging Solutions

Enhanced bridging mechanisms are a cornerstone of these solutions. Traditional bridges, often slow and prone to vulnerabilities, are being replaced with faster and more secure alternatives. For instance, developers are introducing bridging protocols that optimize block confirmations, enabling faster transaction finality. Some advanced bridges allow partial confirmations on the destination chain, expediting asset transfers without compromising security. Integration with Layer-2 solutions, such as rollups, further enhances these mechanisms. By batching transactions, rollups reduce fees and time-to-finality, making cross-chain MEV strategies more cost-effective. Additionally, dynamic fee structures on bridges adapt to network conditions, lowering costs during periods of low activity and making MEV opportunities more accessible to smaller participants.

Atomic transactions and advanced protocols are also pivotal. Hash Time-Locked Contracts (HTLCs) provide a widely adopted solution for enabling atomic swaps between blockchains. These contracts ensure that transactions execute fully or fail entirely, preventing scenarios where assets are stranded mid-operation. Cross-chain consensus protocols like Cosmos' Inter-Blockchain Communication (IBC) enable direct and secure communication between blockchains, allowing for atomic interactions and reducing the complexity of cross-chain operations. Emerging solutions focus on composable atomicity, enabling multiple atomic operations to execute simultaneously across chains. This innovation reduces risks and enhances the efficiency of complex multi-chain strategies.

To address the centralization risks associated with transaction sequencing, decentralized sequencers and fair order execution mechanisms are being explored. Decentralized sequencers distribute transaction ordering power among multiple participants, eliminating single points of control and reducing the risk of biased ordering. Some protocols implement auction systems for transaction ordering, allowing participants to bid for inclusion in blocks. This transparent and competitive process ensures fairness while preventing undue influence by centralized entities. Randomized sequencing introduces another layer of fairness by selecting transaction orders randomly, reducing the likelihood of manipulation.

MEV-resistant protocol designs further enhance the ecosystem's resilience. Encrypted mempools, for example, conceal transaction details until they are executed, preventing malicious actors from exploiting pending transactions. Threshold encryption delays the visibility of transaction data until specific conditions are met, thwarting exploitative practices like front-running. Fee-burning mechanisms, such as those introduced in Ethereum's EIP-1559, reduce the financial incentives for MEV extraction, aligning participant behavior with network health.

Interoperability standards play a critical role in reducing fragmentation across blockchains. Standardized bridge designs ensure consistent operation across networks, minimizing bugs and vulnerabilities. Unified messaging protocols, such as LayerZero and Polkadot's XCMP, enable seamless data and asset exchanges between blockchains, simplifying cross-chain MEV operations. Interoperable smart contracts automate trustless interactions between chains, improving efficiency and reducing manual intervention.

Finally, AI and machine learning are revolutionizing cross-chain MEV by enhancing decision-making and execution. AI algorithms analyze large datasets across multiple blockchains in real-time, identifying arbitrage opportunities or liquidation risks faster than human traders. Predictive modeling anticipates market conditions, such as price movements or network congestion, enabling traders to adapt proactively. Automated bots powered by AI execute complex strategies with precision, ensuring timely and accurate multi-chain operations.

These solutions collectively transform cross-chain MEV, addressing its challenges while unlocking new opportunities for traders, developers, and DeFi protocols. As these innovations mature, they pave the way for a more interconnected, efficient, and equitable blockchain ecosystem.

Conclusion

To conclude, cross-chain MEV represents a transformative force in the DeFi landscape, offering lucrative opportunities and driving technological innovation. However, it also presents significant challenges that must be addressed to ensure its potential is realized equitably. By integrating enhanced bridging mechanisms, atomic transaction protocols, decentralized sequencing, and MEV-resistant designs, the blockchain community can mitigate these challenges and create a more sustainable and inclusive ecosystem. As blockchain networks continue to interconnect, cross-chain MEV will remain a critical driver of efficiency and evolution, shaping the future of decentralized finance.

Glossary

Arbitrage: The practice of taking advantage of price differences for the same asset across different markets.

Atomicity: A property in computing and blockchain where a transaction either completes entirely or not at all, with no partial execution.

DeFi (Decentralized Finance): Financial services and products built on blockchain technology that operate without traditional intermediaries.

Front-running: The practice of entering into a transaction based on advance knowledge of pending transactions.

Layer-2: A secondary framework or protocol built on top of an existing blockchain that helps with scaling and transaction speeds.

Liquidity: The ease with which an asset can be converted to cash or traded without affecting its market price.

MEV (Maximal Extractable Value): The maximum value that can be extracted from block production in excess of the standard block reward and gas fees.

Mempool: A waiting area for transactions that have been broadcast to a blockchain network but not yet confirmed.

Rollups: A scaling solution that processes transactions outside the main blockchain while maintaining security through the main chain.

Sandwich Attack: A type of front-running where an attacker places one transaction before and one after a target transaction.

About The Author

Billy Gao (@__billygao) serves as the Head of Governance for the Stanford Blockchain Club, an analyst at Pantera Capital, and is a sophomore studying computer science. He has experience in the blockchain ventures industry, especially in Hong Kong, having worked with venture capital firms with a focus on DeFi.

.

On Election Day 2024, when most were fixated on the New York Times live election board, an undercurrent of digital activity preferred Polymarket—an emerging blockchain-native prediction market that had eclipsed $3.6 billion in bets solely on the election by the end of the night.1 The climax of Polymarket’s fame came at 11:43 p.m. ET, nearly six hours before the Associated Press called the election, when Polymarket’s odds for Trump had already reached 95%.2 You can’t really call this casual gambling for dads anymore. The staggering volume and its appearance on national and international headlines signaled a watershed moment in decentralized finance (DeFi) and crypto.

Yet this excitement is tampered by increasing regulatory scrutiny. The U.S. ban on Polymarket remains firm, and on November 14th, the FBI raided the home of Polymarket’s founder and CEO, Shayne Coplan.3 Against the controversy, urgent questions arise for observers, users, and investors alike: What are blockchain prediction markets? How does it work? Are Polymarket odds a genuine reflection of collective sentiment, or do they echo the biases of a niche demographic? And what is the long-term future of blockchain-native prediction?

Overview on Polymarket and Blockchain

First, let’s open Polymarket and take a look: https://polymarket.com/. A brief tour of the user interface reveals a design reminiscent of Twitter’s minimalist aesthetic. There is a scrollable feed of ongoing markets, each represented by a small profile image and a concise descriptive blurb. Tabbing between categories like “Sports,” “Politics,” or “Crypto” is intuitive, and a simple clickable sidebar displays implied probabilities, alongside “Yes” or “No” buy buttons with their dollar equivalents. Notably, there is no overt mention of crypto on the front page. I would argue that the platform’s clean, approachable look aims to encourage frequent visits to check up on continuous updates to odds and trading volumes. It almost tricks you into checking back every few hours because these numbers update constantly, making the entire experience feel less like a formal betting exchange and more like a casual, interactive social media.

The moment one attempts to place bets, however, Polymarket’s crypto infrastructure reveals itself. Instead of credit cards, users connect an Ethereum-compatible wallet, such as MetaMask. Since U.S. residents are barred from trading due to a 2022 agreement with the Commodity Futures Trading Commission, Americans must use a VPN.4 This necessity surfaces the uncomfortable regulatory gray zone of crypto. While the site’s interface feels welcoming, the underlying technical requirements and legal constraints remain obstacles for many potential users. Despite these hurdles, Polymarket’s unprecedented $3.6 billion in volume—much of it still held on the platform—and command of 84% of all money placed in election-related betting,5 speaks positively on the demand for decentralized prediction markets even under regulatory limitations.

To understand the broader significance of Polymarket, it is helpful to consider the evolution of internet infrastructure. As Chris Dixon’s Read Write Own explains, Web1 offered a read-only online environment, Web2 introduced read-write capabilities through centralized social media platforms, and Web3 envisions a decentralized read-write-own paradigm. In this future, digital content and financial transactions migrate from corporate servers to decentralized networks. Polymarket exemplifies this vision by shifting trust from intermediaries to cryptographic proofs and publicly verifiable smart contracts. If blockchain becomes the default infrastructure of the future internet following this vision, Polymarket’s billions in event-based wagers will be minimal compared to the future valuation of decentralized finance.

One of the clearest use cases for blockchain even early in the days of its existence is actually prediction markets. When blockchain emerged with Bitcoin in 2008, its transformative power lay behind three fundamental components: trust, decentralization, and ownership. Cryptographic verification obviates the need for intermediaries; decentralization distributes authority across a global network, mitigating risks of manipulation; and smart contracts automatically execute predefined rules without human intervention, ensuring that participants' funds are locked and released solely based on verified outcomes. This programmatic enforcement of rules, combined with on-chain asset ownership, grants participants control independent of central gatekeepers. These elements are the foundations of the broader Web3 vision—and just so happens to be exactly what a prediction platform would want to be built on. Polymarket, built upon these principles, offers participants secure deposits, transparent rules, and verifiable evidence of their holdings.

When bettors review an event on Polymarket, the platform first tells you the Rules explaining what exact outcome must occur for you to "win." Upon clicking "confirm," a smart contract is signed on the Polygon blockchain using a modified version of the Conditional Token Framework (CTF). Each purchased share—backed by USDC stablecoins—emerges as a verifiable ERC-1155 token redeemable if the user's prediction proves correct.6 Lastly, Polymarket's oracle system (UMA Optimistic Oracle) settles outcomes efficiently (read more here: 7). Thus, each trade, position, and resolution exists on a transparent, trust-minimized ledger.

Election Key Events

That’s enough about how it works. The Polymarket timeline of events surrounding the 2024 election provides a fascinating case study on prediction markets in action. Throughout the campaign, odds fluctuated as traders responded to news, polls, and even large, idiosyncratic bets from “whale” accounts:

Between August 8 – October 6, 2024:

Polymarket data shows Donald Trump vs Kamala Harris as essentially a coin flip, each candidate sitting within a 2% lead on any given day.

By October 24, 2024:

Trump’s odds climb to a significant lead. Researchers identify four accounts—Fredi9999, Theo4, PrincessCaro, and Michie—as belonging to a single French trader who has placed $28 million in total on Trump. When questioned, the Polymarket team stated that they don’t believe this to be market manipulation but rather a single high-stakes bettor operating on personal conviction.

On October 25, 2024:

The New York Times runs a story about the French trader, driving increased traffic to Polymarket’s election markets (see here: 8)

On October 30, 2024:

Trump’s odds peak at 67% on Polymarket, spurred by growing speculation and broader news coverage.

On November 3, 2024:

News reports poll shows Harris leading in Iowa, causing Trump’s odds to slip to 53%. Regulated betting sites like Kalshi report similar volatility.

On November 4, 2024 (Pre-Election Day):

Trump’s odds stand at 58%, Harris at 42%. Total betting volume hits $3.01 billion on Polymarket.

On November 5, 2024 (Election Day):

Trump’s odds close at 61%, Harris at 39%. Overall volume tops $3.4 billion on Polymarket. Bitcoin also rises by 4%, reflecting a surge in crypto sentiment tied to the election.

On November 6, 2024:

Polymarket settles its election market, and payouts are sent to those who bought Trump. Daily active users remain high as new participants rush in to make post-election bets on cabinet appointments and other upcoming political decisions.

On November 7–10, 2024:

Widespread discussions erupt on social media and mainstream outlets about Polymarket’s accuracy and potential demographic bias. Ongoing debates highlight the possibility of larger players influencing these markets, but also validate the platform’s speed in “calling” election outcomes ahead of most traditional channels.

Throughout December 2024:

Polymarket rolls out markets for Senate races and global sporting events, extending the model of decentralized prediction into a broader range of real-world outcomes. Bitcoin’s price hits new all-time highs (ATHs) every day, sustaining the post-election rally within crypto markets. Bitcoin hits $100K.

Bias Concerns

Critics wonder if Polymarket’s odds genuinely reflect collective sentiment, or if they merely reveal the biases of a niche demographic. Because of the Ethereum wallet plus VPN barrier to entry, the users of Polymarket are restricted to the subset of people who could overcome it, generally younger, crypto-savvy, and politically homogeneous. Initial inefficiencies definitely exist, either due to these demographic concentrations or whale traders, but research on prediction markets by Wolfers and Zitzewitz (2004) on profit-driven arbitrage argues that there only needs to be a handful of knowledgeable traders to correct biases like these. In theory, prediction markets are the best aggregators of diverse information—pulling info from its participants by incentivizing them financially to reveal their true beliefs. This aggregation process should, ideally, generate forecasts that approximate the “true” probabilities of events more accurately than any single expert could.9 Although Polymarket’s early user base is more on the homogeneous side, the financial incentives trump biases and will continue to beat concerns with the growth of crypto. And as the market size of crypto grows (on the optimistic side, having Bitcoin market size overtake gold) and network effects pull more people into the ecosystem, the deeper liquidity will also combat these skews.

Coplan also built Polymarket on the belief that a large enough group of uninformed traders can collectively provide more accurate predictions than any single expert. This builds on prior research about market efficiency—even if individual traders lack complete information, the aggregation of their behaviors will reveal meaningful probabilities.10 The platform's decentralized architecture adds another dimension to this dynamic. While blockchain technology ensures unprecedented transparency in betting patterns and market movements, it also enables holders of typically unavailable information to trade anonymously, leaking inaccessible information into the market without revealing their identity.

Hedging Use Cases and Future Applications

The platform's potential extends far beyond political betting into risk management tools. We can consider how companies might use prediction markets to hedge against geopolitical risks. Here is one example: semiconductor manufacturers and tech companies heavily dependent on Taiwan Semiconductor Manufacturing Company (TSMC) could use prediction markets to hedge against potential disruption risks. If a company expects to lose $50 million in revenue from supply chain disruptions in the event of increased Taiwan-China tensions, they could offset this by taking positions in prediction markets tied to regional stability indicators. This creates a natural hedge—if tensions escalate and disrupt chip supply, the prediction market positions would pay out, helping to offset business losses.

Cross-chain expansion and ongoing smart contract enhancements could further bolster Polymarket's user base and reliability. Integrating other blockchains (e.g., Arbitrum or zkSync) might help bypass Polygon's occasional congestion, while refined contract designs could introduce advanced risk management features like stop-loss orders or partial share selling. These technical improvements, combined with a more welcoming regulatory environment, stand to transform Polymarket from a niche crypto curiosity into a robust financial instrument that everyday investors would consider alongside their stocks, bonds, and ETFs.

Looking ahead, these markets could become integral to how organizations manage complex geopolitical and environmental uncertainties. The combination of transparent blockchain infrastructure, sophisticated market mechanisms, and real-world applications positions platforms like Polymarket to potentially reshape how we collectively predict and prepare for future events. If prediction markets can secure regulatory certainty while maintaining their decentralized benefits, they could evolve into sophisticated tools for both information aggregation and risk management. Success will require balancing technical innovation with regulatory compliance, and demographic diversity with market efficiency. As the Web3 space continues to evolve, prediction markets may serve as an important testing ground for broader applications of blockchain technology in financial markets.

The Harris-Trump election demonstrated Polymarket’s potential to outperform traditional forecasting methods. However, the FBI raid on Coplan's home afterwards pinpointed the gray regulatory environment the platform must navigate. For decentralized prediction markets to fulfill their promise of democratizing information aggregation and risk management, they must first resolve these fundamental tensions between innovation and oversight. Only then can they truly evolve into mainstream financial instruments that reshape how we collectively prepare our financial strategies with future events.

Huge thank you to Kole Lee and Shaun Maguire for thoughts and conversations that inspired me to research Polymarket and write this piece.