feat: subaccount design using spend function #387
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This subaccount design is based of a new function that we introduce in the account called
spendspecifically for ERC20 token payments.A super admin key can approve spends spend permissions on the account, and since we handle the transfers inside the
spendfunction, we can guarantee that the limits are tracked and enforced correctly.We then use this
spendfunction to create a parent <> subaccount architecture using 2 way spend permissions.Flow
Spend Permissionin the subaccount, withisParent=true, which allows the parent account to sweep any amount of funds, whenever it wants from the subaccounts.Spend Permissionin the parent account, withisParent=false, which allows the sub account to pull some limited amount of funds from the accounts, whenever the DApp requires it.This architecture is different from PR #232 , because that PR treats the parent account as a master key of the subaccount, which means it transfers funds to and from the subaccount using authentication.
But this architecture transfers funds between the 2 accounts, using a dedicated spend function where you can control the flow of funds in either direction.
Note: You don't need to always create a subaccount to use the spend permission. For simple use cases, you can assign a spend permission directly to the DApp. But in this case, the DApp will have to be aware that it can pull funds from the account only using the
spendfunction and directtransfer/transferFromrequests will not work ( since this is not a session key )