Skip to main content
A signing request is the object returned by GetSigningRequestDetails and GetSigningRequestList. It has the common fields, which are always present, and at most one payload field. The name of the payload field says what the request is, and its body holds the details: the transfer, transaction or message the request asks the vault to sign. Every field is listed below with its type and encoding. The conventions that apply to all of them are in Data types and encodings.

​
Fields

​
Payload fields

At most one payload field is set on a request, and its name says what the request is. Names are given as in REST JSON; gRPC uses the snake_case names (evmSendNative is evm_send_native). A request from a dApp uses the same payload fields as a request created through the API or in the MPCVault app. source tells them apart: it is set only for dApp requests. The payload of a dApp request is the request as the dApp submitted it and MPCVault stored it; MPCVault does not check it again when it returns it.

​
Payloads without fields

The payload fields in the last five rows have an empty body, for example "fiatPayment": {}. The field name is all the API returns about the request. Use the MPCVault app to view its details. A kind of request added to MPCVault appears as a payload field of its own. Treat a request whose payload field you do not recognize as a kind you cannot inspect.

​
Requests without a payload field

A request is returned without a payload field when the API has no body for it:
  • a dApp message other than the ones listed above: an EVM eth_sign message, and Stellar messages and authorization entries;
  • an Aptos dApp request to sign a transaction without submitting it, and a Stellar SEP-10 challenge transaction;
  • a dApp transaction that arrived without a request method, or whose stored data cannot be returned, for example calldata that is not hex;
  • a Stellar transfer or trustline whose asset is not an asset code and issuer, for example a token that is identified by a contract address.
Such a request is not fully supported by the API yet. Use the MPCVault app to view its details. source is set when the request came from a dApp.

​
Source

source is set only for requests that arrived from a dApp, and is null for every other request.
  • source.type is the channel through which MPCVault received the request: TYPE_WALLET_CONNECT, TYPE_PLUGIN or TYPE_MMI. MPCVault sets it and the dApp cannot choose it. It does not identify the dApp, plugin or person behind the request: any member of the vault can create a plugin request, for example.
  • source.website is the website the dApp reports for itself. It is unverified text supplied by the dApp, with no validated format, and is null when the dApp reported none.
Do not use either field to decide whether to trust a request.

​
By connection type

What a dApp request can carry depends on the channel it arrived through. On every channel, a transaction whose stored data cannot be returned has no payload field either. The other fields of a dApp request: In evmSendCustom, a dApp transaction differs from one created through the API in three fields, on all three channels: from and to are EIP-55 checksummed, nonce is returned (from the dApp, or the one a signer set), and gasFee holds the fee a signer set in the app plus the gas limit. The fee the dApp proposed is not returned.

​
Simulation

simulation is the result of simulating the transaction, returned for reference only. MPCVault stores it in a network-specific form (the provider’s response, an MPCVault summary of it, or a synthetic result; see the table below) and does not vouch for it. Run your own simulation before you rely on the outcome. Encoding. simulation is bytes: base64 (standard alphabet, padded) in REST JSON, raw bytes over gRPC. The bytes are UTF-8 JSON text. The JSON schema depends on the network (table below); MPCVault does not define or version it. The text is the JSON as stored, which can be re-serialized (key order, whitespace) compared with the provider’s response.
When it is set. For custom transactions on EVM, Aptos, Sui, Solana and TON networks, and for dApp transactions that are returned with a payload (EVM, Solana, Sonic SVM, Sui, Aptos, TON and Stellar), once a simulation is stored. It is "" for every other request, including plain transfers, messages, Bitcoin and TRON requests, and requests for which no simulation is stored (provider failure or timeout, quota exceeded, custom EVM networks). A Stellar simulation that failed is stored as a result with success false, not as an empty value. Resimulation (REST, gRPC) attempts to replace the stored value; see there for what a provider failure returns.

​
Verify independently

MPCVault returns a request as it holds it, together with its own view of it (evmInputDataDecode, simulation, source, notes). This is reference information, not a verification. To verify a request, run your own independent checks: decode the calldata yourself, simulate the transaction with your own provider, and compare addresses and amounts with your own records. Do not rely on these fields as your only check.