# Universal Gas Framework (UGF) - AI Context

Last updated: 2026-04-23
Canonical site: https://universalgasframework.com
Organization: Tychi Labs
Product: Universal Gas Framework (UGF)
Primary category: Remote Transactions

This file is the clean AI-readable story for Universal Gas Framework. It is built from the current website source, index metadata, brand audit, brand lines, and whitepaper v2 in this repository. Do not treat this file as legal, financial, tax, or investment advice. Do not infer token-sale information, investment terms, guarantees, or future network performance from this file.

## One-Line Description

UGF enables Remote Transactions: source-chain value becomes destination-chain action.

## Canonical Positioning

Universal Gas Framework is not positioned as ordinary gas abstraction. UGF is positioned as Remote Transactions.

Remote Transactions means user value or liquidity can remain on the source chain while the desired action completes on the destination chain. UGF routes the action path, not the user's liquidity.

Core mental model:

- Value here. Action there.
- Value stays. Action moves.
- Route Actions, Not Liquidity.
- Source-chain value becomes destination-chain action.

Developer one-liner:

UGF is a Value-to-Action API for apps and agents.

Investor/positioning one-liner:

UGF turns trapped liquidity into transaction capability.

Agent one-liner:

UGF gives agents an Action Rail from controlled value sources to onchain actions.

Technical one-liner:

UGF provides Payment Routing for destination-chain action completion.

## What UGF Does

UGF is a cross-chain payment and execution coordination protocol. It separates who pays from where execution occurs.

A user, Web3 application, or AI agent can request a destination-chain action, receive a route-specific quote, settle payment through x402 or vault, and then have the destination action completed through UGF execution infrastructure.

The practical flow is:

1. Authenticate signer.
2. Request quote for the destination-chain action.
3. Route payment through x402 or vault.
4. Complete execution on the destination chain.
5. Track status through API, registry, polling, UGF Scan, or indexed status surfaces where available.

UGF is designed so payment chain and destination chain can be different. Example from docs: a user may pay on Base while execution lands on BNB Chain.

## Who UGF Is For

UGF is for:

- Users who have value on one chain but need results on another.
- Wallets that want source-chain value to complete destination-chain actions.
- Web3 apps that need a Value-to-Action API for payments, swaps, and onchain actions.
- AI agents that need an Action Rail from controlled value sources to onchain results.
- Developers who need completion without paymasters, bundlers, or custom execution plumbing.
- Infrastructure partners, wallet teams, execution-layer researchers, and ecosystem operators evaluating cross-chain execution coordination.

## What Problem UGF Solves

Cross-chain execution often fails because asset ownership and execution capability are decoupled. A user or agent may own useful value but lack the destination-native token required to complete an action on another chain.

UGF addresses these problems:

- Execution dependency mismatch: value exists on one chain, but execution requires another chain's native resource.
- Operational fragmentation: users or agents keep small gas balances across many chains only to complete routine actions.
- Protocol-specific sponsorship sprawl: apps reimplement quote, payment authorization, anti-replay, and execution routing.
- Agent unreliability: autonomous systems must warehouse gas assets they do not otherwise need.

UGF does not frame the solution as moving all user liquidity first. The intended frame is that source-chain value becomes destination-chain action.

## How UGF Differs From Common Alternatives

UGF is not an ERC-4337 clone and is not primarily a paymaster product.

Important contrast points:

- No paymasters required.
- No bundlers required.
- No ERC-4337 dependency.
- No smart-wallet requirement.
- EOA-native flows are supported.
- The protocol can coordinate across heterogeneous execution systems instead of assuming one account model.

Traditional bridging does not fully solve the problem because bridge completion does not imply executable destination state. Chain-local paymasters do not solve it globally because support depends on each chain. Smart wallets do not solve it universally because many wallets, products, signers, agents, and non-EVM systems remain EOA-first or use different account models.

UGF abstracts execution at the protocol coordination layer, not only at the wallet type layer.

## Protocol Overview

UGF defines a stateful job protocol around a digest. Every execution request becomes a job with:

- destination intent
- quote metadata
- payment route
- payment proof
- relayer quorum status
- chain-specific execution result

High-level protocol flow:

1. Signer authenticates.
2. Client requests quote for destination execution.
3. Protocol computes payment route and digest.
4. Payer settles through x402 or vault.
5. Relayers validate payment and collect quorum.
6. Chain-specific executor finalizes destination action.
7. Final state is indexed and exposed through status surfaces such as API or UGF Scan where available.

