Swapping From a Multisig Wallet (2-of-3, Measured)

A multisig wallet is not a different kind of wallet. It is a different locking script, and an instant-swap site never sees it. To build an order this site asks for four things — the asset you send, the asset you receive, the amount, and the address that should receive the payout — plus a refund address, which has been mandatory here since 25 October 2026. No wallet connection, no signature request, no account. So the real question is not whether you can swap out of a 2-of-3. You can. It is what your script costs in bytes, whether the pre-order validator understands it, and whether your signing ceremony fits inside the 30-minute order window. The numbers below come from five Bitcoin blocks parsed locally on 27 October 2026. (recovering misdirected funds)

What the order form actually requires. The order endpoint takes fromAsset, toAsset, fromAmount, toAddress and refundAddress. Address length is capped at 256 characters; everything else about the address is the upstream provider's business. Two consequences matter for multisig users. First, a multisig address is just an address: a 3… P2SH or a bc1q 32-byte program is accepted exactly like a single-sig one, because nobody is checking whether you can spend from it. Second, the refund address is now a hard requirement, and it must be an address on the network you are sending from — so the refund path is usually another address from the same multisig wallet, not an exchange deposit address. If the swap fails, the coins come back to a script that needs m signatures. That is the point, and also the operational risk: the refund can sit there until your other signers are available. (recovering misdirected funds)

Three script families, one 2-of-3 policy, three prices. The same 2-of-3 arrangement can be encoded three ways, and the chain data shows all three in production. A legacy P2SH input — signatures and the redeem script packed into scriptSig — measured 294 vB (median of 94 inputs). A native P2WSH input, where signatures move into the witness and take the 75% discount, measured 104.2 vB (median of 224). A nested P2SH-P2WSH 2-of-3 came in at 139.2 vB. Same threshold, same key count: 2.8 times the bytes for the oldest encoding. For comparison, a single-sig P2WPKH input is 67.8 vB and a Taproot key-path input 57.5 vB. A 3-of-5 legacy script costs 435 vB per input, about 7.6 times a Taproot signature for the same authority.

The 3… prefix does not tell you what your script costs. We generated two real 2-of-3 addresses offline from fixed public keys: a legacy P2SH address starting 33ybcg… and a nested P2SH-P2WSH address starting 3NBbb…. Both are valid mainnet addresses, both pass every checksum test, and both begin with 3. The input cost differs by more than 2 times. The only way to know which one your coordinator produces is to read its script-type setting; the only way to know what it will cost is to look at the size of the transaction it builds. When you inherit a wallet, or restore from a backup made years ago, many coordinators still default to the legacy encoding.

What the site validates before your order is forwarded. Since 25 October 2026 the order route checks addresses locally instead of trusting providers, after six orders in the database were found to carry mistyped destination addresses — five of them had already paid out. We ran that same function against the generated addresses. Legacy 3…: accepted. Native bc1q with a 32-byte program: accepted. Taproot bc1p in bech32m: accepted, though whether the upstream provider will pay to it is a separate question. One character changed in the 3… address returned “address checksum mismatch — a character was likely mistyped”; one character changed in the bech32 address returned “segwit address fails its bech32 checksum”. One gap worth knowing: Litecoin is not covered by that validator yet. We passed a fabricated LTC address with a broken checksum and it was accepted, because unknown assets are deliberately let through rather than risk rejecting a valid order. On LTC, compare the address character by character.

Why a 2-of-3 scriptSig begins with OP_0. Here is the raw input script of a real 2-of-3 spend from block 973,353: 00 47 30 44 02 20 … 4c 69 52 21 <key> 21 <key> 21 <key> 53 ae. The leading 00 is the famous OP_CHECKMULTISIG off-by-one: the opcode pops one more stack element than it consumes, so a dummy byte is pushed to keep it consistent. The trailing 4c 69 is the push of a 105-byte redeem script, and 52 … 53 ae inside it is OP_2, three public keys, OP_3, OP_CHECKMULTISIG. Two practical consequences. Signatures must appear in the same order as the public keys in the script, which is why a PSBT finalizer sorts partial signatures; and a scriptSig assembled by hand without a finalizer can look valid locally and still fail to broadcast.

