I want to share a unique approach to account authorization delegation that I think is particularly interesting when combined with Coinbase's focus on PassKeys as a primary signing method.
Given the recent comments about the starting an audit next week I don't think these type of features make sense in the core smart account logic but rather as a module or more specifically a second smart account this is an owner of the primary Coinbase smart wallet.
So this is mainly presented as a "hack" for how to use the Coinbase PassKey and smart account infrastructure to add low-level account authorization delegation capabilities to the user signing flows.
The Context
Generally speaking when an account is given permissions/authorizations to perform operations onchain it comes in the form of a smart contract update where the authorization is created using a transaction. Most notably the ERC20 "permit" standard being an exception to this rule.
The concept I'm sharing takes the "permit" concept and takes it to it's furthest conclusion.
A generalized rules/conditions framework for authorizing third-party execution of any public smart contract function call.
The frameworks draws inspiration from an Object capability model which is a computer security model for permissions sharing in decentralized systems.
It allows accounts to delegate fine-tuned permissions/authorizations across the entire EVM protocol space. It does so by embedding rules/conditions/enforcers inside of calldata that can be recursively delegated to third-party accounts using offchain signatures.
The signing process uses the EIP712 standard. Meaning any EVM based account can utilize these delegation capabilities.
The current documentation is a little old, but still includes a better overview of the unique approach works.
Given the the upcoming audit this type of functionality probably isn't well suited for the core smart account logic, but having a generalized account authorization delegation is still super desirable from a security perspective and for experimental capabilities like a generalized "intents" framework, so it would be great to find a way to do this inside of the Coinbase Smart Wallet Stack - specifically with PassKeys as the primary signing mechanism.
My first thoughts on what this could realistically look like, is the owner of the primary smart account is a Passkey and second smart account with these extended delegation capabilities. The owner of the second account would be a PassKey, capable of signing ERC712 signatures and counterfactually authorizing sub-accounts to execute transactions as the primary wallet without requiring an explicit onchain transaction to grant authority.
I think this model has a couple of interesting qualities:
Pairs well in a world with lots of PassKeys and the need for layered security.
Well suited for authorizing single use or recurring transactions in commerce based applications i.e. pull model vs push model.
In a world with lots of rollups (100s or 1000s) counterfactual account authorization delegation scales exceptionally well and is likely a great addition to the recently proposed "multichain KV database" by re-introducing single-chain account authorizations without altering/undermining the core owner/proof model.
A generalized account authorization delegation protocol is still a relatively unsolved problem in the EVM space, but potentially adds a lot of benefits in terms of scaling the blockchain user experience.
The Why
The dominance of PassKeys in the smart wallet flow I think make it an exceptionally good fit to experiment with low-level account authorization delegation and finding the best practices for making a scalable onchain payments network.
With Coinbase's strong focus on payments and Base's attention to creators and commerce this type of approach seems like a nice fit, because it can emulate features found in things like traditional credit card payment networks: automated recurring payments and layered security practices.
tl;dr
I don't think account authorization delegation capabilities necessarily belong in the core smart wallet, but would love to see support for this unique EIP712 signing flow integrated into the Coinbase PassKey signing flow and bolted on at the smart contract level via a third-party.
I want to share a unique approach to account authorization delegation that I think is particularly interesting when combined with Coinbase's focus on PassKeys as a primary signing method.
Given the recent comments about the starting an audit next week I don't think these type of features make sense in the core smart account logic but rather as a module or more specifically a second smart account this is an owner of the primary Coinbase smart wallet.
So this is mainly presented as a "hack" for how to use the Coinbase PassKey and smart account infrastructure to add low-level account authorization delegation capabilities to the user signing flows.
The Context
Generally speaking when an account is given permissions/authorizations to perform operations onchain it comes in the form of a smart contract update where the authorization is created using a transaction. Most notably the ERC20 "permit" standard being an exception to this rule.
The concept I'm sharing takes the "permit" concept and takes it to it's furthest conclusion.
A generalized rules/conditions framework for authorizing third-party execution of any public smart contract function call.
More specifically the https://github.com/delegatable/delegatable-sol smart contract delegation framework.
The frameworks draws inspiration from an Object capability model which is a computer security model for permissions sharing in decentralized systems.
It allows accounts to delegate fine-tuned permissions/authorizations across the entire EVM protocol space. It does so by embedding rules/conditions/enforcers inside of calldata that can be recursively delegated to third-party accounts using offchain signatures.
The signing process uses the EIP712 standard. Meaning any EVM based account can utilize these delegation capabilities.
The current documentation is a little old, but still includes a better overview of the unique approach works.
https://delegatable.org/docs/why
The Hack
Given the the upcoming audit this type of functionality probably isn't well suited for the core smart account logic, but having a generalized account authorization delegation is still super desirable from a security perspective and for experimental capabilities like a generalized "intents" framework, so it would be great to find a way to do this inside of the Coinbase Smart Wallet Stack - specifically with PassKeys as the primary signing mechanism.
My first thoughts on what this could realistically look like, is the owner of the primary smart account is a Passkey and second smart account with these extended delegation capabilities. The owner of the second account would be a PassKey, capable of signing ERC712 signatures and counterfactually authorizing sub-accounts to execute transactions as the primary wallet without requiring an explicit onchain transaction to grant authority.
I think this model has a couple of interesting qualities:
A generalized account authorization delegation protocol is still a relatively unsolved problem in the EVM space, but potentially adds a lot of benefits in terms of scaling the blockchain user experience.
The Why
The dominance of PassKeys in the smart wallet flow I think make it an exceptionally good fit to experiment with low-level account authorization delegation and finding the best practices for making a scalable onchain payments network.
With Coinbase's strong focus on payments and Base's attention to creators and commerce this type of approach seems like a nice fit, because it can emulate features found in things like traditional credit card payment networks: automated recurring payments and layered security practices.
tl;dr
I don't think account authorization delegation capabilities necessarily belong in the core smart wallet, but would love to see support for this unique EIP712 signing flow integrated into the Coinbase PassKey signing flow and bolted on at the smart contract level via a third-party.