Fields
Field visibility
Fields outside their visibility or availability scope are unset. Interpret any emitted zero value or
null according to the field description; it does not mean the operation was authorized. Reading a request does not require a connected ClientSigner.
vaultUuid is unset for organization-scoped requests such as root-key generation, backup and organization-level key-access grants. Vault-scoped list and pending queries do not include requests without a vault.
Signed transaction encoding
signedTransaction is a string whose encoding depends on its network:
A co-signed transaction can still require signatures from other parties before broadcast.
signatures contains complete message/digest signatures in signing order, rather than MPC signature shares; Bitcoin can return one signature per input digest.
Pending operation
pendingOperation is an output-only oneof: approve, sign, or no operation. It describes the current action for the authenticated API user and actual ClientSigner binding. Terminal requests and requests without an applicable action have no operation. Evaluation failures fail the query rather than returning a guessed action.
An approval operation has an empty message body:
approve means the API user can contribute an approval still needed by the current policy. Use ApproveSigningRequest, which records approval without signing.
A signing operation identifies eligible targets:
sign means prerequisite approvals are satisfied for an eligible ClientSigner target. The ClientSigner’s own approval performed with signing is included in that readiness check; a missing API-user approval is not. The keys are distinct alternative targets, not cumulative signature requirements or a list of every organization signer. The list is nonempty; the current binding supports at most one target.
A returned operation does not grant permission to execute it. Approval and execution revalidate access and policy. GetPendingSigningRequests returns the complete action queue across one or all accessible vaults, without pagination.
Payload fields
Names below use REST JSON; gRPC uses the corresponding snake_case names (evmSendNative is evm_send_native). Select gRPC (protobuf) in the field explorer to see types and field numbers.
The queryable payload set is broader than CreateSigningRequest’s accepted
type members. Existing Stellar messages, authorization entries and challenges, Aptos whole transactions, swaps, batch-payment bodies, fiat orders, account setup and management requests can be queried without adding public creation methods for those types. Aptos coin registration and direct NFT receipt cannot be created through CreateSigningRequest.
Transaction and business context
Swap and fiat bodies separate the chain transaction from stored business context.ChainTransaction selects a chain body; FungibleAssetApproval selects a spending-authorization standard. SwapQuoteAsset identifies its account, asset and amount together with a native NetworkInfo identifier. Quote amounts are stored whole-asset decimal text; the nested transaction instead uses its own chain-specific units.
BatchPaymentApproval.approval is the allowance transaction; batchContext is the planned payment, not transfers performed by that approval. BatchPaymentSend.transaction holds the actual batch body, with its stored gasLimit and nonce outside that body. EVM batch bodies expose the output-only batchContractAddress for checking the prepared transaction target.
Fiat beneficiary details are display summaries. Full bank account and routing numbers, beneficiary IDs, email addresses and birth dates are not returned. accountLast4 is empty when a safe suffix is unavailable; the full account is never used as a fallback.
Management details
Vault creation, root-key generation and key-access grants expose their documented details.rootKeyBackup contains public backup-share encryption recipient keys, never backup ciphertext. vaultSettingUpdate remains an empty marker: "vaultSettingUpdate": {} identifies the request without disclosing the setting details.
These management payloads cannot be passed to CreateSigningRequest or ExecuteSigningRequests.
Requests without a payload field
Treat an unknown or absent payload as a request your integration cannot inspect. Do not infer its action or sign it from status alone.dappRequest preserves stored dApp transaction or message data when a chain-specific payload is unavailable; its requestType and data retain their stored format.
Source
source identifies an inbound dApp intake channel: TYPE_WALLET_CONNECT, TYPE_PLUGIN or TYPE_MMI. It is unset for other requests.
MPCVault sets the channel, but it does not authenticate the dApp or person. Any vault member can create a plugin request. source.website is unverified text claimed by the dApp; it does not establish trust.
Mapped dApp transactions and messages use their chain-specific payloads. EVM eth_sign uses evmMessage.type: "TYPE_ETH_SIGN"; Stellar messages, authorizations and SEP-10 challenges use their dedicated payloads. Aptos SIGN_TRANSACTION uses aptosSignTransaction, which co-signs a whole transaction rather than AptosSendCustom’s transaction payload. Its asFeePayer flag authorizes applying the signing wallet as fee payer without rewriting the returned original transaction field.
The payload and stored context are returned for inspection, not independent verification. Decode and verify them before approving or signing.
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.
stellarSendCustom requests, 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.