I propose not adding a 2step flow, but to add a signature: Span<felt252> param to setPublicKey (*) used to validate that we control the new owner, and that it "accepts" this ownership -- all in a single step.
To make this more user-friendly, i'm using SNIP-12 (aka Starknet's EIP712) and defining the AddOwner operation for the Account.add_owner application.
Even though the account is already present in the hash as required by SNIP-12 and that owner is already known by the owner, I decided to make the struct overly explicit so users know what they're signing, even if it adds a bit of cost/redundancy/complexity.
If we move forward with this proposal, we should probably tackle #409 first.
*: i'd probably go even further an rename it set_owner, since that's the term we're using in the OwnerAdded and that I'm using here too.
Maybe it's worth considering having a 2step mechanism anyway, since in the current design the flow requires a bit of coordination between old and new owner:
Fixes #469, #818.
I propose not adding a 2step flow, but to add a
signature: Span<felt252>
param tosetPublicKey
(*) used to validate that we control the new owner, and that it "accepts" this ownership -- all in a single step.To make this more user-friendly, i'm using SNIP-12 (aka Starknet's EIP712) and defining the
AddOwner
operation for theAccount.add_owner
application.Even though the
account
is already present in the hash as required by SNIP-12 and thatowner
is already known by the owner, I decided to make the struct overly explicit so users know what they're signing, even if it adds a bit of cost/redundancy/complexity.If we move forward with this proposal, we should probably tackle #409 first.
*: i'd probably go even further an rename it
set_owner
, since that's the term we're using in theOwnerAdded
and that I'm using here too.