Multi VM compatible Multi Signature Wallet

[ashWhiteHat]

Project Abstract

A Multi-Signature Wallet that is user-friendly and simplifies the management of crypto assets across both Wasm and EVM.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (DOT, USDC & USDT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).

[PieWol]

Hey @ashWhiteHat ,
thank you for your interest in our grants program. The idea of a multisig solution that supports both substrate and evm chains sound great. Have you considered to extend existing multisig solutions that already cover the substrate side and have a great UX already? See https://polkadotmultisig.com/ which is powered by Signet from Talisman Wallet. Their code is open source. I'm interested to hear what you think about extending existing projects.

[ashWhiteHat]

Hey @PieWol
Thank you for your feedback.
As you mentioned, we considered extending the existing multisig wallet to support EVM, but this would result in high gas costs or exceed the EVM gas limit due to compatibility issues.
The current multisig wallet relies on BLS381, whose interface is not supported by EVM.
Implementing curve operations and signing algorithms from scratch for EVM compatibility would be inefficient and require substantial gas costs.
This would be user-unfriendly and impractical.
Instead of extending the existing multisig wallet, we propose implementing an EVM-compatible multisig as a Substrate pallet.
This approach will enable multi-VM compatibility while providing a user-friendly experience.

[Noc2]

@ashWhiteHat thanks a lot for the application. In general, this sounds interesting to me. However, I have one concern here: Given that you already worked on various projects in the past (https://github.com/w3f/Grants-Program/pulls?q=is%3Apr+author%3AashWhiteHat+is%3Aclosed). Is this more of a side project or do you actually plan to focus on it and get it production ready?

[ashWhiteHat]

Hi @Noc2
Thank you for the question.
This is main project.
As I mentioned before, these applications have been already delivered.
#1788 (comment)

[keeganquigley]

Hi @ashWhiteHat thanks for the application. I agree that this sounds interesting, but I'm curious about the implications of using an EVM-compatible substrate solution vs. a typical EVM smart contract multi-sig. Would it possibly introduce any performance overhead or compatibility requirements? How would you ensure that the pallet functions correctly within the substrate runtime?

[ashWhiteHat]

Hi @keeganquigley
Thank you for the review.

Firstly, the primary motivation(implication) of this proposal is to create a multi-signature wallet that supports both EVM and Wasm with a single private key. This simplifies private key management and allows for a single setup to create a multi-signature wallet for both EVM and Wasm.

Would it possibly introduce any performance overhead or compatibility requirements?

Implementing equivalent functionality in EVM with Substrate's existing multi-sig support results in overhead and performance degradation.
Supporting multi-sig compatible with EVM in Substrate's pallet introduces no overhead and, being in a Wasm environment, improves performance.

How would you ensure that the pallet functions correctly within the substrate runtime?

This proposal includes the implementation of a multi-sig contract wallet for EVM. Therefore, by conducting equivalent functional tests within the Substrate runtime pallet, we can ensure its proper functionality.

[Noc2]

Hi @Noc2 Thank you for the question. This is main project. As I mentioned before, these applications have been already delivered. #1788 (comment)

I know that they have been delivered. My concern is that they are no longer maintained or never made it to production.

[ashWhiteHat]

My concern is that they are no longer maintained or never made it to production.

All of our pallets are ready and available for developers as we describe in our organization README.
https://github.com/KogarashiNetwork#activities

We have been working on privacy and scaling so far.
You held the MTG and told me it was hard to support the privacy project.
Then, we changed the direction and focused on scaling solution.
However, in the Substrate Builder Program, the scaling solution was not reasonable for the Polkadot because the overhead took more than the scaling benefits.

This was the MTG report slide.
https://docs.google.com/presentation/d/1QIgXMJ_OZPBUzTrpby0j02eR5pozXIYv/edit#slide=id.p1
And this was the research article.
https://medium.com/coinmonks/brief-introduction-of-latest-zero-knowledge-proof-such-as-zkvm-recursion-and-lookup-9cbc60215a47

Finally, we have changed the direction to enterprise service.
That's the background of this proposal.

I can talk about it more detail in the MTG if you would like.

[PieWol]

Could you please elaborate on the usecase of this project? I don't quite understand what the benefit of this solution would be if you would need to set up your multi-sig on each chain with the help of the substrate pallet or the smart contracts on EVM. With this constraint the benefit to the current multi-sig landscape sounds rather minimal. Given that are wallets already that feature creating ethereum and substrate accounts from the same seed I don't see any improvement from a users perspective. The only difference I am aware of right now is that you are not using a single seed but instead a private key directly. The private key would then be in the format of whatever crypto primitive you come up with?

I'd love to hear more about this.

[PieWol]

Does this mean you will roll your own crypto? Sounds like you want to create your own crypto libraries.

[ashWhiteHat]

It's not from scratch.
We have already implemented primitives tested well so we are going to implement on top of these.
https://github.com/KogarashiNetwork#activities

[ashWhiteHat]

This proposal aims to address the challenges faced when implementing blockchain into corporate business workflows.
Corporate needs typically involve utilizing EVM, which is widely used for transaction settlements, and Wasm for recording the evidence of agreements made on digital documents.

When setting up wallets, it is common practice to store privately generated keys locally, managed by in-house engineers or KYC providers, in cold wallets, rather than relying on seed generation from browser or app wallets.
In constructing multi-signature wallets, our objective is to minimize complex interactions and key management costs between corporations.

This proposal presents a multi-signature wallet designed to meet these requirements.

This use case envisions a business workflow where documents and evidence, agreed upon by a consortium of corporations, can be efficiently verified by anyone in the Wasm environment, while also being stored in a legally binding manner and used for settlements on the widely adopted EVM chain.
Compared to existing wallets, the advantages of this proposal include.

• Implementing a multi-signature wallet compatible with both EVM and Wasm environments with minimal management and communication costs.
• Providing a service that is well-suited to corporate business workflows.

This wallet enables the provision of corporate services leveraging the benefits of both EVM and Wasm, and we anticipate its application across various scenarios in the future.

[PieWol]

I fail to understand the benefit of using this solution over deriving both an EVM and substrate style account from the same seed given that you would still have to send transactions to both chains with your solution. If you would simply abstract this account derivation step from the user it would be the very same user experience, wouldn't it?

[Noc2]

@ashWhiteHat, thanks for the detailed reply, and sorry for the delay. I think at this point, it might be better to get funding via VCs or somebody else who also advice your projects actively and helps you with marketing and other tasks. Therefore, I'm personally not approving the application, but I will also share it again with the rest of the team. Others might still be interested in it.

[coax1d]

The multisig featured wallets currently are not using BLS381 for substrate chains we just started supporting BLS in substrate as of just a couple months ago. I understand the need and want for more multisig solutions but we dont have any protocol based multisigs implemented yet right now all of the wallets are utilizing generally onchain multisigs or other multi sigs which just store the committees public keys and verify them one by one.

[ashWhiteHat]

Hi @Noc2
Thank you for the polite review.
I understand your opinion.

Hi @PieWol

I fail to understand the benefit of using this solution over deriving both an EVM and substrate style account from the same seed given that you would still have to send transactions to both chains with your solution

This solution is mainly for corporate use cases.
The legal basis for using private keys is that they must be registered by a business recognized by the government, and they are managed on a string basis rather than a seed basis.
Most countries use similar management methods, such as passports and ID cards.
When implementing multisig using that private key, the man-hours required to apply for the private key and set up multisig will double if different keys are used for both EVM and Wasm, depending on the number of participants in the consortium.
Because of the complexity of the process, it is difficult to adopt Wasm as a use case because it requires several months for the approval of private key applications, etc., since it is a collaboration of governments and large companies, and the construction of a multi-sig wallet also requires collaboration between the respective companies.
If this man-hour requirement could be significantly reduced, more corporate users would use Wasm because of the demand for VM efficiency and its function as secure storage.

Hi @coax1d
Thank you for the review.
Yes, the protocol based multisigs is also huge benefits for ecosystem.

[PieWol]

Thank you for the detailed explanation @ashWhiteHat. Considering that you confirmed my understanding of the project I'm sorry to let you know that I will not approve it. I simply don't see the need for this project as interesting as it might sound. I hope you understand that we are trying to fund impactful projects within the grants program. Let's see what my colleagues will say. Best of luck.

[keeganquigley]

Hi @ashWhiteHat I'm afraid I have to agree with @PieWol concerns above that I'm not quite convinced about the use case here. There is already a lot of development happening in the multi-sig area and imo it would be better to collaborate on an existing project. I also think that this project could be better funded by VCs, if enough corporations want something like this.

Now that three have voted against it, I will go ahead and close the application. Of course, this decision has nothing to do with your work, which has been great in the past. So let us know if you have other interesting ideas you want to work on.