Skip to main content

Gasless deposits

Overview​

When you call deposit without supplying a depositCallback, the SDK uses its built-in sponsored (gasless) deposit flow. The user signs a token authorization (no gas), and Owney's relayer broadcasts the transfer and pays the gas.

This is the default and recommended path. You only need a custom depositCallback if you want to move funds to the agent smart wallet yourself (for example, through your own paymaster or account-abstraction stack).

How it works​

  1. The SDK derives the agent smart-wallet address for the active chain.
  2. The user signs a token authorization for that transfer — off-chain, gasless:
    • USDC → an EIP-3009 TransferWithAuthorization signature.
    • WETH → a Permit2 PermitTransferFrom signature.
  3. The signed authorization is sent to Owney's sponsor API, which broadcasts the on-chain transfer and pays the gas.
  4. The deposit then proceeds into the agent's selected protocols.

Supported chains & assets​

Gasless deposits are available for both supported assets on every supported chain:

ChainChain IDUSDCWETH
Base8453✅✅
Arbitrum42161✅✅
Ethereum1✅✅

Gasless WETH requires a one-time Permit2 approval​

Unlike USDC (EIP-3009 needs no prior approval), gasless WETH deposits require a one-time Permit2 approval per chain. This single approval transaction is paid by the user — it is the only gas the user pays in the gasless WETH flow.

You do not normally need to handle this yourself: on the first gasless WETH deposit, if the approval is missing the SDK automatically calls approvePermit2, waits for confirmation, and retries the deposit. If you prefer to front-load it in your own setup UX, call approvePermit2 explicitly.

// Optional: pre-approve Permit2 for WETH before the first deposit.
await owney.approvePermit2("WETH");

// Gasless WETH deposit (no depositCallback needed).
await owney.deposit({
  amount: "1000000000000000", // 0.001 WETH (18 decimals)
  asset: "WETH",
});

Fallback to user-paid deposits​

The sponsored flow is resilient but conservative about safety:

  • If the sponsor's infrastructure fails in a way that is provably safe to retry (the signed authorization could not have executed), the SDK transparently falls back to a user-paid deposit.
  • Ambiguous failures (a network drop after the request was sent, a 5xx response) are surfaced to your application unchanged rather than retried — so you can check on-chain state before deciding, avoiding a double transfer.
  • A missing Permit2 approval, or any deposit that used your own depositCallback, never falls back automatically — the user should not pay gas unless your app has opted in.