ugf.execute(): One Call, Every Chain

Every wallet integration we have ever shipped started with the same complaint from users: I have value on one chain, and I need an action on another. The traditional fix is a bridge. Bridges have improved over the years, but they all share the same flaw — they move the value before the action can start. The Universal Gas Framework takes a different approach: route the action directly, while the value stays where it is.

This post walks through what that looks like in code.

The shape of the call

import { UGFClient } from "@tychilabs/ugf-sdk";

const client = new UGFClient({
  baseUrl: "https://gateway.universalgasframework.com",
});

await client.auth.login(wallet);

const quote = await client.quote.get({
  payment_coin: "USDC",
  payment_chain: "8453",        // Base
  dest_chain_id: "56",          // BNB Chain
});

await client.payment.x402.execute({ quote, signer: wallet, token: "USDC" });

Five lines after the import. Source value lives on Base. The action lands on BNB Chain. The user pays in USDC and never holds BNB native gas.

What each step actually does

Authenticate. client.auth.login issues a session against the user's signer. UGF does not custody keys. The session exists so the relayer can correlate payments with quotes.

Quote. The SDK asks the gateway for a quote. The quote is a signed object that pins the payment side and the destination side together. It expires. The user sees the price upfront.

Pay. client.payment.x402.execute settles the payment leg via the x402 protocol — Coinbase's revival of HTTP 402 as a stablecoin payment standard. No bundler, no paymaster, no on-chain account abstraction migration.

Land. UGF relayers detect the payment, then execute the user's signed transaction on the destination chain. From the user's perspective: one click, one signature, two outcomes.

What the SDK is hiding

The five lines above hide three pieces of infrastructure:

• A vault on the source chain. USDC the user pays goes here, and it stays here. The destination chain is fueled by a Tychi-operated reserve, not by the user moving funds.
• A relayer per destination chain family. Different families need different execution paths. EVM destinations use client.chains.evm.execute. Solana uses client.chains.sol.sponsorCustomTx. Sui uses client.chains.sui.execute. The SDK abstracts the difference, but the chain-specific code is real and necessary.
• A correlation layer. The gateway watches for the payment, ties it to the quote, releases the relayer to execute. If anything fails — the quote expired, the user paid the wrong amount, the destination reverted — the system has to recover gracefully without the user paying twice.

When you should use it

UGF is best when the user already has stablecoin liquidity somewhere and needs to take an action somewhere else. Concrete examples:

• A DEX user on Base swapping into a token only listed on Solana.
• A cross-chain NFT mint where the collection lives on Polygon but the user has assets on Arbitrum.
• An AI agent executing across multiple chains from a single USDC balance.

It is not the right tool for: pure token bridging without an action, single-chain dApps with no cross-chain story, or workflows that demand atomic two-leg execution with on-chain rollback. Those need different primitives.

Where to start

If you want to integrate, the path is short:

npm install @tychilabs/ugf-sdk

Read the docs, grab a testnet API key, and run the quickstart. The full method surface — quotes, payment routing, EVM and non-EVM execution — is documented with TypeScript types.

If something breaks during integration, tell us. Half the work of an SDK is making the failure modes survivable, and we improve those by hearing about the cases we missed.

The line we keep coming back to: route the action, not the liquidity. ugf.execute() is what that means in code.