Somnia Gas Sponsorship

Somnia Gas Sponsorship

Coming soon: native gas sponsorship, built into the chain. A payer authorises the gas it covers, so an app or venue can let its users trade without holding SOMI. The sponsorship patterns, and what to use until it ships.

Note

Coming soon. Native gas sponsorship isn't on mainnet or testnet yet. This page describes the patterns it is designed for. Until it ships, a sponsor can pay for a Somnia Account's transactions from its own address: see Today.

Every transaction on Somnia pays gas in the network's native currency: SOMI on mainnet, STT on the testnets. Gas sponsorship lets someone other than the sender pay it: a venue, an app or a protocol authorises the gas it covers, and the chain charges that payer instead of the user. The user signs a plain transaction, the same one they would sign if they paid themselves. Nothing is wrapped, relayed or re-signed, and no extra contract sits between the user and the one they are calling.

Because the sponsorship is native, the chain records who paid on every transaction. Transaction pages in the Somnia Explorer name the sponsor, and an address page shows what that address sponsored.

Patterns

Each pattern is a rule the payer sets onchain about which gas it will cover. They can be combined.

The payer covers gas for any transaction to a contract it names: a venue sponsors its markets, a game sponsors its own contracts. A user's first action on the venue can be a trade, not a token purchase.

  • Scope by contract, or by contract and function, so the venue pays for orders and not for arbitrary calls.
  • Set a budget: a total in SOMI on mainnet or STT on a testnet, or a rate per hour or per day, after which the user pays as normal.
  • Top up or revoke at any time; the rule and its budget are state the payer controls.

The payer covers gas for transactions from addresses it names, wherever they go: an allow-list of users, or every account a venue has created for its users through Somnia Accounts.

  • Cap what each user may spend, and how often.
  • Pair with a session key, so the sponsored account acts without a wallet prompt and only within the session's limits.

The payer covers one transaction, or one kind of transaction, and nothing else: onboarding (creating a user's account, their first deposit), a free cancel, a claim. Creating a Somnia Account is permissionless and the sponsor cannot end up owning it, so this is safe to offer to anyone.

A protocol or a market maker covers gas for a venue's users on the markets it cares about, as a liquidity incentive: the venue keeps its own rules, and the extra payer adds a budget on top. Who paid is on each transaction, so the incentive is auditable.

What a sponsor should check

Whatever pays decides what it will pay for, before the gas is spent:

  • Who is asking. Verify the signature is from someone you sponsor, not just that it is valid.
  • What they are doing. Hold the call to the contracts and functions the rule names.
  • How much. Size the gas limit from what the call needs, not from a round guess, and keep a floor for calls that cannot be estimated.
  • Budget. Stop when the user's or the rule's allowance is spent.

Today

Until native sponsorship ships, a sponsor pays by sending the transaction from an address it funds. The Somnia Accounts SDK builds a call as bytes and lets any relay send them, so a sponsor endpoint or queue can pay for a user's account creation or a signed action: see How to sponsor a transaction and Gas for the limits those calls need. Its checks (who signed, what the authorisation allows, before every broadcast) are the same ones the patterns above rely on.

Follow progress on the Gas Sponsorship page in the Somnia Explorer.

Edit this page

Send feedback

Agents: POST the same to /api/feedback.