Forward an already-prepared transaction to the Ledger device for user signing. Routes on the handle's origin: EVM handles (prepare_aave_*, prepare_compound_*, prepare_swap, prepare_native_send, ...) go through Ledger Live via WalletConnect; TRON handles (prepare_tron_*) go through the directly-co...
AI agents use send_transaction to create or update resources in VaultPilot MCP — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your VaultPilot MCP environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
handle | string | Yes | Opaque handle returned by a prepare_* tool in the `handle` field of the UnsignedTx. Raw calldata is NOT accepted — the handle is the only way to name a tx for s |
confirmed | boolean | Yes | Must be literally `true`. The agent is affirming that the user has seen and acknowledged the decoded preview returned by the preceding prepare_* call. This is a |
previewToken | string | — | Required for EVM and Solana (ignored for TRON — TRON has no preview step). Opaque token returned by the preceding `preview_send` (EVM) or `preview_solana_send` |
userDecision | string | — | Required on every chain (EVM / Solana / TRON). The agent sets this to the literal "send" AFTER presenting the CHECKS PERFORMED block (EVM / Solana) or the VERIF |
acknowledgeRetryRiskAfterAmbiguousFailure | boolean | — | Required ONLY when re-calling send_transaction on an EVM handle whose previous attempt returned a `WalletConnectRequestTimeoutError` (no_broadcast / consumed_un |
Parameters from the server's own tool schema.
An AI agent can call send_transaction faster than any human can review — one bad instruction and it creates or modifies resources in VaultPilot MCP by the hundred, each call as confident as the last.
Attacks that exploit this kind of access
Forward an already-prepared transaction to the Ledger device for user signing. Routes on the handle's origin: EVM handles (prepare_aave_*, prepare_compound_*, prepare_swap, prepare_native_send, ...) go through Ledger Live via WalletConnect; TRON handles (prepare_tron_*) go through the directly-connected Ledger over USB HID and are broadcast via TronGrid. In both cases the user must review and physically approve the tx on the Ledger screen; this call blocks until the user signs or rejects. EVM handles REQUIRE a prior preview_send(handle) call in the same session — send_transaction reads the pinned nonce + fees + gas stashed on the handle and will throw a clear error if the pin is missing. The split exists so the LEDGER BLIND-SIGN HASH is surfaced to the user BEFORE the blocking device prompt. You MUST pass confirmed: true — the agent is affirming that the user has seen and acknowledged the decoded preview AND the LEDGER BLIND-SIGN HASH emitted by preview_send. EVM handles ADDITIONALLY require passing previewToken (the opaque string returned in preview_send's top-level JSON response) and userDecision: "send" (set after the user has replied "send" to the EXTRA CHECKS menu emitted by preview_send's agent-task block). Together these prove the agent actually surfaced the preview-time gate to the user instead of collapsing preview_send + send_transaction into one silent step — missing/mismatched values cause a clear-error refusal. TRON handles ignore both args. For TRON handles, pair_ledger_tron must have been called at least once per session (so the TRON app has been opened on the device) and the Ledger must still be plugged in with the TRON app open at send time; preview_send is skipped (TRON has its own clear-sign UX on-device). It is categorised as a Write tool in the VaultPilot MCP MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
send_transaction accepts 5 parameters: handle, confirmed, previewToken, userDecision, acknowledgeRetryRiskAfterAmbiguousFailure. Required: handle, confirmed. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for send_transaction: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
send_transaction is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the send_transaction rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for send_transaction. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
send_transaction is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.