Skip to main content

Relayers and Session Keys

Overview​

Relayers and session keysShort‑lived keys authorized by a user’s wallet to approve a bounded set of actions (e.g., trading). Enable smooth UX (no constant pop‑ups) while preserving withdrawal controls.View glossary entry are the building blocks for gasless and delegated UXThe overall experience of using a product, including ease, clarity, and flow.View glossary entry in the ftUSDA delta‑neutral, yield‑bearing stable asset designed to target $1 while minimizing liquidation risk by balancing long/short exposures (e.g., supply/stake/borrow loops).View glossary entry ecosystem.

  • Relayer: a service or address that submits transactions and pays gas.
  • Session key: a delegate key a user authorizes ahead of time with strict limits and an expiry.

Together, they let a relayer execute actions on a user's behalf. With sessions, users can avoid signing every transaction by delegating limited authority to a session key.

How session keys work​

A session is an on-chain authorization that binds a delegate key to a specific scope. Users create a session once, and the session key can then sign per-action intents until the session expires, is revoked, or its limits are exhausted.

Typical session fields:

  • Delegate public key
  • Expiry time
  • Allowed contracts
  • Per-asset spend limits
  • Optional call limits
  • Max relayer fee

High-level flow​

  1. User creates a session (via SessionManager or the app), specifying the delegate key and limits.
  2. Delegate signs an intent for a specific action (for example, stake or redeem with slippageThe difference between expected and executed price due to trade size and available liquidity.View glossary entry bounds).
  3. Intent is handed to a relayer (typically via an APIA programmatic interface for accessing data or functionality.View glossary entry), which submits it to the contract and pays gas (charging a fee capped by the session).
  4. Contract validates the session and intent (delegate key, approved relayer, nonce, limits, fee cap).
  5. Action executes if all checks pass (including balances/allowances for the action).

Note: Sessions are always bounded. Users can revoke sessions or invalidate specific nonces at any time.

Where relayers and session keys show up​

Relayer-friendly flows​

For example, MintAndRedeem in ftUSDA delta‑neutral, yield‑bearing stable asset designed to target $1 while minimizing liquidation risk by balancing long/short exposures (e.g., supply/stake/borrow loops).View glossary entryftUSDA delta‑neutral, yield‑bearing stable asset designed to target $1 while minimizing liquidation risk by balancing long/short exposures (e.g., supply/stake/borrow loops).View glossary entry supports *WithPermit functions that combine EIP-2612 permits with an EIP-712 engine authorization. This lets relayers submit mint/redeem actions while the user signs only the required message(s):

  • First use: permit + engine authorization (2 signatures).
  • Subsequent uses: engine authorization only (1 signature) if the permit sets a persistent allowance (for example, max), otherwise a new permit may be needed when the allowance runs out.

Another example is EpochRewardsVault, which supports authorization-based relayer entrypoints like depositWithPermit and withdrawWithAuthorization.

Session-based flows​

For example, EpochRewardsVault supports session-based entrypoints for delegated staking and rewards:

  • depositWithSessionAndPermit
  • withdrawWithSession
  • claimWithSession

These accept a session signature (and optional permit), so a relayer can execute actions on the user's behalf.