[{"data":1,"prerenderedAt":173},["ShallowReactive",2],{"content-\u002Fprompts\u002Fmigrate-from-dynamic":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-dynamic.md","Migrate from Dynamic 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 stablecoin-to-fiat offramp leg of a Dynamic (docs.dynamic.xyz) integration to BlindPay, keeping Dynamic in place for embedded and server wallets.",[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 offramp leg from Dynamic (docs.dynamic.xyz) to BlindPay. Dynamic stays in place as the wallet layer: users' stablecoins keep living in their Dynamic embedded or server wallets. This migration only replaces whatever converts those stablecoins to fiat and pays it out.\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, quotes, blockchain wallets, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n- https:\u002F\u002Fwww.dynamic.xyz\u002Ffeatures\u002Ffunding\n- https:\u002F\u002Fwww.dynamic.xyz\u002Fdocs\u002Foverview\u002Fdeveloper-dashboard\u002Fwebhooks\u002Foverview\nDynamic itself does not settle fiat; its funding surface is built for onramp (cards, Apple Pay, Google Pay, exchange transfers) rather than a native offramp. Confirm in the Dynamic docs which mechanism this codebase actually wired up for the stablecoin-to-fiat leg (a Dynamic funding integration, a bolted-on third-party offramp, or a manual flow) instead of assuming one; if the code shows something not covered by these pages, phrase it as unconfirmed rather than inventing an endpoint.\n\nDo the migration in this order:\n1. Inventory the current offramp path from the codebase: the funding or offramp integration in use, every stored Dynamic wallet ID (embedded or server, and whether it signs directly or through Delegated Access) that sends the crypto leg, any stored provider addresses or transaction hashes, and how completion is detected today (webhook, polling, or manual confirmation). Produce a written mapping from what we actually use to BlindPay concepts: the payee becomes a BlindPay customer (re_) with KYC\u002FKYB, their payout destination becomes a bank account (ba_) on the relevant rail, and the Dynamic wallet that currently sends to the offramp destination becomes the sender_wallet_address on a BlindPay payout instead. Flag anything with no direct equivalent rather than guessing.\n2. Register each Dynamic wallet as a BlindPay external wallet: fetch the sign-message challenge (GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets\u002Fsign-message), sign it with the Dynamic wallet's own signing call (the embedded wallet's client SDK, or delegatedSignMessage on the server for a Delegated Access wallet, per the Dynamic docs), submit the signature to POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets, and persist the returned bw_ ID against the customer record. Re-onboard each payee's KYC\u002FKYB on BlindPay through terms of service, customer creation, and document upload driven by webhooks, since KYC does not transfer between providers; sequence this ahead of the cutover so approved customers are ready when a flow switches over.\n3. Rebuild money movement on BlindPay's explicit two-step model: request a quote (POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes), sign and confirm the returned approve call through the same Dynamic wallet, then execute the payout (POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayouts\u002Fevm) with sender_wallet_address set to the Dynamic wallet's address, before the quote's expires_at (about 5 minutes). Store qu_, po_, and bw_ IDs alongside whatever ID the old offramp path used for the same transfer.\n4. Replace the old offramp completion signal with BlindPay's Svix-signed webhooks: verify svix-id, svix-timestamp, and svix-signature against the raw request body with whsec_, dedup on svix-id, and update payout state on payout.new, payout.update, and payout.complete.\n5. Cut over per payee or corridor behind a feature flag: dual-run new payouts on BlindPay while the old offramp path finishes any in-flight transfers, keep both completion signals live during the window, and only retire the old offramp integration once a full dual-run settlement cycle has completed and reconciled.\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- Keep BlindPay and Dynamic API keys server-side.\n- Store and compare all amounts as integer minor units; never use floating point for money math.\n- Produce a written migration report before changing code: the mapping table, the confirmed old-offramp mechanism, gaps, and the re-KYC plan.\n\nDeliverables: the migration report, the external-wallet registration module (challenge fetch, Dynamic signing call, bw_ persistence), the quote-to-payout orchestration with expiry handling, webhook handlers for the three payout events, 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 the real offramp integration or manual flow instead of assuming one from the Dynamic funding feature list.",[38,42,43],{},"Review the migration report, especially the confirmed old-offramp mechanism and the re-KYC sequencing, before approving code changes.",[38,45,46],{},"Dual-run at least one full settlement cycle per payee or corridor, including the sentinel failure and refund cases, before retiring the old offramp 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\u002Fblockchain-wallets",[61],"nofollow","Blockchain wallets",[38,64,65],{},[57,66,69],{"href":67,"rel":68},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-quotes",[61],"Payout quotes",[38,71,72],{},[57,73,76],{"href":74,"rel":75},"https:\u002F\u002Fwww.dynamic.xyz\u002Ffeatures\u002Ffunding",[61],"Dynamic funding",[38,78,79],{},[57,80,83],{"href":81,"rel":82},"https:\u002F\u002Fwww.dynamic.xyz\u002Fdocs\u002Foverview\u002Fdeveloper-dashboard\u002Fwebhooks\u002Foverview",[61],"Dynamic webhooks overview",{"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-27","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.","md",false,{},true,"\u002Fprompts\u002Fmigrate-from-dynamic",[99,100,101,102],"payouts","quotes","compliance","webhooks","---\ntitle: \"Migrate from Dynamic to BlindPay\"\ndescription: \"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.\"\ndate: \"2026-08-27\"\ncategory: \"migrations\"\nproducts: [\"payouts\", \"quotes\", \"compliance\", \"webhooks\"]\n---\n\nPaste this prompt into your coding agent to move the stablecoin-to-fiat offramp leg of a Dynamic (docs.dynamic.xyz) integration to BlindPay, keeping Dynamic in place for embedded and server wallets.\n\n## Prompt\n\n```text\nYou are migrating my application's stablecoin-to-fiat offramp leg from Dynamic (docs.dynamic.xyz) to BlindPay. Dynamic stays in place as the wallet layer: users' stablecoins keep living in their Dynamic embedded or server wallets. This migration only replaces whatever converts those stablecoins to fiat and pays it out.\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, quotes, blockchain wallets, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n- https:\u002F\u002Fwww.dynamic.xyz\u002Ffeatures\u002Ffunding\n- https:\u002F\u002Fwww.dynamic.xyz\u002Fdocs\u002Foverview\u002Fdeveloper-dashboard\u002Fwebhooks\u002Foverview\nDynamic itself does not settle fiat; its funding surface is built for onramp (cards, Apple Pay, Google Pay, exchange transfers) rather than a native offramp. Confirm in the Dynamic docs which mechanism this codebase actually wired up for the stablecoin-to-fiat leg (a Dynamic funding integration, a bolted-on third-party offramp, or a manual flow) instead of assuming one; if the code shows something not covered by these pages, phrase it as unconfirmed rather than inventing an endpoint.\n\nDo the migration in this order:\n1. Inventory the current offramp path from the codebase: the funding or offramp integration in use, every stored Dynamic wallet ID (embedded or server, and whether it signs directly or through Delegated Access) that sends the crypto leg, any stored provider addresses or transaction hashes, and how completion is detected today (webhook, polling, or manual confirmation). Produce a written mapping from what we actually use to BlindPay concepts: the payee becomes a BlindPay customer (re_) with KYC\u002FKYB, their payout destination becomes a bank account (ba_) on the relevant rail, and the Dynamic wallet that currently sends to the offramp destination becomes the sender_wallet_address on a BlindPay payout instead. Flag anything with no direct equivalent rather than guessing.\n2. Register each Dynamic wallet as a BlindPay external wallet: fetch the sign-message challenge (GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets\u002Fsign-message), sign it with the Dynamic wallet's own signing call (the embedded wallet's client SDK, or delegatedSignMessage on the server for a Delegated Access wallet, per the Dynamic docs), submit the signature to POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets, and persist the returned bw_ ID against the customer record. Re-onboard each payee's KYC\u002FKYB on BlindPay through terms of service, customer creation, and document upload driven by webhooks, since KYC does not transfer between providers; sequence this ahead of the cutover so approved customers are ready when a flow switches over.\n3. Rebuild money movement on BlindPay's explicit two-step model: request a quote (POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes), sign and confirm the returned approve call through the same Dynamic wallet, then execute the payout (POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayouts\u002Fevm) with sender_wallet_address set to the Dynamic wallet's address, before the quote's expires_at (about 5 minutes). Store qu_, po_, and bw_ IDs alongside whatever ID the old offramp path used for the same transfer.\n4. Replace the old offramp completion signal with BlindPay's Svix-signed webhooks: verify svix-id, svix-timestamp, and svix-signature against the raw request body with whsec_, dedup on svix-id, and update payout state on payout.new, payout.update, and payout.complete.\n5. Cut over per payee or corridor behind a feature flag: dual-run new payouts on BlindPay while the old offramp path finishes any in-flight transfers, keep both completion signals live during the window, and only retire the old offramp integration once a full dual-run settlement cycle has completed and reconciled.\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- Keep BlindPay and Dynamic API keys server-side.\n- Store and compare all amounts as integer minor units; never use floating point for money math.\n- Produce a written migration report before changing code: the mapping table, the confirmed old-offramp mechanism, gaps, and the re-KYC plan.\n\nDeliverables: the migration report, the external-wallet registration module (challenge fetch, Dynamic signing call, bw_ persistence), the quote-to-payout orchestration with expiry handling, webhook handlers for the three payout events, and a cutover checklist.\n```\n\n## How to use\n\n1. Point the agent at your codebase so it inventories the real offramp integration or manual flow instead of assuming one from the Dynamic funding feature list.\n2. Review the migration report, especially the confirmed old-offramp mechanism and the re-KYC sequencing, before approving code changes.\n3. Dual-run at least one full settlement cycle per payee or corridor, including the sentinel failure and refund cases, before retiring the old offramp path.\n\n## Related docs\n\n- [Blockchain wallets](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fblockchain-wallets)\n- [Payout quotes](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-quotes)\n- [Dynamic funding](https:\u002F\u002Fwww.dynamic.xyz\u002Ffeatures\u002Ffunding)\n- [Dynamic webhooks overview](https:\u002F\u002Fwww.dynamic.xyz\u002Fdocs\u002Foverview\u002Fdeveloper-dashboard\u002Fwebhooks\u002Foverview)\n",{"title":5,"description":92},"prompts\u002Fmigrate-from-dynamic","iLaNixQPlbLyTtWzOAAHhIVGGVJMs62AlT1VBtlu6ow",[108,112,116,120,124,128,132,136,140,144,145,149,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":97,"title":5,"description":92},{"path":146,"title":147,"description":148},"\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":150,"title":151,"description":152},"\u002Fprompts\u002Fmigrate-from-fireblocks","Migrate from Fireblocks to BlindPay","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.",{"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.",1787868850342]