Can Ethereum enable rollup to function like a network?

In a demonstration at Devcon, a trader placed an order on Ethereum’s rollup to buy tokens using the mainnet liquidity, and subsequently received these tokens on rollup. Gnosis plans to adopt this approach as the default scheme in the spring of 2027. This practice indicates that users may be able to access deeper markets without having to transfer their funds to the mainnet themselves.

• A trader placed one order on the experimental Rollup X network, and the solver of CoW Swap completed the transaction using the liquidity of the Ethereum mainnet.
• On November 4th, the Devcon demonstration also tested how the Safe wallet can use treasury permissions across networks.
• The team stated that the consumption of gas in their signature verification example has been reduced by 91%, and this result is specific to that operation only.
• To participate in the network, it is necessary to generate a proof within 12 seconds on Ethereum using the slot mechanism, and to follow Ethereum during any reorganization process on Ethereum.
• Gnosis The goal is to set this design as the default by the spring of 2027, which will bring it to a network that already has users and applications.

The Ethereum Economic Zone team demonstrated a transaction: a user placed an order on the experimental Rollup X network, and the solver from CoW Swap used the liquidity of the Ethereum mainnet to complete the transaction. The purchased tokens then returned to rollup. This demonstration shows that traders can access the deeper markets on the mainnet without having to transfer funds to the mainnet first and then wait for them to be credited.

On Devcon of November 4th, the team showcased this transaction, which had previously been reported on crypto.news. This distinction is important because when prices fluctuate rapidly, the quotes that traders see when they start to transfer funds may have already changed by the time the funds are ready for the transaction.

Gnosis The goal is to set this design as the default by the spring of 2027. For traders, the real test will be whether wallets and trading applications can provide this option, and whether the price on the mainnet is still worthwhile after taking into account the execution costs.

How does this transaction that spans two execution environments work?

Ethereum Economic Zone The team initially made a transaction in October involving updates to the status of 0.001 ETH and rollup. This swap on Devcon brought the same coordination issues into a scenario familiar to traders. It was necessary to execute orders on liquidity from another chain and send the resulting assets back to where the users started.

For traders, an order describes a result. The seller hopes to exchange one asset for another according to the terms of the order and receive the result on rollup. The solver is responsible for finding the execution path. This distinction is important because users can authorize a result without having to decide which pool the solver will use, nor do they need to prepare a separate transaction for each step.

In the example of Devcon, this path includes the Ethereum mainnet. Transaction liquidity remains on the mainnet, while the starting point of the user's order is at Rollup X. The purchased assets are then returned to Rollup X. This demonstration addresses a problem that may occur even when each network is functioning normally: traders might place their funds on a chain with less depth in the target trading pair market, yet the best execution could occur elsewhere.

If the process is divided into multiple steps, users will be exposed to various decisions along the way. The first transfer may have been completed, but by that time, the quotes displayed to the user may have changed. At this point, the user has three options: accept the current price, wait, or transfer funds again. As long as the participating infrastructure can complete the operations within the agreed execution window, the coordinated process can link the movement of assets with the completion of the entire order.

The actual difference lies in the fact that one approach promises delivery of a single outcome, while the other binds together various constituent operations. A service can handle its own delivery, making cross-chain transactions seem quite simple. The design demonstrated provides a way to connect the results on one chain with the execution on another chain. Which approach offers a better experience depends on factors such as price, available assets, and the terms of service delivery orders.

There is still a lot of work behind user signatures. Applications must present the terms, solvers must find and price the paths, and participants in the network must reach an agreement on the relevant status. Production systems must handle failures in these processes. Applications can simplify the interface, but this does not make this work disappear.

For wallets, an equally practical test is: after an order expires, how well can it display the transaction records? If a user signs just once and the transaction is successful, the user should be able to see the assets received as well as the receiving account. If the process fails, the wallet still needs to distinguish between orders that have expired and those that are still waiting to be settled. This is very important during market fluctuations, as traders may place a second order and need to know whether the first one can still be executed.

What consensus must be reached before the network can proceed together?

Blockchain records more than just balances. Its state also includes information that applications will use, such as account permissions, contract balances, and transaction statuses. Contracts that rely on the results of another chain need evidence regarding that state, and this evidence must be available when the contract needs to utilize those results.

Gnosis will add two conditions to the network designed by EEZ: they need to generate proofs within a Ethereum slot, and they must follow Ethereum during a reorganization of Ethereum. Gnosis describes these conditions as requirements for joining the network, while leaving the choice of some implementations to the participating parties.

slot A deadline has been set for engineers. If the time required to generate a proof for a particular network exceeds the available window, the other side cannot rely on it within the same time frame. Even if a proof system performs well on typical blocks, it still has to face exceptionally heavy workloads, interruptions, and competition for computing power.

