Multi-signature wallet for Stacks blockchain

[talhasch]

Background What problems do you aim to solve? How does it serve the mission of a user owned internet?

This is a grant application to build "Gnosis Safe" equivalent multi-signature wallet infrastructure for Stacks blockchain.

A multi-signature wallet is an essential tool for those want to manage blockchain resources like smart contract ownerships or funds (tokens, nfts, stx...) as multiple parties.

Project Overview What solution are you providing? Who will it serve?

I will build a multi-signature wallet smart contract and a web UI which will allow Stacks blockchain users to create and manage wallets, sign multi-signature transactions in ease.

Scope What are the components or technical specs of the project? What will the final deliverable look like? How will you measure success?

Final deliverables will be consist of these two main components:

1- A multi-signature wallet smart contract written in Clarity. Proof of work version can be found here.

2- A web UI developed with react.js. Anyone will be able to self host it and create their own multi-signature wallets and sign transactions.

All the code will be open source under MIT Licence.

Budget and Milestones What grant amount are you seeking? How long will the project take in hours? If more than 20, please break down the project into milestones, with a clear output (e.g., low-fi mockup, MVP with two features) and include the estimated work hours for each milestone.

Total Grant Request: $55K

M1: Stable version of the multi-signature wallet smart contract. ~100 hours. $25K

M2: The first version of the Web UI. ~160 hours. $25K

M3: Bug fixed & stable version of the Web UI. ~20 hours. $5K

Estimated delivery in 280 hours, 3 months.

Team Who is building this? What relevant experience do you bring to this project? Are there skills sets you are missing that you are seeking from the community? Please share links to previous work.

Talha Buğra Bulut, a full stacks software developer and known as founder of Runkod around the Stacks community.

Risks What dependencies or obstacles do you anticipate? What contingency plans do you have in place?

The only risk is smart contract security. I will be requesting help from Stacks/Hiro teams to review my code to make sure it is bug free.

Community and Supporting Materials Do you have previous projects, code commits, or experiences that are relevant to this application? What community feedback or input have you received? How do you plan to share your plan to the community over time and as the final deliverable?

A prototype of multi-signature wallet contract is here. Please note that it is not final product but proof of work.

I'll share my plan and progress of the project on the community channels of Stacks and ask feedback from people. Since this project will be very beneficial for espacially developers, i believe i'll receive a lot of useful feedback to shape the final product.

[stx-grant-bot[bot]]

Thanks for submitting a grant proposal. Our team will review your submission and get back to you.

[tycho1212]

+1 on this. You should talk to Chris Castig about this. He really wants this to exist

[castig]

Brilliant! Yes, stacks needs a Gnosis Safe equivalent. I'll shoot you an email, let's find a time to chat. +1 this proposal.

[JakeBlockchain]

Super needed for many use cases. Might want to touch base with Ryan Waits (@ryan_waits). He is building some DAO tooling and might have something like this in early stages of development.

[friedger]

Yes, please!

And then later better support for off-chain multi-sig txs: https://github.com/stacks-network/stacks-blockchain/issues/2808

[louiseivan]

@talhasch great that you're back, and I love the idea! My question would lie more on maintenance. What are you going to do after building the multi-sig wallet? Who will maintain it?

I believe we want to mitigate the risk of devs abandoning products like what happened before pre-Stacks 2.0.

What would be best here is to collaborate with other wallet providers in the ecosystem, let's see how we can divide and conquer as a community. I can easily connect you with them.

[castig]

Yes! I believe a "Gnosis Safe"-like multisig is crucial for bringing DAOs to Stacks/Bitcoin in a meaningful way. Today, Gnosis Safe stores over $100b of USD assets. It's become the backbone of so many projects on Ethereum. If we are going to build Bitcoin DAOs, we first need a multisig.

1) Potential hurdles — This week I heard from @orlando.btc @ryanwaits that there might be some issues ahead though - apparently Stacks wallets can only sign regular transactions, and aren't capable of signing "sponsored transactions" (i.e. where someone other than the person executing the transaction can pay the gas fees for the transaction). But I think it is possible if everyone on the contract pays their own gas. So either this is the compromise we'll have to make, or potentially we can team up with someone at Hiro for help?

2) Maintenance — @louiseivan Great feedback regarding maintenance. I could see this living in the Hiro family of product - but at the same time I've heard that Hiro is backlogged on features for quite some time? So it might be something the community has to develop.

