Sponsored By Design

How Sonic is expanding transaction sponsorship with V2.2.

A user bridges assets to Sonic. They have USDC, ETH, or another asset they want to use, but no S to pay the network fee. Despite already having funds onchain, their first interaction can stop before it starts.

Sonic introduced protocol-level transaction sponsorship with v2.1.2, allowing applications to cover network fees for their users. V2.2 takes that model further. Network-sponsored transactions can remove the fee entirely for qualifying activity, while successful-only sponsorship gives applications more control over when their sponsorship budget is spent.

The result is a broader model for transaction execution: the user can pay, an application can pay, or for selected transactions, nobody has to pay at all.

Sponsorship At The Protocol Level

Sponsored Transactions on Sonic do not rely on an offchain relayer forwarding transactions for users. Sonic's transaction processing recognises sponsorship requests directly, while an onchain Subsidies Registry holds deposited S and defines which transactions those funds can cover.

A transaction requests sponsorship by setting its gas price, or fee cap for newer transaction types, to zero. The node checks the Subsidies Registry and, if an eligible fund has sufficient balance, accepts the transaction for sponsored execution. The user still signs through the normal wallet flow.

Sponsorship therefore changes who pays for execution, not who authorises the action.

Apps Choose What They Pay For

Sonic allows sponsors to define which activity they are willing to cover rather than paying for every transaction a user makes.

Sponsorship can apply to transactions from a particular account, interactions with a particular contract, or calls to a specific contract function. Sponsors can narrow this further to a particular account calling a particular function. There are also dedicated mechanisms for ERC-20 approvals and bootstrap sponsorship, which can cover the first few transactions from a new account.

A DEX could cover the approval required before a swap without paying for unrelated wallet activity. A lending market could cover interactions with its contracts, while another application could sponsor a new user's first few actions.

Before execution, Sonic checks that sponsorship is still available. If it is, the user's transaction executes and an internal transaction charges the selected sponsorship fund for the gas consumed.

This means the network fee still exists. It simply comes from the sponsor's deposit rather than the user's wallet.

What If The Fund Runs Out?

Sponsorship coverage can change while a transaction waits in the pool. A transaction might qualify when submitted but lose its backing if other transactions consume the available balance first. Sonic rechecks pending sponsored transactions and can remove those that are no longer covered.

Sponsored transactions also carry an effective tip of zero, giving them the lowest transaction-pool priority. Under high network load, transactions offering a positive tip are prioritised ahead of them.

These constraints are part of the trade-off. Sponsorship removes a payment requirement from the user, but the network still has to account for the execution and ensure someone is covering its cost.

When Nobody Pays

V2.2 extends the existing system with network-sponsored transactions.

With a regular transaction, the user pays. With a sponsored transaction, an application or another sponsor pays from deposited S. With a network-sponsored transaction, a qualifying transaction can be processed without a token payment at all. No S is consumed, burned or rewarded to validators for its execution.

Network sponsorship builds on the existing Gas Subsidies infrastructure rather than introducing a separate transaction system. The Subsidies Registry's chooseFund logic can return a special NETWORK_SPONSORED identifier, telling Sonic that the transaction qualifies to be processed without payment.

The network can still be selective about what qualifies. Criteria could identify a particular stablecoin contract, restrict sponsorship to its transfer function, require a minimum transfer amount, or introduce additional conditions around senders and receivers.

The user experience remains similar to existing sponsorship. An application creates a qualifying transaction with its gas price or gas-fee cap set to zero, the user signs it, and the transaction is submitted to Sonic.

The difference comes during execution. Regular sponsorship requires an internal transaction to charge the sponsor's fund. A network-sponsored transaction has no sponsor to charge, so that payment transaction is not inserted.

Sponsoring Successful Transactions

V2.2 also introduces successful-only sponsorship, changing the economics for applications covering their users' network fees.

Sponsorship applies only when the transaction succeeds. If an application sponsors a user's first deposit and the deposit completes, the application covers the network fee. If execution fails, the failed attempt does not consume its sponsorship budget.

That distinction becomes important at scale. Instead of spending its budget on every attempted interaction, an application can direct sponsorship toward completed user activity.

For protocols using sponsorship as part of onboarding or product UX, this makes the cost much easier to control.

From Sponsored Transactions To Sponsored Workflows

Sponsorship becomes more useful when it can compose with the other execution primitives arriving with V2.2.

Bundled Transactions allow related transactions to execute with fate-sharing and no interleaving between their steps. A workflow can require every transaction to succeed or have the sequence rolled back rather than leaving the user with a partially completed operation.

Consider a flow where a user needs to approve an asset, deposit it and perform another action. Sponsorship can remove the requirement to acquire S before beginning, while bundles can coordinate the related transactions so the workflow does not end in a partially executed state. Sponsored transactions can also be included within bundles.

This creates a more flexible execution model. Sonic can separate who authorises a transaction, who pays for it, whether a qualifying transaction requires payment at all, and how related transactions execute together.

The user still signs what they do. Applications decide what they subsidise. For selected activities, the network can remove the fee entirely. And with bundles, sponsored transactions can become part of coordinated multi-step workflows.

Sponsorship is no longer just a way to pay someone else's gas. With V2.2, it becomes part of how applications are designed.