io.vault is a self-custody product, which enables a company or group of individuals to securely hold and transact with digital assets while simultaneously removing any required single point of trust or failure.
io.vault clients 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, io.vault relies upon robust cryptographic technologies called Multi-Party Computation (MPC) and Threshold Signature Schemes (TSS). io.finnet has developed its own architecture called trustlessMPC (tMPC) which offers enhanced security by physically distributing weighted signing power across multiple participants, rather than relying purely upon server based infrastructure for cryptographic signature generation.
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 does not know your name - just a “public address” and your balance of assets is “owned” by this address.
To transfer your assets anywhere else, you need the corresponding "private key" of the public address. This key is used to cryptographically "sign" for any transfer, the result of which is validated by the blockchain network prior to the execution of the transfer.
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.
MPC-TSS
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 the assets would still be safe 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 signing power across multiple employees instead of relying upon one trusted person who may not be available.
1.2 Concepts
| Concept | Breakdown |
| 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 assets for a given vault can be managed by selecting “manage assets” from within the vault page |
| 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 |
| Reshare Request | Users may submit a request to amend an existing vault threshold and/or signing party, including the distribution of signing power. This request must be approved by reaching the existing vault threshold and “signed” by the resulting signing party. This is known as a vault reshare |
| Signer (or signing party) | A specific user device which contains the allocated secret shares of the vaults for which it is a member of the signing party. A signer can be recovered from an old or lost device on a new device by “restoring” the signer on a new device. However, this process requires the up-to-date signer’s encrypted backup file and the signer passphrase or secret recovery phrase generated upon registration of the signer |
| Signing Party | The collection of signers and their specified signers that contain the secret shares which control a particular vault |
| Signing Power | The number of secret shares a user controls on their specified signing device as part of a particular vault signing party |
| Secret Share(s) | Sensitive cryptographic data that is required to enable the generation of a valid cryptographic signature for a given vault |
| Threshold | The number of secret shares required to enable the signature process or vault reshare for a particular vault |
| Transaction Request | A transaction request may be submitted via the dashboard 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 |
| Vault | A grouping of digital wallets for any supported networks or assets, which are controlled by the same Signing Party and underlying secret shares |
1.3 Dashboard Statuses
| Status | Breakdown |
| Received | The transaction has been received by a vault |
| Pending | The transaction request is pending approval and signature |
| Expired | The request has expired, requests are created by default with a 10 minute time-limit. However, this is configurable via the API on a per-request basis |
| Rejected | The request was rejected by sufficient members of the vault signing party to make it impossible to reach to vault approval threshold |
| Signing | The request has met the threshold for approval and is pending completion of the signature process |
| Failed | The request was either determined to be invalid by the relevant blockchain node/network, or the signature process failed during signing |
| Submitted | The transaction has been signed and broadcast successfully to the relevant network. Submitted transactions may still remain unconfirmed on the blockchain for some time. Submitted transactions may still result in an incomplete transaction in certain circumstances, such as interacting incorrectly with a smart contract |
| Successful | A request has been approved, signed, and submitted (if applicable) successfully |
| Vault-to-Vault transfer | This is used for the special case when a transaction is made between two vaults, a transaction that has been sent from one vault to another will be displayed as “Successful” |