Nuffle: The Ethereum Finality-As-A-Service Layer

In retrospect, rollups have emerged as the definitive scaling solution for Ethereum and decentralized technology as a whole. Nine months after Ethereum's Dencun upgrade, which targeted rollup data availability scaling, transaction throughput has exceeded two hundred transactions per second—representing a five-fold increase year-to-date. The two leading rollups, Arbitrum and OP Mainnet, have achieved stage 1 decentralization—surpassing several prominent alternative Layer 1 networks in decentralization metrics—with additional rollups potentially targeting stage 2 decentralization in 2025. Zero-knowledge proof technology has progressed to enable verification of Ethereum-equivalent transactions at sub-cent costs, establishing a pathway for efficient verification of thousands of standard user transactions on the contemporary Ethereum blockchain. However, this advancement presents new challenges. Multiple teams are developing independent blockchains atop Ethereum, with limited interoperability between them. This limitation primarily stems from rollups' infrequent finalization, which impedes meaningful cross-chain communication. Furthermore, optimistic rollups, which currently host the majority of ecosystem activity and Total Value Locked (TVL), face inherent technical constraints that prevent direct communication outside shared bridges, creating a significant barrier to interoperability between major networks like Arbitrum and Base. The community has proposed various solutions, ranging from intent-based bridging and atomic swaps to comprehensive chain abstraction. Despite their differences, these solutions share a fundamental requirement: a reliable source of truth—a protocol enabling secure state verification between rollups that is both rapid and cost-effective. Among the prominent solutions, which typically rely on optimistic oracles (Across), specialized operator consensus (Stargate via LayerZero), or centralized sequencer trust (Polymer Hub), Nuffle Labs' Fast Finality Layer (NFFL) presents a compelling balance between efficiency, security, and Ethereum alignment. This article examines NFFL's innovative approach to enabling cross-rollup state verification through EigenLayer's restaking mechanism and NEAR DA, explores its architectural design and development roadmap, and analyzes potential applications and their implications for the ecosystem. A refresher on rollups To understand the challenges NFFL addresses, let's examine the fundamental architecture of rollups, their objectives, and their inherent limitations: A rollup is a blockchain that utilizes another independent blockchain for transaction ordering, data availability, and consensus, while executing transactions externally in a manner verifiable by the parent blockchain. While many definitions refer to the parent chain as Layer 1 (L1) and the rollup as Layer 2 (L2), some frameworks don't require L2s to use the L1 for data availability. For clarity, this paper focuses specifically on rollups rather than the broader L2 category. Of course, in our case, the parent L1 is the Ethereum blockchain. It’s responsible for sharing its consensus with the rollups (we’ll elaborate on this later). Let's analyze how rollups leverage Ethereum for their core functions: transaction ordering, data availability, and consensus. Transaction ordering Rollups incorporate an entity called a sequencer, responsible for managing transaction inclusion and ordering via the L1 network. The sequencer functions analogously to a block producer in traditional blockchains. Specifically, it accepts incoming transactions from users sequentially, aggregates them into batches (comparable to L1 blocks), and periodically publishes these batches to a designated smart contract on the L1. A smart contract on the L1 maintains an authoritative record of all published transactions and their ordering. Rollup nodes must monitor this contract to retrieve new blocks and transaction information. Once a batch is included in an L1 block and that block achieves finality through L1 consensus, the inclusion and ordering of all transactions within that batch are guaranteed by the L1's security properties. To some extent, the sequencer is a “starter” of the rollup—it helps the rollup actually accept new transactions in the network, facilitating moving the state forward. Some rollups implement decentralized sequencing—rotating set of specialized entities reducing the risk of downtime of an otherwise centralized sequencer—and based sequencing, which doesn’t use any sequencer as the source of trust before it publishes the batch to the L1. (Based sequencing allows anyone to be a sequencer, but their batches are only used by the nodes when published to the L1. This opens virtually no risk of sequencing downtime at the cost of slower transaction inclusion (best-case scenario is L1’s 12 seconds per block).) However, the sequencers do not decide on the new state of things in the rollup, even after execution of their own batches. Hence, sequencers “start” but not necessarily “run” the rollup, as their actions cannot directly lead to the malicious state transition. Data availability However, information about ordering of some transactions is not sufficient for the rollup’s nodes, as they don’t possess the transactions themselves. In order to execute these transactions and determine their outcome in the rollup’s blockchain, the nodes must have full and unrestricted access to all transactions in the batch. Consequently, rollup sequencers must publish comprehensive transaction data to the L1 in a manner that allows the rollup's smart contract to verify data availability. Once transaction data for a batch is included and finalized on the L1, its availability is guaranteed for all participating nodes. Before Dencun upgrade, Ethereum rollups were posting transaction data in the input data (calldata) of sequencing calls on the L1. Therefore, all transactions must have been posted to the L1's blockchain forever. This might sound reasonable , as we want all nodes, including future ones, to be able to reconstruct the state of the rollup. However, this is very inefficient , as the Ethereum L1 cannot store large data on its ledger, whereas rollups, the high-speedlanes of Ethereum, are very data-intensive. Instead, we can make the rollup's smart contract verify validity of the sequenced transactions, so that he nodes instantly follow the state in the contract, rather than reconstructing it from all transactions starting from genesis. Blobs Ethereum’s Dencun upgrade last March had introduced “blobs”—temporary cells of data that are stored outside the blockchain and pruned (deleted by the network’s validators) after ~18 days. As rollup bridges make it possible to reconstruct the state without re-executing transactions, this property became very useful for rollups, which migrated from calldata to blobs shortly after the upgrade. Speaking numbers, before Dencun, rollups’ total TPS was around 50. Today, it’s over 200, with theoretical limits at 400-800 TPS depending on the rollup. Beyond capacity improvements, blobs eliminated the requirement to pay EVM gas costs for transaction data storage, establishing a separate channel with specialized temporary storage and independent fee pricing. This architectural change has dramatically reduced transaction costs in rollups, with fees dropping from 10-40 cents per transaction to sub-cent levels in networks like Base. Enshrined bridge (consensus) For simplicity, we’ve just flipped the definition of the rollup upside down—usually, all explanations start with a two-way bridge between the rollup and its L1. It’s fairly common among rollups to use the L1’s native currency as its own, to simplify estimating gas fees based on expenses of sequencers and proposers. Moreover, many rollups want to get popular tokens in their ecosystem from day 1, for which bridging them from their L1 is the best choice. Implementing a bridge smart contract from L1 to the rollup is quite straightforward—rollup nodes already listen to all things happening in its contract, thus we can implement an L1 deposit function that all nodes will interpret as a command for issuing the respective “wrapped” token on the rollup itself. However, trustless withdrawals require the bridge contract to validate all rollup transactions and determine their legitimate outcomes. This enables the bridge to process valid withdrawal requests by releasing funds to authorized initiators on the L1. This validation mechanism makes the bridge the definitive source of the rollup's canonical state—nodes align with the bridge's state transition regardless of alternative chain forks. Unlike traditional blockchains, rollups do not implement independent consensus rules for chain selection. The bridge contract on the L1 is what defines the canonical chain. Rollup settlement While sequencers manage transaction ordering and publication, they represent only one component of rollup architecture. Rollups also incorporate entities called "proposers" responsible for convincing the L1 bridge of specific state outputs resulting from newly sequenced batches. In essence, while sequencers establish transaction occurrence and ordering, proposers demonstrate the outcomes of these transactions according to the rollup's processing logic, such as its virtual machine. The proposer's role varies significantly based on the rollup's state validation approach. Two fundamentally different methodologies exist, defining two categories of rollups: Optimistic and Zero-Knowledge (ZK). Optimistic rollups In optimistic rollups, proposers regularly submit state updates to the L1 bridge, typically alongside or shortly after the sequencer's batch publications. These state updates include the new state root (a cryptographic commitment to the rollup's entire new state) after executing all transactions in the latest batches. To prevent invalid state updates, the bridge implements a challenge period (typically 7 days) during which specialized actors called "challengers" can dispute the proposal by submitting a fraud proof. This proof demonstrates that transactions were executed incorrectly by re-executing the disputed transaction on the L1 and comparing results. If a challenger successfully proves that a proposer submitted an invalid state transition, the state output is reverted and the challenger is rewarded (often from a bond that proposers must post). This creates an economic game where proposers are incentivized to submit only valid state transitions. Zero-knowledge rollups In ZK rollups, proposers generate mathematical proofs (called "validity proofs" or, more technically correct, "ZK proofs") that demonstrate the correctness of every state transition. These proofs show that all transactions in a batch were executed according to the rollup's rules without revealing the specific details of their execution. The L1 bridge can quickly verify these proofs using efficient cryptographic operations, for about the cost of a token swap. Once a proof is verified, the bridge accepts the state update as settled. This means proposers must do significant computational work before submitting state updates, but those updates are settled much faster compared to optimistic rollups. Settlement, finality, and interoperability Settlement time through canonical bridges varies significantly between rollup types—from 7 days for optimistic rollups due to their challenge period, to several hours for ZK rollups due to proof generation overhead and batch publishing costs. While this model works well for securing high-value transactions that can tolerate delays, it creates significant friction for the broader DeFi ecosystem. Consider how this impacts real-world usage: a user who wants to use their Arbitrum-based collateral to take out a loan on Base must first bridge their assets and wait up to 7 days before they can be used. A trader spotting an arbitrage opportunity between Uniswap pools on different rollups would see the opportunity disappear long before they could execute on it. A gaming application wanting to let players trade items across different rollup deployments would face unacceptable UX with such long delays. The crucial insight here is that rollup nodes can actually observe state changes much faster—typically within seconds of L1 block confirmation. While this state hasn't gone through full settlement in the canonical bridge, it's based on transaction data that's already been ordered and finalized on Ethereum. Many centralized exchanges already leverage this property, crediting user deposits from rollups after just a few block confirmations by running their own nodes and verifying transaction finality on L1. This creates an interesting dichotomy in the rollup ecosystem. While rollups have successfully scaled Ethereum's transaction throughput, they've introduced severe state and liquidity fragmentation. Each rollup effectively operates as an independent blockchain that cannot efficiently verify the state of other rollups without waiting for bridge settlement, despite all of them deriving their security from the same underlying chain—Ethereum. What are the existing solutions to liquidity and state fragmentation? The ecosystem has developed various approaches to overcome these limitations, from centralized bridges to specialized off-chain networks. These solutions typically make different trade-offs between three key properties: Security - How strong are the guarantees that state verification is correct Speed - How quickly state can be verified across chains Cost - How expensive it is to maintain and use the solution Most existing solutions optimize for speed and cost at the expense of security - often relying on trusted operators, multisigs, or optimistic mechanisms with minimal economic backing. This has led to several high-profile bridge hacks, most notably the $625M Ronin bridge exploit, highlighting the risks of sacrificing security for convenience. The fundamental challenge is establishing a secure "source of truth" about rollup states that can: Verify state changes within seconds or minutes rather than hours or days Provide strong cryptoeconomic security guarantees Operate cost-effectively for both infrastructure providers and users Integrate seamlessly with existing rollup architectures This opportunity to enable secure fast state verification between rollups has sparked significant innovation. Various teams are approaching the problem from different angles, looking to create infrastructure that can power the next generation of cross-chain applications without compromising on security. In the following sections, we'll explore how NFFL approaches this challenge through its novel combination of EigenLayer's restaking and NEAR DA, creating a fast finality layer that strikes a careful balance between security, speed and cost effectiveness. Understanding Nuffle Fast Finality Layer (NFFL) The Nuffle Fast Finality Layer (NFFL) represents a novel approach to enabling secure cross-chain interactions by providing fast state verification between rollups. Rather than forcing developers to choose between security and speed, NFFL leverages EigenLayer's restaked ETH to create a cryptoeconomically secured fast finality layer that can attest to rollup states within seconds. At its core, NFFL operates as an Actively Validated Service (AVS) running on EigenLayer. A decentralized network of operators, each running full nodes for participating rollups, verifies and attests to state updates. These attestations are backed by the operators' restaked ETH, creating strong economic incentives for honest behavior. By combining this with NEAR's Data Availability layer for efficient block data storage, NFFL enables applications to securely verify cross-chain state in 2-3 seconds - orders of magnitude faster than canonical bridge settlement. What makes NFFL particularly compelling is its pragmatic design approach. Rather than trying to replace or compete with Ethereum's security model, it provides a complementary layer optimized for use cases that require faster finality. Applications can choose whether to rely on NFFL's cryptoeconomic security or wait for full L1 settlement based on their specific needs. This flexibility allows NFFL to improve the user experience for many cross-chain interactions while maintaining strong security guarantees. The system introduces three key innovations: A decentralized operator network that achieves consensus on rollup states by comparing locally executed state transitions against block data posted to NEAR DA A checkpoint-based task system that enables efficient aggregation and verification of operator attestations while maintaining accountability through EigenLayer's slashing mechanisms A data storage mechanism using NEAR DA allowing for easy retrieval of attested rollup data across all rollups This design allows NFFL to strike a careful balance between security, speed, and cost-effectiveness - three properties that have traditionally been at odds in cross-chain infrastructure. By providing fast yet secure state verification, NFFL opens up new possibilities for cross-chain applications ranging from lending protocols to liquidity aggregators. In the following sections, we'll explore NFFL's architecture in detail, examining how its various components work together to enable this new primitive for cross-chain interaction. We'll also analyze its security model, discuss potential applications, and look at the protocol's roadmap for future development. An overview of NFFL core components Operator Set At the heart of NFFL lies its operator network - a decentralized system that extends Ethereum's security to enable fast cross-rollup verification. Rather than creating yet another siloed network requiring its own security assumptions, NFFL is built as an Actively Validated Service (AVS) on EigenLayer, allowing it to tap directly into Ethereum's existing validator ecosystem. This architectural choice is fundamental to understanding NFFL's security model. The same validators who secure Ethereum's consensus can restake their ETH through EigenLayer to become NFFL operators. In doing so, they put their staked ETH at risk to back their attestations about rollup states. This creates a powerful security bridge between Ethereum's consensus and NFFL's fast finality layer. When a rollup publishes new block data to the L1, relayers forward it to NEAR DA. Operators retrieve the block data through both sources and make sure they are equivalent. We’ll explain further why publishing rollup data on NEAR DA is necessary to make applications utilizing NFFL more convenient for users and developers. After retrieving new rollup batches, the operators execute them in their rollup nodes. Given they all run the same node software, they’ll always appear with same, and correct, state output. This state output then gets signed by all operators. When the majority of operators agrees on a specific state, it’s accepted by the system and can be transmitted to registry contracts across all rollups. The economic security of such system has a very interesting property that stems from EigenLayer's slashing mechanics: In EigenLayer, Actively Validated Services can implement a verification mechanism that is capable of detecting invalid attestations from operators, and slash (liquidate) their deposit afterwards. As NFFL somewhat “preliminary settles” rollup state off-chain before it’s settled in the bridge, it’s possible to objectively detect fraud by waiting for settlement delay and notifying the AVS contract about output inconsistency in the attestation and the bridge. This economically disincentivizes fraudulent attestations, as they can be detected and slashed by any entity watching the L1 and NFFL’s state, even without them running rollup nodes. In other words, NFFL “insures” the network's claims —operators are putting significant capital at risk to back their claims about rollup states. What makes this particularly powerful is how it aligns incentives across the system. Operators earn fees for honest participation while risking significant losses for dishonesty. The more ETH restaked into NFFL, the stronger these incentives become. And because this security is derived from Ethereum through EigenLayer, it partly benefits from the same robust economic security model that secures hundreds of billions in value on Ethereum itself. Messaging flow NFFL's messaging system represents an innovative approach to handling cross-chain state verification at scale. Instead of recording every state attestation on-chain, which would be prohibitively expensive, NFFL introduces a two-layer system of Messages and Tasks that enables efficient off-chain operation while maintaining strong on-chain security guarantees on demand. Messages are the basic unit of communication in NFFL. When operators verify a new state, they create and sign a Message attesting to that state. These Messages exist primarily off-chain, circulating between operators and the aggregator without incurring on-chain gas costs. There are two distinct types of Messages that flow through the system: State root update Messages contain an operator's attestation about a rollup's state at a specific block height. Each Message includes not only the state root itself but also a reference to the NEAR DA transaction containing the block data, creating a verifiable link between the attested state and its underlying data. Operator set update Messages track changes in NFFL's operator set. These Messages are crucial for the system's security as they enable rollup registry contracts to maintain an up-to-date record of valid operators, ensuring attestations are only accepted from authorized participants with stake at risk. While Messages enable efficient state verification, they alone aren't sufficient to ensure the system's economic security. This is where Tasks come in. Tasks are on-chain units of work that checkpoint the system's state at regular intervals. Rather than submitting every Message to Ethereum, operators periodically construct a Sparse Merkle Tree containing all Messages from a specific time period. The root of this tree is then submitted as a Task response, creating an efficient on-chain commitment to all off-chain attestations. This checkpoint system is particularly clever because it enables selective verification of any Message without requiring all Messages to be stored on-chain. Through Merkle proofs, anyone can verify that a specific Message was included in a checkpoint, enabling efficient challenge mechanisms while keeping baseline costs low. You can think of it as creating a "blockchain of attestations" where the checkpoints serve as block headers that commit to all Messages within a time period. The aggregator plays a crucial role in this system by collecting operator signatures and making them available through an API. When operators sign Messages, they send them to the aggregator which verifies the signatures have reached quorum (weighted by staked ETH) before exposing them for use by applications. This creates a clean interface for developers while maintaining the system's decentralized security properties. We’ll elaborate on aggregator service in the following section. Aggregator Service The aggregator acts as the coordination layer of NFFL, efficiently managing the flow of Messages between operators and applications. While conceptually straightforward, its design reflects careful consideration of both practical developer needs and decentralization principles. At its core, the aggregator solves the "tragedy of the commons" problem in signature aggregation. Without a dedicated service, each application using NFFL would need to independently collect and verify signatures from all operators—an inefficient and costly process. Instead, the aggregator provides a single point of collection for operator signatures, verifying quorum and exposing verified attestations through a simple API. The signature aggregation process works as follows: Operators independently sign Messages attesting to state updates These signatures are sent to the aggregator for collection The aggregator verifies signature validity and tracks quorum Once sufficient stake weight is reached, the aggregated signature becomes available Applications can fetch these attestations through the aggregator's API This design significantly reduces the complexity for developers integrating NFFL. Rather than managing complex cryptographic operations or tracking operator stakes, applications can simply request attestations for specific state updates through a clean API interface. The aggregator handles all the complexity of signature collection, verification, and BLS aggregation behind the scenes. Signature aggregation Let's explore BLS aggregation used by NFFL further. BLS signatures have a powerful mathematical property that allows multiple signatures to be combined into a single signature. Instead of verifying N individual signatures from operators, which would be computationally expensive and gas-intensive, applications can verify a single aggregated signature that proves collective agreement. The efficiency gains here are substantial. When NFFL operators sign a Message, they generate standard BLS signatures using their private keys. The aggregator can then combine these individual signatures into one compact signature that proves quorum agreement. The size and verification cost of this aggregated signature remains constant regardless of how many operators participated – a property that makes the system highly scalable. Moreover, the aggregated signature can be verified against the combined public keys of the signing operators, weighted by their staked amounts to ensure economic security is properly accounted for. The registry contract then only needs to perform one signature verification operation to confirm that sufficient stake weight has attested to the state update. Aggregator and checkpoints It’s important to note that, while the aggregator provides convenience, it doesn't compromise NFFL's security model. The signatures it collects are publicly verifiable, and its role is purely organizational rather than authoritative. Applications can always independently verify that aggregated signatures represent legitimate quorum from staked operators. The aggregator can neither forge signatures nor hide valid attestations—it simply makes them more accessible. The aggregator also plays a vital role in the checkpoint system. By collecting all Messages over time, it can construct the Sparse Merkle Trees used in checkpoint Tasks. This creates an efficient record of all attestations that have passed through the system, enabling later verification if needed for security challenges or auditing purposes. Registry contracts The Registry contract, deployed on each participating rollup, serves as the critical bridge between NFFL's off-chain attestations and on-chain state verification. These contracts enable applications to trustlessly verify the state of other rollups by validating NFFL's cryptoeconomically secured attestations. What makes the Registry particularly interesting is how it maintains the security properties of NFFL across different chains. Each Registry contract keeps a local copy of NFFL's operator set, tracking changes through operator set update attestations. This means that while the operator set is managed through EigenLayer on Ethereum, its state is reliably mirrored across all participating rollups, enabling them to independently verify attestations. When an application needs to verify another rollup's state – for instance, a lending protocol checking collateral on Arbitrum from Optimism – it submits the relevant attestation to its local Registry contract. This attestation includes the aggregated BLS signature we discussed earlier, along with the specific state root being attested to and its associated NEAR DA transaction reference. The verification process in the Registry is remarkably efficient thanks to BLS signature aggregation. The contract only needs to perform a single signature verification against the weighted public keys of the current operator set. If the signature is valid and represents sufficient stake weight, the Registry accepts the attested state as verified. This creates a trustless bridge between rollups that's both secure and cost-effective. The Registry creates a trust-minimized bridge between rollups that's both secure and cost-effective. Through verification of aggregated signatures against the operator set's weighted public keys, it can confirm that a state update has received sufficient attestation weight to be considered valid. This enables applications to reliably verify states across different rollups while inheriting NFFL's economic security guarantees. The Registry also plays a crucial role in NFFL's challenge system. If an attestation is later proven fraudulent through the challenge system, the Registry can invalidate it, protecting applications from relying on incorrect state. This creates multiple layers of security – immediate cryptoeconomic guarantees from staked ETH combined with longer-term fraud protection through challenges. Fault classification & security design in NFFL NFFL's security model centers around detecting and penalizing two primary types of operator misbehavior: Safety Faults and Liveness Faults. Safety Faults are violations that affect the integrity of the network by producing incorrect states or outcomes inconsistent with system rules. There are two key types of safety faults that operators can commit: Equivocation occurs when an operator signs multiple conflicting messages for the same event. For example, signing attestations for different state roots at the same block height, or attesting to multiple different timestamps for the same block. Such behavior undermines the network's ability to reach consensus on the canonical state. Invalid Attestation happens when an operator signs a provably incorrect statement. This could be attesting to an operator set update that doesn't match the on-chain state delta, or signing a state root that doesn't correspond to correct execution of the block's transactions. These faults can be objectively verified through on-chain data. While safety faults directly attack correctness, Liveness Faults affect the network's availability and efficiency. If operators consistently abstain from participating in message signing, it impacts both network availability and increases verification costs for users who need more signatures to reach quorum. The protocol tracks operator participation through checkpoint tasks to identify and penalize such behavior. The challenge process varies based on the type of fault and message being challenged: For checkpoint tasks, challengers can prove either message inclusion or exclusion faults. If a message with valid attestations from the checkpoint's time period was omitted, or an invalid/out-of-period message was included, the challenge succeeds. This is verified through merkle proofs against the checkpoint's message tree. Individual messages can be challenged after their checkpoint period by proving the message's content was invalid. For example: Operator set update messages can be invalidated by showing the claimed update ID or operator delta doesn't match on-chain state State root update messages can be challenged by demonstrating the claimed state root is inconsistent with correct transaction execution This multi-layered verification system allows the protocol to maintain both fast operation through off-chain messaging while preserving strong security guarantees through cryptoeconomic mechanisms. By making invalid behavior provably detectable and economically punishable through EigenLayer's slashing, NFFL creates strong incentives for honest operation while enabling efficient challenges when violations do occur. Real-world applications of NFFL By establishing a way for rapid and dust cheap cross-rollup state reads, NFFL opens a wide range of applications that were not feasible with the current technological stack of the ecosystem. Let’s explore some of the ideas, from something theoretical and simple to more complex and specific applications, useful in the most popular areas of today’s Ethereum ecosystem. Hello Protocol Let's start with a simple example, described in Nuffle Labs’ official documentation—a protocol that allows users to send "hello" messages between different rollups. While basic, this demonstrates the core mechanics of how applications can leverage NFFL for cross-chain communication. Consider a user wanting to send a message on Network #1 that will be read on Network #2. The process begins when they submit a transaction on Network #1 recording their "hello!" message in the network's state. At this point, the message exists only on Network #1 and would normally require waiting for the canonical bridge settlement (potentially hours or days) before it could be verified by other rollups. This is where NFFL comes in. When the block containing this message is produced, it gets posted to NEAR DA by the network's relayer. NFFL operators, running full nodes for both networks, verify this block data matches what their Network #1 node computed locally. Upon verification, they sign messages attesting to the new state root. These attestations flow through NFFL's aggregator service, which collects signatures until sufficient stake weight has attested to the state. Once quorum is reached, the aggregated signature becomes available through NFFL's API, typically within seconds of the original block production. Now comes the interesting part - consuming the message on Network #2. The Hello Protocol's contract on Network #2 can accept a transaction containing: The storage proof showing the message exists in Network #1's state The NFFL attestation proving this state is valid A reference to the NEAR DA transaction containing the block data The protocol routes this data to Network #2's Registry contract, which verifies the attestation's signature against its record of NFFL operators. If valid, this proves the message exists in Network #1's verified state, allowing the protocol to safely process it. What makes this powerful is its combination of speed and security. The entire flow from message submission to cross-chain verification can complete in seconds, rather than hours or days with canonical bridges. Yet the security comes from cryptoeconomic guarantees backed by restaked ETH through EigenLayer, rather than trusted operators or optimistic assumptions. While sending "hello" messages may seem trivial, this same pattern enables much more sophisticated cross-chain applications. The ability to quickly and trustlessly verify state across rollups creates building blocks for everything from cross-chain DeFi to chain-abstracted user experiences. Fast & cheap token bridging Building on these fundamentals, let's explore a more practical application: a token bridge leveraging NFFL for rapid cross-rollup transfers. The current bridge landscape forces difficult tradeoffs between speed, cost, and security. But NFFL can reshape these dynamics and enable an improved bridging experience for users. Today's leading bridges illustrate these tradeoffs clearly. Stargate, powered by LayerZero, achieves relatively low costs but takes 10-30 minutes to complete transfers due to its operator network needing to achieve and relay consensus across multiple chains. Across provides near-instant transfers but at 10-100x higher costs, primarily due to expensive UMA oracle outputs and slow (6-hour) rebalancing cycles that impact liquidity efficiency. NFFL introduces a new paradigm here. By leveraging EigenLayer's AVS framework rather than maintaining a separate operator network, NFFL can achieve consensus on rollup states within seconds. This consensus can be efficiently relayed through registry contracts across all participating rollups, enabling bridge designs that combine Stargate's cost efficiency with even faster finality than Across. Consider a user moving ETH from Arbitrum to Base. When tokens are locked in the bridge contract on Arbitrum, NFFL operators quickly verify and attest to this state change through their full nodes. Once the aggregator collects sufficient attestations, the bridge contract on Base can immediately verify the token lock through its Registry contract and release funds to the user. This speed and efficiency make many existing bridge optimizations less relevant. For instance, intent-based bridging systems are often proposed to work around slow finality - users submit intents to bridge tokens, and these intents are matched and executed by specialized actors. But with NFFL providing consensus nearly as fast as intent matching would take, bridges can instead use more efficient liquidity pool designs similar to Stargate, but without its speed limitations. The cost benefits here are substantial. Bridge operators don't need to maintain separate consensus infrastructure or pay for expensive oracle outputs. Users receive tokens on the destination chain in seconds while paying mainly for the basic gas costs of verification. Liquidity providers can manage positions more efficiently with faster rebalancing cycles. As an added benefit, the system maintains strong security through EigenLayer's slashing mechanisms. Any fraudulent attestations would result in operators losing their staked ETH, while bridges can still verify final settlement through canonical bridges as an additional safety layer. Multi-chain lending protocol Cross-chain lending represents perhaps the most compelling immediate application of NFFL. Current lending protocols face significant limitations due to chain fragmentation. Take Aave—despite being deployed across multiple rollups, each deployment operates in isolation (which creates several problems). Users wanting to use collateral across chains must bridge assets and wait, fragmenting liquidity and reducing capital efficiency. Moreover, some deployments on smaller rollups don’t even have enough liquidity for any meaningful lending, questioning Aave’s marketing position of simple lending for everyone at any size. “Just use Aave” might be better framed as “Just use Aave…but only on its largest deployments” in this case. NFFL enables a fundamentally different approach. Consider a lending protocol that maintains pools across multiple rollups but uses NFFL to share collateral state between them. A user could deposit USDC as collateral on Base, then immediately borrow USDT on Arbitrum against that same collateral—even though USDT isn't deployed on Base at all. The protocol's Arbitrum contract simply verifies the Base collateral position through NFFL attestations, with no bridging required. This creates powerful new possibilities for capital efficiency. Users can access the best rates across any supported rollup without moving assets. Liquidity providers can deploy capital where it's most needed without maintaining separate positions per chain. And because positions can be monitored in near real-time through NFFL attestations, protocols can offer better rates while maintaining security. The benefits extend beyond basic lending. Consider a leveraged trading protocol that allows users to open positions across multiple DEXs. A trader could deposit collateral on Arbitrum, then use it to open leveraged positions on both Arbitrum's and Base's DEXs simultaneously. The protocol can monitor all positions through NFFL attestations, enabling quick liquidations if needed while giving traders access to the best prices across the entire ecosystem. This model is dramatically simpler and more efficient than existing approaches. Rather than complex bridge mechanisms or centralized price feeds, protocols can directly verify positions through registry contracts. The fast finality from NFFL means they can operate with lower safety margins while maintaining security. And users get a seamless experience accessing liquidity across the entire ecosystem. Cross-chain DEX: Deploy once, use everywhere The current approach to scaling decentralized exchanges across rollups often leads to absurd inefficiencies. When protocols like Uniswap deploy to a new rollup, users initially face pools devoid of liquidity and missing critical trading pairs. Consider the recent Uniswap V3 deployment on ZKsync—despite significant excitement and flow of funds from a recent ZK airdrop, many pools remained unusable for days after launch due to insufficient liquidity. Meanwhile, the same protocol's deployments on Arbitrum, Base, and other established chains maintain deep liquidity, low fees, and efficient pricing for thousands of pairs. This fragmentation creates friction throughout the ecosystem. Liquidity providers must split their capital across chains, leading to worse pricing and higher slippage everywhere. Users need to bridge tokens and wait whenever they want to access better liquidity on another chain. Protocol teams must manage multiple deployments, each requiring separate maintenance and monitoring. You’ve guessed it right: NFFL enables a fundamentally different approach again. Let's explore this through two increasingly powerful patterns: Consider a new DEX deploying exclusively to Arbitrum, chosen for its established DeFi ecosystem and favorable gas costs. Rather than launching separate instances across chains, it maintains unified liquidity pools on Arbitrum while enabling trading access from any rollup. Here's how a user on Base might interact with it: Alice wants to swap 10,000 USDC for ETH on Base The DEX's Base interface queries Arbitrum pool state via NFFL attestations Alice sees she can get better pricing than Base's fragmented pools offer She approves the trade on Base The transaction executes on Arbitrum, with the result attested back to Base The benefits of this unified liquidity are substantial. Liquidity providers can concentrate their capital in one place, leading to better pricing and lower slippage. The protocol team only needs to manage one deployment, simplifying development and reducing operational costs. And users get consistent access to deep liquidity regardless of which rollup they're using. Such a protocol could utilize bridging pattern we’ve explored earlier to seamlessly manage swap flow. At the waiting time of just a few seconds, the actual fact of bridging can be fully abstracted away. This moves us excitingly close to the “chain abstraction” thesis that has recently become quite popular in the crypto community: if it doesn’t matter for the dapp what chain you’re on, why would you care what chain you and all these apps are on? A user can simply proceed to the app’s website, connect their wallet, and perform a wanted action. Done. But NFFL enables an even more powerful pattern - wrapping existing DeFi protocols for cross-chain access. Instead of building competing liquidity pools, developers can create "helper" protocols that make Arbitrum's massive Uniswap pools accessible from any rollup. For example, consider Bob who needs to swap a long-tail token pair on Base. Currently, his options are limited - either bridge to another chain and wait, or accept extreme slippage from Base's thin liquidity. With an NFFL-powered wrapper around Arbitrum's Uniswap deployment, Bob could: Query available liquidity across all Arbitrum Uniswap pools via NFFL attestations Find deep liquidity for his desired pair in an established Arbitrum pool Execute the trade from Base through the wrapper protocol Receive his tokens on Base once NFFL attests to the swap completion This pattern is transformative because it turns existing successful deployments into universal infrastructure. Instead of waiting months or years for liquidity to build on new rollups, protocols can instantly tap into established pools. This is dramatically more capital efficient and creates a better user experience. The possibilities extend far beyond simple swaps. With NFFL's real-time state verification, protocols could offer sophisticated features like cross-chain limit orders. A user could place a limit order on Base against Arbitrum's liquidity, with the wrapper protocol monitoring price movements through NFFL attestations and executing when conditions are met. This model could reshape how we think about protocol deployment across rollups. Rather than automatically deploying everywhere or joining the network effects of a specific chain, protocols could strategically choose their primary chain based on factors like: Gas costs for their specific operations Technological stack—virtual machine, AA, sequencing type, DA, etc. Regulatory considerations Then through NFFL, they can still serve users across the entire rollup ecosystem while maintaining simpler, more efficient operations. The implications for MEV are also interesting. With unified liquidity accessible across chains, MEV searchers would need to monitor and interact with fewer deployments. This could lead to more efficient price discovery and better execution for users across all rollups. As you may have already noticed, this pattern of single-chain deployment with multi-chain access through NFFL could extend well beyond DEXs. Any protocol that benefits from liquidity depth or network effects could adopt this model - lending protocols, options platforms, NFT marketplaces, and more. The key insight is that NFFL makes cross-chain access nearly as seamless as same-chain interaction, enabling protocols to optimize their deployment strategy without sacrificing accessibility. In other words, NFFL makes Ethereum an ecosystem again. Nuffle roadmap and future development While NFFL already enables powerful new cross-chain applications, the protocol continues to evolve. NFFL's development roadmap focuses on three key areas: Protocol Security Implementing comprehensive challenge and slashing mechanisms through EigenLayer Activating permissionless operator participation with robust stake management Enhancing cross-chain state verification with improved cryptographic primitives (BLS→ECDSA) Network Scalability Optimizing signature schemes and state propagation Improving checkpoint efficiency and verification costs Developer Experience Building SDK and tooling for easy integration Expanding support for different rollup types and VMs Creating documentation and examples for common use cases In the following sections, we’ll explore some of the most significant planned improvements in detail. BLS to ECDSA One of the most significant planned changes is the transition from BLS to ECDSA signatures. Currently, NFFL uses BLS signatures to enable efficient aggregation—multiple operator signatures can be combined into a single signature that proves quorum agreement. While this reduces verification costs, it creates challenges for operator set management across chains. The issue stems from how BLS signature verification works. When verifying an aggregated BLS signature, the verifier must use exactly the same set of public keys that created it. This means that when the operator set changes on Ethereum, all rollups must update to the exact same operator set before they can verify new attestations. Even a small mismatch in operator sets between chains can prevent signature verification and require to synchronize all messages of operator set changes. ECDSA signatures, while requiring more space and computation to verify, offer more flexibility. Individual operator signatures can be verified independently, allowing for smoother transitions when the operator set changes. Rollups can verify attestations as long as they recognize the signing operators, even if their view of the complete operator set temporarily differs from Ethereum's. This greater flexibility may be worth the minor increase in verification costs. Dynamic operator sets This signature change ties directly into another major protocol improvement—implementing dynamic operator sets. The current system uses a static, whitelisted set of operators. While this simplified initial development, it limits the protocol's decentralization and scalability. A dynamic operator system would allow new operators to join the network permissionlessly by staking through EigenLayer. This introduces several technical challenges that need to be carefully addressed: First, the protocol must manage operator entry and exit queues. When operators want to join or leave the network, these changes need to be coordinated across all participating chains. The queue system ensures smooth transitions without disrupting the network's ability to verify attestations. Second, the protocol needs mechanisms to track operator performance and stake weight. As operators join and leave, the system must maintain accurate records of each operator's stake and their rights to participate in consensus. This becomes more complex with a dynamic set compared to the current whitelisted approach. Finally, the protocol must handle operator set updates across chains efficiently. When the operator set changes on Ethereum, these updates need to propagate to all participating rollups through their registry contracts. The planned ECDSA transition will help here by making these updates more flexible. Taking off the training wheels Another critical area of development is the activation of permissionless challenge and slashing mechanisms. These mechanisms are essential for enforcing honest behavior and providing the economic security guarantees that NFFL relies on. The challenge system centers around the checkpoint task mechanism. When operators submit checkpoints containing merkleized Messages from a time period, anyone can challenge these checkpoints if they believe they contain invalid attestations. A successful challenge can arise from several types of faults: First, safety faults that directly affect network integrity. These include equivocation - where an operator signs multiple conflicting Messages for the same case, like attesting to different state roots for the same block. They also include invalid attestations, where an operator signs off on provably incorrect state transitions or operator set updates. Second, liveness faults that impact network availability. If operators consistently abstain from participating in message signing, this affects the network's ability to verify states efficiently. The challenge mechanism must balance penalizing such behavior while accounting for legitimate downtime. The protocol will implement a collateral-based challenge system. Challengers must lock collateral when submitting a challenge, which they forfeit if the challenge proves invalid. However, if they successfully prove an operator fault, they receive a reward from the slashed operator's stake. This creates economic incentives for monitoring operator behavior while preventing frivolous challenges. For state root updates, the challenge process is particularly interesting. After an operator attests to a rollup's state, this can be challenged by proving either that the relevant block data wasn't properly posted to NEAR DA, or that the attested state doesn't match the canonical state after settlement. This requires challengers to provide proofs through the Rainbow Bridge for NEAR DA verification, creating multiple layers of security. The slashing mechanism itself will be implemented through EigenLayer's middleware contracts. When challenges succeed, operators lose a portion of their staked ETH. The slashing parameters are designed so that potential losses significantly exceed any gains from malicious behavior. Some of this slashed stake is awarded to successful challengers, while the remainder might be distributed to honest operators or used for protocol development. These mechanisms create a comprehensive security framework. Operators face significant financial penalties for misbehavior, challengers are incentivized to monitor the network, and applications can rely on cryptoeconomic guarantees backed by restaked ETH. The challenge periods are much shorter than optimistic rollup fraud proofs, while still providing strong security through EigenLayer's slashing mechanics. The future of fast finality on Ethereum While NFFL provides an immediate solution for cross-rollup state verification, it's worth examining how the protocol fits into Ethereum's broader scaling roadmap. The key question many ask is: "Will NFFL still be relevant as rollup technology advances?" The answer becomes clear when we examine fundamental settlement limitations in different rollup designs. Optimistic rollups, despite their popularity and maturity, cannot fundamentally settle faster than their fraud proof window—typically 7 days. While solutions like Optimism's Superchain and Arbitrum Orbit enable faster communication between rollups sharing a bridge, they don't help with interoperability outside their specific ecosystems—for example, between those two. ZK rollups face different but equally important constraints. Even as ZK proof technology improves dramatically, there are practical limits to settlement speed. Even if we reach a point where proofs can be generated for every L1 block, Ethereum must still have capacity to verify multiple ZK proofs per block across different rollups. When this becomes possible, settlement will still be bound by L1 block time—at least 12 seconds under current parameters. NFFL offers a different approach by utilizing signed sequencer attestations from rollups. Instead of waiting for batches to be published on L1, NFFL operators can verify and attest to state changes as soon as they're produced by the sequencer. This enables cross-chain state verification in seconds while maintaining strong cryptoeconomic security through EigenLayer. Importantly, NFFL should not be viewed as competing with or threatening Ethereum's rollup security model. Rather, it provides a complementary tool that enables new possibilities within the modular Ethereum ecosystem. Applications can use NFFL for rapid state verification while still relying on canonical settlement through L1 when needed. This creates a richer toolkit for developers to build cross-chain applications with security models appropriate to their specific needs. Conclusion NFFL represents a novel approach to solving one of the most pressing challenges in Ethereum's modular ecosystem - enabling secure and efficient cross-rollup state verification. By leveraging EigenLayer's restaked ETH for economic security and NEAR DA for efficient data storage, NFFL creates a fast finality layer that can verify rollup states within seconds rather than hours or days. The protocol's thoughtful design choices reflect deep understanding of the challenges in cross-chain infrastructure. Rather than attempting to replace rollups' security model, NFFL provides a complementary layer optimized for specific use cases that require faster finality. The checkpoint-based task system enables efficient off-chain operation while maintaining strong on-chain security guarantees. And the registry contract architecture allows rollups to trustlessly verify states while inheriting NFFL's economic security. Perhaps most importantly, NFFL enables a new generation of cross-chain applications that were previously impractical. From unified lending protocols that share collateral across rollups to DEX wrappers that make established liquidity universally accessible, NFFL's fast state verification creates building blocks for true chain abstraction. This has profound implications for capital efficiency and user experience across the ecosystem. The protocol's roadmap demonstrates commitment to continuous improvement. Planned upgrades like the transition to ECDSA signatures and implementation of dynamic operator sets will enhance decentralization and scalability. The activation of comprehensive challenge and slashing mechanisms will strengthen security guarantees. And integration with additional DA solutions beyond NEAR will make NFFL even more universal. As Ethereum's rollup ecosystem continues to evolve, the need for secure cross-chain state verification will only grow. NFFL's approach of extending Ethereum's security through restaking while optimizing for speed and cost-effectiveness positions it well to serve this need. By enabling new forms of cross-chain interaction while maintaining strong security guarantees, NFFL contributes to making Ethereum's modular vision a reality. Author’s note: A version of this article was originally published here. In retrospect, rollups have emerged as the definitive scaling solution for Ethereum and decentralized technology as a whole. Nine months after Ethereum's Dencun upgrade, which targeted rollup data availability scaling, transaction throughput has exceeded two hundred transactions per second —representing a five-fold increase year-to-date. The two leading rollups, Arbitrum and OP Mainnet, have achieved stage 1 decentralization— surpassing several prominent alternative Layer 1 networks in decentralization metrics—with additional rollups potentially targeting stage 2 decentralization in 2025. Zero-knowledge proof technology has progressed to enable verification of Ethereum-equivalent transactions at sub-cent costs , establishing a pathway for efficient verification of thousands of standard user transactions on the contemporary Ethereum blockchain. two hundred transactions per second surpassing several prominent alternative Layer 1 networks verification of Ethereum-equivalent transactions at sub-cent costs However, this advancement presents new challenges. Multiple teams are developing independent blockchains atop Ethereum, with limited interoperability between them. This limitation primarily stems from rollups' infrequent finalization, which impedes meaningful cross-chain communication. Furthermore, optimistic rollups, which currently host the majority of ecosystem activity and Total Value Locked (TVL), face inherent technical constraints that prevent direct communication outside shared bridges, creating a significant barrier to interoperability between major networks like Arbitrum and Base. The community has proposed various solutions, ranging from intent-based bridging and atomic swaps to comprehensive chain abstraction. Despite their differences, these solutions share a fundamental requirement: a reliable source of truth—a protocol enabling secure state verification between rollups that is both rapid and cost-effective. Among the prominent solutions, which typically rely on optimistic oracles (Across), specialized operator consensus (Stargate via LayerZero), or centralized sequencer trust (Polymer Hub), Nuffle Labs' Fast Finality Layer (NFFL) presents a compelling balance between efficiency, security, and Ethereum alignment. This article examines NFFL's innovative approach to enabling cross-rollup state verification through EigenLayer's restaking mechanism and NEAR DA, explores its architectural design and development roadmap, and analyzes potential applications and their implications for the ecosystem. Fast Finality Layer (NFFL) A refresher on rollups To understand the challenges NFFL addresses, let's examine the fundamental architecture of rollups, their objectives, and their inherent limitations: A rollup is a blockchain that utilizes another independent blockchain for transaction ordering, data availability, and consensus, while executing transactions externally in a manner verifiable by the parent blockchain. While many definitions refer to the parent chain as Layer 1 (L1) and the rollup as Layer 2 (L2), some frameworks don't require L2s to use the L1 for data availability. For clarity, this paper focuses specifically on rollups rather than the broader L2 category. A rollup is a blockchain Of course, in our case, the parent L1 is the Ethereum blockchain. It’s responsible for sharing its consensus with the rollups (we’ll elaborate on this later). Let's analyze how rollups leverage Ethereum for their core functions: transaction ordering, data availability, and consensus. Transaction ordering Rollups incorporate an entity called a sequencer, responsible for managing transaction inclusion and ordering via the L1 network. The sequencer functions analogously to a block producer in traditional blockchains. Specifically, it accepts incoming transactions from users sequentially, aggregates them into batches (comparable to L1 blocks), and periodically publishes these batches to a designated smart contract on the L1. A smart contract on the L1 maintains an authoritative record of all published transactions and their ordering. Rollup nodes must monitor this contract to retrieve new blocks and transaction information. Once a batch is included in an L1 block and that block achieves finality through L1 consensus, the inclusion and ordering of all transactions within that batch are guaranteed by the L1's security properties. To some extent, the sequencer is a “starter” of the rollup—it helps the rollup actually accept new transactions in the network, facilitating moving the state forward. Some rollups implement decentralized sequencing—rotating set of specialized entities reducing the risk of downtime of an otherwise centralized sequencer—and based sequencing, which doesn’t use any sequencer as the source of trust before it publishes the batch to the L1. (Based sequencing allows anyone to be a sequencer, but their batches are only used by the nodes when published to the L1. This opens virtually no risk of sequencing downtime at the cost of slower transaction inclusion (best-case scenario is L1’s 12 seconds per block).) However, the sequencers do not decide on the new state of things in the rollup, even after execution of their own batches. Hence, sequencers “start” but not necessarily “run” the rollup, as their actions cannot directly lead to the malicious state transition. Data availability However, information about ordering of some transactions is not sufficient for the rollup’s nodes, as they don’t possess the transactions themselves. In order to execute these transactions and determine their outcome in the rollup’s blockchain, the nodes must have full and unrestricted access to all transactions in the batch. Consequently, rollup sequencers must publish comprehensive transaction data to the L1 in a manner that allows the rollup's smart contract to verify data availability . Once transaction data for a batch is included and finalized on the L1, its availability is guaranteed for all participating nodes. data availability Before Dencun upgrade, Ethereum rollups were posting transaction data in the input data (calldata) of sequencing calls on the L1. Therefore, all transactions must have been posted to the L1's blockchain forever. This might sound reasonable , as we want all nodes, including future ones, to be able to reconstruct the state of the rollup. However, this is very inefficient , as the Ethereum L1 cannot store large data on its ledger, whereas rollups, the high-speedlanes of Ethereum, are very data-intensive. Instead, we can make the rollup's smart contract verify validity of the sequenced transactions, so that he nodes instantly follow the state in the contract, rather than reconstructing it from all transactions starting from genesis. Blobs Ethereum’s Dencun upgrade last March had introduced “ blobs ”—temporary cells of data that are stored outside the blockchain and pruned (deleted by the network’s validators) after ~18 days. As rollup bridges make it possible to reconstruct the state without re-executing transactions, this property became very useful for rollups, which migrated from calldata to blobs shortly after the upgrade. Speaking numbers, before Dencun, rollups’ total TPS was around 50. Today, it’s over 200, with theoretical limits at 400-800 TPS depending on the rollup . blobs calldata 400-800 TPS depending on the rollup Beyond capacity improvements, blobs eliminated the requirement to pay EVM gas costs for transaction data storage, establishing a separate channel with specialized temporary storage and independent fee pricing. This architectural change has dramatically reduced transaction costs in rollups, with fees dropping from 10-40 cents per transaction to sub-cent levels in networks like Base. Enshrined bridge (consensus) For simplicity, we’ve just flipped the definition of the rollup upside down—usually, all explanations start with a two-way bridge between the rollup and its L1. It’s fairly common among rollups to use the L1’s native currency as its own, to simplify estimating gas fees based on expenses of sequencers and proposers . Moreover, many rollups want to get popular tokens in their ecosystem from day 1, for which bridging them from their L1 is the best choice. proposers Implementing a bridge smart contract from L1 to the rollup is quite straightforward—rollup nodes already listen to all things happening in its contract, thus we can implement an L1 deposit function that all nodes will interpret as a command for issuing the respective “wrapped” token on the rollup itself. bridge smart contract However, trustless withdrawals require the bridge contract to validate all rollup transactions and determine their legitimate outcomes. This enables the bridge to process valid withdrawal requests by releasing funds to authorized initiators on the L1. This validation mechanism makes the bridge the definitive source of the rollup's canonical state—nodes align with the bridge's state transition regardless of alternative chain forks. Unlike traditional blockchains, rollups do not implement independent consensus rules for chain selection. The bridge contract on the L1 is what defines the canonical chain. Rollup settlement While sequencers manage transaction ordering and publication, they represent only one component of rollup architecture. Rollups also incorporate entities called "proposers" responsible for convincing the L1 bridge of specific state outputs resulting from newly sequenced batches. In essence, while sequencers establish transaction occurrence and ordering, proposers demonstrate the outcomes of these transactions according to the rollup's processing logic, such as its virtual machine. The proposer's role varies significantly based on the rollup's state validation approach. Two fundamentally different methodologies exist, defining two categories of rollups: Optimistic and Zero-Knowledge (ZK). Optimistic Zero-Knowledge (ZK). Optimistic rollups In optimistic rollups, proposers regularly submit state updates to the L1 bridge, typically alongside or shortly after the sequencer's batch publications. These state updates include the new state root (a cryptographic commitment to the rollup's entire new state) after executing all transactions in the latest batches. To prevent invalid state updates, the bridge implements a challenge period (typically 7 days) during which specialized actors called "challengers" can dispute the proposal by submitting a fraud proof . This proof demonstrates that transactions were executed incorrectly by re-executing the disputed transaction on the L1 and comparing results. fraud proof If a challenger successfully proves that a proposer submitted an invalid state transition, the state output is reverted and the challenger is rewarded (often from a bond that proposers must post). This creates an economic game where proposers are incentivized to submit only valid state transitions. Zero-knowledge rollups In ZK rollups, proposers generate mathematical proofs (called "validity proofs" or, more technically correct, "ZK proofs") that demonstrate the correctness of every state transition. These proofs show that all transactions in a batch were executed according to the rollup's rules without revealing the specific details of their execution. The L1 bridge can quickly verify these proofs using efficient cryptographic operations, for about the cost of a token swap. Once a proof is verified, the bridge accepts the state update as settled. This means proposers must do significant computational work before submitting state updates, but those updates are settled much faster compared to optimistic rollups. Settlement, finality, and interoperability Settlement time through canonical bridges varies significantly between rollup types—from 7 days for optimistic rollups due to their challenge period, to several hours for ZK rollups due to proof generation overhead and batch publishing costs. While this model works well for securing high-value transactions that can tolerate delays, it creates significant friction for the broader DeFi ecosystem. Consider how this impacts real-world usage: a user who wants to use their Arbitrum-based collateral to take out a loan on Base must first bridge their assets and wait up to 7 days before they can be used. A trader spotting an arbitrage opportunity between Uniswap pools on different rollups would see the opportunity disappear long before they could execute on it. A gaming application wanting to let players trade items across different rollup deployments would face unacceptable UX with such long delays. The crucial insight here is that rollup nodes can actually observe state changes much faster—typically within seconds of L1 block confirmation. While this state hasn't gone through full settlement in the canonical bridge, it's based on transaction data that's already been ordered and finalized on Ethereum. Many centralized exchanges already leverage this property, crediting user deposits from rollups after just a few block confirmations by running their own nodes and verifying transaction finality on L1. This creates an interesting dichotomy in the rollup ecosystem. While rollups have successfully scaled Ethereum's transaction throughput, they've introduced severe state and liquidity fragmentation. Each rollup effectively operates as an independent blockchain that cannot efficiently verify the state of other rollups without waiting for bridge settlement, despite all of them deriving their security from the same underlying chain—Ethereum. What are the existing solutions to liquidity and state fragmentation? The ecosystem has developed various approaches to overcome these limitations, from centralized bridges to specialized off-chain networks. These solutions typically make different trade-offs between three key properties: Security - How strong are the guarantees that state verification is correct Speed - How quickly state can be verified across chains Cost - How expensive it is to maintain and use the solution Security - How strong are the guarantees that state verification is correct Security Speed - How quickly state can be verified across chains Speed Cost - How expensive it is to maintain and use the solution Cost Most existing solutions optimize for speed and cost at the expense of security - often relying on trusted operators, multisigs, or optimistic mechanisms with minimal economic backing. This has led to several high-profile bridge hacks, most notably the $625M Ronin bridge exploit, highlighting the risks of sacrificing security for convenience. The fundamental challenge is establishing a secure "source of truth" about rollup states that can: Verify state changes within seconds or minutes rather than hours or days Provide strong cryptoeconomic security guarantees Operate cost-effectively for both infrastructure providers and users Integrate seamlessly with existing rollup architectures Verify state changes within seconds or minutes rather than hours or days Provide strong cryptoeconomic security guarantees Operate cost-effectively for both infrastructure providers and users Integrate seamlessly with existing rollup architectures This opportunity to enable secure fast state verification between rollups has sparked significant innovation. Various teams are approaching the problem from different angles, looking to create infrastructure that can power the next generation of cross-chain applications without compromising on security. In the following sections, we'll explore how NFFL approaches this challenge through its novel combination of EigenLayer's restaking and NEAR DA, creating a fast finality layer that strikes a careful balance between security, speed and cost effectiveness. Understanding Nuffle Fast Finality Layer (NFFL) The Nuffle Fast Finality Layer (NFFL) represents a novel approach to enabling secure cross-chain interactions by providing fast state verification between rollups. Rather than forcing developers to choose between security and speed, NFFL leverages EigenLayer's restaked ETH to create a cryptoeconomically secured fast finality layer that can attest to rollup states within seconds. At its core, NFFL operates as an Actively Validated Service (AVS) running on EigenLayer. A decentralized network of operators, each running full nodes for participating rollups, verifies and attests to state updates. These attestations are backed by the operators' restaked ETH, creating strong economic incentives for honest behavior. By combining this with NEAR's Data Availability layer for efficient block data storage, NFFL enables applications to securely verify cross-chain state in 2-3 seconds - orders of magnitude faster than canonical bridge settlement. What makes NFFL particularly compelling is its pragmatic design approach. Rather than trying to replace or compete with Ethereum's security model, it provides a complementary layer optimized for use cases that require faster finality. Applications can choose whether to rely on NFFL's cryptoeconomic security or wait for full L1 settlement based on their specific needs. This flexibility allows NFFL to improve the user experience for many cross-chain interactions while maintaining strong security guarantees. The system introduces three key innovations: A decentralized operator network that achieves consensus on rollup states by comparing locally executed state transitions against block data posted to NEAR DA A checkpoint-based task system that enables efficient aggregation and verification of operator attestations while maintaining accountability through EigenLayer's slashing mechanisms A data storage mechanism using NEAR DA allowing for easy retrieval of attested rollup data across all rollups A decentralized operator network that achieves consensus on rollup states by comparing locally executed state transitions against block data posted to NEAR DA A checkpoint-based task system that enables efficient aggregation and verification of operator attestations while maintaining accountability through EigenLayer's slashing mechanisms A data storage mechanism using NEAR DA allowing for easy retrieval of attested rollup data across all rollups This design allows NFFL to strike a careful balance between security, speed, and cost-effectiveness - three properties that have traditionally been at odds in cross-chain infrastructure. By providing fast yet secure state verification, NFFL opens up new possibilities for cross-chain applications ranging from lending protocols to liquidity aggregators. In the following sections, we'll explore NFFL's architecture in detail, examining how its various components work together to enable this new primitive for cross-chain interaction. We'll also analyze its security model, discuss potential applications, and look at the protocol's roadmap for future development. An overview of NFFL core components Operator Set At the heart of NFFL lies its operator network - a decentralized system that extends Ethereum's security to enable fast cross-rollup verification. Rather than creating yet another siloed network requiring its own security assumptions, NFFL is built as an Actively Validated Service (AVS) on EigenLayer, allowing it to tap directly into Ethereum's existing validator ecosystem. This architectural choice is fundamental to understanding NFFL's security model. The same validators who secure Ethereum's consensus can restake their ETH through EigenLayer to become NFFL operators. In doing so, they put their staked ETH at risk to back their attestations about rollup states. This creates a powerful security bridge between Ethereum's consensus and NFFL's fast finality layer. When a rollup publishes new block data to the L1, relayers forward it to NEAR DA. Operators retrieve the block data through both sources and make sure they are equivalent. We’ll explain further why publishing rollup data on NEAR DA is necessary to make applications utilizing NFFL more convenient for users and developers. After retrieving new rollup batches, the operators execute them in their rollup nodes. Given they all run the same node software, they’ll always appear with same, and correct, state output. This state output then gets signed by all operators. When the majority of operators agrees on a specific state, it’s accepted by the system and can be transmitted to registry contracts across all rollups. The economic security of such system has a very interesting property that stems from EigenLayer's slashing mechanics: In EigenLayer, Actively Validated Services can implement a verification mechanism that is capable of detecting invalid attestations from operators, and slash (liquidate) their deposit afterwards. As NFFL somewhat “preliminary settles” rollup state off-chain before it’s settled in the bridge, it’s possible to objectively detect fraud by waiting for settlement delay and notifying the AVS contract about output inconsistency in the attestation and the bridge. This economically disincentivizes fraudulent attestations, as they can be detected and slashed by any entity watching the L1 and NFFL’s state, even without them running rollup nodes. In other words, NFFL “insures” the network's claims —operators are putting significant capital at risk to back their claims about rollup states. What makes this particularly powerful is how it aligns incentives across the system. Operators earn fees for honest participation while risking significant losses for dishonesty. The more ETH restaked into NFFL, the stronger these incentives become. And because this security is derived from Ethereum through EigenLayer, it partly benefits from the same robust economic security model that secures hundreds of billions in value on Ethereum itself. Messaging flow NFFL's messaging system represents an innovative approach to handling cross-chain state verification at scale. Instead of recording every state attestation on-chain, which would be prohibitively expensive, NFFL introduces a two-layer system of Messages and Tasks that enables efficient off-chain operation while maintaining strong on-chain security guarantees on demand. Messages are the basic unit of communication in NFFL. When operators verify a new state, they create and sign a Message attesting to that state. These Messages exist primarily off-chain, circulating between operators and the aggregator without incurring on-chain gas costs. There are two distinct types of Messages that flow through the system: State root update Messages contain an operator's attestation about a rollup's state at a specific block height. Each Message includes not only the state root itself but also a reference to the NEAR DA transaction containing the block data, creating a verifiable link between the attested state and its underlying data. Operator set update Messages track changes in NFFL's operator set. These Messages are crucial for the system's security as they enable rollup registry contracts to maintain an up-to-date record of valid operators, ensuring attestations are only accepted from authorized participants with stake at risk. State root update Messages contain an operator's attestation about a rollup's state at a specific block height. Each Message includes not only the state root itself but also a reference to the NEAR DA transaction containing the block data, creating a verifiable link between the attested state and its underlying data. State root update Messages contain an operator's attestation about a rollup's state at a specific block height. Each Message includes not only the state root itself but also a reference to the NEAR DA transaction containing the block data, creating a verifiable link between the attested state and its underlying data. Operator set update Messages track changes in NFFL's operator set. These Messages are crucial for the system's security as they enable rollup registry contracts to maintain an up-to-date record of valid operators, ensuring attestations are only accepted from authorized participants with stake at risk. Operator set update Messages track changes in NFFL's operator set. These Messages are crucial for the system's security as they enable rollup registry contracts to maintain an up-to-date record of valid operators, ensuring attestations are only accepted from authorized participants with stake at risk. While Messages enable efficient state verification, they alone aren't sufficient to ensure the system's economic security. This is where Tasks come in. Tasks are on-chain units of work that checkpoint the system's state at regular intervals. Rather than submitting every Message to Ethereum, operators periodically construct a Sparse Merkle Tree containing all Messages from a specific time period. The root of this tree is then submitted as a Task response, creating an efficient on-chain commitment to all off-chain attestations. Merkle Tree This checkpoint system is particularly clever because it enables selective verification of any Message without requiring all Messages to be stored on-chain. Through Merkle proofs, anyone can verify that a specific Message was included in a checkpoint, enabling efficient challenge mechanisms while keeping baseline costs low. You can think of it as creating a "blockchain of attestations" where the checkpoints serve as block headers that commit to all Messages within a time period. The aggregator plays a crucial role in this system by collecting operator signatures and making them available through an API. When operators sign Messages, they send them to the aggregator which verifies the signatures have reached quorum (weighted by staked ETH) before exposing them for use by applications. This creates a clean interface for developers while maintaining the system's decentralized security properties. We’ll elaborate on aggregator service in the following section. Aggregator Service The aggregator acts as the coordination layer of NFFL, efficiently managing the flow of Messages between operators and applications. While conceptually straightforward, its design reflects careful consideration of both practical developer needs and decentralization principles. At its core, the aggregator solves the "tragedy of the commons" problem in signature aggregation. Without a dedicated service, each application using NFFL would need to independently collect and verify signatures from all operators—an inefficient and costly process. Instead, the aggregator provides a single point of collection for operator signatures, verifying quorum and exposing verified attestations through a simple API. The signature aggregation process works as follows: Operators independently sign Messages attesting to state updates These signatures are sent to the aggregator for collection The aggregator verifies signature validity and tracks quorum Once sufficient stake weight is reached, the aggregated signature becomes available Applications can fetch these attestations through the aggregator's API Operators independently sign Messages attesting to state updates Operators independently sign Messages attesting to state updates These signatures are sent to the aggregator for collection These signatures are sent to the aggregator for collection The aggregator verifies signature validity and tracks quorum The aggregator verifies signature validity and tracks quorum Once sufficient stake weight is reached, the aggregated signature becomes available Once sufficient stake weight is reached, the aggregated signature becomes available Applications can fetch these attestations through the aggregator's API Applications can fetch these attestations through the aggregator's API This design significantly reduces the complexity for developers integrating NFFL. Rather than managing complex cryptographic operations or tracking operator stakes, applications can simply request attestations for specific state updates through a clean API interface. The aggregator handles all the complexity of signature collection, verification, and BLS aggregation behind the scenes. Signature aggregation Let's explore BLS aggregation used by NFFL further. BLS signatures have a powerful mathematical property that allows multiple signatures to be combined into a single signature. Instead of verifying N individual signatures from operators, which would be computationally expensive and gas-intensive, applications can verify a single aggregated signature that proves collective agreement. The efficiency gains here are substantial. When NFFL operators sign a Message, they generate standard BLS signatures using their private keys. The aggregator can then combine these individual signatures into one compact signature that proves quorum agreement. The size and verification cost of this aggregated signature remains constant regardless of how many operators participated – a property that makes the system highly scalable. Moreover, the aggregated signature can be verified against the combined public keys of the signing operators, weighted by their staked amounts to ensure economic security is properly accounted for. The registry contract then only needs to perform one signature verification operation to confirm that sufficient stake weight has attested to the state update. Aggregator and checkpoints Aggregator and checkpoints It’s important to note that, while the aggregator provides convenience, it doesn't compromise NFFL's security model. The signatures it collects are publicly verifiable, and its role is purely organizational rather than authoritative. Applications can always independently verify that aggregated signatures represent legitimate quorum from staked operators. The aggregator can neither forge signatures nor hide valid attestations—it simply makes them more accessible. The aggregator also plays a vital role in the checkpoint system. By collecting all Messages over time, it can construct the Sparse Merkle Trees used in checkpoint Tasks. This creates an efficient record of all attestations that have passed through the system, enabling later verification if needed for security challenges or auditing purposes. Registry contracts The Registry contract, deployed on each participating rollup, serves as the critical bridge between NFFL's off-chain attestations and on-chain state verification. These contracts enable applications to trustlessly verify the state of other rollups by validating NFFL's cryptoeconomically secured attestations. What makes the Registry particularly interesting is how it maintains the security properties of NFFL across different chains. Each Registry contract keeps a local copy of NFFL's operator set, tracking changes through operator set update attestations. This means that while the operator set is managed through EigenLayer on Ethereum, its state is reliably mirrored across all participating rollups, enabling them to independently verify attestations. When an application needs to verify another rollup's state – for instance, a lending protocol checking collateral on Arbitrum from Optimism – it submits the relevant attestation to its local Registry contract. This attestation includes the aggregated BLS signature we discussed earlier, along with the specific state root being attested to and its associated NEAR DA transaction reference. The verification process in the Registry is remarkably efficient thanks to BLS signature aggregation. The contract only needs to perform a single signature verification against the weighted public keys of the current operator set. If the signature is valid and represents sufficient stake weight, the Registry accepts the attested state as verified. This creates a trustless bridge between rollups that's both secure and cost-effective. The Registry creates a trust-minimized bridge between rollups that's both secure and cost-effective. Through verification of aggregated signatures against the operator set's weighted public keys, it can confirm that a state update has received sufficient attestation weight to be considered valid. This enables applications to reliably verify states across different rollups while inheriting NFFL's economic security guarantees. The Registry also plays a crucial role in NFFL's challenge system. If an attestation is later proven fraudulent through the challenge system, the Registry can invalidate it, protecting applications from relying on incorrect state. This creates multiple layers of security – immediate cryptoeconomic guarantees from staked ETH combined with longer-term fraud protection through challenges. Fault classification & security design in NFFL NFFL's security model centers around detecting and penalizing two primary types of operator misbehavior: Safety Faults and Liveness Faults. Safety Faults are violations that affect the integrity of the network by producing incorrect states or outcomes inconsistent with system rules. There are two key types of safety faults that operators can commit: Equivocation occurs when an operator signs multiple conflicting messages for the same event. For example, signing attestations for different state roots at the same block height, or attesting to multiple different timestamps for the same block. Such behavior undermines the network's ability to reach consensus on the canonical state. Invalid Attestation happens when an operator signs a provably incorrect statement. This could be attesting to an operator set update that doesn't match the on-chain state delta, or signing a state root that doesn't correspond to correct execution of the block's transactions. These faults can be objectively verified through on-chain data. Equivocation occurs when an operator signs multiple conflicting messages for the same event. For example, signing attestations for different state roots at the same block height, or attesting to multiple different timestamps for the same block. Such behavior undermines the network's ability to reach consensus on the canonical state. Invalid Attestation happens when an operator signs a provably incorrect statement. This could be attesting to an operator set update that doesn't match the on-chain state delta, or signing a state root that doesn't correspond to correct execution of the block's transactions. These faults can be objectively verified through on-chain data. While safety faults directly attack correctness, Liveness Faults affect the network's availability and efficiency. If operators consistently abstain from participating in message signing, it impacts both network availability and increases verification costs for users who need more signatures to reach quorum. The protocol tracks operator participation through checkpoint tasks to identify and penalize such behavior. The challenge process varies based on the type of fault and message being challenged: For checkpoint tasks, challengers can prove either message inclusion or exclusion faults. If a message with valid attestations from the checkpoint's time period was omitted, or an invalid/out-of-period message was included, the challenge succeeds. This is verified through merkle proofs against the checkpoint's message tree. Individual messages can be challenged after their checkpoint period by proving the message's content was invalid. For example: Operator set update messages can be invalidated by showing the claimed update ID or operator delta doesn't match on-chain state State root update messages can be challenged by demonstrating the claimed state root is inconsistent with correct transaction execution Operator set update messages can be invalidated by showing the claimed update ID or operator delta doesn't match on-chain state State root update messages can be challenged by demonstrating the claimed state root is inconsistent with correct transaction execution This multi-layered verification system allows the protocol to maintain both fast operation through off-chain messaging while preserving strong security guarantees through cryptoeconomic mechanisms. By making invalid behavior provably detectable and economically punishable through EigenLayer's slashing, NFFL creates strong incentives for honest operation while enabling efficient challenges when violations do occur. Real-world applications of NFFL By establishing a way for rapid and dust cheap cross-rollup state reads, NFFL opens a wide range of applications that were not feasible with the current technological stack of the ecosystem. Let’s explore some of the ideas, from something theoretical and simple to more complex and specific applications, useful in the most popular areas of today’s Ethereum ecosystem. Hello Protocol Let's start with a simple example, described in Nuffle Labs’ official documentation—a protocol that allows users to send "hello" messages between different rollups. While basic, this demonstrates the core mechanics of how applications can leverage NFFL for cross-chain communication. Consider a user wanting to send a message on Network #1 that will be read on Network #2. The process begins when they submit a transaction on Network #1 recording their "hello!" message in the network's state. At this point, the message exists only on Network #1 and would normally require waiting for the canonical bridge settlement (potentially hours or days) before it could be verified by other rollups. This is where NFFL comes in. When the block containing this message is produced, it gets posted to NEAR DA by the network's relayer. NFFL operators, running full nodes for both networks, verify this block data matches what their Network #1 node computed locally. Upon verification, they sign messages attesting to the new state root. These attestations flow through NFFL's aggregator service, which collects signatures until sufficient stake weight has attested to the state. Once quorum is reached, the aggregated signature becomes available through NFFL's API, typically within seconds of the original block production. Now comes the interesting part - consuming the message on Network #2. The Hello Protocol's contract on Network #2 can accept a transaction containing: The storage proof showing the message exists in Network #1's state The NFFL attestation proving this state is valid A reference to the NEAR DA transaction containing the block data The storage proof showing the message exists in Network #1's state The NFFL attestation proving this state is valid A reference to the NEAR DA transaction containing the block data The protocol routes this data to Network #2's Registry contract, which verifies the attestation's signature against its record of NFFL operators. If valid, this proves the message exists in Network #1's verified state, allowing the protocol to safely process it. What makes this powerful is its combination of speed and security. The entire flow from message submission to cross-chain verification can complete in seconds, rather than hours or days with canonical bridges. Yet the security comes from cryptoeconomic guarantees backed by restaked ETH through EigenLayer, rather than trusted operators or optimistic assumptions. trusted operators While sending "hello" messages may seem trivial, this same pattern enables much more sophisticated cross-chain applications. The ability to quickly and trustlessly verify state across rollups creates building blocks for everything from cross-chain DeFi to chain-abstracted user experiences. Fast & cheap token bridging Building on these fundamentals, let's explore a more practical application: a token bridge leveraging NFFL for rapid cross-rollup transfers. The current bridge landscape forces difficult tradeoffs between speed, cost, and security. But NFFL can reshape these dynamics and enable an improved bridging experience for users. Today's leading bridges illustrate these tradeoffs clearly. Stargate, powered by LayerZero, achieves relatively low costs but takes 10-30 minutes to complete transfers due to its operator network needing to achieve and relay consensus across multiple chains. Across provides near-instant transfers but at 10-100x higher costs, primarily due to expensive UMA oracle outputs and slow (6-hour) rebalancing cycles that impact liquidity efficiency. NFFL introduces a new paradigm here. By leveraging EigenLayer's AVS framework rather than maintaining a separate operator network, NFFL can achieve consensus on rollup states within seconds. This consensus can be efficiently relayed through registry contracts across all participating rollups, enabling bridge designs that combine Stargate's cost efficiency with even faster finality than Across. Consider a user moving ETH from Arbitrum to Base. When tokens are locked in the bridge contract on Arbitrum, NFFL operators quickly verify and attest to this state change through their full nodes. Once the aggregator collects sufficient attestations, the bridge contract on Base can immediately verify the token lock through its Registry contract and release funds to the user. This speed and efficiency make many existing bridge optimizations less relevant. For instance, intent-based bridging systems are often proposed to work around slow finality - users submit intents to bridge tokens, and these intents are matched and executed by specialized actors. But with NFFL providing consensus nearly as fast as intent matching would take, bridges can instead use more efficient liquidity pool designs similar to Stargate, but without its speed limitations. intent-based bridging systems The cost benefits here are substantial. Bridge operators don't need to maintain separate consensus infrastructure or pay for expensive oracle outputs. Users receive tokens on the destination chain in seconds while paying mainly for the basic gas costs of verification. Liquidity providers can manage positions more efficiently with faster rebalancing cycles. As an added benefit, the system maintains strong security through EigenLayer's slashing mechanisms. Any fraudulent attestations would result in operators losing their staked ETH, while bridges can still verify final settlement through canonical bridges as an additional safety layer. Multi-chain lending protocol Cross-chain lending represents perhaps the most compelling immediate application of NFFL. Current lending protocols face significant limitations due to chain fragmentation. Take Aave—despite being deployed across multiple rollups, each deployment operates in isolation (which creates several problems). lending protocols Users wanting to use collateral across chains must bridge assets and wait, fragmenting liquidity and reducing capital efficiency. Moreover, some deployments on smaller rollups don’t even have enough liquidity for any meaningful lending, questioning Aave’s marketing position of simple lending for everyone at any size. “Just use Aave” might be better framed as “Just use Aave…but only on its largest deployments” in this case. NFFL enables a fundamentally different approach. Consider a lending protocol that maintains pools across multiple rollups but uses NFFL to share collateral state between them. A user could deposit USDC as collateral on Base, then immediately borrow USDT on Arbitrum against that same collateral—even though USDT isn't deployed on Base at all. The protocol's Arbitrum contract simply verifies the Base collateral position through NFFL attestations, with no bridging required. This creates powerful new possibilities for capital efficiency. Users can access the best rates across any supported rollup without moving assets. Liquidity providers can deploy capital where it's most needed without maintaining separate positions per chain. And because positions can be monitored in near real-time through NFFL attestations, protocols can offer better rates while maintaining security. The benefits extend beyond basic lending. Consider a leveraged trading protocol that allows users to open positions across multiple DEXs. A trader could deposit collateral on Arbitrum, then use it to open leveraged positions on both Arbitrum's and Base's DEXs simultaneously. The protocol can monitor all positions through NFFL attestations, enabling quick liquidations if needed while giving traders access to the best prices across the entire ecosystem. This model is dramatically simpler and more efficient than existing approaches. Rather than complex bridge mechanisms or centralized price feeds, protocols can directly verify positions through registry contracts. The fast finality from NFFL means they can operate with lower safety margins while maintaining security. And users get a seamless experience accessing liquidity across the entire ecosystem. Cross-chain DEX: Deploy once, use everywhere The current approach to scaling decentralized exchanges across rollups often leads to absurd inefficiencies. When protocols like Uniswap deploy to a new rollup, users initially face pools devoid of liquidity and missing critical trading pairs. Consider the recent Uniswap V3 deployment on ZKsync—despite significant excitement and flow of funds from a recent ZK airdrop, many pools remained unusable for days after launch due to insufficient liquidity. Meanwhile, the same protocol's deployments on Arbitrum, Base, and other established chains maintain deep liquidity, low fees, and efficient pricing for thousands of pairs. This fragmentation creates friction throughout the ecosystem. Liquidity providers must split their capital across chains, leading to worse pricing and higher slippage everywhere. Users need to bridge tokens and wait whenever they want to access better liquidity on another chain. Protocol teams must manage multiple deployments, each requiring separate maintenance and monitoring. You’ve guessed it right: NFFL enables a fundamentally different approach again. Let's explore this through two increasingly powerful patterns: Consider a new DEX deploying exclusively to Arbitrum, chosen for its established DeFi ecosystem and favorable gas costs. Rather than launching separate instances across chains, it maintains unified liquidity pools on Arbitrum while enabling trading access from any rollup. Here's how a user on Base might interact with it: Alice wants to swap 10,000 USDC for ETH on Base The DEX's Base interface queries Arbitrum pool state via NFFL attestations Alice sees she can get better pricing than Base's fragmented pools offer She approves the trade on Base The transaction executes on Arbitrum, with the result attested back to Base Alice wants to swap 10,000 USDC for ETH on Base Alice wants to swap 10,000 USDC for ETH on Base The DEX's Base interface queries Arbitrum pool state via NFFL attestations The DEX's Base interface queries Arbitrum pool state via NFFL attestations Alice sees she can get better pricing than Base's fragmented pools offer Alice sees she can get better pricing than Base's fragmented pools offer She approves the trade on Base She approves the trade on Base The transaction executes on Arbitrum, with the result attested back to Base The transaction executes on Arbitrum, with the result attested back to Base The benefits of this unified liquidity are substantial. Liquidity providers can concentrate their capital in one place, leading to better pricing and lower slippage. The protocol team only needs to manage one deployment, simplifying development and reducing operational costs. And users get consistent access to deep liquidity regardless of which rollup they're using. Such a protocol could utilize bridging pattern we’ve explored earlier to seamlessly manage swap flow. At the waiting time of just a few seconds, the actual fact of bridging can be fully abstracted away. This moves us excitingly close to the “chain abstraction” thesis that has recently become quite popular in the crypto community: if it doesn’t matter for the dapp what chain you’re on, why would you care what chain you and all these apps are on? A user can simply proceed to the app’s website, connect their wallet, and perform a wanted action. Done. But NFFL enables an even more powerful pattern - wrapping existing DeFi protocols for cross-chain access. Instead of building competing liquidity pools, developers can create "helper" protocols that make Arbitrum's massive Uniswap pools accessible from any rollup. For example, consider Bob who needs to swap a long-tail token pair on Base. Currently, his options are limited - either bridge to another chain and wait, or accept extreme slippage from Base's thin liquidity. With an NFFL-powered wrapper around Arbitrum's Uniswap deployment, Bob could: Query available liquidity across all Arbitrum Uniswap pools via NFFL attestations Find deep liquidity for his desired pair in an established Arbitrum pool Execute the trade from Base through the wrapper protocol Receive his tokens on Base once NFFL attests to the swap completion Query available liquidity across all Arbitrum Uniswap pools via NFFL attestations Find deep liquidity for his desired pair in an established Arbitrum pool Execute the trade from Base through the wrapper protocol Receive his tokens on Base once NFFL attests to the swap completion This pattern is transformative because it turns existing successful deployments into universal infrastructure. Instead of waiting months or years for liquidity to build on new rollups, protocols can instantly tap into established pools. This is dramatically more capital efficient and creates a better user experience. The possibilities extend far beyond simple swaps. With NFFL's real-time state verification, protocols could offer sophisticated features like cross-chain limit orders. A user could place a limit order on Base against Arbitrum's liquidity, with the wrapper protocol monitoring price movements through NFFL attestations and executing when conditions are met. This model could reshape how we think about protocol deployment across rollups. Rather than automatically deploying everywhere or joining the network effects of a specific chain, protocols could strategically choose their primary chain based on factors like: Gas costs for their specific operations Technological stack—virtual machine, AA, sequencing type, DA, etc. Regulatory considerations Gas costs for their specific operations Technological stack—virtual machine, AA, sequencing type, DA, etc. Regulatory considerations Then through NFFL, they can still serve users across the entire rollup ecosystem while maintaining simpler, more efficient operations. The implications for MEV are also interesting. With unified liquidity accessible across chains, MEV searchers would need to monitor and interact with fewer deployments. This could lead to more efficient price discovery and better execution for users across all rollups. As you may have already noticed, this pattern of single-chain deployment with multi-chain access through NFFL could extend well beyond DEXs. Any protocol that benefits from liquidity depth or network effects could adopt this model - lending protocols, options platforms, NFT marketplaces, and more. The key insight is that NFFL makes cross-chain access nearly as seamless as same-chain interaction, enabling protocols to optimize their deployment strategy without sacrificing accessibility. In other words, NFFL makes Ethereum an ecosystem again. Nuffle roadmap and future development While NFFL already enables powerful new cross-chain applications, the protocol continues to evolve. NFFL's development roadmap focuses on three key areas: Protocol Security Protocol Security Implementing comprehensive challenge and slashing mechanisms through EigenLayer Activating permissionless operator participation with robust stake management Enhancing cross-chain state verification with improved cryptographic primitives (BLS→ECDSA) Implementing comprehensive challenge and slashing mechanisms through EigenLayer Activating permissionless operator participation with robust stake management Enhancing cross-chain state verification with improved cryptographic primitives (BLS→ECDSA) Network Scalability Network Scalability Optimizing signature schemes and state propagation Improving checkpoint efficiency and verification costs Optimizing signature schemes and state propagation Improving checkpoint efficiency and verification costs Developer Experience Developer Experience Building SDK and tooling for easy integration Expanding support for different rollup types and VMs Creating documentation and examples for common use cases Building SDK and tooling for easy integration Expanding support for different rollup types and VMs Creating documentation and examples for common use cases In the following sections, we’ll explore some of the most significant planned improvements in detail. BLS to ECDSA One of the most significant planned changes is the transition from BLS to ECDSA signatures. Currently, NFFL uses BLS signatures to enable efficient aggregation—multiple operator signatures can be combined into a single signature that proves quorum agreement. While this reduces verification costs, it creates challenges for operator set management across chains. The issue stems from how BLS signature verification works. When verifying an aggregated BLS signature, the verifier must use exactly the same set of public keys that created it. This means that when the operator set changes on Ethereum, all rollups must update to the exact same operator set before they can verify new attestations. Even a small mismatch in operator sets between chains can prevent signature verification and require to synchronize all messages of operator set changes. ECDSA signatures, while requiring more space and computation to verify, offer more flexibility. Individual operator signatures can be verified independently, allowing for smoother transitions when the operator set changes. Rollups can verify attestations as long as they recognize the signing operators, even if their view of the complete operator set temporarily differs from Ethereum's. This greater flexibility may be worth the minor increase in verification costs. Dynamic operator sets Dynamic operator sets This signature change ties directly into another major protocol improvement—implementing dynamic operator sets. The current system uses a static, whitelisted set of operators. While this simplified initial development, it limits the protocol's decentralization and scalability. A dynamic operator system would allow new operators to join the network permissionlessly by staking through EigenLayer. This introduces several technical challenges that need to be carefully addressed: First, the protocol must manage operator entry and exit queues. When operators want to join or leave the network, these changes need to be coordinated across all participating chains. The queue system ensures smooth transitions without disrupting the network's ability to verify attestations. Second, the protocol needs mechanisms to track operator performance and stake weight. As operators join and leave, the system must maintain accurate records of each operator's stake and their rights to participate in consensus. This becomes more complex with a dynamic set compared to the current whitelisted approach. Finally, the protocol must handle operator set updates across chains efficiently. When the operator set changes on Ethereum, these updates need to propagate to all participating rollups through their registry contracts. The planned ECDSA transition will help here by making these updates more flexible. Taking off the training wheels Another critical area of development is the activation of permissionless challenge and slashing mechanisms. These mechanisms are essential for enforcing honest behavior and providing the economic security guarantees that NFFL relies on. The challenge system centers around the checkpoint task mechanism. When operators submit checkpoints containing merkleized Messages from a time period, anyone can challenge these checkpoints if they believe they contain invalid attestations. A successful challenge can arise from several types of faults: First, safety faults that directly affect network integrity. These include equivocation - where an operator signs multiple conflicting Messages for the same case, like attesting to different state roots for the same block. They also include invalid attestations, where an operator signs off on provably incorrect state transitions or operator set updates. Second, liveness faults that impact network availability. If operators consistently abstain from participating in message signing, this affects the network's ability to verify states efficiently. The challenge mechanism must balance penalizing such behavior while accounting for legitimate downtime. First, safety faults that directly affect network integrity. These include equivocation - where an operator signs multiple conflicting Messages for the same case, like attesting to different state roots for the same block. They also include invalid attestations, where an operator signs off on provably incorrect state transitions or operator set updates. First, safety faults that directly affect network integrity. These include equivocation - where an operator signs multiple conflicting Messages for the same case, like attesting to different state roots for the same block. They also include invalid attestations, where an operator signs off on provably incorrect state transitions or operator set updates. Second, liveness faults that impact network availability. If operators consistently abstain from participating in message signing, this affects the network's ability to verify states efficiently. The challenge mechanism must balance penalizing such behavior while accounting for legitimate downtime. Second, liveness faults that impact network availability. If operators consistently abstain from participating in message signing, this affects the network's ability to verify states efficiently. The challenge mechanism must balance penalizing such behavior while accounting for legitimate downtime. The protocol will implement a collateral-based challenge system. Challengers must lock collateral when submitting a challenge, which they forfeit if the challenge proves invalid. However, if they successfully prove an operator fault, they receive a reward from the slashed operator's stake. This creates economic incentives for monitoring operator behavior while preventing frivolous challenges. For state root updates, the challenge process is particularly interesting. After an operator attests to a rollup's state, this can be challenged by proving either that the relevant block data wasn't properly posted to NEAR DA, or that the attested state doesn't match the canonical state after settlement. This requires challengers to provide proofs through the Rainbow Bridge for NEAR DA verification, creating multiple layers of security. The slashing mechanism itself will be implemented through EigenLayer's middleware contracts. When challenges succeed, operators lose a portion of their staked ETH. The slashing parameters are designed so that potential losses significantly exceed any gains from malicious behavior. Some of this slashed stake is awarded to successful challengers, while the remainder might be distributed to honest operators or used for protocol development. These mechanisms create a comprehensive security framework. Operators face significant financial penalties for misbehavior, challengers are incentivized to monitor the network, and applications can rely on cryptoeconomic guarantees backed by restaked ETH. The challenge periods are much shorter than optimistic rollup fraud proofs, while still providing strong security through EigenLayer's slashing mechanics. The future of fast finality on Ethereum While NFFL provides an immediate solution for cross-rollup state verification, it's worth examining how the protocol fits into Ethereum's broader scaling roadmap. The key question many ask is: "Will NFFL still be relevant as rollup technology advances?" The answer becomes clear when we examine fundamental settlement limitations in different rollup designs. Optimistic rollups, despite their popularity and maturity, cannot fundamentally settle faster than their fraud proof window—typically 7 days. While solutions like Optimism's Superchain and Arbitrum Orbit enable faster communication between rollups sharing a bridge, they don't help with interoperability outside their specific ecosystems—for example, between those two. ZK rollups face different but equally important constraints. Even as ZK proof technology improves dramatically, there are practical limits to settlement speed. Even if we reach a point where proofs can be generated for every L1 block, Ethereum must still have capacity to verify multiple ZK proofs per block across different rollups. When this becomes possible, settlement will still be bound by L1 block time—at least 12 seconds under current parameters. NFFL offers a different approach by utilizing signed sequencer attestations from rollups. Instead of waiting for batches to be published on L1, NFFL operators can verify and attest to state changes as soon as they're produced by the sequencer. This enables cross-chain state verification in seconds while maintaining strong cryptoeconomic security through EigenLayer. Importantly, NFFL should not be viewed as competing with or threatening Ethereum's rollup security model. Rather, it provides a complementary tool that enables new possibilities within the modular Ethereum ecosystem. Applications can use NFFL for rapid state verification while still relying on canonical settlement through L1 when needed. This creates a richer toolkit for developers to build cross-chain applications with security models appropriate to their specific needs. Conclusion NFFL represents a novel approach to solving one of the most pressing challenges in Ethereum's modular ecosystem - enabling secure and efficient cross-rollup state verification. By leveraging EigenLayer's restaked ETH for economic security and NEAR DA for efficient data storage, NFFL creates a fast finality layer that can verify rollup states within seconds rather than hours or days. The protocol's thoughtful design choices reflect deep understanding of the challenges in cross-chain infrastructure. Rather than attempting to replace rollups' security model, NFFL provides a complementary layer optimized for specific use cases that require faster finality. The checkpoint-based task system enables efficient off-chain operation while maintaining strong on-chain security guarantees. And the registry contract architecture allows rollups to trustlessly verify states while inheriting NFFL's economic security. Perhaps most importantly, NFFL enables a new generation of cross-chain applications that were previously impractical. From unified lending protocols that share collateral across rollups to DEX wrappers that make established liquidity universally accessible, NFFL's fast state verification creates building blocks for true chain abstraction. This has profound implications for capital efficiency and user experience across the ecosystem. The protocol's roadmap demonstrates commitment to continuous improvement. Planned upgrades like the transition to ECDSA signatures and implementation of dynamic operator sets will enhance decentralization and scalability. The activation of comprehensive challenge and slashing mechanisms will strengthen security guarantees. And integration with additional DA solutions beyond NEAR will make NFFL even more universal. As Ethereum's rollup ecosystem continues to evolve, the need for secure cross-chain state verification will only grow. NFFL's approach of extending Ethereum's security through restaking while optimizing for speed and cost-effectiveness positions it well to serve this need. By enabling new forms of cross-chain interaction while maintaining strong security guarantees, NFFL contributes to making Ethereum's modular vision a reality. Author’s note: A version of this article was originally published here. Author’s note: A version of this article was originally published here . here