[{"data":1,"prerenderedAt":172},["ShallowReactive",2],{"content-\u002Fprompts\u002Fintegrate-fireblocks":3,"prompts-category-integrations":106},{"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":102,"seo":103,"stem":104,"thumbnail":6,"updated":6,"__hash__":105},"content\u002Fprompts\u002Fintegrate-fireblocks.md","Integrate Fireblocks with 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 when your funds sit in Fireblocks vault accounts and need to authorize and fund BlindPay payouts.",[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 integrating BlindPay EVM payouts funded from a Fireblocks vault account into my application. Fireblocks holds the private key material (MPC, direct custody); every signature comes from Fireblocks' API, never from a local key or browser wallet.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the blockchain wallets page and the EVM payout guide)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Fdocs\u002Fquickstart.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fcreate-transactions.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fsign-typed-messages-for-ethereum-and-evm-networks.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Fdocs\u002Finteract-with-smart-contracts.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fmonitoring-transaction-status.md\n\nBuild the flow:\n1. Set up Fireblocks API authentication: generate an RSA-4096 keypair and CSR, upload the CSR in the Fireblocks Console to create an API user, and store the resulting API key and private key server-side. Confirm the SDK (`new Fireblocks({apiKey, secretKey, basePath})`) signs every request as a JWT automatically, so the private key never leaves the server.\n2. Register the sender wallet with BlindPay: call GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets\u002Fsign-message to get the challenge string, then sign it via Fireblocks with a POST \u002Fv1\u002Ftransactions call using operation TYPED_MESSAGE, source pointing at the vault account, and extraParameters.rawMessageData.messages[0] set to {content: hex(challenge), type: \"EIP191\"}; confirm the correct assetId for typed-message signing on this chain in the Fireblocks docs above rather than assuming one. Poll GET \u002Fv1\u002Ftransactions\u002F{txId} until status is COMPLETED, then assemble the signature from signedMessages[0].signature.{r,s,v} using the byte order and v-value convention documented on the Fireblocks typed-message signing page. POST the assembled signature to \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets and persist the returned bw_ ID against the customer record.\n3. Request a payout quote: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes with bank_account_id, network, and token, and persist the quote_id plus the full contract object from the response (address, abi, functionName \"approve\", blindpayContractAddress, amount, network) alongside the pending payout record, reading every field verbatim from that response rather than a stored constant.\n4. Send the approve call through Fireblocks: build the ABI-encoded calldata from the quote's contract.abi and functionName \"approve\" (using ethers.js, viem, or web3.js), then POST \u002Fv1\u002Ftransactions with operation CONTRACT_CALL, assetId matching the chain, source set to the vault account, destination as a ONE_TIME_ADDRESS pointing at the token contract, amount \"0\", and extraParameters.contractCallData set to the encoded hex. Poll GET \u002Fv1\u002Ftransactions\u002F{txId} (or subscribe to Fireblocks' transaction webhook) through PENDING_SIGNATURE, BROADCASTING, and CONFIRMING until status is COMPLETED, and treat BLOCKED, FAILED, CANCELLED, or REJECTED as a hard stop that surfaces the Fireblocks policy or cosigner rejection reason to an operator.\n5. Execute the payout before the quote expires: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayouts\u002Fevm with quote_id and sender_wallet_address before expires_at (about 5 minutes out). Since Fireblocks' Transaction Authorization Policy and cosigner approval add latency on top of the approve confirmation, check the remaining time-to-expiry before calling this endpoint; if the quote has already expired, re-quote and skip a fresh approve call when the existing on-chain allowance already covers the new quote's amount.\n6. Handle payout status from BlindPay's Svix-signed webhooks (svix-id, svix-timestamp, svix-signature verified with whsec_ against the raw body) for payout.new, payout.update, and payout.complete, and update the payout record's state on each event.\n7. Run the full flow end to end on a development instance: use USDB on a testnet (for example base_sepolia), where KYC auto-approves, and verify all three outcomes with sentinel amounts: a normal amount completes, $666.00 (66600 minor units) forces a failed payout, and $777.00 (77700 minor units) forces a refunded payout.\n\nConstraints:\n- API keys and the Fireblocks RSA private key stay server-side; nothing about signing touches the client.\n- Amounts are integer minor units everywhere, in both BlindPay and Fireblocks calls; never use floating point for money.\n- Treat any Fireblocks TAP or cosigner-approval detail you can't confirm from the docs above as unverified and check the Fireblocks Console\u002Fdocs before hardcoding an assumption about it.\n\nDeliverables: Fireblocks API auth setup, the wallet registration flow (TYPED_MESSAGE sign plus bw_ persistence), the CONTRACT_CALL approve module with async status polling or webhook handling, quote-execute orchestration with the expiry race handled against Fireblocks' approval latency, BlindPay webhook handlers, and a passing end-to-end test on the development instance covering the normal, failed, and refunded sentinel amounts.\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",{},"Have your Fireblocks API user, CSR-signed API key, and vault account ID ready before running this; the agent needs them to wire the SDK.",[38,42,43],{},"Point the agent at your actual Transaction Authorization Policy setup if you have approval quorums configured, since that changes how long the approve confirmation takes.",[38,45,46],{},"Run the sentinel-amount test on a development instance first; the quote-expiry race is the flow's main failure mode when Fireblocks' cosigner approval is slow.",[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-evm",[61],"EVM payouts",[38,71,72],{},[57,73,76],{"href":74,"rel":75},"https:\u002F\u002Fdevelopers.fireblocks.com\u002Fdocs\u002Fquickstart.md",[61],"Fireblocks quickstart",[38,78,79],{},[57,80,83],{"href":81,"rel":82},"https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fcreate-transactions.md",[61],"Fireblocks create transactions",{"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},"integrations","2026-08-26","Fund BlindPay stablecoin payouts from Fireblocks vault accounts: MPC-signed wallet registration and the ERC-20 approve through Fireblocks' transactions API.","md",false,{},true,"\u002Fprompts\u002Fintegrate-fireblocks",[99,100,101],"payouts","quotes","webhooks","---\ntitle: \"Integrate Fireblocks with BlindPay\"\ndescription: \"Fund BlindPay stablecoin payouts from Fireblocks vault accounts: MPC-signed wallet registration and the ERC-20 approve through Fireblocks' transactions API.\"\ndate: \"2026-08-26\"\ncategory: \"integrations\"\nproducts: [\"payouts\", \"quotes\", \"webhooks\"]\n---\n\nPaste this prompt into your coding agent when your funds sit in Fireblocks vault accounts and need to authorize and fund BlindPay payouts.\n\n## Prompt\n\n```text\nYou are integrating BlindPay EVM payouts funded from a Fireblocks vault account into my application. Fireblocks holds the private key material (MPC, direct custody); every signature comes from Fireblocks' API, never from a local key or browser wallet.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the blockchain wallets page and the EVM payout guide)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Fdocs\u002Fquickstart.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fcreate-transactions.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fsign-typed-messages-for-ethereum-and-evm-networks.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Fdocs\u002Finteract-with-smart-contracts.md\n- https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fmonitoring-transaction-status.md\n\nBuild the flow:\n1. Set up Fireblocks API authentication: generate an RSA-4096 keypair and CSR, upload the CSR in the Fireblocks Console to create an API user, and store the resulting API key and private key server-side. Confirm the SDK (`new Fireblocks({apiKey, secretKey, basePath})`) signs every request as a JWT automatically, so the private key never leaves the server.\n2. Register the sender wallet with BlindPay: call GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets\u002Fsign-message to get the challenge string, then sign it via Fireblocks with a POST \u002Fv1\u002Ftransactions call using operation TYPED_MESSAGE, source pointing at the vault account, and extraParameters.rawMessageData.messages[0] set to {content: hex(challenge), type: \"EIP191\"}; confirm the correct assetId for typed-message signing on this chain in the Fireblocks docs above rather than assuming one. Poll GET \u002Fv1\u002Ftransactions\u002F{txId} until status is COMPLETED, then assemble the signature from signedMessages[0].signature.{r,s,v} using the byte order and v-value convention documented on the Fireblocks typed-message signing page. POST the assembled signature to \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fblockchain-wallets and persist the returned bw_ ID against the customer record.\n3. Request a payout quote: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes with bank_account_id, network, and token, and persist the quote_id plus the full contract object from the response (address, abi, functionName \"approve\", blindpayContractAddress, amount, network) alongside the pending payout record, reading every field verbatim from that response rather than a stored constant.\n4. Send the approve call through Fireblocks: build the ABI-encoded calldata from the quote's contract.abi and functionName \"approve\" (using ethers.js, viem, or web3.js), then POST \u002Fv1\u002Ftransactions with operation CONTRACT_CALL, assetId matching the chain, source set to the vault account, destination as a ONE_TIME_ADDRESS pointing at the token contract, amount \"0\", and extraParameters.contractCallData set to the encoded hex. Poll GET \u002Fv1\u002Ftransactions\u002F{txId} (or subscribe to Fireblocks' transaction webhook) through PENDING_SIGNATURE, BROADCASTING, and CONFIRMING until status is COMPLETED, and treat BLOCKED, FAILED, CANCELLED, or REJECTED as a hard stop that surfaces the Fireblocks policy or cosigner rejection reason to an operator.\n5. Execute the payout before the quote expires: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayouts\u002Fevm with quote_id and sender_wallet_address before expires_at (about 5 minutes out). Since Fireblocks' Transaction Authorization Policy and cosigner approval add latency on top of the approve confirmation, check the remaining time-to-expiry before calling this endpoint; if the quote has already expired, re-quote and skip a fresh approve call when the existing on-chain allowance already covers the new quote's amount.\n6. Handle payout status from BlindPay's Svix-signed webhooks (svix-id, svix-timestamp, svix-signature verified with whsec_ against the raw body) for payout.new, payout.update, and payout.complete, and update the payout record's state on each event.\n7. Run the full flow end to end on a development instance: use USDB on a testnet (for example base_sepolia), where KYC auto-approves, and verify all three outcomes with sentinel amounts: a normal amount completes, $666.00 (66600 minor units) forces a failed payout, and $777.00 (77700 minor units) forces a refunded payout.\n\nConstraints:\n- API keys and the Fireblocks RSA private key stay server-side; nothing about signing touches the client.\n- Amounts are integer minor units everywhere, in both BlindPay and Fireblocks calls; never use floating point for money.\n- Treat any Fireblocks TAP or cosigner-approval detail you can't confirm from the docs above as unverified and check the Fireblocks Console\u002Fdocs before hardcoding an assumption about it.\n\nDeliverables: Fireblocks API auth setup, the wallet registration flow (TYPED_MESSAGE sign plus bw_ persistence), the CONTRACT_CALL approve module with async status polling or webhook handling, quote-execute orchestration with the expiry race handled against Fireblocks' approval latency, BlindPay webhook handlers, and a passing end-to-end test on the development instance covering the normal, failed, and refunded sentinel amounts.\n```\n\n## How to use\n\n1. Have your Fireblocks API user, CSR-signed API key, and vault account ID ready before running this; the agent needs them to wire the SDK.\n2. Point the agent at your actual Transaction Authorization Policy setup if you have approval quorums configured, since that changes how long the approve confirmation takes.\n3. Run the sentinel-amount test on a development instance first; the quote-expiry race is the flow's main failure mode when Fireblocks' cosigner approval is slow.\n\n## Related docs\n\n- [Blockchain wallets](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fblockchain-wallets)\n- [EVM payouts](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-evm)\n- [Fireblocks quickstart](https:\u002F\u002Fdevelopers.fireblocks.com\u002Fdocs\u002Fquickstart.md)\n- [Fireblocks create transactions](https:\u002F\u002Fdevelopers.fireblocks.com\u002Freference\u002Fcreate-transactions.md)\n",{"title":5,"description":92},"prompts\u002Fintegrate-fireblocks","Rw00JdemPJ4WNPTXWa0jsUM4xQXOhJfhr1jLSRkaAl8",[107,111,115,119,123,127,128,132,136,140,144,148,152,156,160,164,168],{"path":108,"title":109,"description":110},"\u002Fprompts\u002Fbuild-contractor-payouts","Build a global contractor payout product","Compose onboarding, bank accounts, quotes, payouts, and reconciliation into a complete pay-your-contractors feature across Pix, SPEI, SEPA, and ACH.",{"path":112,"title":113,"description":114},"\u002Fprompts\u002Fconnect-ai-agent-mcp","Connect an AI agent with the MCP server","Wire Claude, Cursor, or any MCP-compatible host to the BlindPay API with the official MCP server and agent skills, with guardrails for money movement.",{"path":116,"title":117,"description":118},"\u002Fprompts\u002Fintegrate-external-wallet-payouts","Fund payouts from external wallets","Let customers pay out from their own EVM, Solana, or Stellar wallets: signed-message registration plus the on-chain authorization step per chain.",{"path":120,"title":121,"description":122},"\u002Fprompts\u002Fintegrate-circle-wallets","Integrate Circle wallets with BlindPay","Fund BlindPay payouts from Circle developer-controlled wallets: sign the registration challenge and the ERC-20 approve through Circle's API instead of a browser wallet.",{"path":124,"title":125,"description":126},"\u002Fprompts\u002Fintegrate-dfns","Integrate Dfns with BlindPay","Fund BlindPay stablecoin payouts from Dfns MPC wallets: sign the registration challenge and the ERC-20 approve through Dfns's User Action Signature flow.",{"path":97,"title":5,"description":92},{"path":129,"title":130,"description":131},"\u002Fprompts\u002Fintegrate-privy","Integrate Privy with BlindPay","Fund BlindPay stablecoin payouts from Privy Server Wallets: sign the registration challenge and the ERC-20 approve through Privy's wallet RPC endpoint.",{"path":133,"title":134,"description":135},"\u002Fprompts\u002Fintegrate-virtual-accounts","Integrate US virtual accounts","Give each customer a named US bank account with ACH, RTP, wire, and SWIFT details that settles automatically to USDC or USDT in their wallet.",{"path":137,"title":138,"description":139},"\u002Fprompts\u002Fintegrate-utila","Integrate Utila with BlindPay","Fund BlindPay payouts from Utila MPC vaults: sign the wallet-registration challenge and the ERC-20 approve through Utila's service-account API, with async transaction confirmation handled.",{"path":141,"title":142,"description":143},"\u002Fprompts\u002Fintegrate-customer-onboarding","Integrate customer onboarding with KYC and KYB","Build the full onboarding pipeline: terms of service, individual and business customers, document uploads, RFI handling, and status webhooks.",{"path":145,"title":146,"description":147},"\u002Fprompts\u002Fintegrate-offramp-wallets","Integrate offramp wallets for auto-conversion","Give each bank account a dedicated crypto deposit address: stablecoins sent to it convert and pay out to the linked bank account automatically.",{"path":149,"title":150,"description":151},"\u002Fprompts\u002Fintegrate-payins","Integrate payins from bank transfers to stablecoins","Accept Pix, ACH, wire, SPEI, and other local bank transfers and settle them as USDC or USDT in a wallet, with quotes, payment instructions, and webhooks.",{"path":153,"title":154,"description":155},"\u002Fprompts\u002Fintegrate-quotes-fx","Integrate quotes and FX handling","Handle payin, payout, and transfer quotes correctly: expiry windows, currency_type conventions, fees, and displaying rates to users.",{"path":157,"title":158,"description":159},"\u002Fprompts\u002Fintegrate-stablecoin-payouts","Integrate stablecoin payouts end to end","Build a complete stablecoin to fiat payout flow: customer onboarding, bank accounts, quotes, and payout execution over Pix, ACH, SPEI, SEPA, and more.",{"path":161,"title":162,"description":163},"\u002Fprompts\u002Fintegrate-wallet-transfers","Integrate wallet transfers and cross-chain USDC","Move stablecoins from managed wallets to any address with transfer quotes, including cross-chain USDC over Circle CCTP v2.",{"path":165,"title":166,"description":167},"\u002Fprompts\u002Fintegrate-webhooks","Integrate webhooks end to end","Register endpoints, verify Svix signatures correctly, deduplicate retries, and drive payment state from the full BlindPay event catalog.",{"path":169,"title":170,"description":171},"\u002Fprompts\u002Fintegrate-payables","Pay boletos and Brazilian bills with payables","Register boletos, arrecadacao slips, and PIX codes as payables and settle them from stablecoins through the quote-and-execute flow.",1787868848571]