Skip to main content
This flow starts with a funded source asset on any supported chain and ends with BTC delivered to Spark, Bitcoin L1, or Lightning, or USDB delivered to Spark. If you want a reusable deposit address that runs this flow automatically on each deposit, use reusable addresses. Common uses:
  • Wallet buy flow: users pay USDC and receive BTC to a Spark address, Bitcoin address, or Lightning invoice.
  • Payout rails: convert USDC into BTC without running Bitcoin infrastructure.
Live pairs, per-asset contract addresses, decimals, and chain ids come from GET /v1/orchestration/routes. Per-route amount bounds come from GET /v1/orchestration/limits. Never hardcode contract addresses; read them from the route entry’s source and destination detail objects.

Flow

  1. Create a quote: POST /v1/orchestration/quote.
  2. Send the source asset to depositAddress for amountIn.
  3. Submit the deposit transaction: POST /v1/orchestration/submit.
  4. Track status via webhooks or GET /v1/orchestration/status?id=....
Quotes expire 2 minutes after creation. Late deposits are always repriced at live market rates at detection time and execute against the quote’s slippageBps.

Affiliate fees

App fees are supported on these routes when amountMode=exact_in. Fees are computed in USDC and settled on Solana. Flashnet retains a 20% platform cut of all app fees; the remaining 80% goes to the fee recipient. Affiliate fees use a holdback model where the recipient’s 80% share accumulates and is claimed by the affiliate. For SOL/ETH routes, the engine converts to USDC first, then applies fees. See Quotes and Orders for the full affiliate fee model.

Example: USDC (Base) to BTC (Spark)

Example: SOL (Solana) to BTC (Spark)

amount is lamports (1 SOL = 1_000_000_000 lamports).

Example: SOL (Solana) to BTC (Spark) with affiliate fee

Example: SOL (Solana) to BTC (Spark) with affiliate registry

Example: USDC to BTC (Bitcoin L1)

Set destinationChain = bitcoin and provide a Bitcoin address in recipientAddress.
The submit step is the same as any USDC source quote.

Example: USDC to BTC (Lightning)

Lightning-destination routes use custom pricing. USDB routes get the lowest rates. For Lightning payouts, recipientAddress must be a BOLT11 invoice. Use an amountless (0-amount) invoice for exact-in mode, or an invoice with an amount matching the target sats for exact-out mode. Amountless invoices are accepted in both modes.
The submit step is the same as any USDC source quote.

Example: USDC to BTC (Lightning, exact out)

Use exact-out when the recipient must receive a precise number of sats on Lightning. The system determines the required USDC input and includes a routing fee buffer.
amount is the target BTC delivery in sats. The recipientAddress can be an amountless invoice or an invoice encoding the same amount (100,000 sats in this case). The quote response includes the same exact-out fields as BTC-to-USDC exact-out:
  • targetAmountOut: the requested sats (matches amount)
  • requiredAmountIn: USDC to deposit
  • maxAcceptedAmountIn: upper bound on accepted deposit
  • inputBufferBps: buffer applied to the required input
Affiliate fees (appFees / affiliateId / affiliateIds) are not supported with amountMode=exact_out.

Example: USDT (Ethereum) to BTC (Spark)

For chain sources other than Solana, the quote returns a deposit address on the source chain. The deposit is detected automatically.
amount is in USDT smallest units (6 decimals). The depositAddress in the response is an Ethereum address. Send USDT there and the order is created automatically.

Deposit verification

The engine verifies that the deposit transaction sent the correct asset to the quoted depositAddress. When sourceAddress is provided on submit, the verifier also confirms the sender matches. Deposits do not need to match the quoted amountIn exactly. See Deposit Amount Flexibility for details on how over/underpayments are handled.

Next steps