Skip to main content
An Orchestration Address is the inverse of a Virtual Account: 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 held PENDING and swept into the next qualifying batch.
  • SCHEDULED - a tick whose PENDING total is below the minimum batches nothing; the deposits roll into the next tick.
  • THRESHOLD - thresholdAmount is validated to be ≥ the rail minimum at create/update time, so a crossed threshold always clears it.
Every active address also supports a manual trigger that batches whatever is currently pending - regardless of mode - without advancing the 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 eligible PENDING 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
Response
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.
Get an Orchestration Address (the single-address endpoint) also returns a live balance field - the on-chain balance of the source token held by the address - so you don’t need a separate provider call to check funds in flight.

Managing the Address Lifecycle

Update

Change the mode, schedule, threshold, or destination account at any time while the address is ACTIVE. 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 a walletAddress to receive any remaining refunds. Deactivation:
  • Refunds all PENDING (not-yet-batched) deposits to walletAddress.
  • Lets in-flight PROCESSING batches continue to completion.
  • Stops offramping any new deposits - they are recorded as IGNORED with no automatic refund.
Request
The on-chain address keeps receiving deposits even after deactivation, since the underlying wallet cannot be taken offline.

Manual trigger

Batches whatever is currently PENDING right now, regardless of mode - useful for forcing an early settlement instead of waiting for the next scheduled tick or threshold crossing. Request
Response
If there’s nothing eligible to batch, 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 GET v3/users/:userId/orchestration-addresses/:orchId/deposits to retrieve a list of deposits of an orchestration addresses with optional query filter. Request
Response

Statuses

Tracking Batches

Use the GET v3/users/:userId/orchestration-addresses/:orchId/batches to retrieve a list of created batches of an orchestration addresses with optional query filter. Request
Response
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

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.
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).
In both cases the funds remain in the on-chain wallet. Contact support to arrange a manual refund.
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.
The deposits in a failed batch remain in 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