Xstelea wrote about a possible architecture for a synchronous multisig wallet that can used by the DAO members: multisig · GitHub
I like it, my only concern is that it will depend on an offchain backend that combines sub-intents toghether; if that backend goes offline, the wallet will be unusable.
At the same time, I drafted a possible asynchronous multisig wallet: GitHub - nemster/dao_wallet: This blueprint is a wrapper implementing M-of-N multisignature around an Account.
It keeps trace of how many members signed an operation and executes it only when there are enough signers.
It has no external dependencies, the Radix developer console is enough to use it.
I don’t fill like wasting more time on completing it if it will not be used.
Apart from what you mention are there any other pros and cons to consider? And in terms of actual functionality do they both meet the same requirement, but just using a different approach?
Thanks for this post. The multi-sig part is hard. No definite opinion on this just yet, but two thoughts:
Multi-sig is more than just the underlying technology. Many entities pay for some custodian to store their assets and handle the multi-sig (BitPanda, Copper, PrimeVault, etc.). That’s not because multi-sig is so difficult to build, but because you want to outsource the risk of something going wrong, and assets being lost. I believe the Foundation does too, and continuing to use that solution might also be an option?
Your solution is super neat, and requires less dependencies. I like it. But… it is a lot less flexible. You need to hard-code all operations (and I think you cannot easily stitch them together either?). Doing it through sub-intents, a multi-sig transaction could be built just like any regular transaction: write the manifest for exactly what you want to happen.
Before I would make a decision about your vs. Stelea’s approach, I think first a decision needs to be made on whether we want to outsource the multi-sig, or have a crack at it ourselves.
If we’re gonna do it ourselves, I think your solution might be better in the short term (but haven’t given it that much thought yet). Looks like it’s easier to get set up, and also easier for multi-sig signers to create transactions (they don’t have to craft manifests themselves, but we could make a simple interface for your component).
I think we should continue using what the current foundation is using so the hand off can happen as soon as possible. With that already in place we can take time to build our own multisig if we want (ie if our own solution saves enough money from using an off the shelf solution like the current foundation).
The current tool the Foundation uses is PrimeVault.
Announcement when it happened:
I’ve also gone through most of their documentation here:
It does looks like a polished multsig, but I would still like to see a demo for how it is used by the Foundation.
They do charge a premium (my opinion) for their service and it’s probably a bit overkill for our needs, but let’s see what we can develop ourselves to see if it satisfies our basic requirements.
Regarding the cost for their service: Nothing is published publicly (that I can find online), but Adam has provided me the costs the Foundation pays. I’m obviously not going to report those values here since it’s a contractual agreement between those 2 parties, but I do believe we can do better with an in-house/simplified solution.
The multi-sig the community would create won’t happen or the off the shelf solution the foundation uses wont be used by the new entity or there wont be any issues if we use a community solution?
Maybe it’s me being naive … but I expected that in Radix, the use of badges would surpass the multi-sig scenario?
How complex/hard would it be to have a vault/component being controlled by badge proofs in order to have a signaling consensus to carry out a specific instruction?
Sometimes not being a dev is really hard, I keep thinking things are easy?
