Gas Sponsorship

Sequence Builder offers a Gas Sponsorship feature that allows project owners to sponsor gas for their users in web3 apps. By covering transaction fees, users can enjoy a seamless gaming experience without worrying about obtaining crypto for fees.

When a user utilizes a Sequence wallet, we offer the compatibility of sponsoring gas on any chain for your users - either at the contract or address level. This means higher conversion rates to smooth the onboarding experience for your users. By default, Sequence sponsors all gas on testnets for a smooth developer experience, however we recommend when going to Mainnet that sponsor gas for your users.

Current Builder behavior:

Treat Builder contract deployments on production networks as self-funded transactions. Even if you add a wallet or contract under Gas Sponsorship, deploying a new contract from Builder, including most factory-based deployments, may still require the deploying wallet to pay network gas.

Gas sponsorship is most reliable for relayed interactions with contracts that are already deployed.

Sponsoring a wallet address is broader than sponsoring a contract address. A sponsored wallet can cover relayed transactions from that wallet on the sponsored network beyond a single contract, while sponsoring a contract address is the narrower option.

Why would I want to sponsor gas for my app?

Obtaining the crypto needed to cover gas fees poses a challenge for onboarding your users. Sponsoring gas on their behalf solves this problem, ultimately leading to higher conversion rates and retention.

Sponsoring gas is easy and works across all networks we support with a single balance.

How to Enable Gas Sponsorship

1. Create or Select Project

   To create a project, follow this walkthrough

   If you have a project already, sign in and select from the listed projects.

2. Sponsor Wallet or Contract

   First, navigate to the gas sponsorship overview page.

   Then, either + Add Address to sponsor gas for a specific wallet address.

   

   Or, Add Contract to select a smart contract that you’d like to sponsor.

   

   Wallet sponsorship and contract sponsorship are scoped differently. Sponsoring a wallet can cover that wallet’s relayed transactions across many contracts on the selected network. Sponsoring a contract can benefit many users, but only when they interact with that specific contract.

3. Add Payment & Configure

   Now, we are going to add a payment method via a credit card in order to fund the sponsorship. Go to the gas sponsorship configuration and select Setup Payment Method.

   Add a payment method which will update your gas sponsorship configuration.

   You can either do a one-time top off or an automated top-up based on preferred ranges so you can precisely configure how much you’d like to willing to subsidize for your users each month. Once you have selected your top-up amounts, go ahead and save your settings.

   We will automatically notify you if your balance falls below $5 and you have sponsored contracts.

4. Test your Sponsorship

   We recommend testing out your sponsorships prior to launching. After the contract is already deployed, call the contract or use your sponsored wallet for a mainnet transaction. You should shortly see the sponsored transactions list populating with these transactions.

   Do not use a Builder contract deployment as your sponsorship test, since deployment transactions may still require the deploying wallet to pay gas.

Ecosystem Gas Sponsorship

We also offer the capability to sponsor all transactions for your ecosystem where we orchestrate a number of signers through our relayer at the chain level. This means any developer building on your ecosystem as well as any user of Sequence wallets has the best onboarding and UX experience possible. Please feel free to contact us to set this up for your ecosystem.

Conditional Sponsorship via Webhook

If you need to make per-transaction sponsorship decisions — for example to apply per-wallet spend caps, KYC gates, or user-tier rules — you can attach a webhook to any gas sponsor. When a sponsored transaction arrives, the Relayer POSTs the transaction details to your endpoint and only sponsors it if you approve.

Configuration

When creating or updating a gas sponsor, set:

• webhookUrl — your HTTPS endpoint. HTTPS is required.
• webhookAuthToken (optional, recommended) — a shared secret of at least 32 characters. The Relayer sends it as Authorization: Bearer <token> on every call. Without a token, anyone who learns the URL can invoke it.

Request

The Relayer POSTs a JSON body to your webhookUrl:

{
  "chainId": 137,
  "projectId": 12345,
  "gasSponsorId": 678,
  "walletAddress": "0x70236ffbAd7b70c2C65928c7Ca413AEa639FA0dE",
  "transactions": [
    { "to": "0xA0b8...", "value": "0x0", "data": "0xa9059cbb..." }
  ]
}

Headers sent on every call:

• Content-Type: application/json
• Authorization: Bearer <token> — only if you configured a webhookAuthToken
• X-Sequence-Request-Id: <uuid> — stable per-call identifier; use it for logging or deduplication

transactions[].value and data are hex-encoded. A single decision can cover multiple batched calls — apply your rules to the array as a whole.

Response

Return HTTP 200 with exactly this JSON body:

{ "sponsor": true }

or

{ "sponsor": false }

The HTTP status code matters. The Relayer treats only 200 OK as a valid decision — any other status (including 201, 202, 400, 500) is treated as a transport-level failure and the transaction is sponsored (see “Fail-open” below).

Do not encode a deny as 400 or an approve as 201. Always return 200 and put the decision in the sponsor field.

Timeout and fail-open behavior

The Relayer waits up to 2 seconds for your response. If your endpoint is slow, unreachable, returns a non-200 status, returns malformed JSON, or omits the sponsor field, the Relayer falls back to sponsoring the transaction.

This fail-open behavior is deliberate: a broken webhook should not silently break sponsorship for your users. Denying a transaction requires an explicit {"sponsor": false} over HTTP 200.

Security

• HTTPS is required. The Relayer will not follow redirects, so an HTTPS endpoint that redirects to http:// is rejected.
• Configure a webhookAuthToken unless your endpoint enforces auth at a different layer (IP allowlist, edge proxy).
• The token is sent verbatim in the Authorization header — do not log this header.
• To rotate the token, call UpdateGasSponsor with a new value. To stop gating entirely, clear webhookUrl.