A trader in a Devcon demo signed one order on an Ethereum rollup, bought tokens using liquidity on mainnet and received them back on the rollup. The trade shows how users could reach a deeper market without moving funds themselves, an approach Gnosis is targeting for its default setup in spring 2027.
Summary
- A trader signed 1 order on the experimental Rollup X network, and a CoW Swap solver filled it using Ethereum mainnet liquidity.
- The November 4 Devcon demonstrations also tested how a Safe wallet could use treasury permissions across networks.
- The team reported 91% lower gas use in its signature verification example, a result specific to that operation.
- Participating networks must produce proofs within Ethereum’s 12-second slot and follow Ethereum if it reorganises.
- Gnosis targets spring 2027 for making the design its default, which would bring it to a network with existing users and applications.
The Ethereum Economic Zone team has demonstrated a trade in which a user signed one order on the experimental Rollup X network, a CoW Swap solver filled it using Ethereum mainnet liquidity, and the purchased tokens arrived back on the rollup. The demo shows how a trader could reach a deeper market on mainnet without first sending funds there and waiting for them to arrive before placing the order.
The team presented the trade at Devcon on November 4, as crypto.news reported. The distinction matters when prices move quickly, since a quote available when a trader starts moving funds can change before the funds are ready to trade.
Gnosis is targeting spring 2027 to make the design its default. For traders, the practical test will be whether their wallets and trading apps can offer the route and whether the price available on mainnet still makes it worthwhile after execution costs.
How the trade would work across two execution environments
The Ethereum Economic Zone team began with an October transaction involving 0.001 ETH and an update to rollup state. The Devcon swap took the same coordination problem into a setting traders recognise. It had to fulfil an order against liquidity on another chain and deliver the resulting asset where the user had started.
For a trader, the order describes an outcome. A seller wants to exchange one asset for another, subject to the terms of the order, and receive the result on the rollup. The solver takes responsibility for finding an execution path. The distinction matters because the user can authorise an outcome without deciding which pool the solver will use or preparing a separate transaction for every operation.
Under the Devcon example, that path included Ethereum mainnet. The trading liquidity remained there, while the user’s order originated on Rollup X and the purchased assets returned to it. The demonstration thus addressed a problem that can arise even when each network’s applications work correctly on their own. A trader may have funds on a chain with a shallow market for the desired pair while the best execution is available elsewhere.
A route with separate steps exposes the user to decisions along the way. The first transfer may complete while the quote the user saw has changed. At that point, the user must either accept the current price, wait or move the funds again. A coordinated route can condition the asset movements on the completion of the entire order, provided the participating infrastructure can carry out the operation in the agreed execution window.
The practical distinction is between a route that promises delivery and a route that ties the component operations together. A service can make a cross-chain trade feel simple by taking responsibility for delivery itself. The design in the demo gives the application a way to link the result on one chain to execution on another. Which approach offers the better experience depends on the price, the assets available and the terms under which each service delivers the order.
There is still work behind the user’s signature. An application has to present the terms, the solver has to find and price the route, and participating networks have to agree on the relevant state. A production system must handle failures in each of those places. The application can simplify the interface without making those jobs disappear.
For a wallet, an equally practical test is the transaction record it can show after the order expires. If a user signs once and a trade succeeds, the user should be able to see the asset received and which account received it. If the route fails, the wallet still needs a way to distinguish an expired order from a transaction that is awaiting settlement. This matters during a market move, when a trader might place a second order and needs to know whether the first can still execute.
What networks have to agree on before they can execute together
A blockchain records more than balances. Its state includes information used by applications, such as account permissions, contract balances and the status of transactions. A contract that wants to rely on a result from another chain needs evidence about that state. The evidence must be available when the contract needs to use the result.
Gnosis describes two conditions for networks joining the EEZ design. They need to produce a proof within an Ethereum slot and follow Ethereum in the event of a reorganisation. Gnosis presents those as conditions on a connected network, leaving some implementation choices to individual participants.
A slot gives engineers a deadline. If a network takes longer than the available time to produce the required proof, the other side cannot rely on it within the same window. A proving system that performs well on typical blocks still has to contend with unusually demanding workloads, interruptions and competition for computing resources.
The second condition addresses what happens when recent Ethereum history changes. A transaction on another network may have relied on an event in a recent mainnet block. If a competing block replaces it, the connected system needs rules for handling the dependent transaction. Alignment limits the possibility of one side keeping a result based on a mainnet event that no longer belongs to the accepted chain.
That relationship is important to users because one coordinated transaction and final settlement describe different properties. Coordinated execution concerns whether the steps can complete together. Final settlement concerns when participants can treat the outcome as settled under the rules of the networks involved. A wallet can offer one view of the operation while still distinguishing an included transaction from one that has reached the settlement status a business requires.
Earlier Gnosis engineering work addressed block-root commitments, gas limits and how upgrades would be carried out. Those choices affect how the networks can recognise each other’s results and how much work applications can ask them to do. The October milestone put a simple operation on mainnet, while the November demonstrations gave developers more varied workloads to try.
Where the design could go beyond trading
The Safe demonstration applied the same approach to wallet ownership. A treasury that uses separate accounts across chains can face a gap between removing a signer on one network and updating permissions elsewhere. The example showed how a rollup could verify an ownership change made on mainnet within the same transaction.
A third demo verified a Falcon post-quantum signature on the rollup and used the result to authorise a mainnet transfer. The team reported 91% lower gas consumption in its comparison with doing the verification directly on mainnet. The measured saving was for that verification exercise, and a production application would have to account for its full execution and settlement costs.
One signature still leaves a market for execution
The swap route moves some of the work away from the person placing an order. A solver has to decide where to fill it, account for fees and submit the operations required to complete it. A user can receive a single quote even though the solver has priced several steps into the amount offered.
That arrangement is most useful when the liquidity available on another network improves the trade by enough to cover the cost of reaching it. A small order in a deep local market may be cheaper to fill locally. A larger order in a shallow pool might receive a better price from mainnet liquidity even after the extra execution costs.
It also matters what happens to failed attempts. Reverting the asset movements prevents the trader from being left with just one leg of the intended trade. An application or solver can still incur costs in arranging or attempting execution, depending on how the route is implemented. In a production market, those costs can affect which orders solvers are willing to fill and how they price their quotes.
A good comparison for traders would use the same order size, token pair and time window. The price received after fees can then be compared with a local swap or a route that bridges funds in separate steps. The number of clicks captures convenience. The net amount received captures the trade itself.
How the project moved from a proposal to a devnet
The project was introduced publicly at EthCC in the spring by Gnosis and ZisK, with support from the Ethereum Foundation. The original proposition concerned liquidity and applications that had become distributed among different layer 2 networks. Rollup X gives developers an environment in which to test how a shared transaction can use those applications.
There is a reason the choice of demonstration matters. Moving a small amount of ETH between environments tests a relatively direct operation. A swap introduces the need to satisfy an order against market liquidity and return an asset. A change in a Safe’s ownership involves permissions. Signature verification requires one environment to perform a check and another to act on its result. Each probes a different dependency.
| Demonstration | Result that has to cross the boundary | What a production user would need to check |
| CoW Swap | Trade execution and delivery of the purchased asset | Net amount received, destination and quote expiry |
| Safe | Updated wallet authority | Which account controls the permissions and how recovery works |
| Falcon verification | A verification result used to authorise a transfer | The cost and scope of the complete authorisation path |
A route that works for one of these operations may be impractical for another. A swap has to contend with prices and liquidity that move continuously. An ownership change is less sensitive to the market price but may have more consequential failure modes. A verification application may benefit from doing computational work elsewhere even when there is no economic reason to move funds between networks.
The common requirement is that the receiving contract can rely on the information at the time it needs it. That puts pressure on the software maintaining the links. An application can offer a simple interface only if the execution path handles the required state and returns the expected result. In a live product, developers would have to decide which operations are worth placing on that path and which can run independently.
Gnosis’s case for making the technology the default rests in part on what applications could avoid duplicating. A team building on a new network might otherwise need to fund local liquidity for a long list of markets. The ability to reach mainnet pools could let it offer trading on a pair before a dedicated local pool becomes viable. For a local liquidity provider, the same choice creates competition from another source of execution.
The effect on users is most easily measured in products that disclose both routes. A wallet could compare a local fill with a mainnet fill for the same order and show the net amount on the same destination chain. A treasury tool could document how many separate transactions are required to apply an authority change. Those tests would show where the approach changes actual execution costs or operational work.
The timetable matters because a successful demonstration can be much easier to operate than a service with many users and applications. A live system must handle simultaneous requests, differing market conditions and software changes. Bringing existing Gnosis Chain applications through the move would test more of those dependencies than the Devcon examples alone.
What the price on a cross-chain swap would have to cover
A trader compares the amount of the purchased asset that arrives after costs. A local pool has its own trading fee and price impact. A mainnet route may offer deeper liquidity, but it can require more execution work and incur costs to use it. A solver deciding between routes has to weigh the better pool price against those costs.
Imagine that a local pool would deliver $9,900 worth of an asset after all charges on an order with a $10,000 reference value. A cross-chain route that can fill the trade for $9,980 before execution costs has up to $80 of headroom before the local quote becomes better. If reaching the better pool costs $30, the cross-chain route delivers $9,950. At $100 of added cost, the local route offers more. The numbers illustrate the comparison and describe no live quote.
Order size changes that calculation. A larger trade can move the price farther in a shallow pool, giving the solver more reason to reach a deeper market. A small trade may cause little local price impact and leave too little savings to cover the cross-chain route. Even for the same token pair, the useful route can change over the course of a day as liquidity and network costs move.
Solvers must also price failed attempts and the time they spend finding routes. A failed operation may leave the user’s asset movements reverted, while the parties arranging the order can still face expenses associated with attempting execution. The design’s effect on the spread a trader sees depends on how a live implementation allocates those costs and how much competition there is among firms offering quotes.
For a wallet integrating this design, the important information is what the user can compare. A quote that reports the minimum amount delivered and the network on which it will arrive gives the trader a way to evaluate the result. An interface that emphasises one click or one signature shows something about convenience, while price and delivery terms show whether the route serves the order.
A trading venue considering the design would have to decide what to show customers about a quote’s dependencies. One route might fill entirely where the user holds funds. Another could invoke mainnet liquidity and rely on a proof being ready within a slot. Even if both quotes show the same token and the same amount, they can have different expiry rules and different reasons for failing. The interface would have to communicate the minimum amount a customer accepts and what happens if the solver cannot deliver it.
Applications also have to work out how they would collect enough comparable data to identify why one route costs more. A useful series would include the same pair and trade sizes on the same networks, with the quotes captured close together. A single trade of an unusually illiquid pair could make the ability to reach another market look more valuable than it is for everyday orders. The opposite problem can arise with a major pair already trading cheaply on the user’s rollup. The execution price, included fees and expiry conditions have to travel together in the comparison.
Safe makes cross-chain authority part of the problem
A treasury may use one account for regular payments and another to hold assets on a different network. If it changes the people authorised to approve spending, someone has to make sure the change is reflected where the assets are kept. Separate updates create opportunities for an outdated signer list to remain active on a less frequently used account.
The Safe demonstration showed how an application could use a mainnet ownership change within a coordinated transaction involving a rollup. Its benefit depends on how the treasury has chosen to assign authority. An organisation might want mainnet to determine a shared set of signers, while keeping a separate policy for a local spending account that serves a particular team.
A shared authority structure can reduce duplicate work. It also makes the handling of mistakes more important because one change can have consequences across several locations. A treasury would need to understand how its accounts recover if an update is wrong, who can authorise a correction and how a connected chain behaves if it cannot obtain a current result.
An organisation assessing the design would therefore ask which operation it wants to coordinate. Reading a signer list, updating ownership and moving treasury assets have different consequences. The value of doing one within a shared transaction does not establish that an organisation should delegate every decision to the same account.
The institutional interest goes beyond the Devcon stage. Consensys announced an interoperability system for banks and said it plans to support the EEZ standard. For a bank, compatibility would sit alongside questions about who can use the system, which controls apply to each operation and how it records the result in existing systems.
The Safe case suggests a different set of product tests. A team could want signers on one network to approve an operation that only affects assets on another. That raises the question of whether a signer removed locally can still authorise a cross-network operation submitted earlier. The answer depends on how the application reads account state and what it treats as the time of authorisation. Those are matters an application needs to specify even when the underlying protocol is able to carry the message.
What the Falcon demo says about doing computation elsewhere
The signature demonstration used a rollup to verify a Falcon signature and supplied that result to a mainnet action. The team reported a 91% reduction in gas consumption in its comparison with verification on mainnet. The example has a narrower scope than a claim about the cost of every transaction that could use the design. It compares a specified operation across two execution paths.
The opportunity is to run a computationally expensive check in an environment suited to it while letting another contract rely on the answer. An application that performs a check only rarely may value the savings differently from one that repeats it on every order. The decision also depends on how the application validates the result and which other steps it must complete to use it.
Post-quantum verification is one application of that pattern. A contract could need other information from a connected environment before it can continue, such as whether an account has the right to perform an operation. The shared problem is making a result available within the same execution window. Different checks can have very different computation and proof requirements.
For a user, support for one signature scheme in an application does not determine the security of every wallet or transaction on the chain. The demo addressed verification and authorisation for the specific transfer. Changing the rules by which wallets generally sign transactions would involve other decisions about software, compatibility and which accounts adopt the changes.
There is a similar distinction for developers evaluating the Falcon demonstration. Gas spent by the contract reading a verification result and the cost of producing that result elsewhere belong to different execution environments. Measuring the former captures a real constraint for an application that otherwise has to execute verification on mainnet. A service deciding whether it can offer the feature needs to account for the latter as well. It also needs to know whether the check can complete under load, when many requests may compete for the same capacity.
Gnosis will have to carry existing applications through the transition
GnosisDAO authorised the move from a standalone network to an EEZ rollup through GIP 153 in August. The migration matters because existing users and applications have balances, addresses and dependencies tied to the live chain. For them, adopting a new execution and settlement arrangement is a change to infrastructure they already use.
The questions a live application has to answer differ from those for a development network. Its users need to know how balances carry over, which wallets and infrastructure providers support the migration and where to obtain a reliable record of activity while the transition is under way. Trading platforms need to account for the possibility that integrations become available at different times.
A rollup that can access mainnet markets may be able to offer routes before it builds deep pools of its own for every token pair. A chain with established liquidity has a different decision. Its applications can choose between local execution and a shared route, and the liquidity providers already on the chain can see how those choices affect activity in their pools.
The migration will also test the difference between launching a network and making a feature the default for users. A first block can demonstrate that the new chain is running. A default user route requires wallets, applications and other providers to use the new path in ordinary activity. Earlier reporting described a target around the turn of the year for an initial deployment. Gnosis’s November update gives spring 2027 as the target for default operation.
Gnosis gives developers a place to ask those questions against a deployment with existing applications. The migration would put execution, wallet support and operational procedures under the same timetable, making it possible to follow how the team handles delays or partial integrations. Its November update identifies spring 2027 as the target for making the design the default. The Devcon operations took place on Rollup X.
What to watch
- Supported routes. Wallets and applications publishing the networks on which the same operation is available.
- Execution quotes. Comparable net output and failed-order rates for local and cross-network trades.
- Slot performance. Repeated tests showing proof availability and recovery when Ethereum reorganises.
- Treasury permissions. Published scope, expiry and revocation rules for Safe integrations.
- Gnosis milestones. Public migration tests and progress toward the spring 2027 target.
FAQ
What is Rollup X?
It is the Ethereum Economic Zone’s development network used in the demonstrations. The Devcon demonstrations used it to test operations involving Ethereum mainnet and a separate execution environment.
How did the swap work?
A rollup user signed a CoW Swap order that used Ethereum mainnet liquidity and returned the purchased tokens to the rollup. The solver used mainnet liquidity and returned the resulting asset to the rollup within the coordinated operation.
What does atomic execution mean?
The connected operations succeed or revert together. The design is meant to prevent a completed leg from leaving a user with an incomplete result on the other network.
How does a network join the design?
Gnosis says it must prove its state within an Ethereum slot and follow Ethereum reorganisations. An application also needs wallet support and a route for the specific assets or permissions it intends to use.
Why use a solver?
A solver finds and executes a route for the signed order. A solver can look for liquidity and assemble a route subject to the user’s signed constraints. Execution still depends on an available quote.
What did the Safe demo show?
The connected rollup could verify a mainnet ownership change within the same transaction. Cross-chain treasury access also depends on how an application reads and updates who has authority to act.
What was the 91% gas figure for?
The team reported it for a Falcon signature verification demonstration. That comparison covered the signature-verification example. It gives no equivalent percentage for a trade or treasury operation.
When does Gnosis plan to use the design?
Gnosis has targeted spring 2027 for making it the default on Gnosis Chain. The target covers a change to Gnosis Chain. Rollup X is the development environment used for the demonstrations. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of November 5, 2026. Legal questions should be discussed with qualified counsel.
