The End of Bridging: How Tychi Routes Actions, Not Liquidity

Every cross-chain action today starts with a tax: a bridge step. The user has value on chain A. They want to act on chain B. Before they can act, they have to move the value. Wait for confirmations. Pay native gas on the destination. Then act. Two transactions to do one thing.

That tax has been the dominant model for so long that most users no longer notice it. Tychi exists because we think the model is wrong.

What "route the action, not the liquidity" actually means

The phrase is the shortest summary of the Universal Gas Framework: when a user wants to do something on a different chain, the action moves, not the value. The user's USDC stays on Base. The action executes on Solana. UGF settles the difference using its own reserves on the destination chain.

This is structurally different from a bridge. A bridge has to physically move tokens across chains via lock-and-mint, burn-and-release, or similar mechanisms. The user's funds are in transit. The user pays the bridge fee, the slippage, the wait time.

UGF doesn't move the user's funds at all. It moves settlement in the destination chain's reserve. The user's value stays put.

Why the distinction matters

Three reasons.

Latency. A bridge takes minutes. A remote transaction takes seconds. The difference matters most when the destination chain has time-sensitive opportunities — arbitrage, liquidations, fast-moving NFT mints.

Failure modes. When a bridge fails, the user's funds are stuck in transit. Recovery often requires manual support and can take days. When a remote transaction fails, the destination action reverts and the source-chain payment is refunded. Same chain, same wallet, same minute.

Cognitive load. The bridge model forces the user to think about chains. They have to plan the bridge step, watch it, decide which chain holds what. The remote-transaction model lets them think about intent — "swap into SOL", not "bridge to Solana then swap on Jupiter".

How UGF makes it possible

Three pieces of infrastructure, working together.

A vault on each source chain. The user pays USDC into the vault. The vault accumulates assets that match what the destination relayers need to execute against.

A relayer on each destination chain. Holds a reserve of native gas. When a payment is confirmed on the source chain, the relayer is authorized to execute the user's signed transaction using that reserve.

A correlation layer (the gateway). Watches source chains for payments. Validates quotes haven't expired. Signals the destination relayer to proceed. If anything fails, it triggers refunds.

The user sees none of this. They sign a quote, pay USDC, and the destination action lands. From their perspective: one click, one outcome.

What this unlocks

A few flows that go from awkward to trivial:

• Apps don't need cross-chain liquidity pools. A DeFi app on Base no longer needs Solana liquidity to serve Solana users. UGF provides the cross-chain leg.
• Users don't need native tokens on every chain. Holding 0.01 ETH on five different L2s is no longer the price of admission.
• AI agents move freely between EVM and non-EVM. A single USDC balance funds activity across twelve chains. Agents stop being walled off by chain family.
• Onboarding stops failing on gas errors. New users land USDC via an onramp and immediately do useful things.

What UGF is not

We are deliberate about what we're not building.

We are not a bridge. Bridges have a place. We are not trying to replace them for use cases that genuinely need value movement.

We are not a paymaster. Paymasters are an ERC-4337 primitive that sponsor gas on a per-chain basis. They require chain-specific deployments and bundler infrastructure. UGF works differently — see Moving Beyond Paymasters for the comparison.

We are not a smart-wallet migration project. UGF works with existing EOAs. Users do not need to migrate to a new wallet model. The integration cost stays low.

We are not a custodian. The user's keys remain with the user. UGF only ever holds destination-chain reserves, not the user's primary funds.

Where this leaves bridges

Bridges still matter for cases where value genuinely needs to move — long-term holdings shifting chains, large LP relocations, pure capital movements. For those, use a bridge.

For the case that dominates most users' day-to-day — "I have USDC, I want to do something" — the bridge step is the friction we are removing. Routing the action directly is faster, safer, and dramatically simpler than moving the liquidity first.

That is what ugf.execute() does. Once you see it work, the question is no longer "how do I bridge for this action" but "why was I bridging in the first place."