Our Hive Multisig proposal just expired and we're proud to have achieved what we set up to do (read more about this below). After discussing with community members and major Hive dApps, we realize that there is still some work to be done, that could make a big difference in the ecosystem.
What is Multisig?
An account set to use multisignature (or multisig) will require one or more signatures to perform a transaction, as opposed to traditional accounts that only require one signature.
I encourage you to read this article to better understand how this works on Hive. It was written for S***m at the time but the principles are the same on Hive.
TL;DR
For owner, active, and posting authorities, instead of having only one key, you can set several, or also set other accounts as having authority. Each of these keys or accounts has an associated weight, and the authority has a threshold. For the transaction to be broadcasted successfully, the combined weights of the keys and accounts used for signing need to reach the threshold.
Example
If your posting authority has 1 key (weight set to 2) and 3 other accounts (all weights set to 1)and its threshold is set to 3, you can either require the three other accounts to sign (1 + 1 + 1 = 3), or sign with your key and one other account (2 + 1 = 3)
Why is this important?
Here are a few use cases of multisig wallets on Hive:
Enhanced security
With a multisig account, even if one of your keys is compromised, your funds are still safu.
2 Factors Authentication (2FA)
One way this could be used on Hive is by creating a 2FA using a desktop and mobile wallet (Keychain for instance ;p). You could sign once with an account present on your computer, and be prompted to sign a second time on your mobile wallet.
Community decisions
Hive is based on communities, and multisig is a very powerful tool for them to make decisions based on consensus.
DHF Proposals
I see two possible applications of multisig linked to the DHF :
- For "umbrella proposals" that ask for funds in advance (marketing, petty cash, etc.), it could be used to distribute the funds based on consensus.
- Because we fear abuse, it is currently quite hard for new developers to fund their projects on the DHF, without a reputation to back them up. With multisig, we could assign them reviewers who would unlock the funds upon reaching milestones.
Authority granularity
How to allow someone to vote with your account but not to post?
Give that user an insufficient posting authority, and run a bot to complete the signature only for voting.
What we've achieved so far
We started working on Hive Multisig about a year ago and achieved everything we originally proposed in our first DHF proposal. @krios003 worked on the frontend and @tshiuan worked on the backend, while I managed the project.
Hive Multisig dApp
Our dApp allows users to do everything related to Multisig:
- Change/Add/Remove keys or accounts authorities
- Change the authorities weights and threshold
- Build transactions and start the multisig process
- Receive multisig signature requests initiated by another user/key
- Decrypt, sign, and broadcast requested transactions
- Receive notifications about the multisig transactions status
Backend and infrastructure
Our backend takes care of passing encrypted data to the potential signers, without ever knowing what the transaction is about, for security purposes.
Using WebSockets, potential signers are notified in real-time if they are already online, or at their next connection within the transaction expiration frame.
After a sufficient number of signatures is collected, the last signer broadcasts the transaction.
Other signers are then notified of the result of the transaction.
A video is worth a thousand words
- Confucius
A step-by-step explanation of the process can be found here.
SDK, Documentation, and Dev Support
Although our own dApp works great for punctual usage, if we want to really unleash the potential of multisig in the ecosystem, we need to get other dApps onboard.
For this, we created and published a Software Development Kit (SDK), along with its documentation to make it easy for developers to integrate Hive Multisig in their project.
Repositories
Links
New Proposal
What we want to build
As shown above, the groundwork has been laid and we have a working multisig system already, but there's still work to do for it to have a profound impact on our Hive ecosystem.
What we are proposing here are three different features that improve the security, the onboardability, and the granularity of the system.
On top of this, we also want to work on decentralizing our backend to make it more robust, and support developer integration.
Decentralizing the backend
If we want to have Multisig features used across the ecosystem, we cannot afford to have a single point of failure. That is why we plan to work on having multiple nodes rather than one centralized backend in the future.
Authority granularity
With four different keys (owner, active, posting, memo), the Hive blockchain already has a much better key granularity than most other blockchains.
Multisig allows us to go further and create keys that obey certain rules and share them with others.
Here's an example of a use case:
We regularly run HP delegations giveaways for our Hive Keychain followers on X. I could assign our Community Manager an active key that would only work for delegations, and would be capped to a certain amount / daily amount / monthly amount.
It would work as follows:
- Assuming that the key threshold is 1 for our active key, an authority of 0.5 would be given to both our Community Manager and an account managing granularity, let's call it @multisig-bot.
- On the Multisig dApp, the parameters of the CM authorities are selected to only allow delegations, up to 10k HP a month.
- Each time the CM is using his active authority to sign an operation on our behalf; since he has insufficient authority, the bot will receive a request.
- The bot checks if the operation is within the authorized scope.
- If yes, the bot also signs, and the operation is successfully broadcasted. If not, the operation will expire and nothing will happen.
Other use cases could include:
- Giving curation teams access to your voting rights only, possibly capped to a certain amount of votes per day, and limited to some tags/authors/communities
- Only authorizing the signature of some types of custom JSON for giving specific access to some game tools
- The two applications described below
- Basically any use case you might think of, in which you need to give narrow access to someone else, or to yourself in a specific device
2FA Module
Having multisig means that we can now work on applying 2FA to our keys to add security to our wallets. Here is how this would work:
- The account active keys are updated to necessitate both signatures from the current active key and @multisig-2fa
- The 2FA code is created and imported into the user's preferred 2FA App (Authy, Google Authenticator, etc.)
- When sending a transfer, the 2FA code must be entered
- If the 2FA code is correct, @multisig-2fa will also sign the transaction and broadcast it, if not, the transaction is canceled
Combining this with the key granularity system described above, we can go even further and only require 2FA in some cases, for example:
- for transfers, but not for delegations
- only for transfers that exceed a certain daily limit
Onboarding Module
By using multisig, and a referral generation App, anyone with account creation tickets (or 3 HIVE to spare) could create accounts for people around them, without ever seeing their private keys, and while ensuring that the broadcasted keys have not been tampered with.
This can actually be done without multisig, but the broadcast request can be more efficiently passed to the signer through the Hive Multisig communication layer.
Example:
- User A has account creation tickets and wants to invite his friend newUser to use Hive
- User A gives a small weight authority to the referral dApp. That small-weight authority doesn't allow the dApp to do anything by itself, rather it allows it to make signature requests. (On Hive Multisig, only authorized accounts can make such requests)
- User A generates a referral code in the dApp
- newUser creates his keys on the dApp and uses the referral code to submit a request for broadcast
- The dApp approves the referral code, signs the transaction, and passes it to User A
- User A signs the account creation operation and broadcasts it
- newUser is now the proud owner of a Hive account
Developer support
We will keep our SDK and documentation up-to-date and support any dApp wishing to integrate Hive Multisig.
We have already been in touch with Peakd, Ecency, SPK Network, Splinterlands, InLeo and OneUp Cartel, to discuss potential integrations. We are happy to discuss it with any other dApp that would like to know more about it. Of course, this will be integrated into Hive Keychain as well to further improve the experience.
Budget
For this proposal, we will continue working with a budget of 230 HBD/day for a year. This will cover the salaries of the two developers (part-time) who have done a great job so far, and the growing infrastructure costs. A small part of the funding will be kept in the savings to cover server costs during a potential funding interruption and after the end of the proposal.
/!\ NOTE: This proposal is totally independent of the Hive Keychain proposal, and the teams will not overlap. I will just put in a few extra hours to manage our devs and support other dApps integrations.
Commitments
- We commit to keeping all the code produced through this funding opensource (see the list of repositories above).
- We also commit to writing regular updates to keep the community updated.
What if the proposal doesn't get the funding?
We believe these new features would add value to the ecosystem. If that's not the general consensus though, we will continue hosting and supporting the current features for as long as possible.
Support Hive Multisig Development by voting for this proposal on Hive Keychain, PeakD or HiveSigner.