Executing functions on other contracts with multisig wallets, or, multisig functions on Ethereum
Multisig wallets are typically used to handle ether and ERC20/ERC223 tokens, but they can also be used to interact with other smart contracts, including requiring that a function from another smart contract cannot be executed without multisig approval. By sending raw transaction data in the `data` input of a transaction, signatories can use multisig contracts to execute a function from a separate contract.
WARNING: We dive into Solidity code for multiple smart contracts. Some experience with Solidity will allow you to get the most from this article, but is not required to follow along.
Why multisig wallets aren’t actually wallets
To refer to a multisig (multisignature) wallet as a “wallet” is technically a misnomer. In Ethereum, a multisig “wallet” is actually a smart contract. Both a smart contract and a wallet are identified with a unique address: an unsigned 256-bit integer. However, a wallet has a private key, which is required to sign transactions. A wallet’s address can be generated with its private key, which is why a wallet’s address is also referred to as its public key.
Because a smart contract lacks a private key (and is therefore unable to sign transactions), it does not implicitly have the ability to send ether. This means that, by default, if someone sends ether to the address of a smart contract (which is technically a valid address), the ether becomes inaccessible. Developers and investors alike have watched etherscan.io in horror as various smart contracts collect tokens, forever lost from the market. This is how the ERC223 proposal came about: it is a clever way to cause a transaction to fail if tokens are sent to a contract that can’t handle them. But this is only to prevent sending tokens to contracts that can’t handle them. If a smart contract is intentionally going to be used to handle ether or tokens, it needs to have that functionality written into it. Some basic ways to do accomplish this are through the
selfDestruct() function for ether and token fallback function for tokens.
What multisig contracts do
Multisig contracts provide an alternate security measure for storing cryptocurrency by requiring multiple authorized signatories to confirm a proposed transaction before the transaction can execute. Weuse the word “alternate” because multisig contracts don’t reduce risk — they reduce a kind of risk and replace it with another, so the decision to use such a wallet is a strategy decision according use-case, not something that every crypto user necessarily needs.
Traditional use-cases for multisig contracts
The particular risk multisig contracts seek to alleviate is the loss of a private key. With wallets, if you lose access to your private key (including any backup seed, phrase, or password), you lose access to its assets. A multisig contract effectively allows multiple wallets to have authority over a single set of assets. If one private key is lost, remaining wallets can still access the set of assets. If the ownership of a private key is compromised, it alone does not have the authorization to unilaterally access the assets.
How to get ether from a multisig contract
When a new instance of the contract is deployed to the blockchain (depending on which multisig contract you use), you typically specify the public keys that represent which wallets will be authorized signatories, as well as how many of the signatories are required to authorize a proposed transaction. Any wallet can send ether to the contract, but a minimum number of signatories are required to get ether out of the contract.
Risk when using multisig contracts
The trade-off compared to using a traditional wallet is that you take on the risk that your tokens will stolen or permanently locked in the smart contract through hackers discovering an exploit in the contract code. See the Parity “wallet” (smart contract) hack. The code for previously-found exploits has been patched for subsequent smart contracts. Every new exploit acts as a learning experience for the Ethereum community. The mistakes of one contract become the education for a series of new contracts, including GNOSIS, ConsenSys, and Mist wallet. Multiple growing communities are at work to develop the robustness of these technologies. However, just because a new exploit hasn’t been found in newer multisig contracts doesn’t mean another doesn’t exist. If you are going to use a multisig contract, you must consider the use-case and its associated risk.
What we need from a multisig contract at Woolf
What if we don’t only want to use a multisig contract to handle ether transactions? What is we want certain functions to only be executable when approved by a certain number of signatories? Let me give you two examples:
- We want to transfer ERC20 or ERC223 tokens held by the smart contract with the same security measures afforded to a multisig contract handling ether.
- We want to override standard rules in a smart contract according to some network vote or in response to a legal requirement.
Both of these examples call for functionality that we at Woolf want to build into some of our smart contracts. For the first example: because we have an ERC223 token, we want those held in a multisig contract like ether. For the second example: part of our company organization involves an entity called the Woolf Reserve. The Woolf Reserve holds a large number of ERC223 tokens from the moment tokens begin to be sold. The Reserve makes available 0.035% of its token balance available to withdraw by an authorized address once per month to fund ongoing blockchain development. But what if we discover a bug in our smart contract? We would need to withdraw the entire token balance at once and move it to a new contract version of the Reserve. We call this function
forceWithdraw(). But we don’t want anybody to be able to call this. Typically in Solidity, we use the
onlyOwner() modifier for this. But we also don’t want a single person within the organization to have the power over all those tokens. What we need is for multiple pre-approved signatories and no one else to be able to call this function upon approval, where signatories are separated by business domain: core leadership, management, and legal authority.
How to execute multisig contract functions
executeTransaction() functions can be called by an authorized signatory.
replaceOwner() can only be executed if the sending address is the multisig contract itself, through the modifier,
onlyWallet(), which functions like
onlyOwner(). This is a protection mechanism. If one private key was compromised and the individual had authority to add, remove, and replace owners unilaterally, much of the purpose of a multisig contract is defeated. The only way to call a function from the contract itself is for a signatory to propose it by calling
How to use
submitTransaction() function takes three parameters:
destination (type address),
value (type uint), and
data(type bytes). When you’re simply trying to send ether from the smart contract to some address, you enter the address you want to send ether as
to, then how much you want to send (denominated in wei) for
value, then leave the
data section empty. But if you’re trying to execute a function from the multisig contract, like
addOwner(), it’s a different process.
To execute a function of the multisig contract that has the
onlyWallet() modifier, the
to address must be the contract itself. Think of this as an individual submitting a proposal to the contract. The
value (of ether) is
0 or left blank. The
data section is where things get interesting. There, you input function information in the form of hex code. Think of this section as the thing that gets executed when a transaction is approved by the required signatories. If you want that function to be
addOwner(), then the hex code of the
addOwner() and associated parameters is submitted within the
data section. The same is true for
removeOwner() and any other function with the
In this example, we will submit a new transaction to add an owner (signatory). Here’s what that looks like:
to: 0x0000000000000000000000000000000000000000000000000000000000000001 // multisig contract address
amount: 0 // amount of ether
data: 0x7065cb480000000000000000000000000000000000000000000000000000000000000002 // addOwner(address owner)
You may be wondering about what’s going on with the
data section. It’s the hash of the
addOwner() function, including the parameter being passed to it (in this case, an address to add).
0x7065cb48 = hash of
0000000000000000000000000000000000000000000000000000000000000002 = the address
0x0000000000000000000000000000000000000002 with the
0x removed then converted to a 256-bit value.
This function is being proposed by an existing owner, or signatory, using
submitTransaction(). Other owners use
confirmTransaction() to confirm the proposal by passing in the automatically-generated ID associated with the proposed transaction as a parameter. The minimum number of required owner approvals, as set in the constructor, must confirm the proposal before the proposed transaction (the
data portion) will be executed. Once the minimum has been met, any owner can call
executeTransaction(). This will cause the multisig contract to execute the proposed transaction, including what was in the
Note: executing the transaction proposed to the multisig contract causes
msg.senderto be the contract address, not the address of any of the contract owners (or signatories). This is crucial for executing functions in separate contracts with regard to contract ownership. More on that later.
How to get the hash of a function that you want to propose to a multisig contract with
Before you can propose a transaction in the form of a hash, you need to know what that hash is. I’ve found that the easiest way is to use a website like MyEtherWallet. This may seem like a lot of steps, but it becomes a relatively rapid process after you understand the workflow.
From MyEtherWallet, Choose the appropriate network you want to use (i.e. MainNet; a test network like Rinkeby or Ropsten, etc.).
Click the Contracts tab and make sure you are on the Interact with Contract sub-tab. Type in the contract address of your multisig contract. Ignore “Select Existing Contract”, then type in the ABI / JSON Interface of the contract.
Note: An easy way to get the ABI / JSON Interface is to use Remix, the Solidity IDE. In Remix, from the Compile tab, paste your code, click
Start to compile, then click
Details. A window will pop up.
Scroll down to the section labeled ABI. Copy that value to the clipboard and paste it into corresponding input on MyEtherWallet.
Once you have inputted the contract address and the ABI on MyEtherWallet, click
Access to see available functions for the contract.
Select from the dropdown menu the function you want to propose, then type in the values for any parameters you want to submit with the function, like an
Select how would you like to access your wallet, e.g. MetaMask / Mist, Ledger Wallet, TREZOR, etc. The wallet you use doesn’t matter, you just need to go through these steps. You won’t need to actually execute the transaction. You will cancel the transaction procedure at the very last step and won’t need to spend gas.
In the window that opens, leave
Amount To Send as
0. Set a gas limit like
300000 so you get past any warning in MyEtherWallet, then click
Generate Transaction. This doesn’t execute the transaction yet. It first shows the transaction data for the
Raw Transaction and
Signed Transaction. Scroll through the content of
Raw Transaction and copy the content associated with the key
In the above example, the
data portion to copy is:
Yes, I am sure! Make transaction. Exit instead. You only needed to copy the data.
You now have the data necessary to include when submitting a transaction. By including it in the
data section, you can execute that function through the multisig contract.
Submitting the transaction with MyEtherWallet
You don’t have to use MyEtherWallet for submitting a transaction, but if you do, here are the remaining steps to carry it out:
- Still on the
Contractstab, choose the
submitTransaction()function from the dropdown below
Read / Write Contract.
- Set the multisig contract address as the
value, then paste the copied data for
data. We are actually going to submit a transaction this time.
- After reviewing the transaction data, select
Yes, I am sure! Make transaction.This may prompt a further confirmation from the wallet you are using.
How to execute functions on other contracts through a multisig contract
Follow the previous steps for executing a function as part of the multisig contract, but with the following changes:
- Instead of the multisig contract address as the
toparameter, make it the contract you want to call a function from in a multisig manner.
- Instead of using the hash of the multisig contract function as the
dataparameter, make it the hash of the function you want to call from an external function, specifically, of the contract address you just used as the
Just like using MyEtherWallet to get the data from multisig contract functions to use in the
data parameter of
submitTransaction() (like for
addOwner()), you can also use it to get the hash of the function you want to call from an external function. Load that contract’s address and ABI, then follow the steps to get the get the hash of the function and function arguments.
Now, signatories confirm the transaction with the corresponding internally-generated ID. This process allows multisig contracts to execute functions of other contracts.
Securing contract functions with a multisig contract.
onlyOwner() from OpenZeppelin is a popular modifier that prevents functions from being executed unless the address of
msg.sender is the
msg.sender of a multisig contract is the contract address, we can use this to make the contract owner not a typical wallet, but the multisig contract itself. This way, the function cannot be called unless it is first proposed, confirmed, and executed through a multisig contract, like how the modifier
onlyWallet() is used within the multisig contract.
Because only wallets can sign transactions, you cannot use a multisig contract to create a contract. You can, however, set the multisig contract address as the
owner at the instantiation of some other contract. If you want to change the existing owner of a contract, you can call
transferOwnership() and set the address of the new owner as the multisig contract address.
Bringing it all together
By sending raw transaction data in the
data input of a transaction, signatories can use a multisig contract to execute a function from a separate contract, offering an alternative security measure or business strategy decision according to your organization’s needs.