The aim of this post is to provide another approach for having and working with threshold signatures like 3-of-5 or any other using the assembler service!
Why Not ZK-Treasury
Currently, using threshold signatures and collective signing is possible using the ZK-Treasury, however, users need to set up their own nodes and also run the ZK-Treasury app!
By using this approach, users can use any wallet capable of managing tokens to simply spend assets collectively. Only the user’s wallet and the assembler service will be enough for this approach to work, meaning, no separate app, node, or server is needed!
The New Approach
Let’s suppose a group of 10 people want to manage some assets together (for any reason) with 6 out of 10 of them being able to spend the assets.
They will first issue a token with the quantity of 10 and distribute between each other, this is simply possible using the assembler service!
Then they will send their assets to the p2s address derived from the following contract:
{
val inTokens = INPUTS.fold(0L, {(x:Long, b:Box) => {
val cur = b.tokens.fold(0L, {(y:Long, t:(Coll[Byte], Long)) => y + {
if (t._1 == tokenId) t._2 else 0L
}})
x + cur
}
})
sigmaProp(inTokens >= 6)
}
The above contract simply counts the number of valid tokens in the transaction’s input and let the box be spent if there are at least 6! It is obvious that a box protected by the above contract is only spendable if at least 6 of the 10 members participate.
The next thing needed is a contract which guarantees that if a member sends her token to it, it will be used only for the input of the transaction spending group’s assets (protected by the mentioned contract) and then return the token to the same user in the same transaction. This contract can also guarantee a specific transaction, hence, a predefined usage of assets so that it won’t be used to spend the assets in a way that the user didn’t agree to.
Basically, such a contract is mostly like the one explained here and the aim of it is to prevent misusage of user’s assets. This contract is skipped as it is mostly trivial.
Now, using the assembler service, if a member wants to participate in some collective spending, then she can use her favorite wallet and send her token to the explained contract; her token will be returned to her in the same transaction that spends the assets.
For using this approach, members need a platform for communication maybe!
Many details are skipped and some other minor works are needed for the above approach to actually work without any barriers, nevertheless, I thought it was worth sharing!