Skip to Content
WaaP for AppsGas Tank

Gas Tank

The Gas Tank pays network fees on behalf of WaaP users, so they can transact without holding native tokens for gas. It comes in two forms:

  • Personal gas tanks: every WaaP user has one, funded and used entirely from inside the wallet. No integration work is needed on your side.
  • Sponsor gas tanks: a pre-funded tank owned by your project. Once configured, transactions your users make on your dApp are paid from your tank instead of theirs, so they never think about gas at all.

This guide covers setting up sponsorship for your project. Everything is managed in the Gas Tank Console with your WaaP wallet.

The gas tank is not a paymaster. It does not co-sign or wrap your transaction. The user signs the exact transaction they reviewed, the gas tank transfers gas to their wallet, and then that unchanged transaction is broadcast. Nothing about the transaction differs from an unsponsored one.

Sponsoring your users’ gas

1. Create a project

Open the Gas Tank Console and sign in with your WaaP wallet. Opening your project creates it if it doesn’t exist yet: you get a project ID and an empty sponsor gas tank administered by your wallet.

2. Pass your project ID to the SDK

import { initWaaP } from "@human.tech/waap-sdk";
 
initWaaP({
  project: {
    projectId: "<your-project-id>",
    // ...other project fields, e.g. name, logo
  },
  config: {
    // ...UI configuration
  },
});

config is UI configuration (auth methods, styles) and has no projectId field. A project ID passed there is silently ignored and nothing is ever sponsored.

The same field works on the single-chain entry points, initWaaP({ chain: 'sui', project: { projectId } }) and initWaaP({ chain: 'solana', project: { projectId } }), and on initWaaPMulti.

With the project ID set, eligible transactions from your dApp are checked against your project’s gas tank and sponsored automatically.

3. Configure allowlists

Sponsorship is scoped by two allowlists, managed in the Gas Tank Console:

  • Targets: what your tank pays gas for, per chain. What counts as a target depends on the chain:

    ChainAllowlisted targetMatching
    EVMContract addressCase-insensitive
    SuiMove package idCase-insensitive, zero-padding ignored
    SolanaProgram idCase-sensitive base58

  • Domains: the site origins allowed to request sponsorship.

A transaction is sponsored only when both match; anything outside the allowlists is not sponsored and the user pays gas as usual. The allowlist is per chain. The same address on another chain is a different entry.

4. Fund the tank

Fund your tank from the Gas Tank Console. The deposit is sent from your admin wallet and credited to the project. The current balance is shown in the console, and each sponsored transaction is deducted from it.

A tank holds one balance per asset, and each chain is paid in its own asset: EVM sponsorship spends the ETH balance, Sui spends SUI, Solana spends SOL. Fund every chain you intend to sponsor on.

For the ETH balance, the amount shown is the gross balance and the amount spendable on gas is 90% of it. Each sponsored transaction deducts its gas cost ÷ 0.9.

When sponsorship applies

There is no SDK method to call at send time. When a transaction is eligible, WaaP sponsors it during send; when it is not, the transaction proceeds normally and the user pays gas. Your integration code is identical either way.

The order matters, and it is deliberate:

  1. The user reviews and signs the exact transaction.
  2. Eligibility is re-validated server-side. The check at preparation time is advisory and is not trusted at send time.
  3. Gas is transferred to the user’s wallet.
  4. The funding is observed on-chain.
  5. The original, unchanged transaction is broadcast.

Signing happens before funding, and broadcast happens only after funding is observed. Preparing a transaction never spends or reserves tank balance, so a prepared-then-abandoned transaction costs nothing.

What is not eligible

  • Any chain outside the supported list below.
  • Contract creation.
  • A target or domain outside your project’s allowlists.
  • Anything when the tank’s balance is insufficient.

Rejections are deliberately generic in production responses. The gas tank owns its own identity, allowlist, and balance rules, and does not leak which one failed. In local development the bounded detail is retained so you can tell a missing tank from a sender mismatch or an empty balance.

Supported chains

  • EVM: ETH-native mainnet chains: Ethereum, Optimism, Base, Arbitrum, zkSync, Shape, World Chain, Linea, and Scroll. Chains whose native token is not ETH (such as Polygon, Gnosis, Avalanche, or Celo) cannot be sponsored. See Supported Networks for the full chain list.
  • Sui: sponsored from the project’s SUI balance, against an allowlisted Move package.
  • Solana: sponsored from the project’s SOL balance, against an allowlisted program id.

Testnet transactions are never sponsored.

A chain appearing in some other registry does not start being sponsored as a side effect. Adding one here is a deliberate decision.

Sui sponsorship works by having the sponsor’s own coin pay for gas, so a sponsored transaction may not take its value from transaction.gas. A plain SUI transfer built that way can never be sponsored, however the project is configured. Move a non-gas asset instead.

Solana also refuses to leave an account below the rent-exempt minimum, so a user account holding no SOL at all cannot move SOL however well funded the project is.

Security notes

  • The gas tank never has access to user funds. It only ever sends gas money to the user’s address before a transaction.
  • Wallet addresses are resolved server-side from the user’s keyshares; the sponsorship API never trusts a client-supplied address.
  • The requesting origin is verified server-side against your domain allowlist; a page cannot claim an origin it is not served from.
Last updated on
TransactionsStyling WaaP