> ## Documentation Index > Fetch the complete documentation index at: https://docs.daya.co/llms.txt > Use this file to discover all available pages before exploring further. # Bridges > Move USDT to another chain and track each deposit, payout, or refund ## 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](/api-reference/bridges/create-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](/api-reference/bridges/list-bridge-deposits) or [bridge webhooks](/api-reference/webhooks/events#bridge-events). 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](/concepts/funding-accounts#temporary-crypto-balance-funding). ## Assets and chains Choose different source and destination chains from the supported list for the asset: | Asset | Source and destination chains | | - | - | | `USDT` | `POLYGON`, `BSC`, `SOLANA`, `APTOS` | The source must support deposits and withdrawals; the destination must support withdrawals. Check [Supported Chains](/api-reference/supported-chains/list-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. | Limit | Value | | - | - | | Minimum deposit for automatic processing | `1` unit of the asset | | Total deposits accepted for automatic processing per bridge | `100000` units of the asset | | Unfunded requests that still accept deposits per merchant | `20` | | Unfunded bridges created per merchant in 24 hours | `100` | 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](/api-reference/bridges/create-bridge#idempotency-and-errors). ## 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](mailto: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. | Deposit | Fee | Recipient amount | | - | - | - | | `1.000000` | `0.010000` | `0.990000` | | `100.000000` | `1.000000` | `99.000000` | | `500.000000` | `2.000000` | `498.000000` | Use decimal arithmetic when reading amounts. The fee is charged only when the payout completes. ## Status and recovery | Deposit status | Meaning | | - | - | | `RECEIVED` | Deposit received; payout is not complete. | | `PROCESSING` | Payout or refund is in progress. | | `REQUIRES_REVIEW` | The deposit needs review. | | `FAILED` | Payout failed. | | `COMPLETED` | The recipient has been paid. | | `REVERSED` | The full deposit has been refunded. | 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](mailto: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](mailto: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](/api-reference/bridges/create-bridge#idempotency-and-errors) 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](/limits/sandbox-testing#bridges) to test your integration. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.