THORChain’s Router v6: A Stateless Step Forward for Cross-Chain Liquidity

Most THORChain users never think about the Router. Yet every swap, deposit, and outbound transaction on Ethereum, BNB Chain, and other EVM chains passes through it first.

The Router is the gateway between THORChain and the EVM world. It receives assets, reads user intent through memos, and emits the signals that THORChain’s network uses to execute swaps, liquidity provision, and redemptions.

With Router v6, THORChain has quietly upgraded this gateway in a major way. The Router is no longer a custodial component that temporarily holds user funds. It is now a stateless forwarding and signalling contract. This single architectural shift removes an entire layer of risk from THORChain’s EVM stack while making the system easier to upgrade, easier to integrate, and more resilient at scale.

This is not a flashy upgrade. But it fundamentally strengthens the backbone of THORChain’s cross-chain operations.

1️⃣ Under the Hood: Router V6

🔹What the Router Does and Why v6 Matters

On non-EVM chains like Bitcoin, THORChain operates directly with vaults that hold real assets. On EVM chains, things work differently. Users send assets to a Router contract along with a memo that describes what they want to do. THORChain’s Bifrost system watches for those Router events and relays the instructions into the network.

In practice, this means the Router is the single entry and exit point for THORChain on every EVM chain. If the Router is clunky, risky, or hard to upgrade, that friction propagates across the entire ecosystem.

Earlier Router versions were designed at a time when the ecosystem was smaller, integrations were simpler, and aggregation was limited. As THORChain has grown into a core piece of cross-chain infrastructure, the Router needed to evolve from a functional gateway into hardened settlement plumbing.

That is exactly what Router v6 delivers.

🔹The Shift From Stateful to Stateless

The most important change in Router v6 is the move from a stateful design to a stateless one.

In earlier versions, when a user deposited ERC-20 tokens, those tokens were first held inside the Router itself. Internally, the Router kept a private accounting system that tracked how much each vault was entitled to withdraw later. When outbounds were executed, vaults would instruct the Router to release tokens based on this internal bookkeeping.

From a user perspective, this mostly worked. From an architectural perspective, it created a hidden risk concentration. The Router was:

• Holding real user funds
• Maintaining internal balances
• Acting as an extra custodial layer between users and vaults

Router v6 removes this entire pattern.

Now, when a user deposits tokens, they are forwarded directly to the vault in the same transaction. The Router never holds a meaningful balance. It does not maintain any internal accounting. Vault balances are determined purely by checking the vault’s real on-chain token balances.

In simple terms, the Router is no longer a “wallet”. It is a pipe.

This change dramatically reduces the attack surface, eliminates risky balance migrations during upgrades, and aligns how EVM chains work with how THORChain already operates on native chains like Bitcoin.

🔹Cleaner Deposits, Better Outbounds, and Smarter Aggregation

Older Routers required every deposit to include an expiry timestamp. If a transaction landed after that deadline, it would be rejected and pushed into the refund system. This made sense when internal balances had to be protected, but over time it introduced unnecessary failure cases.

Late blocks, delayed transactions, and automated systems could all trigger failed deposits even when users did nothing wrong.

Router v6 makes expiry optional. Users and applications can now set expiry to zero, meaning the deposit should simply be processed whenever it arrives. This removes a category of avoidable failures and makes THORChain far more reliable for smart contract wallets, automated trading systems or aggregators.

It is a “small” rooting change with a large impact on reliability.

🔹Better Outbounds Through Mixed Batching

THORChain processes large numbers of outbound transactions every day. Batching allows multiple payouts to be executed together, reducing gas costs and improving throughput.

Router v5 introduced batching for ERC-20 tokens, but ETH still required separate handling. Router v6 extends batching to support mixed outputs. ETH and ERC-20 tokens can now be sent together in the same execution flow.

For users, this improves settlement efficiency. For integrators, it reduces gas overhead. For the network, it improves outbound scalability.

Again, this is not a visible feature, but it directly improves performance under load.

🔹Stronger and Safer DEX Aggregation

DEX aggregation has become a core extension of THORChain’s role as a cross-chain liquidity hub. Many routes now involve moving from THORChain into an external DEX as part of a single user flow.

Router v6 significantly upgrades this integration layer. The updated transferOutAndCallV2 function provides clear tracking of input amounts, more expressive payloads for aggregator instructions, improved failure signalling and cleaner refund handling when downstream DEX calls fail

Previously, failed DEX calls could be difficult to diagnose and recover cleanly. With Router v6, these paths become deterministic and auditable. This is a critical improvement as THORChain increasingly acts as the settlement layer beneath more complex multi-hop trading flows.

2️⃣ What Users and Integrators Gain

For users, the impact of Router v6 is subtle but important. Deposits become more reliable because expiry is no longer forced, which means fewer transactions fail simply because of timing issues. Since the Router no longer holds assets, vaults also deal with fewer edge cases during processing and refunds. For users moving through aggregated routes that extend beyond THORChain into external DEXs, execution becomes more predictable and easier to trace when something goes wrong. The result is a smoother experience with fewer silent failures along the way.

For integrators, the benefits are even more pronounced. With the Router now operating in a stateless way, it becomes safer to rely on, simpler to audit, and far easier to integrate into complex systems like smart contract wallets or automated trading infrastructure. The removal of private allowance tracking shortens code paths and makes the system’s behaviour easier to reason about under stress. Mixed batching improves efficiency for platforms that process large numbers of redemptions at once, while the expanded aggregation interface enables more sophisticated and resilient routing strategies. Together, these changes turn the Router from a specialised access point into reliable, composable infrastructure.

3️⃣ Conclusion

Router v6 is a foundational improvement to THORChain’s EVM architecture. By eliminating custodial state, simplifying deposits, improving batching, and strengthening aggregator support, it modernises a component that sits at the very centre of THORChain’s cross-chain operations.

The upgrade is not flashy, but its impact is structural. It improves reliability, reduces risk across the entire network, and removes a layer of friction that users never should have had to think about in the first place.

It also prepares THORChain for better user experiences in the future, especially as the protocol continues to evolve into a universal settlement layer for cross chain liquidity.