prepare_btc_multisig_send
Initiator flow — build a tx FROM a registered multi-sig wallet, sign it with our Ledger key in the same call, return the partial PSBT for cosigners to sign. Pipeline: (1) fetch UTXOs across the wallet's gap-limit window, (2) coin-select with a multi-sig-aware vbyte estimator (P2WSH sortedmulti(M,...
This record as markdown: /tools/io-github-szhygulin-vaultpilot-mcp/prepare-btc-multisig-send.md
What prepare_btc_multisig_send does on VaultPilot MCP
AI agents invoke prepare_btc_multisig_send to trigger actions in VaultPilot MCP. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
to | string | Yes | Recipient address. Any of the four mainnet types is accepted as a destination. |
amount | string | Yes | Decimal BTC string (up to 8 fractional digits, e.g. "0.001") or "max" to sweep every UTXO across the wallet's gap-limit window. "max" picks the fee-aware amount |
walletName | string | Yes | Name of a registered multi-sig wallet (matches `register_btc_multisig_wallet`). |
allowHighFee | boolean | — | Override the fee-cap guard. The cap is `max(10 × feeRate × vbytes, 2% of recipient value)` and uses the multi-sig vsize estimator. |
feeRateSatPerVb | number | — | Fee rate in sat/vB. Optional — defaults to mempool.space's `halfHourFee` (~3-block target). Multi-sig txs are inherently larger than P2WPKH, so the absolute fee |
Parameters from the server's own tool schema.
Why prepare_btc_multisig_send is rated High
This tool initiates a Bitcoin multi-sig transaction by fetching UTXOs, constructing and signing a PSBT with a hardware wallet key. It does not finalize or broadcast the transaction (it returns a partial PSBT for cosigners), so it stops short of Financial. However, it executes a complex cryptographic signing pipeline with real-world financial implications — committing one Ledger key's signature to a multi-sig spend.
From the tool's definition build a tx FROM a registered multi-sig wallet, sign it with our Ledger key in the same call, return the partial PSBT for cosigners to sign
Risk signalsBulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs prepare_btc_multisig_send safely
PolicyLayer is an MCP gateway: it sits between your AI agents and VaultPilot MCP, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For prepare_btc_multisig_send, this is the rule to start with:
prepare_btc_multisig_send stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect VaultPilot MCP, apply this rule, and every prepare_btc_multisig_send call is checked against it from then on.
Questions about prepare_btc_multisig_send
Initiator flow — build a tx FROM a registered multi-sig wallet, sign it with our Ledger key in the same call, return the partial PSBT for cosigners to sign. Pipeline: (1) fetch UTXOs across the wallet's gap-limit window, (2) coin-select with a multi-sig-aware vbyte estimator (P2WSH sortedmulti(M,...,N) inputs are ~2-4× P2WPKH), (3) resolve a fresh chain=1 change address (lowest unused index), (4) build PSBT v0 with witnessUtxo + nonWitnessUtxo (Ledger app 2.x requirement) + witnessScript + bip32_derivation for ALL cosigners, (5) sign with our Ledger via the existing co-signer flow (the device walks every output address + amount on-screen), (6) splice our signature into the PSBT, return the partial PSBT. We do NOT finalize or broadcast — the caller gathers remaining signatures externally, then runs combine_btc_psbts + finalize_btc_psbt. The fee-cap guard scales to multi-sig sizes automatically. Phase 3 supports wsh (P2WSH) wallets only; taproot lands in a follow-up PR. It is categorised as a Execute tool in the VaultPilot MCP MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
prepare_btc_multisig_send accepts 5 parameters: to, amount, walletName, allowHighFee, feeRateSatPerVb. Required: to, amount, walletName. 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 prepare_btc_multisig_send: 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.
prepare_btc_multisig_send is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the prepare_btc_multisig_send 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 prepare_btc_multisig_send. 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.
prepare_btc_multisig_send 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.
More on VaultPilot, and thousands of servers like it.
Across the catalogue