Tokens but no gas: sponsored transactions in BXB
Customer A has 100 tokens and wants to send 10 to B, but the wallet has no native coin to pay the network fee. A has both the balance and the right to transfer the tokens, yet lacks a different asset needed to submit the transaction.
If the service pays the fee, it can avoid asking the customer to acquire native coin first. Does paying the fee also give the service the right to move A's tokens as it chooses? Who pays the cost and who permits execution from A's account are separate questions.
BXB's sponsorship path combines a sponsor wallet with execution code linked to an existing account through EIP-7702. We will follow a transfer of 10 tokens to see what is needed when preparing the account and when executing the transfer.
1. Account for the 10 tokens and the fee separately
In this example, A is an existing EOA whose key an institution manages. An EOA is a blockchain account controlled by a private-key signature. This is independent of the smart account example in Part 1; we do not assume that the same balance is being moved to a new account. Assume token T and the required delegate code are available on an EVM network that supports EIP-7702.
T has zero decimal places, so the integer 10 passed to the contract represents 10 tokens. A holds 100 T and no native coin; B holds no T. The service's sponsor wallet S holds 1 native coin to pay fees. There is no minting, burning, token transfer fee, or concurrent transaction, and the service does not charge the sponsorship cost back to the customer.
We account for the initial delegation setup cost separately and consider one transfer after setup is complete. Suppose the actual fee F for that transaction is 0.001 native coin. A successful transfer produces the following result. F is an assumption for this calculation, not a fixed price or a measured result.
| Balance | Before | After success |
|---|---|---|
| A's T | 100 | 90 |
| B's T | 0 | 10 |
| A's native coin | 0 | 0 |
| S's native coin | 1 | 0.999 |
The total of 100 tokens is preserved, and the fee comes out of S's native coin balance. The goal is to reach this result without first sending native coin to the customer's wallet. The fee still exists; a different account bears it.
2. First, attach execution rules to A's address
When an ordinary EOA A signs its own transaction, A also pays its gas fee. For another account S to pay while A's tokens move, we must define how A's account accepts S's request.
EIP-7702 delegation links an EOA address to the execution rules of designated code. That code runs in A's account context, so when it calls token T, T sees A as the caller. The tokens are not entrusted to the sponsor and then sent onward. The article on EIP-7702 delegation for EOAs explains how an account can use those rules while retaining its address and assets.
The initial setup requires a signature with A's account key that authorizes the choice of delegate code. This is the authorization. BXB provides a path that includes this authorization in a transaction, signs the transaction with the sponsor's key, and submits it to the chain. A's authorization signature and the fee-paying transaction signature are both needed, but they have different roles.
Preparation takes more than recording an address in a local setting. The execution code must exist on the selected network, and A's delegation must have taken effect on-chain. This setup transaction also incurs a fee, which is excluded from F above.
Delegation persists after that transaction ends. When the prepared account A requests another transfer, the same delegation path can be reused. However, permission to keep using the code and permission to send 10 tokens to B this time are separate matters. The latter depends on the conditions under which the delegated code accepts a call.
3. Three different signature roles
Start with USER_SIGNATURE, the mode that signs each individual call with A's account key.
The business system authenticates customer A and decides whether the request to send 10 tokens to B satisfies its business rules.
BXB uses A's selected wallet to construct the token T transfer call and prepares an execution signature for that call.
Although the mode is named user signature, the custody server's signing path uses A's account key here. It does not mean the customer's browser signed directly with a private key. Nor does this signature alone prove which screen the customer saw and approved. The article on customer accounts and signing boundaries explains this separation of responsibilities between customer authentication, business approval, and use of signing keys.
In this mode, BXB binds the call target and contents, network and account, execution sequence, and deadline into the execution signature. The execution sequence, or nonce, is a value used to prevent the same approval from being reused. The current implementation sets the deadline to five minutes after the call signature is created. The delegated code checks these conditions and A's signature before calling the token contract.
Finally, S's key signs the outer blockchain transaction. S uses it to call A's address and pays the fee. The code executing at A's address checks the approval conditions inside that call. The signature paying the fee is therefore distinct from the signature approving the call that moves A's assets.
| Signature | Key | Approves |
|---|---|---|
| Delegation setup | A | Code to use at A |
| This call | A | T transfer with conditions |
| Outer transaction | S | Call to A and its cost |
With delegation already set up, the transfer proceeds as follows.
Business system authenticates A
and approves the transfer
↓
Custody server signs the call
with A's key
↓
S signs and submits the outer tx
↓
A's code checks call approval
↓
A's account calls T to transfer
↓
Check result: A 90 / B 10
Receiving a transaction hash is not the same as a successful transfer. Check the receipt, token events, and balances, then apply the service's required confirmation criteria before treating the transfer as complete.
4. A permitted sponsor can also authorize execution
BXB provides another verification mode, SPONSOR_WHITELIST.
Here, the delegated code checks whether its caller is a permitted sponsor and whether the requested execution sequence matches the current value.
An operator manages the allowlist; this differs from requiring A's execution signature for each call.
Initial account delegation still needs A's authorization. For subsequent execution, the question changes from “Does this call have A's valid signature?” to “Is a permitted sponsor requesting the correct sequence?” A permitted sponsor can choose the target and call contents to execute from A's address without a separate signature from A for that call. Registering a sponsor therefore both selects a fee payer and grants execution authority.
| Mode | Call checks | Responsibility |
|---|---|---|
| Call signature | A's signature, nonce, deadline | Approval matches signature |
| Allowed sponsor | Sponsor permission, nonce | Sponsor authority and call policy |
The five-minute deadline of the first mode must not be assumed to apply to the second. Neither are daily budgets or per-transfer amount limits common features guaranteed by both modes. If the service wants a rule such as “Sponsor at most five transfers per customer today” or “Only transfer this token,” it must separately decide where that business policy will actually be enforced.
In the BXB path examined here, S signs and submits the transaction directly. We do not call this an ERC-4337 Paymaster. It can serve the same sponsorship purpose as a Paymaster-based path, but the execution examined here does not go through an EntryPoint and Bundler. The article on ERC-4337 Paymasters explains how that path separates execution approval from fee payment.
5. A failed transfer can still cost the sponsor
Return to USER_SIGNATURE, starting from A100/B0 and requesting a transfer of 10 tokens.
Assume the call signature was created and the transaction submitted before the deadline, but the transaction waited and executed in a block after the deadline.
This is an individual transfer from an already delegated account, not the initial delegation setup transaction.
The delegated code rejects execution at the deadline check. It never reaches token T's transfer, so with no other transactions, the balances remain A100/B0. However, if the transaction was included in a block and ran the check, it consumed gas. A failed transfer does not mean the sponsor gets the entire fee back.
Let G be the actual fee for the failed transaction. S's native coin balance falls from 1 to 1 − G.
We do not assume G equals F from the successful example. A still holds no native coin.
If the request instead stopped before submission because expiry was detected, and no transaction was put on-chain,
that attempt would incur no on-chain execution fee.
This distinction makes the stopping point relevant even when the outcome is simply “Sponsorship rejected.” Treating business rejection, failure before submission, and failed on-chain execution as the same cost state leads to mistakes in customer support and reconciliation. Before retrying a failed call, check the previous transaction's result, then prepare fresh execution approval with the current nonce and deadline.
What expired in this example was the signature for this call. The delegation set on A's account does not automatically disappear. The failed result, the remaining delegation, and the next call's approval conditions each need to be checked.
6. Stopping sponsorship and revoking delegation
To stop paying fees, the service can remove a sponsor from operation or remove its permission from the allowed-sponsor list. To stop A's account from using the delegated code, it needs to revoke the account delegation itself.
BXB provides a path that creates a revocation authorization with A's key and has a sponsor submit the transaction. Under EIP-7702's revocation rule, a valid authorization naming the zero address clears the account's delegation code. Revocation also needs a transaction to take effect on-chain, so it requires a signature and a fee. It differs from simply turning off a server-side setting.
Revocation does not reverse a completed token transfer from A to B. The successful example remains A90/B10; what changes is the execution path available afterward. Gas sponsorship also does not supply the assets A wants to send. It cannot resolve a shortage of native coin that A intends to transfer as value.
The customer's experience is “I sent 10 tokens without first acquiring native coin.” Providing that experience requires managing the account's code, the conditions for each execution, the sponsor paying the fee, and the cost of failure together. This BXB path connects those roles. The business system checks the customer's intent and authority, and the institution defines the scope of sponsorship by deciding which executions it will fund and under what conditions.