[AIP] Account Abstraction#512
Conversation
| - Multisig v2 account | ||
| - Sandbox or temporary account to isolate assets/risks, etc. | ||
| - Restricted permissions granted to trusted applications so users don’t need to sign every transaction. | ||
| - Delegation of asset management to a different account (semi-custodial model) |
There was a problem hiding this comment.
it'd be nice if a bit more detail can be provided here for each item. i'm curious how this can be related to multisig v2 accounts
There was a problem hiding this comment.
multisig v2 uses MultisigAccount as the account resource.
And the sender of multisig v2 transaction is a normal sender. They could be an AA account. I think basically if you want to migrate an account from multisig v2 to AA account. We have to find a way first to convert multisig account to a normal account with AA auth to seamlessly migrate. I think you are asking about this.
But this^ seems unrelated to AA design itself. It would be worth another AIP to explain this migration option.
There was a problem hiding this comment.
Enabling AA for an account means registering an account resource that contains a dispatchable auth function, right?
If enabling AA can be done via say a private entry function call, I think there won't be any special treatment needed for multisig v2 accounts. Since multisig v2 accounts are just accounts that happen to have a MulsitigAccount resource, they can just call the AA enabling function like any other accounts.
There was a problem hiding this comment.
at the minimum, other authentication resources (like MulsitigAccount) need to be removed, in order for AA to be able to be registered, right @lightmark ?
There was a problem hiding this comment.
I think they can coexist. Any problem for that. Once you get the master signer in any means, you can opt to remove any auth resources.
|
|
||
| - Multisig v2 account | ||
| - Sandbox or temporary account to isolate assets/risks, etc. | ||
| - Restricted permissions granted to trusted applications so users don’t need to sign every transaction. |
There was a problem hiding this comment.
Would it be more appropriate to include a provision for resource locks here? I made a similar suggestion in the LightAccount AIP, but I believe this feature could be integrated into this proposal as well.
lightmark
force-pushed
the
account_abstraction
branch
from
33dc0d6 to
513043c
Compare
igor-aptos
left a comment
igor-aptos
left a comment
There was a problem hiding this comment.
address comments inline, and land
| - Multisig v2 account | ||
| - Sandbox or temporary account to isolate assets/risks, etc. | ||
| - Restricted permissions granted to trusted applications so users don’t need to sign every transaction. | ||
| - Delegation of asset management to a different account (semi-custodial model) |
There was a problem hiding this comment.
at the minimum, other authentication resources (like MulsitigAccount) need to be removed, in order for AA to be able to be registered, right @lightmark ?
lightmark
force-pushed
the
account_abstraction
branch
from
513043c to
2b167c0
Compare
* [AIP] Account Abstraction * Update and rename account_abstraction.md to aip-104.md --------- Co-authored-by: Frances Liu <frances.liu168@gmail.com>
5 participants
AIP for account abstraction on Aptos