Very happy to help collaborate on this! P.S. If anyone hasn't used the Gnosis Safe before, happy to add you to a sandbox Safe of mine and take you on a tour of the functionality.

[talhasch]

It is so nice to see such support, feedback and brainstorming here.

@castig thank you very much for your interest and feedback so far. I would be so happy to see your collaboration with this project. As you mention, multisig wallets a very crucial component and what mid/large teams and enterprises check before they move their funds or deploy their code on a chain.

I think Stacks wallets (Hiro wallet or others..) shouldn't integrate multisig capabilities and should stay easy to use as much as possible for average users. It makes more sense to me to use a separated web UI for multi-sig transactions since it requires a certain level of technical knowledge.

@louiseivan i understand your concern about maintenance and i noticed that i haven't mentioned my long term plans about this project. (sorry i'm not too comfortable with filling long forms:) With this project my vision is to build an open source multi-signature infrastructure and build a business around it later with extra features while maintaining core codebase. So anyone will be able to create their own multisig wallets, sign transaction and manage funds or resources on Stacks chain. If they need extra features or support there will be a business to provide service. Gnosis says that they store value around $100b. Considering tvl on bitcoin ecosystem and Stacks is the first true smart contract platform connected to bitcoin, $100b is not too big and there is a big opportunity to try to create this kind of business.

What happens if things don't go as i envision or i disappear somehow? (i have no intention at all but want to animate what could happen in worst scenario) Stacks ecosystem would have a fully fledged multi-signature infrastructure and since it is a smart contract centric and open source software, it continues to work and funds on wallets remains safu. If something went wrong on UI code any dev from the community could fix it easily.

[tycho1212]

Side note: you'd have to ask Hiro but I don't think this type of product is a fit for the strategy they're pursuing (developer tools) so a good plan to help this product live long term is necessary :)

[will-corcoran]

@talhasch Very excited to receive and approve this proposal!
The one caveat we would like to add is only approving M1 and M2 at this time. We would like you to re-evaluate the scope of M3 when you get closer to completing the project and we will solicit feedback from @friedger @tycho1212 @castig and others to ensure we budget in top notch smart contract auditing and give a continuity plan a bit more consideration. If you agree to this revision - we will disburse M1 and revise the contract total to $50k. Best, Will

[will-corcoran]

@talhasch when you respond regarding the fee revision can you also let me know if you would be open to a weekly or bi-monthly call with @castig from Trust Machines on this topic. He has a sincere interest in collaborating with you on this and factoring your work into some DAO tooling he is working on. He would be open to providing UI design support and auditing.

[aulneau]

@talhasch this is a very promising grant request! as others have stated, I also think this is very much needed. I took a look through some of your repos and code around the clarity stuff that would enable a gnosis like safe, very exciting!

My main questions would be around how you expect end users to interact with this? My understanding is that wallets need to be able to support multi-sig transactions. Currently none of the most popular Stacks wallets offer multi-sig support. Additionally, the ledger stacks app does not support multi-sig transactions, either.

I think Stacks wallets (Hiro wallet or others..) shouldn't integrate multisig capabilities and should stay easy to use as much as possible for average users. It makes more sense to me to use a separated web UI for multi-sig transactions since it requires a certain level of technical knowledge.

This comment worries me a bit -- are you suggesting that you'd build out a completely separate wallet, distinct from something like Hiro's or xverse's? To me, that seems like a much larger, and more complex undertaking than building out contracts and UI to interact with those contracts.

From my understanding of what you've proposed, it sounds like you'd build out a react application which would handle private keys in order to correctly sign these transactions. I think there are a number of problems with that direction -- users should really never enter private keys into a web application, hence the move away from a web-app based wallet to the extension model that Hiro took. I could see how you might want to interact with the ledger software such that the signing would happen on hardware devices, but that also unfortunately is not currently possible (as far as I know).

To me, this direction requires extensive knowledge of building wallets, cryptographic best practices, and many security audits.

Any comments you might have on this would be super helpful!

[talhasch]

@talhasch Very excited to receive and approve this proposal! The one caveat we would like to add is only approving M1 and M2 at this time. We would like you to re-evaluate the scope of M3 when you get closer to completing the project and we will solicit feedback from @friedger @tycho1212 @castig and others to ensure we budget in top notch smart contract auditing and give a continuity plan a bit more consideration. If you agree to this revision - we will disburse M1 and revise the contract total to $50k. Best, Will

