Each Orchestration Address is bound to one user, one chain, one source token (USDC or USDT), and one destination External Account. The address is persistent - once created it lives forever and keeps accepting deposits, even after deactivation.
Once orchestration address is deactivated, no new conversion will be triggered.
How Orchestration Addresses Work
1
Create the address
Configure a source
(currency, chain), a destination External Account, and an orchestration mode. HIFI provisions a dedicated on-chain wallet and returns its address.2
Receive stablecoin deposits
Senders transfer USDC or USDT on-chain to the address. HIFI detects each deposit as it lands on-chain.
3
Automatic offramp
Based on the configured mode, HIFI batches eligible deposits and runs them through the standard offramp pipeline. USD lands in the destination account - no manual quote-accept step required.
Orchestration Modes
Choose one of three modes at create time. The mode is changeable later via the update endpoint.PER_DEPOSIT- a deposit at or above the minimum is batched immediately; a sub-minimum deposit is heldPENDINGand swept into the next qualifying batch.SCHEDULED- a tick whosePENDINGtotal is below the minimum batches nothing; the deposits roll into the next tick.THRESHOLD-thresholdAmountis validated to be ≥ the rail minimum at create/update time, so a crossed threshold always clears it.
SCHEDULED clock.
Supported Source Pairs
Unsupported pairs (for example, USDC on Tron) are rejected at create time.
Minimum Amounts
Every destination rail enforces a minimum amount. A batch is only created once the eligiblePENDING deposits sum to at least that minimum.
Creating an Orchestration Address
Provisions the wallet and returns the address immediately -status is normally already ACTIVE by the time this call returns (it can briefly be PENDING_WALLET if wallet provisioning is still in flight). Requires an Idempotency-Key header.
Request
status may briefly be PENDING_WALLET while the on-chain wallet is being provisioned. The create endpoint waits for provisioning to complete, so the typical response is already ACTIVE with address populated.Managing the Address Lifecycle
Update
Change the mode, schedule, threshold, or destination account at any time while the address isACTIVE. Updates do not affect offramps already in flight - only future deposits use the new configuration. A DEACTIVATED address can’t be updated.
Request
Deactivate
Deactivate the address with awalletAddress to receive any remaining refunds.
Deactivation:
- Refunds all
PENDING(not-yet-batched) deposits towalletAddress. - Lets in-flight
PROCESSINGbatches continue to completion. - Stops offramping any new deposits - they are recorded as
IGNOREDwith no automatic refund.
Manual trigger
Batches whatever is currentlyPENDING right now, regardless of mode - useful for forcing an early settlement instead of waiting for the next scheduled tick or threshold crossing.
Request
triggered is false and batch is null, with a reason of no_pending_deposits, below_offramp_minimum, or address_no_longer_active.
Tracking Deposits
Use the GETv3/users/:userId/orchestration-addresses/:orchId/deposits to retrieve a list of deposits of an orchestration addresses with optional query filter.
Request
Statuses
Tracking Batches
Use the GETv3/users/:userId/orchestration-addresses/:orchId/batches to retrieve a list of created batches of an orchestration addresses with optional query filter.
Request
offrampTransactionId is null until the worker picks up the batch, then becomes the id of the produced Offramp - use GET v3/offramps/:offrampId for full transfer details, including its own quote, status history, and receipt.
Statuses
Additional Information
Reconciling with offramps
Reconciling with offramps
Orchestration offramps flow through the same pipeline as direct offramps, so the existing offramp endpoints and webhooks work without changes - once a batch produces an offramp, that offramp emits the standard
OFFRAMP.STATUS.* webhooks, and you can GET it directly for full transfer details.Ignored deposits
Ignored deposits
A deposit is recorded with
status = IGNORED (and not offramped) in two cases:ADDRESS_DEACTIVATED- the deposit arrived after the address was deactivated.UNSUPPORTED_TOKEN- the sender used the wrong stablecoin (for example, sending USDT to a USDC-only address).
Failed batches
Failed batches
A batch can land in
FAILED for one of two reasons, surfaced as failureReason:ADDRESS_NOT_ACTIVE- the address was deactivated between batch creation and processing.- A terminal offramp status (
NOT_INITIATED,QUOTE_FAILED,CRYPTO_FAILED,FIAT_FAILED,EXPIRED,REJECTED,CANCELLED) - the underlying offramp terminated. Compliance issues (lost product access, KYC rejection) surface here.
BATCHED status and are not automatically retried. Contact support to re-batch them once any underlying issue is resolved.Getting Help
- 📧 Email: support@hifi.com
- 💬 Slack: Message us in our shared Slack channel
Related Resources
- Orchestration Overview - Orchestration resources
- Virtual Accounts - The inverse flow: fiat deposits converted to stablecoins
- Offramps - The transaction each batch produces
- External Account - Valid destination accounts