Multisig Contract

NEAR advises that the Multisig Contract is experimental - recommended to thoroughly test it on TestNet before incorporating into anything you're doing on MainNet.

The whole premise of a multisig contract is that it can implement logic that requires more than one person or entity to confirm a request/proposal before it will execute.  This is known as setting a K out of N multi sig scheme, where N is the total number of participants and K is the number that must be in agreement before the request or proposal will execute.

This multisig contract allows the owners of keys that have been added to it to request to sign transfers, function calls, or add/remove existing or additional keys.

There is no time limit built into this.  Any of the authorized access keys can confirm up to the point where the required number of confirmations is achieved.

Let's take a look at an overview of the entire process:

Walking Through the Flow

Step 1: Initialization

Before we deploy and use the contract, we need a couple things:

• Decide on how many confirmations we want before some request actions will execute; and
• The public keys of all the accounts we want to initialize with (should be greater than the number of confirmations we're looking to have).

For example, I want to deploy a multisig that will have three participants (three access keys) and I want two separate confirmations before any action will execute.  In other words, two of the three pers using the contract must agree on the request.

With that info in hand, we can deploy the contract calling it's initContract function.  We'll do it using near repl:

Of course, one can assign as many keys as one wants and raise or lower the number of confirmations required.  One can also add more keys later on or change the number of confirmations required.

Step 2: FunctionCall Access Keys

Step 3: Submitting a Request

At star 3 - user C submits a multisig request to the contract.  We'll assume it is a request to transfer funds to somebody.near.  Using near-cli it would take this form:

Transfer Request

Add Another Key to Multisig

Change number of confirmations required to approve multisig request

All of these return the request_id which can be used to query/confirm details.  Also keep in mind that you can create more complex calls that chain multiple actions together.

The contract also has a number of view requests one can call to get some information:

List all request ids

See information about a specific request

See confirmations for a specific request

Total confirmations required for any request

You might notice...

If you're looking closely at the differences between the Rust multisig contract and this AssemblyScript contract, you'll notice some differences in how the MultiSigRequest is structured.  AssemblyScript doesn't have functionality for embedding arguments in an enum, so we had to extract those things out and put them in the MultiSigRequest class as arguments and then reference them appropriately in the switch statement during execution.   Here are the two enums in Rust (left) and AssemblyScript (right) (click on each to enlarge):

For a more detailed look and how this then changes how each type of contract executes the request - check the execute_request function of the Rust contract and compare it to the execute_request function of the AssemblyScript contract.

Step 4: Confirmations

At star 4 - both user's B and C call the 'confirm' method on the contract indicating their support for the associated request_id.   It's pretty straight forward.  That looks like this:

As we initialized the contract requiring 2/3 confirmations - with B & C's confirmations, it triggers the execute_request function which takes us to the last step.

Step 5: Execution

Execution is exactly what it sounds like.  Because the request submitted at step 3 received the necessary two confirmations, the execute_request function executes and performs whatever actions were part of the request (assuming all the relevant arguments are present). They include:

• Transfer
• CreateAccount
• DeployAccount
• AddKey
• DeleteKey
• FunctionCall
• SetNumConfirmations
• SetActiveRequestsLimit

So What's a MultiSig Contract Good For?

Use your imagination - probably come up with many scenarios where it makes sense to submit a request and reach a majority (or some other consensus) among participating people.  

This is essentially how decentralized autonomous organizations (DAOs) run and NEAR's account and access key system along with a multisig contract in this context opens up some novel ways to implement those systems.

This multisig could be the beginning of a super robust DAO. The contract could be extended to include various other request types and the members of the DAO (as depicted by their access keys) could indicate support for certain requests, add/delete additional members or whatever else you can imagine.

It's Upgradeable

But be careful if you decide to do it - following request will deploy new contract code on the given account.  You need to consider data and requiring migrations (contract updates should include data migrations moving forward).

This still acts like a request and will require confirmation by the number of confirmations setup for the contract.

Video Code Walkthrough

All the code for the multisig contract in AssemblyScript is in this repo.

Test Your Knowledge