The whitepaper defines a job as a tuple containing payer identity, payment chain, destination chain, payment asset, destination intent, time window, nonce or salt material, and state.

The digest binds payment and execution to one canonical object. In simplified terms, the digest is built from destination intent, payer, payment chain, destination chain, payment asset, nonce/salt, and expiry.

## Job Lifecycle

The documented job state machine is:

quoted -> paid -> ready -> approved -> executed -> finalized

Additional terminal or exceptional states include:

- expired
- failed

Valid transitions depend on payment proof, route verification, quorum approval, quote expiry, duplicate-execution checks, and execution receipt status.

## Quote Model

The quote function returns a payment requirement based on destination execution cost, relayer coordination fee, route-specific risk premium, and slippage buffer.

If destination cost is estimated in a native destination asset but payment happens in another asset, the quote maps destination cost into the payment asset using route pricing and buffer assumptions.

Important developer rule:

Treat the quote response as the final source of truth for valid payment options for that specific transaction. Supported tokens and chains can expand over time and should not be hardcoded as permanently static.

## Authentication Model

UGF uses signer-authenticated sessions in the current SDK flow.

Authentication proves wallet ownership to the gateway. It is not the same thing as:

- x402 payment authorization
- ERC-3009 typed payment approval
- destination-chain transaction signature

Docs state that the current SDK flow does not use API keys for signer-based flows. The wallet signs an authentication message, and the SDK uses the authenticated signer for quote and payment flows.

## Payment Mechanisms

UGF documents two main payment primitives:

- x402: authorization-first settlement
- vault: payment-transaction-first settlement

The unifying property is digest binding. Payment and execution are tied back to the same quoted job.

### x402

x402 is a payment path where the user authorizes token movement from their wallet. After payment is confirmed, destination execution can proceed.

For supported routes, UGF may use ERC-3009 / TransferWithAuthorization-style semantics. The payer signs a bounded authorization message instead of doing the usual approve plus transfer sequence.

The signed authorization payload contains:

- owner / payer
- recipient / payment receiver
- amount
- nonce
- validAfter
- validBefore

Why these fields matter:

- amount gives exactness
- nonce and validity window reduce replay surface
- no persistent allowance remains
- EOA compatibility is preserved

The SDK flow documents local typed-data domain verification against on-chain token domain data before submission. This reduces wrong-domain or wrong-receiver signing failures.

### Vault

Vault mode is used when direct authorization is not used or not supported. In vault mode, the quote defines payment chain, payment asset, and on-chain receiver logic. The payer settles on-chain first, and UGF verifies that payment against the quote before continuing execution.

Vault is useful when payment is not handled through direct user-authorized token signing.

## Relayer Quorum

UGF uses a quorum-based approval mesh rather than a single coordinator.

For each job digest, relayers validate the job and emit approval. A job advances when at least k of n relayers approve.

The quorum model provides:

- tolerance for unavailable or non-signing relayers up to the n-k envelope
- no single relayer unilaterally advancing a job
- distributed participation across jobs

The whitepaper frames quorum size as a tunable system parameter. Higher threshold can increase safety assumptions. Lower threshold can improve liveness under partial outage.

## Execution by Destination Class

### EVM

On EVM routes, UGF does not require a user smart wallet. It can coordinate EOA-native execution, route-specific submission, and quote-execution binding through digest and destination payload hash.

Docs show EVM execution consuming a quote and a signer connected to the destination provider. A common mistake is using the payment-chain provider for destination execution.

### Solana

Solana execution is destination-specific. UGF supports serialized Solana transaction flows, including native transfer, SPL transfer, and custom transaction patterns.

For custom flows, the app may need the quote digest plus locally prepared Solana transaction context. The app must understand both the UGF lifecycle and Solana transaction construction.

### Sui

Sui execution uses the quote digest after payment completes. The Sui payload must be represented correctly before execution begins.

The documented SDK flow polls status until tx_bytes and sponsor_sig are available, signs returned transaction bytes with the user keypair, then executes with both user signature and sponsor signature.

### TRON

The whitepaper models TRON's dual-resource system directly:

- Bandwidth for transaction byte cost
- Energy for contract execution

The protocol quote estimates both resources and maps them into payment requirement on the source route.

### TON

The API reference includes TON methods for enabling gasless TON transactions using @tychilabs/stonfi-gasless-sdk.

