Introduction to io.vault

  • Updated


io.vault is a self-custody product, which enables a company or group of individuals to securely hold and transact digital assets while simultaneously removing any required single point of trust or failure.

io.vault users are provided the ability to directly distribute cryptographic signing material (secret shares) across multiple individuals within their organization and to determine a threshold of those secret shares required before a transaction can be successfully approved.

This approach provides a customizable, secure and scalable way to manage an organization's or individual's digital assets. To accomplish this feature, io.vault relies upon robust cryptographic technologies called Multi-Party Computation (MPC) and Threshold Signature Schemes (TSS).


1.1 Technology Background 

Public private key pairs

When holding digital assets directly in self-custody (i.e. not via an exchange or 3rd party custodian) the blockchain doesn’t know your name - just a “public address” and your balance of assets is “owned” by this address.

In order to move your assets anywhere else you need the public address’ corresponding “private key” to “sign” any transaction, which is then verified by the blockchain network before the transaction is processed.

This private key is simply a string of characters (e.g. 310fe2e677a3ad28acb91d2645bb33882f015ab11e59dce9d2a72905979e3cb6) that is used to cryptographically prove ownership of its corresponding public address through cryptographic functions (i.e. “signing”).

The issues arise around ownership, since there is no name attached to your public address and it is only controlled by the private key. Anyone who manages to gain access to this private key can take complete control of any assets associated with your public address and send them anywhere they like.



TSS (threshold signature schemes) technology eliminates the use of a single private key and instead uses a customizable number of “secret shares” to accomplish the same feat of signing a transaction for a corresponding public address. In addition to being able to customize the number of secret shares you can also set a “threshold” which determines how many secret shares are required in order to generate a valid signature.

This means that you could have many different secret shares held in different locations, with different people, and if one of them was stolen no assets could be stolen as the threshold could not be reached by the attacker.

The Multi party computation (MPC) technology allows devices that contain their own secret shares to communicate with one another and produce a signature trustlessly, without ever disclosing to the other devices their own secret share.

The end result is a technology which allows us to eliminate the single point of failure normally associated with holding self-custody of digital assets. In addition, it allows users of our product to determine for themselves the level of security for each vault (number of shares, and required threshold) and distribute that signing power across multiple employees instead of relying upon one trusted person who may not be available.


1.2 Concept

Concept Breakdown
Vault A grouping of digital wallets for any supported asset(s), which are controlled by secret shares.
Threshold The number of secret shares required to enable the signature process or vault re-share for a particular vault.
Secret Share(s) Sensitive cryptographic data that provides a user's device with an allocated level of signing power that is required when signing a digital asset transaction.
Signing Power The number of secret shares a user controls on their specified device as part of that particular vault signing party.
Singing party The collection of signers and their specified devices that contain the secret shares which control a particular vault.
Reshare Request Users may submit a request to amend the vault threshold and signing party or create a new vault. This request must be approved, by reaching the existing vault threshold and “signed” by the resulting signing party. This is known as a reshare request.
Vault Card A vault card displays the name of the vault, total USD value of assets held within the vault, total BTC equivalent value of assets in the vault, vault threshold, and an illustration of the individual vault signing party members.
Asset Card An asset card displays asset quantity and equivalent US$ value, as well as the wallet address of a particular asset within a given vault. Displayed or hidden asset cards for a given vault can be managed in the “vault settings” tab.
Deposit Address A deposit address is the specific public address for the digital asset on the relevant blockchain/network that is cryptographically controlled by the underlying secret shares of the given vault.
Transaction request A transaction request may be submitted via the dashboard by any user within an organisation and is transmitted to the devices of the signing party of the vault. The request includes the network, asset, destination address, and the quantity to be sent. The request must be approved and signed by members of the signing party for the given vault that have sufficient combined signing power to meet or exceed the vault threshold


1.3 Dashboard Transaction Statuses

Status Breakdown
Received The transaction has been received by a vault
Pending The transaction request is pending approval and signature
Expired The transaction request has expired
Rejected The transaction was rejected by enough of the vault signing party to make it impossible to reach to vault approval threshold
Signing The transaction request has met the threshold for approval and is pending completion of the signature process
Failed The transaction was either determined to be invalid by the blockchain node/network, or the signature process failed during signing
Broadcast The transaction has been signed and broadcast successfully to the relevant network. Broadcast transactions may still remain unconfirmed on the blockchain for some time. Broadcast transactions may still result in an incomplete transaction in certain circumstances, such as interacting incorrectly with a smart contract.
Transferred This is used for the special case when a transaction is made between two vaults, a “broadcast” transaction that is sent from one vault to another will be displayed as “transferred”.



Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request



Please sign in to leave a comment.