Can Ethereum make rollups operate like a network?
During a demo at Devcon, a trader signed an order on an Ethereum rollup, used mainnet liquidity to purchase tokens, and then received those tokens directly on the rollup. Gnosis plans to make this design the default by spring 2027. This approach demonstrates that users may be able to access deeper markets without personally moving their funds to the mainnet.
- A trader signed one order on the experimental Rollup X network, and the CoW Swap solver executed the trade using Ethereum mainnet liquidity.
- The Devcon demo on November 4 also tested how Safe Wallet uses vault permissions across networks.
- The team stated that gas consumption for their signature verification example decreased by 91%, a result specific to this operation.
- To participate in the network, you must generate attestations within Ethereum's 12-second slot and follow Ethereum during reorganizations.
- Gnosis aims to make this design the default by spring 2027, bringing it to a network with existing users and applications.
The Ethereum Economic Zone team demonstrated a transaction: a user signs an order on the experimental Rollup X network, CoW Swap’s solver uses Ethereum mainnet liquidity to fulfill the trade, and the purchased tokens are then returned to the rollup. This demonstration shows that traders can access deeper markets on the mainnet without first transferring funds to it and waiting for confirmation.
The team demonstrated this transaction at Devcon on November 4, as previously reported by crypto.news. This distinction is important because, during rapid price fluctuations, the quote traders see when initiating fund transfers may already have changed by the time the funds are ready for the transaction.
Gnosis aims to make this design the default by spring 2027. For traders, the real test will be whether wallets and trading apps can provide this pathway, and whether prices on mainnet remain worthwhile after execution costs.
How does this transaction work across two execution environments?
The Ethereum Economic Zone team initially made a transaction in October involving 0.001 ETH and a rollup state update. This swap at Devcon brought the same coordination issue into a scenario familiar to traders: it had to fulfill an order using liquidity on another chain and return the resulting assets to where the user started.
For traders, an order describes a result: the seller wishes to exchange one asset for another according to the order terms and receive the outcome on the rollup. The solver is responsible for finding the execution path. This distinction is important because users can authorize a result without deciding which pools the solver will use or preparing individual transactions for each step.
In the Devcon example, this path includes the Ethereum mainnet. Liquidity remains on the mainnet, while users’ orders originate on Rollup X, and the purchased assets are returned to Rollup X. This demo addresses a problem that can arise even when each network’s applications function properly: traders might hold funds on a chain with shallow markets for their target trading pair, while the best execution occurs elsewhere.
If the path is divided into multiple steps, users are exposed to various decisions along the way. The first transfer may already be complete, but the quote the user sees has changed. At this point, the user must either accept the current price, wait, or initiate another transfer. As long as the participating infrastructure can complete the operation within the agreed execution window, the coordinated path can link asset movement to the full execution of the order.
The actual difference lies in that one path guarantees delivery, while the other ties together the individual constituent operations. A service can make cross-chain transactions appear simple by taking responsibility for delivery itself. The design shown in the demo, however, provides applications with a way to link results on one chain to executions on another. Which approach offers a better experience depends on pricing, available assets, and the terms under which each service delivers orders.
There is still a lot of work happening behind the user’s signature. The application must present the terms, the solver must find and price the path, and the participating network must agree on the relevant state. Production systems must handle failures across these steps. While applications can simplify the interface, they cannot make this work disappear.
For wallets, a similarly practical test is: what transaction history does it display after an order expires? If the user signs only once and the transaction succeeds, they should be able to see the received assets and the receiving account. If the path fails, the wallet must still distinguish between an expired order and a transaction still pending settlement. This is crucial during market volatility, as traders may place a second order and need to know whether the first one can still be executed.
Before the network can collectively execute, it must first reach consensus.
The blockchain records more than just balances. Its state also includes information that applications rely on, such as account permissions, contract balances, and transaction statuses. Contracts that depend on the results of another chain require evidence of that state, and this evidence must be available when the contract needs to use the results.
Gnosis will join the network designed by EEZ under two conditions: they must generate proofs within a single Ethereum slot and follow Ethereum during reorganizations. Gnosis describes these as requirements for network access, while leaving certain implementation choices to the participating parties.
The slot set a deadline for engineers. If generating the required proof for a network exceeds the available window, the other side cannot rely on it within the same time window. Even if a proof system performs well on typical blocks, it still faces exceptional workloads, interruptions, and computational competition.
The second condition addresses what happens when Ethereum’s recent history changes. If a transaction on another network depends on an event from a recent block on the main chain, and a competing block replaces that event, the connecting system needs rules to handle the dependent transaction. Maintaining consistency reduces the likelihood that one side retains results based on a main chain event that is no longer part of the accepted chain.
This distinction is important for users because coordinated execution and final settlement describe different attributes. Coordinated execution focuses on whether all steps can be completed together, while final settlement concerns when participants can regard the outcome as settled according to relevant network rules. A wallet can provide a unified view of operations while still distinguishing between a transaction that has been included and one that has reached the settlement status required for business purposes.
Gnosis’s earlier engineering work involved block root commitments, gas limits, and how upgrades are executed. These choices affect how the network recognizes each other’s results and how much work applications can ask the network to perform. October’s milestone deployed a simple operation on mainnet, while November’s demo provided developers with a broader range of workloads to test.
How far can this design go, beyond trading?
Safe's demo applied the same approach to wallet ownership. A vault using separate accounts across different chains might have a gap between removing a signer from one network and updating permissions elsewhere. This example shows how a rollup can verify ownership changes completed on the mainnet within the same transaction.
The third demo verified Falcon post-quantum signatures on a rollup and used the results to authorize a mainnet transfer. The team reported that gas consumption in this comparison was reduced by 91% compared to verifying directly on the mainnet. This savings applies specifically to the verification operation; production applications must still account for the full execution and settlement costs.
One signature still requires a market execution.
The swap path shifts some of the workload away from the trader. The solver must determine where to execute the trade, calculate fees, and submit the necessary operations to complete the transaction. The user only receives a quote, even though the solver has already factored in the multi-step costs within the quoted amount.
This arrangement is most useful when liquidity on another network is sufficient to cover the cost of accessing it. Small orders in a deeply local market may execute more cheaply locally, while large orders in a shallow pool may still achieve better prices from mainnet liquidity, even after accounting for additional execution costs.
It’s also important to understand what happens when attempts fail. Reversing asset movements can prevent traders from receiving only half the outcome of their intended trade. However, the party initiating or attempting to execute the action may still incur costs, depending on how the path is implemented. In live markets, these costs influence which orders solvers are willing to accept and how they price them.
For traders, a good comparison should use the same order size, token pair, and time window. The price received after fees can be compared to local swaps or step-by-step bridge pathways. Clicks reflect convenience, but the net amount received reflects the actual trade.
How does a project move from proposal to devnet?
The project was initially proposed by Gnosis and ZisK at EthCC in the spring and received support from the Ethereum Foundation. The original proposal focused on liquidity and applications already distributed across different Layer 2 networks. Rollup X provides developers with an environment to test how shared transactions can utilize these applications.
There is a reason for selecting different demonstration scenarios. Transferring a small amount of ETH between environments tests relatively straightforward operations. Swapping introduces the need to fulfill market liquidity orders and return assets. A change in Safe ownership involves permissions. Signature verification requires one environment to perform a check and another to act based on its result. Each tests a different dependency.
A path that works for one type of operation may not apply to another. Swaps must contend with fluctuating prices and liquidity. Ownership transfers are less sensitive to market prices, but the consequences of failure may be more severe. Verification applications may benefit from offloading computational work, even without an economic reason to move funds between networks.
The common requirement is that the receiving contract must rely on it at the point when information is needed. This places pressure on the software maintaining the connection. An application can only provide a simple interface when the execution path has properly handled the required state and returns the expected result. In real-world products, developers must decide which operations are worth including on this path and which can run independently.
Gnosis advocates making this technology the default in part because applications can avoid redundant development. A team building on a new network might otherwise need to provide local liquidity for a long list of markets. By connecting to the mainnet pool, it could offer trading for a specific pair even before a local dedicated pool becomes viable. For local liquidity providers, the same option means competition from another source of execution.
The impact on users is most easily measured in products that simultaneously disclose both pathways. Wallets can compare local execution versus on-chain execution for the same order and display the net amount received on the target chain. Treasury tools can illustrate how many separate transactions are required for changes in application permissions. These tests reveal exactly where this approach alters actual execution costs or operational effort.
Scheduling is important because the complexity of running a successful demo is far lower than that of a service with many users and applications. A live system must handle concurrent requests, varying market conditions, and software changes. Migrating existing Gnosis Chain applications will test more relevant dependencies than relying solely on Devcon examples.
The price of a cross-chain swap must cover:
Traders compare the net amount of assets received after deducting costs. Local pools have their own trading fees and price impact. The mainnet path may offer deeper liquidity, but it may require more execution effort and incur usage costs. The solver deciding between these two paths must balance better pool prices against these costs.
Suppose a local pool, after deducting all fees, delivers assets worth $9,900 on an order with a reference value of $10,000. If a cross-chain path can execute the trade at $9,980 before execution costs, it has up to $80 of room to improve before the local quote becomes more favorable. If the cost to access a better pool is $30, the cross-chain path ultimately delivers $9,950; if the additional cost reaches $100, the local path becomes more advantageous. These numbers are for illustrative purposes only and do not represent any real-time quotes.
Order size affects this calculation. Larger trades may push prices further in shallow pools, giving the solver more reason to reach deeper markets. Smaller trades may have minimal impact on local prices and leave insufficient room for savings across cross-chain paths. Even for the same token pair, the most beneficial paths can change within a day due to fluctuations in liquidity and network costs.
The solver must also account for the time spent on failed attempts and pathfinding in its pricing. Failed operations may result in the reversal of user asset movements, while the party placing the order may still incur fees associated with the attempt. The impact of this design on the spread seen by traders depends on how these costs are actually allocated and how competitive the market is among institutions providing quotes.
For wallets integrating this design, the key information is what users can compare. If quotes display the minimum delivery amount and the receiving network, traders can evaluate the outcomes. An interface emphasizing “one-click” or “one-signature” only highlights convenience; it is the price and delivery terms that determine whether this path is suitable for the order.
Exchanges considering this design must determine which conditions underlie the quotes presented to customers. One path may execute entirely within the user’s own funds, while another may tap into mainnet liquidity and rely on proof of readiness within a slot. Even if two quotes display the same token and amount, they may have different expiration rules and distinct failure reasons. The interface must clearly state the minimum amount the customer is willing to accept, as well as what happens if the solver cannot fulfill the order.
The app must also find a way to collect sufficient comparable data to determine why one path is more expensive. A useful series of comparisons should include the same trading pair, the same trade size, the same network, and closely timed quote collection. Making a single trade with unusually low liquidity might make accessing another market appear more valuable than it is for routine orders. Conversely, if a major trading pair can already be traded cheaply on the user’s rollup, the opposite issue may arise. Execution price, included fees, and expiration conditions must all be considered together in the comparison.
Safe makes cross-chain permissions part of the problem.
A vault might use one account for daily payments and another account to hold assets on different networks. If it needs to change who is authorized to approve expenditures, someone must ensure that this change is also reflected in the locations where the assets are actually stored. Updating them separately leaves outdated signatory lists active on less frequently used accounts.
The Safe demo illustrates how applications can use ownership changes on the mainnet in coordinated transactions involving rollups. Its benefits depend on how the treasury assigns permissions. An organization might wish to have a shared set of signers determined by the mainnet, while maintaining separate policies for local spending accounts serving specific teams.
A shared permission structure reduces redundant work, but it also makes error handling more critical, as a single change can affect multiple locations. The vault must determine: how accounts can be recovered if an update fails, who is authorized to make corrections, and how the system behaves if the connected chain cannot retrieve the latest results.
Therefore, organizations evaluating this design will ask: Which specific operation do they want to coordinate? Reading the list of signers, updating ownership, and moving vault assets each have different implications. Including one of these operations in a shared transaction does not mean the organization should entrust all decisions to the same account.
Institutional interest extends beyond the Devcon stage. ConsenSys has announced a suite of interoperable systems designed for banks and stated its intention to support the EEZ standard. For banks, compatibility is only one part of the equation; they also need to consider who can access the system, what controls apply to each operation, and how results can be integrated into existing systems.
The Safe case highlights another set of product tests. A team might want a signer on one network to approve an operation that only affects assets on another network. This raises the question: Can a signer removed locally still authorize a cross-network operation previously submitted? The answer depends on how the application reads account state and what it considers the authorization time. Even if the underlying protocol can transmit messages, the application must clearly define these matters.
Falcon demonstrates what it means to move computation elsewhere.
This signature demonstration uses a rollup to verify Falcon signatures and submits the results to an on-chain operation. The team reports that gas consumption in this comparison is reduced by 91% compared to direct verification on mainnet. The scope of this example is much narrower than “how much gas is reduced for all possible transactions using this design”; it compares the performance of a specific operation across two execution paths.
The opportunity lies in performing computationally intensive checks in an environment better suited for them, while having another contract rely on that result. The value saved may differ for applications that rarely perform checks compared to those that must repeat the check with every transaction. This decision also depends on how the application verifies the result and what other steps it must complete before using it.
Post-quantum verification is one application of this model. Contracts may also require additional information from the connected environment to proceed, such as whether an account is authorized to perform a specific action. A common challenge is: how to make results available within the same execution window. Different checks may vary significantly in their computational and proof requirements.
For users, an app supporting a particular signing scheme does not determine the security of each wallet or transaction on the chain. This demonstration only concerns the verification and authorization of specific transfers. Changing the rules by which wallets typically sign transactions requires additional decisions regarding software, compatibility, and which accounts will adopt these changes.
Developers evaluating the Falcon demo also noted a similar distinction: the gas cost of a smart contract reading the verification result differs from the cost of generating that result elsewhere, as they belong to different execution environments. Measuring the former reflects the real constraints an application would face if it had to perform verification on the mainnet. Deciding whether to offer this feature also requires accounting for the latter, and further depends on whether the check can still be completed under high load, when many requests compete for the same capacity.
Gnosis needs to bring existing applications through the transition period.
GnosisDAO authorized the migration of the independent network to the EEZ rollup via GIP 153 in August. The migration is significant because existing users and applications have balances, addresses, and dependencies tied to the current chain. Adopting the new execution and settlement arrangement means changing infrastructure already in use.
Real-world applications require answers to different questions than those on development networks. Users need to know how balances will be migrated, which wallets and infrastructure providers support the migration, and how to obtain reliable activity records during the transition. Exchanges, on the other hand, must consider integrations that may become available at different times.
A rollup that connects to the mainnet market may offer trading paths before establishing deep liquidity pools for each trading pair. For chains with mature liquidity, the situation differs: applications can choose between executing locally or sharing paths, and existing on-chain liquidity providers can see how these choices impact activity within their pools.
The migration will also test the difference between "launching a network" and "setting a feature as the user default." The first block can prove that the new chain is operational; the default user path requires wallets, applications, and other services to adopt this new path in their daily operations. Earlier reports indicated that the initial deployment was targeted for early in the year. Gnosis’s November update set a target of making it the default operation by spring 2027.
Gnosis provides developers with a place to raise these questions within their existing application deployment environments. Migration aligns execution, wallet support, and operational processes on the same timeline, enabling teams to observe how they handle delays or partial integrations. The November update set spring 2027 as the target for making this design the default. The actions at Devcon took place on Rollup X.
Content worth paying attention to
- Supported paths: The networks on which the same operation can be performed by the wallet and app.
- Execute quote: Are the net output and failure order rates comparable between local and cross-network trades?
- Slot performance: Verified through repeated testing for usability and recovery during Ethereum reorganizations.
- Vault permissions: Are the scope, expiration, and revocation rules for Safe integration publicly disclosed?
- Gnosis Milestone: Public migration testing and progress toward the spring 2027 target.
Frequently Asked Questions
What is Rollup X?
It is the development network used by the Ethereum Economic Zone in its demonstration. Devcon used it to test operations involving the Ethereum mainnet and another execution environment.
How does this swap work?
A Rollup user signed a CoW Swap order using Ethereum mainnet liquidity, and the purchased tokens were subsequently returned to the Rollup. The solver used mainnet liquidity and delivered the resulting assets back to the Rollup as part of the coordination process.
What is atomic execution?
The operation either succeeds entirely or rolls back entirely. This design prevents users from receiving incomplete results on one network after a step has completed on another.
How can the network join this design?
Gnosis states that the network must prove its state within a single Ethereum slot and follow Ethereum during reorganizations. The application also requires wallet support and the specific paths for the assets or permissions it intends to use.
Why use a solver?
The solver will find and execute a path for the signed order. It can locate liquidity and assemble a path within the user's signing constraints. Execution still depends on the availability of quotes.
What does the Safe demonstration show?
Connected rollups can verify ownership changes on the mainnet within the same transaction. Cross-chain vault access also depends on how the application reads and updates who is authorized to act.
What is the 91% gas figure referring to?
The team used it for the Falcon signature verification demo. This comparison covers only the signature verification example and does not correspond to an equivalent percentage for transactions or vault operations.
When does Gnosis plan to implement this design?
Gnosis has set spring 2027 as the target for default enablement on Gnosis Chain. This target pertains to changes on Gnosis Chain. Rollup X is the development environment used for demonstration purposes. This is an educational analysis and does not constitute investment advice.