Skip to main content

Gas and fee funding for withdrawals

When OrcaRail executes withdrawals (drains, transfers, bridge steps), transaction fees (gas) must be paid on each chain. This page explains the three funding mechanisms: paymaster (sponsored gas), native self-fund, and hot wallet, and the order in which they are used.

This is primarily for operators who deploy the API and configure environment variables, and for developers who want to understand how gas is paid.

Paymaster (sponsored gas)​

When a paymaster is configured, the system can sponsor gas so that the user's deposit wallet does not pay fees.

  • Configuration: Set ALCHEMY_PAYMASTER_POLICY_ID in your environment. When set and the chain is in the supported set, the system uses Alchemy's paymaster (ERC-4337 on EVM; Alchemy fee payer on Solana).
  • Effect: The user's wallet does not pay gas; the sponsor (Alchemy policy) covers it. This allows sending the full token balance from the deposit wallet.
  • Where it's used: EVM smart-account flows (drain, transfer, batch), Relay/bridge execution, and Solana when an Alchemy policy is configured.
  • Fallback: If the paymaster is not set, fails, or the chain is not supported, the system falls back to native self-fund or hot wallet.

Native self-fund​

Native self-fund means the deposit wallet (or smart account) pays gas from its own native balance (e.g. ETH/BNB on EVM, SOL on Solana, BTC on Bitcoin).

  • Effect: The user's deposit wallet must hold enough native token to cover the transaction fee. Any remainder of the target token can still be sent.
  • Role: Used as the first tier in drain/transfer flows when possible, so the full token balance can be sent without requiring a hot wallet or paymaster.

Hot wallet​

The hot wallet is an operator-only configuration. API users do not set it; it is configured via environment variables for the deployment.

ChainEnvironment variablePurpose
EVMHOT_WALLET_PRIVATE_KEYFee-payer and rescue for EVM withdrawals
SolanaSOLANA_HOT_WALLET_PRIVATE_KEYFee-payer and rescue for Solana withdrawals
BitcoinBITCOIN_HOT_WALLET_PRIVATE_KEYFee inputs and rescue for Bitcoin withdrawals

Roles:

  • Fee-payer: When paymaster is unavailable or fails, the hot wallet can be used to pay gas so the deposit wallet can still send the full token balance.
  • Rescue: If the deposit wallet cannot complete the transfer (e.g. insufficient native balance for gas), the hot wallet can send from its own balance to the withdrawal address so funds are not stuck.

If no hot wallet is configured for a chain, fallback options are limited (e.g. self-funded only, or failure if self-fund is insufficient).

Fallback order (by chain)​

EVM​

  1. Tier 1: Self-funded UserOp (deposit wallet pays gas from native balance).
  2. Tier 2: Paymaster (sponsored gas when ALCHEMY_PAYMASTER_POLICY_ID is set and chain is supported).
  3. Tier 3: Hot-wallet rescue (hot wallet sends from its own balance).

Solana​

  1. Tier 1: Alchemy-sponsored (fee payer from Alchemy policy when configured).
  2. Tier 2: Hot wallet as fee-payer (deposit wallet sends; hot wallet pays fee).
  3. Tier 3: Hot-wallet rescue (hot wallet sends from its own balance).

Bitcoin​

Fee inputs and rescue use the Bitcoin hot wallet when BITCOIN_HOT_WALLET_PRIVATE_KEY is set.

Summary​

  • Paymaster: Configured by operator (ALCHEMY_PAYMASTER_POLICY_ID). Used first when available; avoids user paying gas.
  • Native self-fund: N/A (wallet balance). Deposit wallet pays gas from its native token.
  • Hot wallet: Configured by operator (per-chain *_HOT_WALLET_PRIVATE_KEY). Used as fee-payer or rescue when paymaster or self-fund fail.

See also​