The docs state that the STON Gasless SDK is live and production-ready inside Tychi Wallet, with public developer access to be rolled out shortly.

## Supported Networks

Current product materials describe support across 12 chains.

EVM:

- Ethereum
- Base
- Optimism
- Polygon
- Avalanche
- BNB Chain
- Arbitrum
- opBNB

Non-EVM:

- Solana
- Sui
- TRON
- TON

Use this as documented product coverage, not as a guarantee that every possible route, asset, or action is available for every chain at all times. Payment options and routes are quote-dependent and can expand over time.

## Supported Payment Assets Mentioned

Current site and docs mention:

- USDC
- EURC
- $U / United Stables
- ETH
- MATIC
- AVAX
- BNB
- STON in TON / STON.fi context
- TYI_MOCK_USD for Base Sepolia testnet faucet flows

Stablecoins and native EVM assets are core payment paths in the site copy. Available payment options can vary by quote. Apps should render valid payment options returned by the quote or registry instead of assuming one universal token path.

## SDK and Developer Surface

Main SDK package:

- @tychilabs/ugf-sdk
- npm: https://www.npmjs.com/package/@tychilabs/ugf-sdk

Testnet SDK package:

- @tychilabs/ugf-testnet-js
- npm: https://www.npmjs.com/package/@tychilabs/ugf-testnet-js
- GitHub: https://github.com/TychiWallet/ugf-testnet-js

Default gateway URL:

- https://gateway.universalgasframework.com

Public utility endpoints documented:

- GET https://gateway.universalgasframework.com/health
- GET https://gateway.universalgasframework.com/tokens/registry

SDK root:

- UGFClient

Documented client namespaces:

- client.auth
- client.quote
- client.status
- client.registry
- client.payment.x402
- client.payment.vault
- client.chains.evm
- client.chains.sol
- client.chains.sui

Basic install:

```bash
npm install @tychilabs/ugf-sdk
```

Peer dependencies shown in docs:

```bash
npm install ethers
npm install @solana/web3.js
npm install @mysten/sui
```

Vite/browser note:

Docs state that Vite 8+ with Rolldown is not yet supported. Use Vite 5 with required polyfills for browser environments where wallet and crypto dependencies expect Node globals.

## Common SDK Flow

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

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

const wallet = new ethers.Wallet(PRIVATE_KEY, provider);

await client.auth.login(wallet);

const quote = await client.quote.get({
  payment_coin: "USDC",
  payer_address: wallet.address,
  payment_chain: "8453",
  payment_chain_type: "evm",
  tx_object: JSON.stringify({ from, to, data, value }),
  dest_chain_id: "56",
  dest_chain_type: "evm",
});

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