The second condition deals with what happens when there are changes in Ethereum's recent history. If a transaction on another network relies on an event from a recent block of the mainnet, and a competing block replaces that event, then the connecting system needs rules to handle this dependent transaction. Maintaining consistency can reduce the likelihood of one side retaining results based on a mainnet event that no longer belongs to the accepted chain.

This relationship is very important for users because the coordinated transactions and the final settlement describe different aspects. Coordinated execution focuses on whether each step can be completed together; final settlement focuses on when the participants can consider the results as settled according to the relevant network rules. A wallet can provide a view of the operations, while still distinguishing between a transaction that has been included and a transaction that has reached the state required for settlement in business terms.

Gnosis Previous engineering work involved block root commitments, gas ceilings, and how upgrades are executed. These choices affect how the network recognizes each other, as well as how much work applications can request the network to handle. The milestone in October put a simple operation onto the mainnet, while the demonstration in November provided developers with more different types of workloads to test.

How far can this design go? It's not just about trading...

The demonstration of Safe applies the same method to wallet ownership. A treasury that uses separate accounts on different chains may experience a gap between removing a signer from one network and updating permissions elsewhere. This example shows how rollup verifies the ownership change completed on the mainnet within the same transaction.

The third demonstration involved verifying the post-quantum signature of Falcon on rollup, and using the result to authorize transfers on the mainnet. The team stated that compared to verifying directly on the mainnet, the consumption of gas in this comparison was reduced by 91%. This savings is applicable to this verification operation; however, production applications still need to consider the full execution and settlement costs.

One signature still requires an execution market.

swap The path transfers some of the work away from the person who places the order. The solver must decide where to execute the transaction, calculate the fees, and submit the operations required to complete the exchange. The user only receives one quote, although the solver has included multiple steps of costs in the quoted amount.

This arrangement is most useful when the liquidity on another network is sufficient to cover the cost of accessing it. Small orders in a deeply localized market may be executed more cheaply locally. Large orders in a shallow pool may still obtain better prices from the mainnet liquidity, even with additional execution costs.

It is also important to know what happens in case of failed attempts. Canceling an asset transfer can prevent traders from only receiving half of the expected results of a transaction. However, the party that arranged or attempted to execute the transfer may still incur costs, depending on how the process was carried out. In a production market, these costs will affect which orders solvers are willing to take on and how they price those orders.

For traders, a good comparison should use the same order size, token pair, and time window. The price received after deducting fees can be compared with that of local swap or the path for phased bridging of funds. The number of clicks reflects convenience, while the net amount received actually reflects the transaction itself.

How does a project go from a proposal to devnet?

The project was initially proposed by Gnosis and ZisK during the spring of EthCC and received support from the Ethereum Foundation. The initial proposal focused on liquidity and applications that were already distributed across different Layer networks. Rollup X provided developers with an environment to test how shared transactions could utilize these applications.

There is a reason for choosing different demonstration scenarios. Transferring a small amount of ETH between different environments tests relatively direct operations. swap introduces the need to satisfy market liquidity orders and return assets. The change of ownership in Safe involves permissions. Signature verification requires one environment to perform checks, while another environment takes action based on the results. Each scenario tests different dependencies.

A path that is effective for one type of operation may not be suitable for another. swap must adapt to constantly changing prices and liquidity. Changes in ownership are less sensitive to market prices, but the consequences of failure can be more severe. Verification applications may also benefit from offloading computational work to other locations, even if there is no economic reason to move funds between networks.

The common requirement is that the receiving contract must rely on it at the point in time when the information is needed. This puts pressure on the software that maintains the connection. Only when the execution path handles the required states and returns the expected results can the application provide a simple interface. In real products, developers must decide which operations are worth including on this path and which can run independently.

Gnosis advocates setting this technology as the default for several reasons, one of which is that it can prevent duplicate construction in applications. A team developing on a new network may originally need to provide local liquidity for a long list of markets. By connecting to the main network pool, they might be able to offer transactions for certain pairs before it becomes feasible to create local dedicated pools. For providers of local liquidity, this same option means competition from another source of execution.

The impact on users is most easily measured in products that disclose both paths simultaneously. Wallets can compare local transactions with mainnet transactions for the same order and display the net amount received on the same target chain. Treasury tools can indicate how many separate transactions are required for changes in application permissions. These tests can show in which areas this approach actually changes the actual execution costs or the amount of operational work.

Schedules are very important because the difficulty of running a successful demonstration is likely to be much lower than that of a service with a large number of users and applications. A live system must handle concurrent requests, different market environments, and software changes. Migrating the existing Gnosis Chain application over will involve testing more related dependencies than testing with just the Devcon example.

What needs to be covered by the price of cross-chain swap?

