Sponsored transactions—the separation of fee payment from transaction content—have been a long standing feature request. Unlike similar proposals, this EIP specifies a method of implementing sponsored transactions that allows both externally owned accounts (EOAs) and [EIP-2938](./eip-2938.md) contracts to act as sponsors.
With the explosion of tokens built on Ethereum, especially stable coins, it has become common for EOAs to hold valuable assets without holding any Ether at all. These assets must be converted to Ether before they can be used to pay gas fees, but without Ether to pay for the conversion, it's impossible to convert them. Sponsored transactions break the circular dependency.
While it is possible to emulate sponsored transactions (ex. [Gas Station Network](https://www.opengsn.org/)), these solutions require specific support in callee contracts.
- sets the caller and origin addresses based on an ECDSA signature, and
- optionally transfers Ether from the recovered account.
When invoked through `CALL` (`0xF1`), `DELEGATECALL` (`0xF4`), or `CALLCODE` (`0xF2`) the `CALL_PRECOMPILE` invokes the callee as if it had used `CALL` (`0xF1`.) When invoked through `STATICCALL` (`0xFA`), the `CALL_PRECOMPILE` invokes the callee as if it had used `STATICCALL` (`0xFA`.)
The signature (`v`, `r`, `s`) arguments are computed from `secp256k1(keccak256(type || abi.encode(nextra, mingas, to, valueTotal, valueSponseeMax, data, invoker, chainid)))`.
`CALL_PRECOMPILE` returns a success in all other cases.
The return data of `CALL_PRECOMPILE` will be a single byte to indicate the status of the call into callee followed immediately by the return data from that call.
It is important to differentiate between a failure in `CALL_PRECOMPILE`'s preconditions versus a failure in the callee. Correctly implementing replay protection requires the invoker to change its state even if the callee fails (to burn the nonce) but doing so if, for example, the signature failed would be nonsensical.
Including `sponsee` in the arguments to `CALL_PRECOMPILE` is a gas optimization. Without it, invokers would have to do their own `ecrecover` before calling into `CALL_PRECOMPILE` to verify/adjust any state for replay protection.
Allowing `CALL_PRECOMPILE` to transfer Ether on the sponsee's behalf provides a uniform interface for all transactions a sponsee might want to perform. Sponsees with sufficient Ether might use a sponsor when swapping Ether for an ERC-20 on a subsidized exchange, or when relying on that sponsor to resubmit transactions to optimize gas pricing.
### Reserving an [EIP-2718](./eip-2718.md) Transaction Type
While clients should never directly interpret transaction-like packages as true transactions, reserving an [EIP-2718](./eip-2718.md) transaction type for transaction-like packages reduces the likelihood of a transaction-like package being misinterpreted as a true transaction.
Other approaches to sponsored transactions, which rely on introducing a new transaction type, are not immediately compatible with account abstraction (AA). These proposals require a _signed_ transaction from the sponsor's account, which is not possible from an AA contract, because it has no private key to sign with.
Besides better compatibility with AA, a precompile is a much less intrusive change than a new transaction type. This approach requires no changes in existing wallets, and little change in other tooling.
`CALL_PRECOMPILE`'s single purpose is to set `CALLER`. It implements the minimal functionality to enable sender abstraction for sponsored transactions. This single mindedness makes `CALL_PRECOMPILE` significantly more composable with existing Ethereum features.
More logic can be implemented around the call into `CALL_PRECOMPILE`, giving more control to invokers and sponsors without sacrificing security or user experience for sponsees.
Earlier approaches to this problem included mechanisms for replay protection. This proposal explicitly does not handle replay protection, but instead includes a signed-but-unused field (`nextra`) which is expected to be used by invoker contracts to implement replay protection. Delegating replay protection to the invoker sidesteps the issue of giving a precompile contract its own storage, while opening the door to more innovative replay protection methods in the future.
There are several implementation details about this operation that might evolve over time (ex. the signature algorithm.) If each evolution of sponsored transactions required a new opcode, the opcode space would be quickly exhausted.
Further, as a precompile, sponsored transactions can be combined with the existing call opcodes (`CALL`, `STATICCALL`, etc) to achieve different levels of state mutability. This would require several opcodes (`SIGCALL`, `SIGSTATICCALL`, etc) and would further exhaust the opcode space.
This is not strictly true without this proposal (ex. contracts under construction have no code.) Contracts relying on this assumption are therefore insecure regardless.
> `tx.origin` is the gas payer.
It is unlikely that contracts making this assumption (i.e. ones which already implement sponsored transactions) would continue to be used after this proposal is implemented.
> `tx.origin == msg.sender` asserts that the current execution frame is the topmost frame.
Several properties are unique to the topmost execution frame:
1. The return value is inaccessible.
2. Reverting or returning in the topmost frame ends execution.
3. The caller is an EOA and not a contract.
Properties (1) and (2) no longer hold when `tx.origin == msg.sender`, while property (3) is maintained: only an EOA can sign a transaction-like package.
It is unlikely, but not impossible, for a contract to only return a value when called by an EOA. It is difficult to imagine uses cases for such behavior, so invalidating property (1) seems to have low impact.
Property (2) would likely have the greatest impact, for two reasons: it creates the opportunity for atomicity where there was none before, and it makes pre- and post-conditions undetectable to the callee. Since the topmost frame is always executed, a contract in that frame can be certain—barring revert and out-of-gas conditions—that it will execute, regardless of the state changes it makes. With `CALL_PRECOMPILE`, an invoker could revert the callee if certain post-conditions were not met, allowing a retry at a later time. That said, a miner can break either of these assumptions by, respectively, executing two separate but adjacent transactions, or simply excluding a transaction that doesn't meet the pre- or post-conditions.
> Only one `tx.origin` can exist in a single transaction.
Reentrancy guards that rely on `tx.origin` cease to function under this proposal.
If setting `ORIGIN` is unacceptable, an alternative is to not set `ORIGIN` and for `CALL_PRECOMPILE` to fail if `sponsor == sponsee`.