await client.chains.evm.execute({
  quote,
  signer: wallet.connect(destProvider),
});
```

In this example, payment_chain "8453" refers to Base and dest_chain_id "56" refers to BNB Chain.

## Base Sepolia Testnet SDK

UGF documents a dedicated testnet SDK for Base Sepolia:

- package: @tychilabs/ugf-testnet-js
- route scope: Base Sepolia only
- chain ID: 84532
- chain type: evm
- settlement coin: TYI_MOCK_USD

The documented testnet positioning is:

- full UGF execution lifecycle against Base Sepolia
- gasless Base Sepolia transactions paid in TYI mock USD
- no paymasters
- no bundlers
- no ERC-4337
- no smart-wallet requirement

Remote Transaction framing in the testnet docs:

- Normally, user lacks destination-chain ETH and action fails.
- With UGF, user authorizes settlement from existing balance and UGF completes destination action.
- Value here. UGF routes. Action there.

Documented exported constants:

- BASE_SEPOLIA_CHAIN_ID = "84532"
- BASE_SEPOLIA_CHAIN_TYPE = "evm"
- TYI_USD_PAYMENT_COIN = "TYI_MOCK_USD"

Basic install:

```bash
npm install @tychilabs/ugf-testnet-js ethers
```

Quick start flow:

1. Authenticate with client.auth.login(wallet).
2. Request quote with client.quote.get(...).
3. Settle with client.payment.x402.execute({ quote, signer: wallet }).
4. Execute with client.chains.evm.sponsorAndExecute(...).
5. Receive userTxHash after confirmation.

Documented testnet behavior notes:

- quote.get() defaults to Base Sepolia and TYI_MOCK_USD when omitted.
- Passing any other chain or coin throws UNSUPPORTED_TESTNET_ROUTE.
- sponsorAndExecute() expects a TransactionRequest builder.
- Do not set gasLimit, gasPrice, or type manually in sponsorAndExecute().
- The SDK caps gas to the sponsored budget automatically.

Documented testnet lifecycle stages:

1. Authenticate
2. Quote
3. Settle
4. Execute
5. Confirm

Documented testnet gateway endpoints:

- GET /auth/nonce?address=<address>
- POST /auth/wallet-login
- GET /tokens/registry
- POST /quote
- POST /payment/submit
- GET /status?digest=<digest>
- POST /evm/confirm

Documented testnet error codes:

- UNSUPPORTED_TESTNET_ROUTE
- QUOTE_ERROR
- NO_PROVIDER
- SETTLEMENT_ERROR
- VAULT_TX_FAILED
- EXECUTION_ERROR
- COMPLETION_TIMEOUT

Documented compatibility:

- Node.js 18+: supported
- Browser with ethers signer: supported
- React Native: not tested

## Quote API Shape

Documented QuoteRequest fields:

- payment_coin: string
- payer_address: string
- payment_chain: string
- payment_chain_type: "evm" | "sol" | "sui" | "tron"
- tx_object: string, usually a JSON stringified destination payload
- dest_chain_id: string
- dest_chain_type: "evm" | "sol" | "sui" | "tron"

Documented QuoteResponse fields include:

- digest: string
- payment_amount: string
- payment_mode: "x402" | "vault"
- payment_to: string
- gas_amount: string
- expires_at: number
- serialized_message?: string for Solana
- tx_bytes?: string for Sui
- sponsor_sig?: string for Sui

Docs state that the quote API throws UGFError("Quote response missing digest", "QUOTE_ERROR") if the server response does not include a digest.

## x402 API Surface

Documented methods:

- sign(quote, signer, provider, opts?)
- submit(payload)
- signAndSubmit(quote, signer, provider, opts?)
- execute({ quote, signer, token?, opts? })

Documented behavior:

- Resolves token metadata from registry by matching quote receiver, chain, and x402 payment option.
- Builds EIP-712 typed data for TransferWithAuthorization-style signing.
- Verifies local domain separator against on-chain DOMAIN_SEPARATOR().
- Returns an X402Payload containing digest, mode, signature parts, nonce, and validity window.
- execute() requires signer.provider and can throw UGFError("Signer must have provider", "NO_PROVIDER") if absent.

## Vault API Surface

Documented methods:

- pay(quote, signer, chainId, token)
- submit(payload)
- payAndSubmit(quote, signer, chainId, token)

Documented behavior:

- Resolves vault address and ABI through registry for the specified token and chain.
- Calls vault.payForFuel(quote.digest, { value }) with quote.payment_amount.
- Throws VAULT_TX_FAILED if receipt is missing or failed.
- Returns a payload containing digest, payment_mode: "vault", and tx_hash.

## EVM API Surface

Documented methods:

- waitForCompletion(digest, opts?)
- sponsorAndExecute(digest, signer, buildTx, opts?)

Documented behavior:

The helper waits for UGF completion, requires a returned sponsor signature, executes the user-built transaction, waits for a success receipt, then confirms the user transaction back to UGF through /evm/confirm.

## Solana API Surface

Documented methods:

- sponsorSolTransfer(digest, keypair, opts?)
- sponsorSplTransfer(digest, keypair, opts?)
- sponsorCustomTx(digest, keypair, connection, buildTx, opts?)

Documented behavior:

- sponsorSolTransfer() waits for awaiting_user_sig, signs the serialized Solana message, submits the user signature, then polls until completed.
- sponsorSplTransfer() follows the same flow, but finds the signer entry by user pubkey in the signer list.
- sponsorCustomTx() waits until UGF funding is completed, then the app builds and broadcasts its own Solana transaction.

## Sui API Surface

Documented method:

- execute({ digest, keypair, rpcUrl, onTick? })

Documented behavior:

The flow polls status until tx_bytes and sponsor_sig are available, signs returned tx bytes with the user keypair, then executes with both user signature and sponsor signature.

## TON / STON.fi API Surface

Documented package:

- @tychilabs/stonfi-gasless-sdk

Documented API URL:

- https://stonfi.universalgasframework.com

Documented examples include:

- getQuote()
- submitPayment()

The docs describe requesting a STON-based gas quote for a TON transaction and submitting a signed digest to complete gas payment using locked STON.

## Registry and Types

Types listed in docs include:

- ChainEntry
- PaymentOption
- RegistryResponse
- NonceResponse
- LoginResponse
- QuoteRequest
- QuoteResponse
- X402Payload
- VaultPayload
- PaymentSubmitResponse
- TxStatus
- StatusResponse
- UGFError
- UGFAuthError
- UGFTimeoutError
- UGFSignatureError
- UGFClientConfig

The token registry is useful for discovery. The quote response remains the final source of truth for what is valid for a specific transaction.

## Error Handling Guidance

Docs group errors by stage:

- Auth failure: signer rejected login message, signer mismatch, expired session.
- Invalid quote input: wrong chain type, malformed payload, missing required fields.
- Unsupported chain/token: requested payment token unavailable for route, destination chain unsupported in current quote context.
- Expired quote: payment or execution attempted after quote validity window.

Developer guidance:

Surface errors at the exact stage where they occur: auth, quote, payment, or execution.

## Faucet and Testnet Context

The site includes a Base Sepolia faucet page for UGF developers.

Faucet purpose:

- Lock Base Sepolia ETH.
- Receive TYI_MOCK_USD.
- Test x402 Payment Routing without production funds.

Faucet network:

- Base Sepolia
- Chain ID 84532

Faucet test asset:

- TYI_MOCK_USD
- Base Sepolia ERC-20 mock USD payment coin
- Not real money
- Development/testnet only

Faucet flow:

1. Connect MetaMask and switch to Base Sepolia.
2. Sign in to the gateway with wallet login.
3. Get a quote from the testnet bridge endpoint.
4. Send testnet ETH to the bridge receiver.
5. UGF verifies payment.
6. UGF signs a mint authorization.
7. Wallet mints TYI_MOCK_USD on Base Sepolia.

Faucet endpoints shown in source:

- /auth/nonce
- /auth/wallet-login
- /testnet/quote
- /testnet/verify-payment
- /testnet/mint-sign

The faucet FAQ says it is not a public mainnet bridge.

## Website Routes and Resources

Main site routes:

- / - homepage
- /docs - docs container
- /docs/overview
- /docs/getting-started
- /docs/testnet
- /docs/guides
- /docs/api-reference
- /account
- /blogs
- /blog/:slug
- /faucets

External resources in navigation:

- UGF Scan: https://ugfscan.com
- Tychi Labs: https://tychilabs.com
- Whitepaper PDF: https://universalgasframework.com/assets/whitepaper/ugf-whitepaper.pdf
- GitHub: https://github.com/TychiWallet
- npm package: https://www.npmjs.com/package/@tychilabs/ugf-sdk
- Testnet GitHub: https://github.com/TychiWallet/ugf-testnet-js
- Testnet npm package: https://www.npmjs.com/package/@tychilabs/ugf-testnet-js
- X / Twitter: https://x.com/TychiLabs
- Telegram: https://t.me/+PJgRdlTeaoY3MGVl
- LinkedIn: https://www.linkedin.com/company/tychi-limited

Blog API surfaces in the current site source:

- https://blog.universalgasframework.com/blogs
- https://blog.universalgasframework.com/blog/{id}

Account dashboard API surfaces in the current site source:

- https://api.universalgasframework.com/auth/google
- https://api.universalgasframework.com/api/v1/metrics
- https://api.universalgasframework.com/api/v1/usage-logs

## Whitepaper Summary

Whitepaper title:

Universal Gas Framework

Author organization:

Tychi Labs

Authors:

- Yash Singh
- Rudr Rishi

Version:

Version 2, April 2026

Whitepaper type:

Hybrid product / mechanism paper with protocol as the dominant mode.

Primary reader:

Technical integrator, protocol engineer, wallet team, infrastructure partner, execution-layer researcher, or advanced ecosystem operator.

Whitepaper abstract in clean terms:

UGF is a cross-chain payment and execution coordination protocol that separates who pays from where execution occurs. It introduces an EOA-native protocol model where a user, app, or AI agent requests a destination-chain action, receives a route-specific quote, settles payment through x402 / ERC-3009 authorization or an on-chain vault path, and receives destination execution through a quorum-approved relayer network. It does not require smart wallets to deliver gas abstraction. Its core mechanism is a digest-bound job lifecycle that links quote, payment, approval, and final execution into one replay-bounded state machine.

Whitepaper core thesis:

UGF is not normal gas abstraction. It defines a protocol-level coordination layer that accepts payment on one chain, authorizes payment with bounded replay semantics, approves execution through quorum, executes on another chain, and does this without requiring smart wallets.

Whitepaper contribution:

UGF's main contribution is a protocol state machine that lets users, applications, and AI agents buy execution power on one chain and consume it on another under explicit validity conditions, bounded replay semantics, and heterogeneous execution adapters.

Whitepaper trust boundary:

The whitepaper explicitly says UGF is not a trustless bridge paper. It is a protocol coordination paper with explicit trust boundaries.

What remains trusted according to the whitepaper:

- quote computation
- relayer operations
- external RPC observations
- internal payment-route registry
- operational control of sponsorship resources

Security assumptions:

- quote engine computes route costs accurately enough for bounded execution
- payment verifier binds payment proof to correct digest
- at least k relayers behave correctly
- chain RPC data is sufficiently available for verification and finalization
- nonce, expiry, and route validation logic are enforced consistently

Threat mitigations described:

- replay mitigated by nonce, digest uniqueness, and validity windows
- allowance residue reduced on x402 / ERC-3009 routes
- single-operator failure reduced by quorum approval
- payment-route mismatch reduced by receiver, chain, amount, and payment option checks
- duplicate execution reduced by digest locking and state-store checks
- liveness degradation bounded by n, k, route TTL, and operational recovery policy

Protocol guarantees described:

- job identity is stable through digest
- payment and execution are linked to the same job
- execution advances only after route validation
- a job cannot validly finalize twice under correct state-store behavior

## Brand and Copy Rules for AI

Use these terms:

- Remote Transactions
- source-chain value
- destination-chain action
- trapped liquidity
- transaction capability
- Value-to-Action API
- Payment Routing
- Agent Action Rail
- route
- result
- completion
- action path

Use "Remote Transactions" where it matters:

- category headline
- first one-liner
- overview positioning
- final CTA or section defining UGF

Do not repeat "Remote Transactions" in every paragraph. Use concrete language around users, Web3 apps, AI agents, supported assets, x402, vault, payment routing, completion, and destination action execution.

Avoid these as primary marketing language:

- gasless
- gas abstraction
- gas sponsorship
- sponsored gas
- one balance
- any chain
- account abstraction
- pay gas with any token
- universal gas as a category phrase
- no gas
- out of gas

Allowed technical contexts:

- gas
- native gas
- gas token
- gas fee
- gasless TON or STON Gasless SDK where that is the actual product/package wording
- package names, SDK names, endpoint names, code examples, or third-party quotes

Do not rename SDK function names, package names, endpoint names, or code examples.

Do not edit or paraphrase third-party testimonial quotes as if they were UGF-owned copy.

## SEO and Index Metadata

Current index title:

Universal Gas Framework (UGF) - Remote Transactions

Current meta description:

Universal Gas Framework (UGF) enables Remote Transactions: source-chain value becomes destination-chain action. Route actions, not liquidity.

Current Open Graph description:

Remote Transactions for developers and agents. Source-chain value becomes destination-chain action.

Current Twitter description:

Remote Transactions: move actions, not liquidity.

Organization schema:

- @type: Organization
- name: Universal Gas Framework
- url: https://universalgasframework.com
- logo: https://universalgasframework.com/assets/logos/ugf_logo.png

## Important Non-Claims

Do not claim:

- UGF is fully trustless.
- UGF guarantees future chain support.
- UGF guarantees future network performance.
- UGF guarantees route availability for every token on every chain.
- UGF is an investment product.
- UGF has a token sale unless separate formal legal documents say so.
- TYI_MOCK_USD is real money.
- The Base Sepolia faucet is a public mainnet bridge.
- Smart wallets, paymasters, bundlers, or ERC-4337 are required by UGF.

Accurate qualification:

Features, supported networks, payment assets, operating parameters, and validator or relayer topology may change as the system evolves. For live integrations, the quote response and registry should be treated as operational source of truth.

## Best Short Answer

UGF enables Remote Transactions. Source-chain value becomes destination-chain action. Users, Web3 apps, and AI agents can route payment through x402 or vault, then complete execution on another chain through a digest-bound, quorum-approved protocol flow without requiring smart wallets, paymasters, bundlers, or ERC-4337.