PoC: Create (and fund) Subaccounts #4456
Conversation
Branch preview✅ Deploy successful! Storybook: |
Coverage report
Show new covered files 🐣
Show files with reduced coverage 🔻
Test suite run success1584 tests passing in 210 suites. Report generated by 🧪jest coverage report action from 1f75787 |
📦 Next.js Bundle Analysis for safe-wallet-webThis analysis was generated by the Next.js Bundle Analysis action. 🤖
|
| Page | Size (compressed) |
|---|---|
global |
1.16 MB (🟡 +174.16 KB) |
Details
The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!
Eighteen Pages Changed Size
The following pages changed size from the code in this PR compared to its base branch:
| Page | Size (compressed) | First Load |
|---|---|---|
/apps |
47.15 KB (🟢 -1.28 KB) |
1.2 MB |
/apps/custom |
38.78 KB (🟢 -1.28 KB) |
1.2 MB |
/apps/open |
51.06 KB (🟢 -4.13 KB) |
1.21 MB |
/balances |
38.14 KB (🟢 -133 B) |
1.2 MB |
/home |
57.64 KB (🟢 -1.88 KB) |
1.21 MB |
/new-safe/advanced-create |
22.95 KB (🟢 -12.03 KB) |
1.18 MB |
/new-safe/create |
22.21 KB (🟢 -12.03 KB) |
1.18 MB |
/new-safe/load |
5.18 KB (🟢 -9.59 KB) |
1.16 MB |
/settings/environment-variables |
8.87 KB (🟢 -304 B) |
1.17 MB |
/settings/notifications |
26.88 KB (🟢 -176 B) |
1.18 MB |
/stake |
591 B (🟢 -6 B) |
1.16 MB |
/swap |
727 B (🟢 -6 B) |
1.16 MB |
/transactions |
61.44 KB (🟢 -12.26 KB) |
1.22 MB |
/transactions/history |
61.4 KB (🟢 -12.26 KB) |
1.22 MB |
/transactions/messages |
34.23 KB (🟢 -4.98 KB) |
1.19 MB |
/transactions/msg |
24.56 KB (🟢 -4.98 KB) |
1.18 MB |
/transactions/queue |
27.78 KB (🟢 -3.53 KB) |
1.19 MB |
/transactions/tx |
17.56 KB (🟢 -3.53 KB) |
1.18 MB |
Details
Only the gzipped size is provided here based on an expert tip.
First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this.
There was a problem hiding this comment.
Looking and working great 🔥
I added some comments regarding multichain compatibility
Feature wise:
I think we could already add a new page on e.g. route /subaccounts which fetches and lists all SubAccounts / owned Safes of the currently opened Safe and simply offers links to open those.
We could also include the Create button there.
| params: SetupSubaccountForm | ||
| onSubmit: (params: SetupSubaccountForm) => void | ||
| }) { | ||
| const fallbackName = useMnemonicSafeName() |
There was a problem hiding this comment.
Just an idea:
Maybe the fallbackName should somehow relate to the current Safe's name if one is set?
E.g. If the Safe is called "Bob's Safe" we call it something like "Bob's Safe - Subaccount 1"
| } | ||
| }, [safeVersion, safeAddress]) | ||
|
|
||
| const [predictedSafeAddress] = useAsync(async () => { |
There was a problem hiding this comment.
I think we should display this address somewhere.
Otherwise it will be hard to verify that the target of the transactions that transfer assets is correct.
| const { balances } = useBalances() | ||
| const safeVersion = getLatestSafeVersion(chain) | ||
|
|
||
| const [safeAccountConfig] = useAsync(async () => { |
There was a problem hiding this comment.
We have a helper createNewUndeployedSafeWithoutSalt which will end up with SafeAccount configs that create multichain compatible Safes.
It is not compatible with the core-sdk though. So it comes with its own methods to deploy / predict the address:
- predictAddressBasedOnReplayData
- createNewSafe
There is a new version of the protocol-kit that could allow us to get rid of this workaround but it contains multiple breaking changes.
Thank you for the thorough review (I agree with everything). Since this is a PoC and subject to change, I’ll leave your comments as unresolved for the time being and reference them when we plan this out properly. |
What it solves
We want to make the deployment and usage of Subaccounts easier. Currently the methodology behind creating (and funding) a Subaccount is complex.
This adds a new transaction flow (accessible via a temporary button in the sidebar) to create (and fund) a Subaccount in one transaction.
How this PR fixes it
A new button located in the sidebar opens a flow where you can name and select the desired assets to fund a Subaccount with. After selection, a (batch) transaction achieving this can be queued/executed.
How to test it
Screenshots
Checklist