We’ve updated to move it to txn type 0x79 and 0x7a for payer magic byte!
Excellent, this will spare us quite some confusion! Thanks!
1 Like
Can an EIP-8130 account authorize an actor with permission to originate transactions on behalf of the account, while withholding administrative permissions such as adding/removing actors?
Specifically, can an EOA be authorized to “remote control” an 8130 smart account (i.e. make tx.origin == the smart account) without that EOA also having the ability to modify the smart account’s authorization configuration?
Yes, so the scope system in 8130 is what allows this.
0x00 = admin (all actions including adding / removing actors)
If the account is not admin, it uses bit flags that are currently:
SENDER - send actions from the account (which is what you are asking)
POLICY - restricted sender to only the actor’s policy contract / manager
SELF_PAY - can pay for gas for its transactions
SPONSOR_PAY - can pay gas for other accoun’ts transactions
NONCE - can use the ordered nonce space (including nonce 0 (standard protocol nonce), otherwise must use nonce-free)
So in your case, if you wanted everything but the ability to change owners it would just be
SCOPE = SENDER | SELF_PAY | NONCE (optionally SPONSOR_PAY if you wanted to)
I’d like to float a potential amendment to 8130:
Would it make sense to support a wildcard or public POLICY actor?
The account would configure a policy manager but no actor allowlist. Any account could originate a transaction as the account, provided every top-level call is restricted to that manager. The actor would have no CONFIG, PAYER, or other authority; the manager contract would determine whether the requested action is currently permitted.
My use case is permissionless unwrapping of a legacy asset: its owner records an on-chain, time-limited unwrap authorization, after which anyone may execute the policy-gated transaction. The wrapper validates the authorization and performs the unwrap as itself.
This could also support alarm-clock/keeper use cases where a contract makes an action publicly executable once specified on-chain conditions are met. Is a public-policy mode compatible with 8130’s validation and DoS model?
Sorry I didnt see this! Yes this is essentially the AlwaysValidAuthenticator - didn’t include it in the canonical set but would be a very simple add!
sorry @cyrus I didn’t see this prior - here is the example eip-8130-examples/src/authenticators/pure/AlwaysValidAuthenticator.sol at master · base/eip-8130-examples · GitHub