@will-at-stacks I agree to this version 🎉 We already in touch with @castig and he is already helping. We can start to arrange regular meetings with him when project made some progress.

[talhasch]

@talhasch this is a very promising grant request! as others have stated, I also think this is very much needed. I took a look through some of your repos and code around the clarity stuff that would enable a gnosis like safe, very exciting!

My main questions would be around how you expect end users to interact with this? My understanding is that wallets need to be able to support multi-sig transactions. Currently none of the most popular Stacks wallets offer multi-sig support. Additionally, the ledger stacks app does not support multi-sig transactions, either.

I think Stacks wallets (Hiro wallet or others..) shouldn't integrate multisig capabilities and should stay easy to use as much as possible for average users. It makes more sense to me to use a separated web UI for multi-sig transactions since it requires a certain level of technical knowledge.

This comment worries me a bit -- are you suggesting that you'd build out a completely separate wallet, distinct from something like Hiro's or xverse's? To me, that seems like a much larger, and more complex undertaking than building out contracts and UI to interact with those contracts.

From my understanding of what you've proposed, it sounds like you'd build out a react application which would handle private keys in order to correctly sign these transactions. I think there are a number of problems with that direction -- users should really never enter private keys into a web application, hence the move away from a web-app based wallet to the extension model that Hiro took. I could see how you might want to interact with the ledger software such that the signing would happen on hardware devices, but that also unfortunately is not currently possible (as far as I know).

To me, this direction requires extensive knowledge of building wallets, cryptographic best practices, and many security audits.

Any comments you might have on this would be super helpful!

Thanks for your input @aulneau

Basically the multisig wallet i propose is a clarity smart contract. Users will interact with it through a web UI that works with Hiro wallet (a reactjs-stacks dapp basically and other wallets can be integrated later). They can create new wallets (basically deploying a new contract) and manage resources on the them such as STX, tokens, NFTs etc... So the UI part won't be requiring private keys or similar kind of sensitive information.

Let me explain with an example: Let's say Alice is a part of an organization and the organization wants to send some STX from the multisig wallet to someone else. There are ten owners of the wallet and minimum confirmation requirement is six. Alice logins on the UI with Hiro wallet, starts the transaction with some clicks, and other owners confirms the transaction. The transaction gets executed once it receive six confirmations in total. I hope it makes sense.

[aulneau]

Basically the multisig wallet i propose is a clarity smart contract. Users will interact with it through a web UI that works with Hiro wallet (a reactjs-stacks dapp basically and other wallets can be integrated later). They can create new wallets (basically deploying a new contract) and manage resources on the them such as STX, tokens, NFTs etc... So the UI part won't be requiring private keys or similar kind of sensitive information.

Right, this makes sense. Thanks for the clarification!

However, the application won't be fully usable until a wallet such as Hiro's web wallet supports multi-signature transactions. Wallets need to be able to handle a transaction that takes multiple signatures. The react application nor the clarity contract would not be able to correctly construct the multi-sig transaction without using private keys, thus a wallet needs to be able to support that.

Just wanted to make sure everyone involved realized this, and that there needs to be upstream changes to any of the popular wallets to enable applications that make use of multi-sig transactions.

[talhasch]

A multi-signature transaction is a record on a smart contract. Wallet owners creates it by sending real blockchain transactions with Hiro wallet. I think "transaction" term confuses here. It maybe a good call to work on this naming first 🤔

[aulneau]

@talhasch I see, that makes sense in this context. Thanks for the additional clarification.

I think these technically would not be considered multisig transactions, but instead each individual would call a function in the contract approving or denying a given activity.

Traditionally, multisig means multiple private keys sign a transaction before broadcast.

[will-corcoran]

@talhasch and @aulneau - Great to see this dialog taking place. @talhasch I am going to go ahead and approve the grant now for $50k - nice to hear you are already collaborating with @castig. Clearly this project has a lot of interest and possible applications. Please stay in touch during the development process. Best, Will

[stx-grant-bot[bot]]

Congratulations. Your grant is now approved. Please complete the on-boarding link here: https://grants.stacks.org/onboard?q=ecd99548ca318bf72d587901d331719e