Traders compare the amount of money that arrives in their accounts after deducting costs from the purchase price of assets. Local pools have their own transaction fees and price impacts. The mainnet route may offer deeper liquidity, but it may require more execution work and incur additional usage costs. The solver that decides how to choose between the two routes must weigh the better pool prices against these costs.

Assume that a local pool can deliver assets worth $9,900 after deducting all fees for an order with a reference value of $10,000. If a cross-chain path can execute the transaction for $9,980 before incurring any execution costs, then it has a maximum margin of $80 before its local quote becomes more favorable. If the cost of accessing a more advantageous pool is $30, then the cross-chain path will ultimately deliver assets for $9,950; however, if the additional cost reaches $100, the local path becomes more advantageous. The numbers mentioned here are merely for illustrative purposes and do not represent any real-time quotes.

The order size can change this calculation. Larger transactions may push prices further in shallow pools, thus giving solvers more reason to reach deeper markets. Small transactions may have little impact on local prices, and there may not be enough room for savings in cross-chain paths. Even for the same token pair, the truly useful path can change within a single day as liquidity and network costs vary.

Solvers must also include the time spent on failed attempts and path searches in the pricing. Failed operations may result in the reversal of users' asset movements, and the party that arranged the order may still have to bear the costs associated with those attempts to execute. The impact of this design on the spreads seen by traders depends on how these costs are allocated in the actual implementation, as well as the level of competition among the institutions providing quotes.

For wallets that incorporate this design, the important information is what users can compare. If the quote displays the minimum payment amount and the network for fund arrival, traders can then evaluate the outcome. An interface that emphasizes "one-click" or "one-signature" only indicates convenience; it is the price and delivery terms that determine whether this approach is suitable for a particular order.

For trading venues that consider adopting this design, it is necessary to decide on the conditions upon which quotes are displayed to customers. One path may be executed entirely within the funds held by the user; another may rely on mainnet liquidity and depend on proof that it is ready within a slot. Even if both quotes show the same token and the same amount, they may have different expiration rules and different reasons for failure. The interface must clearly indicate the minimum amount that customers are willing to accept, as well as what will happen if the solver is unable to fulfill the transaction.

The application also must find ways to collect sufficient comparable data to determine why a particular route is more expensive. A useful series of comparisons should include the same pair of assets, the same transaction size, the same network, and the quotes should be collected at similar times. If only one transaction with exceptional lack of liquidity is considered, it may make accessing another market seem more valuable than regular orders. Conversely, if a mainstream asset pair can already be traded at a lower price on the user's rollup, the opposite problem may arise. The execution price, included fees, and expiration conditions must all be taken into account in the comparison.

Safe Making cross-chain permissions a part of the issue

A vault may use one account to handle daily payments and another account to hold assets across different networks. If it wishes to change the individuals authorized to approve expenditures, someone must ensure that this change is also reflected in the actual locations where the assets are stored. Separate updates can allow outdated lists of authorized signatories to continue to be effective on less frequently used accounts.

The demonstration of Safe showed how applications can utilize ownership changes on the mainnet in coordinated transactions involving rollup. The benefits of this approach depend on how the treasury manages permissions. A certain organization might prefer that the mainnet determine a set of shared signatories, while retaining separate policies for local expenditure accounts that serve specific teams.

Sharing permission structures can reduce repetitive work. However, it also makes error handling more important, as a single change may affect multiple locations. The vault needs to clarify: in the event of an update error, how can accounts be restored, who can authorize corrections, and what will happen if the connected chains cannot obtain the latest results.

Therefore, the organization evaluating this design would ask: which type of operation do they wish to coordinate? Reading the list of signatories, updating ownership, and moving assets from a vault each have different consequences. Incorporating one of these operations into a shared transaction does not mean that the organization should delegate all decisions to the same account.

Institutional interest extends beyond the Devcon platform. Consensys has announced an interoperable operating system for banks and stated plans to support the EEZ standards. For banks, compatibility is just one aspect; they also need to consider who can use the system, what controls apply to each operation, and how to record the results in existing systems.

The case of Safe indicates another set of product tests. A team might wish for a signer on one network to approve an operation that only affects assets on another network. This raises a question: can a signer who has been removed locally still authorize cross-network operations that were previously submitted? The answer depends on how the application reads the account status and what it considers as the authorization time. Even if the underlying protocols can transmit messages, the application still needs to clarify these matters.

Falcon Demonstrates what it means to offload computations to another location

This signature demonstration uses rollup to verify the Falcon signature and provides the results for operations on the mainnet. The team claims that compared to direct verification on the mainnet, the gas consumption in this comparison has been reduced by 91%. The scope of this example is much narrower than “how much the transaction costs of all possible uses of this design have been reduced.” It compares the performance of a specific operation on two different execution paths.

