---
title: "Migrate from Utila to BlindPay"
description: "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."
date: "2026-08-26"
category: "migrations"
products: ["payouts", "quotes", "compliance", "webhooks"]
---

Paste this prompt into your coding agent to move the stablecoin-to-fiat leg of a Utila (docs.utila.io) integration to BlindPay while Utila keeps custody and signing.

## Prompt

```text
You are migrating the stablecoin-to-fiat leg of my application from Utila (docs.utila.io) to BlindPay. Utila stays in place as custodian and transaction signer (vaults, wallets, transaction initiation, policy engine, co-signer). Only the payout and offramp flow moves to BlindPay.

Before writing code, read these sources and follow them over any prior knowledge:
- https://blindpay.com/docs/llms.txt (read the quickstarts, customers, bank accounts, quotes, payouts, offramp wallets, and webhooks pages)
- The OpenAPI spec: curl https://api.blindpay.com/doc

Do the migration in this order:
1. Inventory my Utila usage from the codebase: every Utila endpoint called (vaults, wallets, transactions_initiatetransaction, transactions_voteontransactionrequest, addressbook entries) and every stored Utila resource name (vault, wallet, transaction). Separate transactions that are actually fiat payouts (transfers to OTC desks, exchange addresses, or address book entries tagged for offramp) from internal treasury moves. Confirm the exact policy engine vote-threshold and co-signer behavior in the Utila docs rather than assuming, since these are account-configurable. Produce a written report listing what stays on Utila (custody, signing, policy engine) and what moves to BlindPay (the fiat leg), before touching code.
2. Register each Utila wallet address that will keep custody with BlindPay as an external wallet, using the sign-message challenge flow, and store the resulting bw_ ID next to the Utila wallet resource name. This is the connection point: funds keep living in Utila wallets, BlindPay only needs proof of ownership to route payouts against them.
3. Onboard recipients as BlindPay customers (re_) with KYC/KYB and add their rail-specific bank accounts (ba_) for Pix, SPEI, SEPA, ACH, or wire. Utila KYC and policy approvals do not transfer, so sequence re-verification ahead of cutover.
4. Rebuild the payout leg on BlindPay's two-step model: request a quote (qu_), then execute the payout (po_) referencing the registered external wallet before expires_at (about 5 minutes). The actual on-chain transfer still goes through Utila's transaction initiation and policy engine vote. Store qu_ and po_ IDs alongside the originating Utila transaction resource name so both sides of one payout are traceable.
5. Port event handling to BlindPay's Svix-signed webhooks (customer.*, payout.*, wallet.inbound) with signature verification and svix-id dedup, and run these handlers alongside the existing Utila webhook handler (x-utila-signature, TRANSACTION_STATE_UPDATED) so custody-side and fiat-side state both stay current.
6. Cut over per flow behind a feature flag: dual-run with new payouts going through the BlindPay quote and payout path while Utila continues to sign and enforce policy on every transfer, keep both webhook handlers live during the window, and retire the old direct-to-OTC or direct-to-exchange transaction path only once a full dual-run settlement cycle completes with no discrepancies.

Constraints:
- Develop against a BlindPay development instance (USDB on testnets) first; test the $666.00 forced-failed and $777.00 forced-refunded sentinels before touching production amounts.
- Amounts are integer minor units on both sides; no floating point money math.
- API keys stay server-side.
- Produce the written inventory and mapping report before changing code.

Deliverables: the migration report, the external wallet registration script and stored bw_ mapping, the BlindPay client and quote/payout code paths behind a flag, both webhook handlers, and a cutover checklist.
```

## How to use

1. Point the agent at your codebase so it inventories real Utila usage instead of assuming which transactions are payouts.
2. Review the migration report, especially which vaults and wallets stay on Utila and the re-KYC sequencing, before approving code changes.
3. Dual-run at least one full settlement cycle, with both webhook handlers live, before retiring the old Utila-to-OTC path.

## Related docs

- [Introduction](https://blindpay.com/docs/introduction)
- [Customers](https://blindpay.com/docs/learn/customers)
- [Offramp wallets](https://blindpay.com/docs/offramp-wallets)
- [Utila webhooks](https://docs.utila.io/reference/webhooks)