send_transaction
Forward a prepared transaction to a Ledger device for user review and signing, blocking until the user approves or rejects on the hardware wallet.
Instructions
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).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| handle | 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 signing, so the tx the user previewed is exactly the tx sent to Ledger. If the tx chain has a `next` step (e.g. approve → swap), each step has its own handle; call send_transaction once per handle in order. Handles expire 15 minutes after prepare and are single-use. | |
| confirmed | 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 schema-enforced contract — omitting it fails validation before any tx is submitted. | |
| previewToken | No | 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` (Solana) call in its top-level JSON response. Must be passed back verbatim here — a mismatch or omission proves preview was skipped or re-run after capture, and send_transaction refuses. Closes the gap where the agent collapses preview + send into one step without surfacing the CHECKS PERFORMED block to the user. | |
| userDecision | No | 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 VERIFY-BEFORE-SIGNING block (TRON) and receiving the user's explicit 'send' reply. Schema-enforced contract that the preview-time / prepare-time summary was surfaced to the user, not skipped. Missing value → send_transaction refuses with a clear error. | |
| acknowledgeRetryRiskAfterAmbiguousFailure | No | Required ONLY when re-calling send_transaction on an EVM handle whose previous attempt returned a `WalletConnectRequestTimeoutError` (no_broadcast / consumed_unmatched / ambiguous_disagreement). Issue #326 P3: a previous timeout-with-probe outcome leaves the device in an uncertain state — Ledger Live may have silently completed signing in the background, and a blind retry queues a duplicate signing prompt that LOOKS exactly like a key-leak attack pattern (two prompts for the same nonce). The flag is the agent's schema-level confirmation that the user has been told about the duplicate-prompt risk (reject any duplicate prompt; the original tx will land normally) AND has verified via a block explorer that no tx with the pinned nonce has landed in the last ~5 minutes. Without this flag on a marked handle, send_transaction refuses and surfaces the previous outcome's recovery guidance. Cleared by the ack itself — a SECOND ambiguous outcome on the retry requires another explicit ack. EVM-only; ignored on TRON / Solana / BTC / LTC handles since their signing paths don't go through WalletConnect. |