Skip to main content

Overview

MPCVault API Overview​

MPCVault's API offers versatile support for a variety of purposes, including:

  • Generating signing requests for users to manually sign, following the existing multisig policy.
  • Enabling programmatic transaction signing.
  • Setting up accounts for customer deposits on different blockchains.
  • Signing messages and typed messages.
  • Monitoring incoming transactions and subscribing to blockchain event notifications.
  • Creating addresses that consolidate payments into an omnibus account.
  • Signing raw messages.
  • Facilitating batch payments on various blockchains.

Signing Flow​

Before initiating any transaction signing, a signing request has to be generated. A signing request outlines the principal fields of a transaction but occasionally requires additional information before it can be serialized into bytes for the signing algorithms such as ECDSA or EDDSA. For example, it could say "send 5 ETH to address A". The signing request might lack the nonce of the transaction or the gas fee. Leaving these fields to be set just prior to signing allows the most appropriate values to be established before the transaction is sent to the blockchain. MPCVault automates this process so developers don't have to manage such details. It is also possible for a developer to set the nonce or gas fee within the signing request if desired.

To programmatically complete a signing request, MPCVault's non-custodial architecture requires the client to run the MPCVault Client Signer within the client's environment. This service is also conveniently provided as a Docker image. It holds key shares and actively participates in the signature computation process.

The following diagram illustrates the flow:

signing flow

For high-security deployment, we also recommend considering the following setup: have the request initiator and request verifier in separate client environments. This approach helps mitigate the risks associated with client environment compromise.

signing flow2

For example, the request verifier could allow certain transactions to be signed automatically. For high-value transactions, it would require the transaction to be signed by an internal user whose public key has been pinned in the client implementation of the request verifier.