The opportunity lies in executing computationally intensive checks in an environment that is more suitable for them, while having another contract rely on this result. For applications that rarely perform these checks, the savings may be different from those of applications that need to repeat the checks with each order. This decision also depends on how the application verifies the results and what other steps it must complete in order to use those results.

Post-quantum verification is an application of this mode. Contracts may also require additional information from the connected environment to proceed, such as whether an account has the authority to perform a certain operation. The common issue is: how to make the results available within the same execution window. Different checks may have vastly different requirements for computation and proof.

For users, the fact that an application supports a certain signing scheme does not determine the security of each wallet or every transaction on the blockchain. This demonstration only involves the verification and authorization of specific transfers. To change the rules by which wallets typically sign transactions, additional decisions need to be made regarding the software, compatibility, and which accounts will adopt these changes.

When developers evaluate Falcon, there are similar differences as well. The gas it takes for the contract to read and verify results is different from the cost of generating those results elsewhere, as they occur in different execution environments. Measuring the former can reflect the real constraints faced by applications that would otherwise have to perform verification on the mainnet. When deciding whether to provide this feature, the latter cost also needs to be taken into account. It is also necessary to know whether this check can still be completed under high loads, when many requests compete for the same capacity.

Gnosis It is necessary to have a transition period for existing applications.

GnosisDAO successfully obtained authorization through GIP on August 153 to migrate its independent network to EEZ rollup. The importance of this migration lies in the fact that existing users and applications have balances, addresses, and dependencies bound to the current chain. For them, adopting new execution and settlement arrangements means making changes to the infrastructure they are already using.

The questions that need to be answered in real-world applications are different from those encountered in development environments on the internet. Users need to know how to migrate their balances, which wallets and infrastructure providers support migration, and how to obtain reliable transaction records during the transition period. Trading platforms, on the other hand, need to consider integrating features that may only become available at different times.

A rollup that can connect to the mainnet market might be able to provide a trading path before establishing deep pools for each pair of assets. However, this is not the case for chains that already have mature liquidity. For such chains, users can choose between executing applications locally or sharing paths, and the existing liquidity providers on the chain can also see how these choices affect the activity in their pools.

The migration will also test the difference between “launching a network” and “setting a certain feature as the user’s default option.” The first block can prove that the new chain is already running; the default user path, however, requires wallets, applications, and other services to use this new path in their daily activities. Previous reports mentioned that the initial deployment was targeted for the beginning of the year. Gnosis The goal set in the November update was to set it as the default by the spring of 2027.

Gnosis provides developers with a platform to raise these issues within the deployment environment of existing applications. Migration will align the execution, wallet support, and operational processes under the same timeline, allowing for observation of how the team handles any delays or partial integrations. The update in November set spring 2027 as the target date for making this design the default. The operations mentioned in Devcon take place on Rollup X.

Content worth noting

• Supported paths: Which networks can be used for the same operations announced by wallets and applications.
• Execution Quotation: Is it possible to compare the net output and failure order rates between local transactions and cross-network transactions?
• slot Performance: Repeated tests have proven its usability, as well as its recovery capability during Ethereum reorganizations.
• Treasury Permissions: Whether the integration scope, expiration, and revocation rules of Safe are made public.
• Gnosis Milestone: Public migration testing and progress towards the goal of spring 2027.

Frequently Asked Questions

What is Rollup X?

It is the development network used by Ethereum Economic Zone in the demonstration. Devcon uses it to test operations involving the Ethereum mainnet and another execution environment.

How does this swap work?

rollup A user placed an order CoW Swap that utilized liquidity from the Ethereum mainnet, and the purchased tokens were subsequently returned to rollup. The solver used the mainnet liquidity and sent the resulting assets back to rollup during the coordinated operation.

What is atomic execution?

The operations must either all succeed or all roll back together. This design is intended to prevent users from obtaining incomplete results on another network after one step has been completed.

How does the internet fit into this design?

Gnosis indicates that the network must prove its status within a Ethereum slot, and it must follow Ethereum during Ethereum's reorganization. The application also requires wallet support, as well as the specific assets or permission paths that it intends to use.

Why use a solver?

The solver will search for and execute paths for signed orders. It can find liquidity and assemble paths under the constraints of user signatures. However, execution still depends on whether there are available quotes.

What does Safe demonstrate?

The connected rollup allows for the verification of ownership changes on the mainnet within a single transaction. Cross-chain treasury access also depends on how the application reads and updates who has the authority to act.

What is 91% of the gas numbers for?

The team used it for the Falcon signature verification demonstration. This comparison only covers the signature verification examples and does not correspond to the same percentage of transactions or treasury operations.

Gnosis When is the plan to use this design?

Gnosis has set the spring of 2027 as a goal to be enabled by default on Gnosis Chain. This goal is aimed at the changes related to Gnosis Chain. Rollup X is the development environment used for demonstrations. This is an educational analysis and does not constitute investment advice.