We have fairly involved and potentially slow logic for account creation and recognizing that an account exists from the client side.
Allowing a user to derive the component address and build a transaction offline (without having to first assert whether the account exists and adjust the transaction accordingly) will greatly improve UX.
Proposal 1
The following flow should apply:
a user derives the account component id from a public key (e.g. derive_component_address_from_public_key(PublicKey, TemplateAddress))
the user calls deposit on the derived account
if the engine sees that this account does not exist, it creates a new account component for the public key
the engine calls deposit as normal
Considerations:
the component should be an input - however this is currently invalid if the component does not exist
option exists to create a separate substate type called Account. In addition to making it clear that a substate is an account from a user perspective, it allows accounts to be optimised for the use case and allows the engine to implement specific cases for the Account substate type. e.g. account_xxxxxx...xxxx
Problem
We have fairly involved and potentially slow logic for account creation and recognizing that an account exists from the client side. Allowing a user to derive the component address and build a transaction offline (without having to first assert whether the account exists and adjust the transaction accordingly) will greatly improve UX.
Proposal 1
The following flow should apply:
derive_component_address_from_public_key(PublicKey, TemplateAddress))Considerations:
account_xxxxxx...xxxx