Implementing a fully functioning multisig wallet on Stacks

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:

  1. Message signature verification is easier
  2. Can call any contracts within Stacks without making forcing them to make additional interfaces
  3. No additional smart contract risks

Disadvantages:

  1. 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
  2. Hiro and other wallets, as well as micro-stacks and stacks packages should add functions which support multisig transactions and multisig message signatures & verification
  3. Message signatures & verification should be standardized anyway

Full list of advantages/disadvantages of the smart contract approach:
Advantages:

  1. Possibility to add and remove owners, change the confirmation threshold
  2. No need to have additional calls in micro-stacks for multisignature transactions

Disadvantages:

  1. 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
  2. Signature verification is more complex and a SIP is also needed
  3. 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.

4 Likes

After our discussion on the weekly SIP call, we decided to go with the native approach for now and make a SIP proposal to speed up things with the ordering issue

I’ll attach the SIP when a draft is created

1 Like

Hi Vlad, thanks for updating us on your proposal! I hope many others can chime in on your proposal. We host a SIP Editor call bi-weekly, next call is on the Thursday 11th May.
Editors are the group of people who will be doing the first review pass on your proposal, support proposers that the draft is done according to guidance.
Feel free to join our call!

1 Like

Last Friday’s SIP call, Asigna team Vlad @fess-v & @ viven kindly joined and shared more details and demo their Advanced Bitcoin&Stacks Multi-sig wallet solution

Thank you kindly Vlad.

Recording will be published on Youtube within the next 2 weeks: Stacks Community - YouTube

1 Like

Thanks, Hero! Following up on the conversation, I created a PR (Signature order-independence fix for multisig tx by fess-v · Pull Request #3710 · stacks-network/stacks-blockchain · GitHub) for the stacks blockchain repo to proceed with our discussion of the problem and potential solutions.

1 Like

Dropping the result here. stacksgov/sips/pull/152 (can’t post a link, it’s on github) We’re working with @jbencin on the order-independent version of the SIP, with the same implementation link in the comment above. Planning to make this change with the Nakamoto upgrade :crossed_fingers:

2 Likes