@sullof For sure! Here are a few of the options we’ve been considering if the owner()
function is to be re-named:
executor()
operator()
signer()
controller()
custodian()
steward()
manager()
admin()
The goal of these names is to reduce the emphasis on the holder of the token as the canonical owner of the account, since the token itself is the owner. The holder simply has temporary execution permissions.
However, as discussed earlier in this thread, the concept of a canonical controller makes it difficult for this pattern to be applied to tokens that lack a canonical owner. Additionally, there is currently no way to determine whether a given address has execution permissions on an account without assuming that the executor must be the owner. This assumption will likely be broken in practice quite quickly. As a result, it might make sense to replace owner()
with a new method that can be queried to determine whether a given address has permissions on the account.
Here are a few options that are being considered:
-
is...(address) returns (bool)
for any of the above names (e.g. isExecutor
).
isValidSigner(address) returns (bool)
isAuthorized(address) returns (bool)
controlledBy(address) returns (bool)
managedBy(address) returns (bool)
Another option is to add a function that can be queried to determine a caller’s ability to execute a certain function on the account. This could look like:
isAuthorized(bytes4 sig, address caller) returns (bool)
canExecute(bytes4, address) returns (bool)
hasPermission(bytes4, address) returns (bool)
This could be even further extended to accept the full calldata bytecode as a parameter instead of just the method signature. Something like:
canExecute(bytes calldata data, address caller) returns (bool)
Additionally, each of the above functions which return a boolean could return a magic value instead, allowing for further extension of functionality at the account implementation level.
I don’t want to stray too far into mandating specific access control patterns here (e.g. role-based permissions) as I think those are out of scope for the proposal. However, access control is a central part of this proposal and I think some minimal pattern should included in the account interface.
Part of the challenge here is determining a term that can be used in place of owner
to properly captures the distinction between the token (which “owns” the account) and the token holder (which “uses” the account).
I’m leaning towards the term signer
, as I think it fits well with existing smart contract account terminology (e.g. “signer on a gnosis safe”). It’s also similar to the verbiage used in EIP-1271.
I would propose that the owner
function be replaced by the function:
isValidSigner(address) returns (bytes4)
The proposal would specify that the token holder should be regarded as the default signer and that all valid signers should also have execution rights.
Would love any and all feedback on these potential interfaces 