[{"data":1,"prerenderedAt":173},["ShallowReactive",2],{"content-\u002Fprompts\u002Fmigrate-from-fireblocks":3,"prompts-category-migrations":107},{"id":4,"title":5,"author":6,"body":7,"categories":6,"category":90,"categoryType":6,"date":91,"description":92,"extension":93,"faq":6,"howto":6,"isBlog":94,"isChangelog":94,"meta":95,"navigation":96,"path":97,"pillar":94,"products":98,"rawbody":103,"seo":104,"stem":105,"thumbnail":6,"updated":6,"__hash__":106},"content\u002Fprompts\u002Fmigrate-from-fireblocks.md","Migrate from Fireblocks to BlindPay",null,{"type":8,"value":9,"toc":84},"minimark",[10,14,19,30,34,47,51],[11,12,13],"p",{},"Paste this prompt into your coding agent to move the fiat payout leg of a Fireblocks (developers.fireblocks.com) integration to BlindPay, keeping Fireblocks for custody and signing where you want it.",[15,16,18],"h2",{"id":17},"prompt","Prompt",[20,21,27],"pre",{"className":22,"code":24,"language":25,"meta":26},[23],"language-text","You are migrating my application's stablecoin-to-fiat payout leg from Fireblocks (developers.fireblocks.com) to BlindPay. Fireblocks can stay in place for custody and transaction signing (vault accounts, transactions, whitelisted addresses); this migration targets only the fiat payout and offramp surface.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the quickstarts, customers, bank accounts, payout quotes, payouts, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n\nDo the migration in this order:\n1. Inventory my Fireblocks usage from the codebase: every Payments Engine call (payout instruction set creation, payout execution), connected fiat accounts, travel rule policy config, and webhook subscriptions (Fireblocks-Signature or Fireblocks-Webhook-Signature headers), plus every stored Fireblocks ID (payment accounts, payee accounts, payout instruction sets). Derive the concept mapping from what we actually use, roughly: Fireblocks payee fiat accounts map to BlindPay customers (re_) with KYC\u002FKYB and bank accounts (ba_); a Fireblocks payout instruction set maps to a BlindPay quote (qu_) followed by an executed payout (po_); Fireblocks vault accounts, transactions, and whitelisted addresses have no BlindPay equivalent and stay on Fireblocks as the custody and signing layer. Flag anything with no direct equivalent instead of guessing, and confirm any Fireblocks mechanism I have not explicitly listed against the Fireblocks docs before relying on it.\n2. Re-onboard payees on BlindPay: create customer, KYC\u002FKYB via document upload, add rail-specific bank accounts (Pix, SPEI, SEPA, ACH, wire), driven by webhooks. KYC does not transfer between providers, so plan for re-verification and sequence it before the cutover so approved payees are ready when we switch. Store the resulting re_ and ba_ IDs next to the legacy Fireblocks payee account IDs.\n3. Rebuild the payout leg on BlindPay's explicit two-step model: request a quote, then execute the payout before expires_at (about 5 minutes), replacing the Fireblocks payout instruction set creation-then-execution flow. If funds keep custody in Fireblocks vault accounts, register the Fireblocks-controlled wallet with BlindPay through the external-wallet sign-message challenge (bw_ ID) so BlindPay can source funds from it. Store qu_, po_, and bw_ IDs alongside the legacy Fireblocks IDs during the transition.\n4. Port webhooks to BlindPay's Svix-signed events (customer.*, payout.*, wallet.inbound), verifying svix-id, svix-timestamp, and svix-signature against the raw request body with whsec_ and deduping on svix-id, replacing the Fireblocks-Signature RSA verification. Confirm every Fireblocks event type we currently consume has a BlindPay equivalent before cutting a flow over.\n5. Cut over per payout corridor behind a feature flag: dual-run with new payouts on BlindPay while Fireblocks payout instruction sets handle in-flight items, keep both webhook handlers live during the window, and only retire the Fireblocks payout path once a full dual-run settlement cycle has completed and been verified against the corridor's expected outcomes.\n\nConstraints:\n- Develop against a BlindPay development instance (USDB on testnets, KYC auto-approves) first, and exercise the $666.00 forced-failed and $777.00 forced-refunded sentinel amounts before touching production traffic.\n- Amounts are integer minor units; API keys stay server-side.\n- Produce a written migration report before changing code: the mapping table, gaps, and the re-KYC plan.\n\nDeliverables: the migration report, re-onboarding script, the BlindPay client and quote\u002Fpayout code paths behind a flag, the external-wallet registration flow if custody stays on Fireblocks, webhook handlers, and a cutover checklist.\n","text","",[28,29,24],"code",{"__ignoreMap":26},[15,31,33],{"id":32},"how-to-use","How to use",[35,36,37,41,44],"ol",{},[38,39,40],"li",{},"Point the agent at your codebase so it inventories real Fireblocks Payments Engine usage rather than assuming.",[38,42,43],{},"Review the migration report, especially which Fireblocks pieces stay (custody, signing) versus move (payouts, webhooks), before approving code changes.",[38,45,46],{},"Dual-run at least one full settlement cycle per corridor, including the sentinel failure and refund cases, before retiring the Fireblocks payout path.",[15,48,50],{"id":49},"related-docs","Related docs",[52,53,54,63,70,77],"ul",{},[38,55,56],{},[57,58,62],"a",{"href":59,"rel":60},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fintroduction",[61],"nofollow","Introduction",[38,64,65],{},[57,66,69],{"href":67,"rel":68},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Flearn\u002Fcustomers",[61],"Customers",[38,71,72],{},[57,73,76],{"href":74,"rel":75},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-quotes",[61],"Payout quotes",[38,78,79],{},[57,80,83],{"href":81,"rel":82},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Flearn\u002Fwebhooks",[61],"Webhooks",{"title":26,"searchDepth":85,"depth":85,"links":86},2,[87,88,89],{"id":17,"depth":85,"text":18},{"id":32,"depth":85,"text":33},{"id":49,"depth":85,"text":50},"migrations","2026-08-26","Move the stablecoin-to-fiat payout leg of a Fireblocks integration to BlindPay: map payout instruction sets, fiat accounts, and webhooks while Fireblocks stays as custodian.","md",false,{},true,"\u002Fprompts\u002Fmigrate-from-fireblocks",[99,100,101,102],"payouts","quotes","compliance","webhooks","---\ntitle: \"Migrate from Fireblocks to BlindPay\"\ndescription: \"Move the stablecoin-to-fiat payout leg of a Fireblocks integration to BlindPay: map payout instruction sets, fiat accounts, and webhooks while Fireblocks stays as custodian.\"\ndate: \"2026-08-26\"\ncategory: \"migrations\"\nproducts: [\"payouts\", \"quotes\", \"compliance\", \"webhooks\"]\n---\n\nPaste this prompt into your coding agent to move the fiat payout leg of a Fireblocks (developers.fireblocks.com) integration to BlindPay, keeping Fireblocks for custody and signing where you want it.\n\n## Prompt\n\n```text\nYou are migrating my application's stablecoin-to-fiat payout leg from Fireblocks (developers.fireblocks.com) to BlindPay. Fireblocks can stay in place for custody and transaction signing (vault accounts, transactions, whitelisted addresses); this migration targets only the fiat payout and offramp surface.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the quickstarts, customers, bank accounts, payout quotes, payouts, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n\nDo the migration in this order:\n1. Inventory my Fireblocks usage from the codebase: every Payments Engine call (payout instruction set creation, payout execution), connected fiat accounts, travel rule policy config, and webhook subscriptions (Fireblocks-Signature or Fireblocks-Webhook-Signature headers), plus every stored Fireblocks ID (payment accounts, payee accounts, payout instruction sets). Derive the concept mapping from what we actually use, roughly: Fireblocks payee fiat accounts map to BlindPay customers (re_) with KYC\u002FKYB and bank accounts (ba_); a Fireblocks payout instruction set maps to a BlindPay quote (qu_) followed by an executed payout (po_); Fireblocks vault accounts, transactions, and whitelisted addresses have no BlindPay equivalent and stay on Fireblocks as the custody and signing layer. Flag anything with no direct equivalent instead of guessing, and confirm any Fireblocks mechanism I have not explicitly listed against the Fireblocks docs before relying on it.\n2. Re-onboard payees on BlindPay: create customer, KYC\u002FKYB via document upload, add rail-specific bank accounts (Pix, SPEI, SEPA, ACH, wire), driven by webhooks. KYC does not transfer between providers, so plan for re-verification and sequence it before the cutover so approved payees are ready when we switch. Store the resulting re_ and ba_ IDs next to the legacy Fireblocks payee account IDs.\n3. Rebuild the payout leg on BlindPay's explicit two-step model: request a quote, then execute the payout before expires_at (about 5 minutes), replacing the Fireblocks payout instruction set creation-then-execution flow. If funds keep custody in Fireblocks vault accounts, register the Fireblocks-controlled wallet with BlindPay through the external-wallet sign-message challenge (bw_ ID) so BlindPay can source funds from it. Store qu_, po_, and bw_ IDs alongside the legacy Fireblocks IDs during the transition.\n4. Port webhooks to BlindPay's Svix-signed events (customer.*, payout.*, wallet.inbound), verifying svix-id, svix-timestamp, and svix-signature against the raw request body with whsec_ and deduping on svix-id, replacing the Fireblocks-Signature RSA verification. Confirm every Fireblocks event type we currently consume has a BlindPay equivalent before cutting a flow over.\n5. Cut over per payout corridor behind a feature flag: dual-run with new payouts on BlindPay while Fireblocks payout instruction sets handle in-flight items, keep both webhook handlers live during the window, and only retire the Fireblocks payout path once a full dual-run settlement cycle has completed and been verified against the corridor's expected outcomes.\n\nConstraints:\n- Develop against a BlindPay development instance (USDB on testnets, KYC auto-approves) first, and exercise the $666.00 forced-failed and $777.00 forced-refunded sentinel amounts before touching production traffic.\n- Amounts are integer minor units; API keys stay server-side.\n- Produce a written migration report before changing code: the mapping table, gaps, and the re-KYC plan.\n\nDeliverables: the migration report, re-onboarding script, the BlindPay client and quote\u002Fpayout code paths behind a flag, the external-wallet registration flow if custody stays on Fireblocks, webhook handlers, and a cutover checklist.\n```\n\n## How to use\n\n1. Point the agent at your codebase so it inventories real Fireblocks Payments Engine usage rather than assuming.\n2. Review the migration report, especially which Fireblocks pieces stay (custody, signing) versus move (payouts, webhooks), before approving code changes.\n3. Dual-run at least one full settlement cycle per corridor, including the sentinel failure and refund cases, before retiring the Fireblocks payout path.\n\n## Related docs\n\n- [Introduction](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fintroduction)\n- [Customers](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Flearn\u002Fcustomers)\n- [Payout quotes](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-quotes)\n- [Webhooks](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Flearn\u002Fwebhooks)\n",{"title":5,"description":92},"prompts\u002Fmigrate-from-fireblocks","ExHlVZL5fR1-Q2NHfwjL070Gsa7uwh3I32W6Y6anMEo",[108,112,116,120,124,128,132,136,140,144,148,152,153,157,161,165,169],{"path":109,"title":110,"description":111},"\u002Fprompts\u002Fmigrate-from-anchorage","Migrate from Anchorage Digital to BlindPay","Keep Anchorage Digital for custody and move the stablecoin-to-fiat leg to BlindPay: map transfers, withdrawals, and settlement events to BlindPay quotes, payouts, and webhooks.",{"path":113,"title":114,"description":115},"\u002Fprompts\u002Fmigrate-from-bitgo","Migrate from BitGo to BlindPay","Move the stablecoin-to-fiat leg of a BitGo integration to BlindPay: map wallets, transfers, and settlement webhooks to BlindPay customers, quotes, payouts, and Svix events.",{"path":117,"title":118,"description":119},"\u002Fprompts\u002Fmigrate-from-bridge","Migrate from Bridge to BlindPay","Move an existing Bridge integration to the BlindPay API: map customers, external accounts, liquidation addresses, and transfers to their BlindPay equivalents.",{"path":121,"title":122,"description":123},"\u002Fprompts\u002Fmigrate-from-circle","Migrate from Circle to BlindPay","Move payouts and fiat on\u002Foff ramps from Circle Mint or the Circle Payments Network to BlindPay's quote-and-execute API with local rails.",{"path":125,"title":126,"description":127},"\u002Fprompts\u002Fmigrate-from-cobo","Migrate from Cobo to BlindPay","Move an existing Cobo Payments integration to the BlindPay API: keep Cobo for custody if you want, and replace the stablecoin-to-fiat leg with BlindPay's customers, quotes, and payouts.",{"path":129,"title":130,"description":131},"\u002Fprompts\u002Fmigrate-from-coinbase-cdp","Migrate from Coinbase CDP to BlindPay","Move the stablecoin-to-fiat offramp leg of a Coinbase Developer Platform integration to BlindPay: add Pix, SPEI, SEPA, ACH, and wire payouts while CDP wallets keep custody.",{"path":133,"title":134,"description":135},"\u002Fprompts\u002Fmigrate-from-conduit","Migrate from Conduit to BlindPay","Move a Conduit cross-border payments integration to BlindPay: counterparties, corridors, and settlement tracking on the quote-and-execute model.",{"path":137,"title":138,"description":139},"\u002Fprompts\u002Fmigrate-from-crossmint","Migrate from Crossmint to BlindPay","Move the stablecoin-to-fiat leg of a Crossmint integration to BlindPay while Crossmint keeps handling wallets, checkout, or orchestration.",{"path":141,"title":142,"description":143},"\u002Fprompts\u002Fmigrate-from-dfns","Migrate from Dfns to BlindPay","Keep Dfns for MPC wallet custody and move the stablecoin-to-fiat leg to BlindPay: map transfers and exchange withdrawals to quotes, payouts, and registered external wallets.",{"path":145,"title":146,"description":147},"\u002Fprompts\u002Fmigrate-from-dynamic","Migrate from Dynamic to BlindPay","Keep Dynamic for embedded and server wallets, move the stablecoin-to-fiat offramp leg to BlindPay: register the Dynamic wallet, quote and execute payouts, and verify webhooks.",{"path":149,"title":150,"description":151},"\u002Fprompts\u002Fmigrate-from-fern","Migrate from Fern to BlindPay","Move a Fern stablecoin integration to BlindPay: customers, wallets, on\u002Foff ramps, and webhook-driven settlement on the quote-and-execute model.",{"path":97,"title":5,"description":92},{"path":154,"title":155,"description":156},"\u002Fprompts\u002Fmigrate-from-privy","Migrate from Privy to BlindPay","Keep Privy for embedded and server wallets, move the stablecoin-to-fiat offramp leg to BlindPay: register the Privy wallet, quote and execute payouts, and verify webhooks.",{"path":158,"title":159,"description":160},"\u002Fprompts\u002Fmigrate-from-swift-wires","Migrate from SWIFT wires to stablecoin payouts","Replace multi-day international wires with same-day stablecoin settlement over local rails, keeping SWIFT as a fallback where you still need it.",{"path":162,"title":163,"description":164},"\u002Fprompts\u002Fmigrate-from-turnkey","Migrate from Turnkey to BlindPay","Keep Turnkey for wallets and signing, and move the stablecoin-to-fiat offramp leg of a Turnkey-based product to BlindPay: map payout accounts, quotes, and webhooks.",{"path":166,"title":167,"description":168},"\u002Fprompts\u002Fmigrate-from-utila","Migrate from Utila to BlindPay","Keep Utila as custodian and signer, and route the stablecoin-to-fiat leg through BlindPay: map vaults, wallets, transactions, and webhooks to their BlindPay equivalents.",{"path":170,"title":171,"description":172},"\u002Fprompts\u002Fmigrate-from-manual-payouts","Migrate from manual bank payouts to the API","Turn a spreadsheet-and-bank-portal payout operation into an automated, webhook-driven API flow with an auditable state machine.",1787868850392]