Skip to main content

​
What a bridge does

A bridge receives USDT on one chain and sends USDT to an address on another chain. It belongs to your merchant account and does not require a customer. Bridge deposits do not credit your Daya balance.
  1. Create a bridge with type: TEMPORARY, asset: USDT, the expected amount, source chain, destination, and refund address.
  2. Show the payer the returned deposit_address, asset, chain, and expires_at.
  3. Track payments through bridge deposits or bridge webhooks.
  4. Show a successful payout only when the deposit is COMPLETED.
Check the destination and refund addresses before creating the bridge. You cannot edit or cancel a bridge through the API. To credit your USD balance instead, use temporary crypto balance funding.

​
Assets and chains

Choose different source and destination chains from the supported list for the asset: The source must support deposits and withdrawals; the destination must support withdrawals. Check Supported Chains for current capabilities. For Solana, payout and refund addresses must have an active token account for the selected asset. Sandbox bridges use the same chain list with simulated payments.

​
Amounts and limits

Send amount as a decimal string in major token units, from 1 to 100000, with at most six decimal places. It is the expected amount, not an exact-payment requirement. Each deposit is processed separately and has its own fee and status. Deposits below the minimum or above the remaining bridge limit require review. For example, after 99999 USDT has been accepted, another 2 USDT deposit requires review in full. It is not split into a payout and refund. Request limits apply across your API keys. Expired requests can still count toward the quota. If creation returns 429 RATE_LIMITED, wait for Retry-After, then retry with the same idempotency key and body. See retry guidance.

​
Payment window

The payment window is 30 minutes. Use expires_at for the countdown and stop showing payment instructions at that deadline. Do not reuse an expired address for another payment. A request becomes EXPIRED at expires_at, including when it has received a payment. Expiry does not cancel a payout or trigger a refund. Track each deposit’s status until it completes or needs attention. Late payments can be held as REQUIRES_REVIEW with flag_code: LATE_DEPOSIT. A held deposit will not pay out automatically. Contact support@daya.co with the bridge and deposit IDs.

​
Fees

The default bridge fee is 1% per deposit, capped at 2 units of the asset. Use the returned fee and payout_amount to show the fee and recipient amount. Do not hard-code the default fee. Use decimal arithmetic when reading amounts. The fee is charged only when the payout completes.

​
Status and recovery

Read payout and refund for transfer status and transaction hashes. For REQUIRES_REVIEW or FAILED, read flag_code and flag_message, then contact support@daya.co with the bridge and deposit IDs. Do not send a replacement payment while the original outcome is unknown.

​
Refunds

A refund returns the full deposit amount to the refund_address, in the source asset and chain, with no refund fee. Partial refunds are not supported. Contact support@daya.co for help with a refund. Track progress through refund. The deposit becomes REVERSED when the refund completes. Paying a different amount from the estimate does not trigger an automatic refund.

​
Retries and webhooks

Retry a create with the same idempotency key and body to avoid a duplicate bridge. Successful retries return the original address and deadline; use GET for current status. See Create a bridge for retention and error handling. Use bridge reads and bridge.* webhooks to track this flow. Bridge deposits do not appear in ordinary deposit or payout lists. Follow the sandbox guide to test your integration.