On-ramps and off-ramps

A fiat-on-ramp adds a new chain by standing up nodes, indexers, reorg handling, and per-chain treasury wiring. Each addition is a quarter of engineering work, and the users sitting on the unsupported chain churn out long before the new integration ships.

With a UDA you skip that entire path. Issue one address per user, advertise "deposit any supported stablecoin from any supported chain", and let Stridge route the deposit to the chain your treasury actually operates on. The set of chains you support on the deposit side grows whenever Stridge adds a network — without you shipping anything.

The user does not pick a network in your UI — they paste an address. The on-ramp side of your app stays a single-chain integration; the deposit side is multi-chain by construction. Start at the UDA Quickstart.

B2B payouts and treasury

Reconciling stablecoin payouts across chains is the kind of work that produces shadow spreadsheets. The same nominal "USDC" splits into USDC.e, native USDC, bridged USDC; payers send on whichever network their CFO happened to fund last; finance has to map every transfer back to a customer by memo, timing, and luck.

Issue one UDA per customer, biller, or counterparty and the reconciliation problem collapses. Whatever chain the payer sends from, the funds land on the chain and in the token you operate in — and every deposit shows up as a uda.settlement.completed webhook tagged with the owner you assigned at create time.

• One row per customer — the owner field is your stable identifier; use the customer id, the entity id, or the email you already index on.
• No more memos — the deposit lands at a per-customer address; the address itself is the routing key.
• One token, one chain on the way out — settle every payer to your operational chain (e.g. Arbitrum USDC) regardless of where they sent from.

The settlement record at GET /v1/settlements/{id} carries the source-chain tx, the destination-chain tx, the route taken, and the total fee in destination units — drop it into your ledger and reconciliation is one webhook event away. See Settlements for the full record shape.

For payout and withdrawal flows where the back-office only knows the payer's on-chain deposit tx hash, look the settlement up by reference:

GET /v1/uda/settlements/by-reference?reference={deposit_tx_hash}

Three lookup paths cover every back-office need:

See List settlements by reference for the full response shape.

Peer-to-peer payments

A consumer P2P app's signup funnel dies on the second screen, where the new user has to pick a network. They hold USDC on Polygon; the app expects USDC on Base; nobody who is not already a crypto power user gets past that screen.

UDA turns "deposit" into a single field. Every user gets one address at signup, that address accepts deposits on every chain the user might happen to hold funds on, and the destination chain is whatever your wallet stack is built around. The chain picker disappears from your onboarding.

The three webhooks (deposit.confirmed, uda.settlement.created, uda.settlement.completed) give you exactly the events you need to drive the in-app deposit UI — pending state on confirm, "swap in progress" on settlement created, "funds available" on settlement completed.

Crypto neobanks

A neobank's deposit screen sets the tone for the entire product. If users see "select network, select token, copy the right address, double-check the chain in your sending wallet, hope for the best", the app feels like a developer tool. If they see one address that just works, it feels like a bank.

UDAs let you ship the second experience without operating bridges, monitoring solver liquidity, or staffing a settlement on-call. Each account holder gets one persistent deposit address that:

• Accepts USDC, USDT, and the chain's native asset on Ethereum, Arbitrum, Base, BNB Smart Chain, and Polygon.
• Lands every deposit in your account-ledger token on your account-ledger chain.
• Emits one webhook per lifecycle stage so the in-app balance can update without polling.

Pair it with GET /v1/uda/quote to surface an estimated fee and arrival time in the deposit UI before the user broadcasts. The quote response mirrors a completed settlement, so the same UI components render both the pre-deposit estimate and the post-deposit confirmation.

Invoicing and checkout

Invoice flows want a one-to-one mapping between an invoice and an address — for the same reason cash registers want a receipt number. The address is the routing key for reconciliation, support, and dispute handling.

UDAs satisfy this with no extra wiring. Create one UDA per invoice (use the invoice id as owner), embed the deposit address in the invoice, and the payer sends from whatever chain and stablecoin they happen to hold. The settlement webhook arrives tagged with the same owner, so closing the invoice is a one-line lookup against your invoice id.

Because every invoice gets a dedicated UDA, partial payments, overpayments, and late payments all land on the right invoice automatically — no memos, no human triage.