You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Find a way to improve both the UX and the DevX when signing multiple transactions and messages that simply can't be bulk signed using signAllTransactions.
For example, when minting an NFT using Bundlr, it will require 5 approvals:
One for signing the fund transaction of the first upload (the image)
One for signing a message allowing Bundlr to upload it.
One for signing the fund transaction of the second upload (the metadata referencing the first upload).
One for signing a message allowing Bundlr to upload it.
One for signing the transaction that will create the NFT.
(Note that the two funding transactions could be merged into one)
In these situations, the user will inevitably end up having to click "approve" multiple times. A better UX would be to provide them with a modal like the one below where they can see what they are going to approve and why.
The SDK should probably facilitate that for the developers by providing an abstraction layer on top of "batches of approval" Something that would accept an Array<() => Promise<T>> and keep track of which ones were triggered.
Nothing set in stone, we'd need to discuss in more detail how this would look like concretely by gathering more use cases.
The text was updated successfully, but these errors were encountered:
Find a way to improve both the UX and the DevX when signing multiple transactions and messages that simply can't be bulk signed using
signAllTransactions
.For example, when minting an NFT using Bundlr, it will require 5 approvals:
(Note that the two funding transactions could be merged into one)
In these situations, the user will inevitably end up having to click "approve" multiple times. A better UX would be to provide them with a modal like the one below where they can see what they are going to approve and why.
The SDK should probably facilitate that for the developers by providing an abstraction layer on top of "batches of approval" Something that would accept an
Array<() => Promise<T>>
and keep track of which ones were triggered.Nothing set in stone, we'd need to discuss in more detail how this would look like concretely by gathering more use cases.
The text was updated successfully, but these errors were encountered: