Protocol
Gas & payers
Gas sponsorship is native: a separate payer field and payer_auth blob, domain-separated from the sender. No bundler, no EntryPoint, no off-chain relayer required for inclusion.
Why native sponsorship
Other AA designs often push gas payment into wallet validation or a bundler/EntryPoint path. 8130 keeps it in the envelope: the sender commits to who may pay, the payer co-signs under a different type byte, and the node validates both with the same authenticate → authorize pipeline. Inclusion is ordinary typed-transaction behavior.
Payer modes
Two independent fields control payment. payer is in the sender's signed hash. payer_auth is the payer's own auth blob (authenticator || data).
| Concept | Meaning |
|---|---|
| payer empty · payer_auth empty | Self-pay. Charged account is the sender. Resolved sender actor must have SELF_PAYER (or be admin). |
| payer = sender · payer_auth set | Self-pay via a dedicated gas key. Same account, sibling actor with SELF_PAYER funds another key’s transactions. |
| payer = other address · payer_auth set | Sponsored. Authenticate against the payer account; require SPONSOR_PAYER. Fee bumps need a fresh payer_auth. |
Payer authentication is metered separately and does not draw from gas_limit, so the payer's authenticator choice cannot starve calls. Signing hashes and domain separation (AA_TX_TYPE vs AA_PAYER_TYPE) are detailed in Scopes, payers & phases.
SELF_PAYER vs SPONSOR_PAYER
Both spend the account's ETH on gas and neither bounds how much: a compromised key of either kind can burn the balance. The split is what the spend can buy:
- SELF_PAYER: ETH only funds this account's own transactions (gated if the actor also has POLICY). Compromise is vandalism; monetizable mainly with a colluding builder taking tips.
- SPONSOR_PAYER: ETH funds inclusion for arbitrary third-party senders, economically transferable, operable as a paymaster service without builder collusion.
Session keys typically stay POLICY-only and rely on a sponsor. A sponsorship hot key is often SPONSOR_PAYER-only on a locked treasury. See Authenticators & locks for higher payer rate when locked + trusted bytecode.
Paying for gas with a session key
| Concept | Meaning |
|---|---|
| Sponsor | Default: owner or payer service co-signs payer_auth. Session key never touches account ETH. |
| POLICY | SELF_PAYER | Session key self-pays from account ETH. Deliberate opt-in: a griefing key can burn the full balance on fees. |
| Payer service (ERC-8168) | Off-chain payment or spend-limit budget; service co-signs payer_auth. Repayment can settle in phase 0. |
| Builder-native gas | Builders/sequencers MAY cover gas natively (e.g. empty payer_auth + recognized sentinel). Chain-specific. |
More detail on session-key framing in Policies and session keys.
Phases and token repay
Call phases give sponsorship a commit boundary: settle the payer in phase 0, run user actions in phase 1. If phase 1 reverts, phase 0 still persists, so a token push or repay to the sponsor survives a failed user batch. Builder-facing phase semantics also live in Block building.
Mempool: high-throughput payers
One payer sponsoring many senders is the hard balance case. Hardening design uses a PayerBook (Σ max_cost ≤ balance) for locked + trusted-bytecode payers, and a payment count otherwise. See Mempool design · PayerBook.