[castig]

Thanks @aulneau @will-at-stacks @talhasch!

I think these technically would not be considered multisig transactions, but instead each individual would call a function in the contract approving or denying a given activity.

Yes, that's how I understood Talhasch's approach — The Clarity contract doesn't sign with your private keys (is that even possible with either BTC or ETH? If so I'd love to see an example @aulneau so I can learn more.). — I believe Talhasch's implementation is similar to how Gnosis Safe works. Gnosis is just a series of Solidity smart contracts, and once the function clears "2 out of 3" users then finally it goes ahead and executes the transaction on-chain.

Technically that would work, no?

And most importantly, I think this implementation would work well for STX DAOs. Right now most STX DAOs are keeping their treasury funds in singe signature wallets, controlled by one person, and so we want to offer a solution whereby a community can lock their funds in a smart contract, and distribute the power to withdraw funds across 2+ people.

[ryanwaits]

The Clarity contract doesn't sign with your private keys (is that even possible with either BTC or ETH?

im not sure of the exact implementation details that go into passing along a tx across multiple wallets, but the clarity contract would not sign with your private keys - however it could provide functions to check for valid signatures along the way that are signed by the wallet (currently not available with hiro), which is how i believe gnosis safe works https://github.com/gnosis/safe-contracts/blob/da66b45ec87d2fb6da7dfd837b29eacdb9a604c5/contracts/GnosisSafe.sol#L145

Basically the multisig wallet i propose is a clarity smart contract. Users will interact with it through a web UI that works with Hiro wallet (a reactjs-stacks dapp basically and other wallets can be integrated later). They can create new wallets (basically deploying a new contract) and manage resources on the them such as STX, tokens, NFTs etc... So the UI part won't be requiring private keys or similar kind of sensitive information.

so this almost reads more like on-chain proposal contracts rather than a multisig - right? as technically there would be some state logic in the contracts that would presumably "vote" on execution by broadcasting their own tx's before being able to execute the original tx proposal...am i understanding that correctly?

[talhasch]

@ryanwaits yes, that's correct. Basically an owner creates a proposal (transaction), it gets approved when it receives enough confirmations from other owners, and a separated smart contract linked to the proposal gets triggered with authority of the multisig wallet contract.

The link you shared above is from newer gnosis safe wallet source code. They transformed their multisig wallet in a way that they collect all owner signatures into a centralized data store and send them all with the last owner's approval to the wallet. So only the last owner pays fees and previous approvals off chain.

Although it is possible to verify signatures with Clarity and create a similar wallet to that we go with the older version of Gnosis Safe approach which all approvals stored on chain. Because it's not an option to depend on a centralized data store (or a backend) since one of the main goals of this project is to provide an open source and easy to deploy multi signature wallet. Additionally we are not dealing with ethereum level tx fees.

[castig]

Updates: @talhasch and I have been working on the "Multi-Signature wallet" together. We're calling it MultiSafe. We'd love to invite you to test, or contribute to the project when we publish the smart contract code on April 1st. Stay tuned.

Here's the latest updates:

1) MultiSafe Project Roadmap — Notion

2) Wen MultiSafe? April — Smart Contract Testing May — Simple UI testing June — 1st security audit

3) Follow the project on Twitter: https://twitter.com/multisafexyz

[will-corcoran]

hey @castig and @talhasch thanks for the update! really looking forward to the demo. I am OOO from 4/2-4/14. Castig, I will send you and invite for 4/1. If it works, please forward it to Talhasch as I don't have his email. Thanks, Will

[talhasch]

hey @castig and @talhasch thanks for the update! really looking forward to the demo. I am OOO from 4/2-4/14. Castig, I will send you and invite for 4/1. If it works, please forward it to Talhasch as I don't have his email. Thanks, Will

Hey @will-at-stacks please use talhabulut@hotmail.com

[larrysalibra]

This is a really great initiative and I'm super excited to see progress on it!

Apologies if this question is totally off-base and stems solely from my confusion/ignorance:

Doesn't Stacks already have multisig built in at the chain-level? A number of us had tokens in multisig wallets prior to stacks 2.0 launch and we are able to move funds and/or execute smart contracts using funds in those wallets. The process involves also making bitcoin transactions to "prepare" the Stacks 2.0 chain. I'm not sure if it functions independently of bitcoin.

