Hi there! We’re making a multisig wallet called Asigna.
While we were preparing the first multisig to come out, we tried to implement it using two opposite approaches, and both of them had complications that blocked us on our way.
The first approach is to utilize the native multisig transactions on Stacks.
The main problem which we’re facing right now with this approach is that owners of multisig wallets have to sign transactions only in the order their public keys were added to the multisig which is described in this issue. This prevents multisig applications to use this logic because it adds logic for signing orders, which is not applicable to a proper user-friendly multisig solution.
The second thing that is missing is that in micro-stacks and stacks.js packages there’s nothing like openSignMultisigTransaction. There are openSignMessage, openSignStructuredMessage, openSignTransaction, but it is not currently possible to connect to wallets on Stacks and add a signature to a multisig transaction.
The last thing in this method is that we need also a standard for message signature verification, which sometimes is crucial for dApps like marketplaces, exchanges, authorization purposes, etc.
The second approach is to make a smart contract wallet.
This way has even more complications on the way. The first one is that the Clarity language does not allow to call of arbitrary contracts and needs to have a standard trait defined for external smart contract calls, which is proposed in this SIP - github.com/fess-v/sips/blob/smart-contract-wallets-external-calls-standard/sips/sip-02X/sip-02X-smart-contract-wallet-external-call-standard.md.
The second thing is as well about message signatures, similarly to smart contract wallets on Ethereum like Gnosis, we should define a standard for signed messages for the same purposes described above, this is also proposed in another SIP - github.com/fess-v/sips/blob/smart-contract-signature-verification-standard/sips/sip-02X/sip-02X-smart-contract-signature-verification-standard.md.
Full list of advantages/disadvantages of the native approach:
Advantages:
- Message signature verification is easier
- Can call any contracts within Stacks without making forcing them to make additional interfaces
- No additional smart contract risks
Disadvantages:
- Owners and threshold can’t be changed, otherwise a new multisig address will be generated and all funds will need to be moved from the previous multisig
- Hiro and other wallets, as well as micro-stacks and stacks packages should add functions which support multisig transactions and multisig message signatures & verification
- Message signatures & verification should be standardized anyway
Full list of advantages/disadvantages of the smart contract approach:
Advantages:
- Possibility to add and remove owners, change the confirmation threshold
- No need to have additional calls in micro-stacks for multisignature transactions
Disadvantages:
- Have to accept the SIP proposal for external calls, which adds additional work for any dApp which wants to be integrated with a multisig wallet
- Signature verification is more complex and a SIP is also needed
- Smart contract wallets imply additional development risks
Overall summary
Both ways have their own positive and negative sides, while the first native approach is still more appealing because it doesn’t force application developers to make additional work for making executor interfaces using the SIP mentioned above. But for this approach, the issue with signature orders should be fixed as well as client-side libraries should also support native multisig transactions. While the second thing shouldn’t be complicated, the first one could block the whole process for a while. We’re looking to get the initial feedback for our approaches, which will help us on our way of making a fully functioning multisig solution for the Stacks ecosystem.
P.S. Both ways also require additional work for the frontend SDK part, which will make the cross-domain communication possible between the web multisig page and internally opened in iframes dApps, but it’s not the main complication point and can be easily solved.
P.S.S. SIP links were attached in that way due to a limit of 2 links maximum.