The chain data: 1,085 multisig inputs in 18,574 transactions. Across blocks 973,350 to 973,354 there were 16,035 non-coinbase inputs. 1,085 of them, 6.77%, spent a multisig script, and those inputs accounted for 9.7% of all input bytes and 3.7% of total block weight. The distribution is a decent map of what wallets actually do: nested P2SH-P2WSH 2-of-4 led with 443 inputs, most likely one service consolidating; then native P2WSH 2-of-3 with 224, legacy P2SH 2-of-3 with 94, and 17 inputs of 3-of-5. Only 70 of the 18,574 transactions were pure multisig, and their median fee rate was 2.03 sat/vB — well above the 1 sat/vB that was enough to land in the next block that morning. One single-input multisig transaction paid 30 sat/vB, 6,480 satoshis, about $5.17 for a transaction that needed roughly $0.17. (how Monero fees work)

What the extra bytes cost at today's fees. At 06:00 UTC the mempool held 44,475 transactions across 19.5 MvB, the next block was projected at a median 0.122 sat/vB, and the recommended rate was 1 sat/vB with 2 sat/vB for the next block. With BTC at $79,802, one satoshi is $0.000798. A 1-input, 2-output spend from a legacy 2-of-3 is about 367 vB, so $0.29. The same spend from a native P2WSH 2-of-3 is about 178 vB, $0.14. At 50 sat/vB, an ordinary congestion level, those become $14.60 and $7.10. Consolidation is where the multiplier really bites: one transaction in our sample swept 149 multisig inputs into two outputs, 22,110 vB and a 22,148-satoshi fee at 1 sat/vB, about $17.70. At 50 sat/vB the same sweep is roughly $880. Consolidate when the mempool is empty, not when you are in a hurry. (how Monero fees work)

The 30-minute window is shorter than a signing ceremony. Orders expire 30 minutes after creation; late deposits are looked for up to six hours afterwards, and anything the provider cannot see is force-expired at 24 hours. The deposit address only exists after the order is created, so you cannot sign first and order second. A 2-of-3 spread across two cities is: create order, build a PSBT for the exact amount, carry it to signer A, then signer B, finalise, broadcast. If any step needs a phone call, the window is gone and you are relying on a late-deposit lookup that may or may not find your payment. Practically: have both signers at their devices before you create the order, preload the coordinator with payout and refund addresses, verify the deposit address against the order page rather than the clipboard, and pay 1 sat/vB instead of letting the wallet guess. (recovering misdirected funds)

Per-chain reality. Bitcoin and Litecoin: script multisig works end to end, with the Litecoin validation gap described above. EVM chains: there is no native multisig, so the multisig is a contract, Safe being the common one. A deposit from it is an ordinary transfer and the address passes validation like any 0x address, but spending is a contract call that several owners approve and one executor pays gas for, which costs more than a plain transfer. Monero: M-of-N multisig exists in the CLI and GUI wallets, but it is a multi-round protocol and the tooling is far thinner than Bitcoin's. Receiving is trivial, because a multisig wallet's address is an ordinary 4… address; spending is the hard part. Zcash: no threshold signing for shielded notes at the time of writing, so a shielded payout is single-key by construction. Choose the chain around what your signers can actually sign. (Zcash vs Monero 2026)

A six-point checklist before you create the order. One: generate both the payout address and the refund address from the same multisig wallet, and confirm the first address matches on every device — a passphrase or derivation-path mismatch is the most common way a multisig restore goes wrong. Two: read the coordinator's script type and prefer native P2WSH or Taproot over legacy P2SH; the saving is 2 to 3 times on every input, forever. Three: check the payout address checksum by hand on mobile, where clipboard malware is most common. Four: put the exact amount into the PSBT; the order is priced for one amount and a shortfall is not scaled proportionally. Five: keep the deposit address on screen while signing and compare the first and last six characters. Six: sign in the order the coordinator expects, with a finaliser, or the transaction will be rejected after you have already spent the fee. (recovering misdirected funds)

That is the whole trade. A multisig wallet buys you the ability to lose one device and still move your coins; it costs bytes, and bytes are cheap only when the mempool is. As of writing — 27 October 2026, 06:00 UTC — the swap itself is the expensive part: 100 USDT-TRC20 priced at 0.14614999 XMR implied about 684 USDT per XMR, while 5,000 USDT priced at 8.17658023 XMR implied 611.5, and 1 XMR sold for 582.55 USDT. Live rates move; use the page. Spend your attention on the fixed costs and the signing window, not on the 294 bytes of a legacy input, which today cost 23 cents. (XMR to USDT exit)