https://github.com/stacks-network/stacks-blockchain/blob/85f07f1aa74638458ac118627477d05936994841/src/chainstate/stacks/transaction.rs#L694

Can/should this existing functionality be integrated with this initiative?

[castig]

Thanks @larrysalibra! That's helpful.

1) Is there any documentation or examples of how to use the Multi-Sig feature your referencing? Curious to learn more how it's used in practice.

2) Part of our initiative, is to create a Clarity contract + friendly UI so that its easy enough for anyone to deploy a multi-sig.

3) With that said, perhaps if there is some built-in multi-sig functionality in Stacks already we could somehow leverage that. I'm not sure exactly. @talhasch what are your thoughts?

[aulneau]

@castig one thing I'd suggest is maybe changing the title of this grant/project. I think the use of "multi-sig" is a bit misleading/not accurate. The concept of using a contract to track approvals is much different than a "multi-sig" transaction, which I think will lead to a lot of confusion such as what @larrysalibra is getting at.

As I've mentioned a few times, for true "multi-sig" support, a major wallet would need to implement support for multi-signature transactions. Until that happens, no application would be able to make use of them.

Perhaps "multi-party" is a better term for this kind of application.

Just my 2 ustx :~) happy to expand on it more

[castig]

@aulneau What are your thoughts on calling it a "Multi-sig Safe" (not a wallet). @talhasch and I were drawing inspiration from Gnosis which uses "multi-signature" in their branding. It's also an easy way for people to quickly grasp the concept. Happy to chat more on a call or here. Thanks!

[aulneau]

@castig maybe "multi-party safe" I think the main issue is the use of signature in any form, because that has real, technical implications around anything related to transactions/crypto generally :)

[larrysalibra]

@kantai might have information about pre-stacks 1.0 multisig and the degree to which it is applicable to stacks 2.0. And if there’s code or documentation that can be shared.

@aulneau you’re right about the confusion!

I was on a call yesterday and someone wanted multisig support for BNS name ownership and I was pointed to this issue.

[kantai]

Yes -- multisig support is available at the transaction signing level, with addresses represented the same as if they were Bitcoin p2ms-over-p2sh addresses (though encoded as C32 addresses, with the Stacks network bits). These addresses appear in Clarity as if they were any other principal instance.

There are two ways in which these multisig addresses (and any other addresses) can issue transactions in the Stacks network today.

The first way is like any other Stacks network transaction: a signed transaction, broadcasted to a stacks-node, propagated through the mempool, and mined by a Stacks miner. These transactions follow the wire format and signing scheme described in SIP-005: Transaction Signing and Verifying, and the implementation of the verification scheme can be found in the stacks-blockchain repo:

https://github.com/stacks-network/stacks-blockchain/blob/master/src/chainstate/stacks/auth.rs#L252

The stacks-blockchain repo also contains an implementation of a signer for the multisig scheme.

There is some library support for these kinds of multisig transactions via stacks.js, and, I believe, there is limited hardware support on the Stacks app on ledger devices (I think it may only function for 2-of-n multisig transactions).

The second way of sending transactions is using Stacks-over-Bitcoin transactions. These are limited transactions that can only perform stx-transfer and stack-stx invocations. The wire format and operation of these is described in SIP-007: STX Operations on Bitcoin. These transactions are Bitcoin network transactions, sent from the Bitcoin address corresponding to the Stacks address that will be used as the tx-sender for those transactions. The requirement of sending and linking a PreStxOp with these transactions presents a significant user burden. I wrote a set of web scripts for producing these transactions using a Trezor device, available at hirosystems/multisig-stx-btc. This script was written long ago, in the times of Stacks 1.0, and has been adapted for use in 2.0, and as such, the libraries used, and requirements of the Trezor device firmware are quite out-of-date. However, the script probably is a decent starting point for anyone interested in supporting these kinds of Stacks-over-Bitcoin transactions. However, I should reiterate, that the user experience of the Stacks-over-Bitcoin transactions is much more odious than the normal Stacks transactions, and that supporting multisig using the first scheme will likely produce a much better user experience.

[talhasch]

@kantai thank you so much for broad explanation!

@larrysalibra thanks for letting know about the built-in multi-sig feature of Stacks.

@castig Let's take a look if we can integrate built-in multisig features of Stacks (or take advantage of it in a way) after we release our first version.

