The standard way to send crypto without a multisig wallet involves creating a raw transaction and signing it with your private key. The result is a signed transaction that is then broadcasted over the network. The downside of that approach is decreased security.
If the transaction is signed with a single private key, which means that if that key is compromised, an attacker can access and transfer all of the funds associated with that wallet. This creates a single point of failure and increases the risk of theft or loss of funds through key mismanagement.
A multisig (or multi-signature) wallet is a type of cryptocurrency wallet that requires multiple parties to sign off on a transaction before it can be executed. These wallets are typically created using a combination of public keys from the involved parties. The wallet will only allow transactions if a predetermined number of these parties have provided their signatures.
The easiest way to store crypto is to use a software wallet, more advanced users are utilizing the security of hardware wallets, but none of these approaches are ideal for businesses and organizations, which is where multisig shines.
Creating a multisig wallet for your organization means you are protected if a single employee's key is compromised.
Let's say that you are a partner in a VC fund. There are four partners, and they decide to create a multisig wallet where 3 of those four partners are required to approve the order for the transaction to execute (3-of-4 setup). That means that no single partner can move funds on their own, and also, if a partner is compromised or unable to produce a private key, funds are still safe.
There are several implementations of the multisig protocol depending on the cryptocurrency. For example, Bitcoin has native multisig implementation, while Ethereum and other EVM-compatible chains use smart contracts.
In the last couple of years, the usage of Multi-Party Computation (MPC) is gaining much popularity for digital asset security. There are many advantages in comparison with standard multisig solutions.
Also, recently implemented ERC 4337 allows us to use Smart Contract accounts instead of EOA (Externally owned accounts), opening many doors for several multisig setups.
There is a growing discussion about whether a single solution is better than the other. Still, we at Bizzllet are implementing a combination of the two for our Business wallets and would like to share the advantages of doing so.
MPC is a cryptographic protocol that allows multiple parties to jointly compute a function on their private inputs without revealing their inputs. This means sensitive data can be processed collaboratively without parties accessing the other's data.
Now that sounds like something that would find a perfect application in blockchain systems, given that we have a lot of private inputs (private keys) that we wouldn't like to share with others, and it did find it.
Many companies have gone on record publicly saying they are using the technology in their solutions and supporting the technology's research and development. Check MPC Alliance.
To read more about the MPC, check out our MPC blog here.
MPC is a protocol where multiple parties are involved. So what exactly is a party? Excellent question! By definition, a party can be anyone involved in the protocol. So in the case of a single user running an MPC setup, multiple parties can be multiple user devices like laptops and phones, for example. For business use cases, parties often refer to various persons. If we take our VC fund example from before, and they are running an MPC setup, each partner in a VC fund would be a party in the protocol.
Working with key shares instead of keys is a significant improvement from a security standpoint. If a single share is compromised, our funds are still safe, and we can even implement key share rotation to prevent the possibility of shares being stolen even further. If it still happens, we can produce new shares and distribute them to parties while keeping the public key identical; no fund transfers are required.
Most organizations overlook that when using standard multisig setups, both native and smart contracts, they are broadcasting their security policy to the world. Everyone knows how many keys are involved in the transaction, who signed and who did not etc.
MPC produces a signature identical to the signature produced by a single private key, meaning that in the case of cryptocurrency, transactions signed with MPC are precisely the same as transactions signed by a standard private key wallet. That means no one knows how many parties are involved and which were part of the signing process. This dramatically increases the privacy of your wallet, which in turn also increases the security.
All interactions with the Ethereum and other EVM-compatible blockchains must be initialized by the account, essentially a generated key pair. The only purpose of this account is to use the private key to sign a transaction while keeping the key secure. This is called an Externally Owned Account (EOA).
The other type of account is a Contract account. It is a code deployed on the blockchain and can execute any logic. The downside of contract accounts is the inability to initiate actions. They can control the assets. However, all actions must be initialized and paid for by EOAs.
What if we can make Contract accounts initiate actions and pay for gas fees? That would mean we are getting the best of both worlds, programmable access to funds with any arbitrary logic without the need to manage private keys and worry about gas fee management. Of course, there has to be some standard for these smart contract accounts, including the newly released ERC-4337 EntryPoint contract by Ethereum Foundation. This is basically what account abstraction is.
The Account Abstraction is not a single feature but a set of features that work together to abstract the smart contract account. UserOperation, Bundler, EntryPoint Contract, Aggregators, and Paymasters are those features. We will only focus on some of them in this post, so stay tuned for our future blog posts.
UserOperation represents an intent to execute a particular transaction, not the transaction itself. For example, if we intend to transfer 4 ETH to Address A from our wallet, the authorization logic can be wholly programmable and handled by the smart contract code. It can require a single, multiple, or no signature (possible, but please wait to do that).
With the current implementation of the UserOperation object, the easiest and most secure way to authorize an action is by signing the message with your EOA. Since the authorization logic is entirely customizable, it's possible to make it so that losing access to your EOA is not as catastrophic because it doesn't mean you automatically lose control of your funds. But in most cases, it doesn't put you in an ideal situation either.
The main benefit of MPC is that it is entirely off-chain and chain agnostic since it works with cryptographic algorithms directly. Generating an address is free, unlike the eventual deployment of smart contracts. However, the drawback is that one or more parties must enforce policies; they need to be more transparent since the code to do that is outside the chain.
The benefit of account abstraction is the programmable authorization logic and allowing someone else to pay gas fees in any supported token without purchasing ETH separately. Each implementation has its benefits regarding the privacy of the policies, security chain compatibility (AA is an EVM-only feature), and so on.
Since there is a lot of crossover between the technologies, there is a lot of debate about which one you should use and which is better; however, more thought needs to be put into the potential combination of the two for the ultimate solution.
Here are the suggestions we plan on utilizing with Bizzllet:
Sounds like a match made in heaven 𓆩♡𓆪.
We at Bizzllet are developing a solution using these two technologies together. A company can deploy its smart contract wallet with programmable policies and customizable recovery while each employee interacts with the smart contract by submitting UserOperation signed by their MPC wallet.
With this approach, companies can securely use a smart contract wallet with a web2-like experience and easily switch from our custom MPC implementation to a traditional wallet like MetaMask or any other wallet they are comfortable with.
It's possible to create a recovery policy that will suit their needs, ranging from simple seed phrases to multi-hardware wallet recovery. We are developing several features in this area and are excited to share them with you in the future.
Don't miss out on the opportunity to stay current on Bizzllet’s progress and how it can transform how we use MPC and AA to store and manage our digital assets. Sign up for early access here.