@aulneau Thank you for your feedback. But i don't think it's necessary to change title of this issue because what we are building is also a multi-sig wallet.

I know when you hear "multi-sig" it feels like it must be something low level requiring some complex cryptologic math calculations etc...

MultSafe allows multiple parties to manage funds (stx, token, nft) executing transactions via their Hiro wallets by signing some data with their keys. This makes it a multi-sig wallet.

[castig]

You can now deploy a MultiSafe contract: http://multisafe.xyz/

• We invite you to deploy a MultiSafe on mainnet/testnet.
• We'd love all and any feedback, especially from anyone who is able to review our Clarity code.
• Please be aware that the code hasn't been audited by an independent security team yet.
• We are planning a formal audit of the Clarity contract in July 2022

[markmhendrickson]

Congrats on the forward progress! If you ever want to sync with the Hiro Wallet team about your plans here, please feel free to reach out (mark@hiro.so).

FWIW I also suggest the "multi-party safe" naming instead of "multi-sig" to help reduce confusion here.

[will-corcoran]

Hello and thank you for participating in the Stacks Foundation Grants Program!

We are in the process of migrating from GitHub to the new Grants Dashboard. In order to complete your grant, you will need to submit any remaining Progress Review and/or Final Review requests through the Dashboard in order to receive your remaining payments.

• If you have questions about the Grants Dashboard in general please email ambassadors@stacks.org.
• If you have questions regarding payments and/or contracts please email payments@stacks.org.

Lastly, please note we are marking this grant 'closed' on GitHub for organizational purposes, but it is still 'open' on the Grants Dashboard.

Thanks and we hope to continue to support your efforts with additional grants!

Best, Will

[castig]

To everyone following the progress of MultiSafe.xyz — I made a 10m explainer video on how to use MultiSafe to deploy a STX DAO. Please reach out to me here, or on Twitter @multisafexyz with any questions.

YouTube Video -> https://www.youtube.com/watch?v=kA1iEvbll7E

[larrysalibra]

Checked out the video...@castig looks great!

[314159265359879]

I did some user testing, I really like the ease with which the dapp works, it is easy to set up and manage the contract, add/remove users and approve/decline transactions. I like that one can just as easily make a vault with no obligation to be one of the owners. I am looking forward to seeing support for more assets. I think this is a very valuable addition for the Stacks ecosystem.

One feature I would love to see is BNS-names with the Stacks addresses (basically anywhere were you see a STX address), it makes it much easier to identify who owns what address and even to help double-check we have the right address in the first place.

At this stage design is probably still being worked out, some things I would like to see:

1. On login, show contracts with the multisafe trait deployed by that address, so I can click the one I want to load.
2. When a user inputs a Stacks address into the "load contract" field instead of a contract address: load all the contracts so they can be clicked to load.

How did you arrive at 20 for the maximum number of participants? I am certain this will suffice for many cases, I am simply wondering if there are technical limitations that restrict this number from being much higher.

[talhasch]

I did some user testing, I really like the ease with which the dapp works, it is easy to set up and manage the contract, add/remove users and approve/decline transactions. I like that one can just as easily make a vault with no obligation to be one of the owners. I am looking forward to seeing support for more assets. I think this is a very valuable addition for the Stacks ecosystem.

One feature I would love to see is BNS-names with the Stacks addresses (basically anywhere were you see a STX address), it makes it much easier to identify who owns what address and even to help double-check we have the right address in the first place.

At this stage design is probably still being worked out, some things I would like to see:

1. On login, show contracts with the multisafe trait deployed by that address, so I can click the one I want to load.
2. When a user inputs a Stacks address into the "load contract" field instead of a contract address: load all the contracts so they can be clicked to load.

How did you arrive at 20 for the maximum number of participants? I am certain this will suffice for many cases, I am simply wondering if there are technical limitations that restrict this number from being much higher.

Thanks for feedback @314159265359879 !

We are working on a UI update and it'll include all features you suggest. BNS to address resolution, quick access to previously used safes, built-in sip-009, sip-010 token support and much more...

We picked 20 as maximum owners depending on some previous experiences with decentralized organizations/projects. The max owner count i've ever seen was 13 on a gnosis-safe contract of a community driven DEX. So 20 would be sufficient for almost all cases.