How to bridge USDT across networks with an API

What a USDT bridge actually does

Bridging means moving a token from one network to another — for example, taking USDT off BNB Chain and receiving USDT on Polygon. It is worth understanding what happens underneath, because it explains the states your integration will see.

USDT on BNB Chain is an ERC-20 contract on that network. USDT on Polygon is a different contract, on a different network. There is no literal "moving": there is delivering on the origin and receiving the equivalent on the destination, with someone guaranteeing the correspondence between the two ends.

That is why the operation has states rather than an immediate result.

The flow, in four states

Every transfer follows the same path, and your interface should reflect it:

1. Order created. You declare origin, destination, amount and receiving address. The order is born with an identifier. 2. Deposit broadcast. The token leaves the origin wallet. There is now a transaction hash on the origin network. 3. Awaiting confirmation. The origin network must consider that deposit final. That time is nobody's choice: it is a property of the network. 4. Delivery on the destination. The equivalent amount is sent on the destination network, and there is a second hash — that is the one the user wants to see.

Showing those four states is the difference between an integration that generates support tickets and one that does not. The most common mistake is displaying only "processing" and leaving the user unsure whether their money left at all.

The short way

npm install @vkx/bridge

The call needs five things: your key, the origin network, the destination network, the amount and the destination address. VKX Bridge creates the order, broadcasts the deposit, tracks confirmation and returns the destination hash.

The call comes from your server. The key is secret and must not exist in the app or the browser — the same rule as any payment credential.

Networks, directions and gas

Two things change with direction, and both affect the experience:

• Leaving Polygon, the deposit is sponsored: the origin wallet does not need POL to pay the send's gas. That removes a prerequisite that blocks many transfers — the user has the USDT but not the native coin.
• Leaving BNB Chain, the ERC-20 send is paid by the origin, in BNB. The wallet needs a minimum BNB balance for the send transaction.

The current list of served pairs per direction is on the product page. Check it before assuming a direction: it is not symmetric — serving A to B does not imply serving B to A.

Minimums, fees and what to check before sending

Three validations prevent most support problems:

• Minimum amount. Every bridge has a floor, because below it network cost eats the transfer. Check the direction's minimum before letting the user confirm.
• Address on the right network. EVM addresses have the same format across every EVM network, which is convenient and dangerous: a valid address may belong to a network where the user controls nothing. If the destination is an exchange, confirm it accepts deposits on that specific network.
• Gas balance on the origin, when the direction requires it.

On fees: they are charged per transfer and depend on the pair and the amount. The current number lives in the product, and it is worth computing at quote time rather than hardcoding.

Common errors, and what to do

• Deposit below the minimum. The order does not complete. That is why validation must happen before the user signs, not after.
• Wrong network on the destination. If the destination is a wallet you control, it is recoverable. If it is an exchange that does not support that network, often it is not. Warn beforehand.
• Origin without gas. The send transaction never leaves. A clear message here saves a lot of support.
• Failure mid-path. There is a refund. The user needs to see that in the interface, not discover it on their own.

On timing

There is no fixed deadline. Timing depends on the origin network's finality and current congestion. Promising "in 30 seconds" would be imprecise — what you can do, and what serves the user better, is showing the order's real state at each step.

FAQ

Do I need the origin network's native coin? Leaving Polygon, no — the deposit is sponsored. From BNB Chain, yes: the ERC-20 send is paid in BNB.

Can the call come from the app? No. The key is secret; the call originates on your server.

How long does it take? It depends on origin finality and congestion. There is no honest fixed deadline; the order state is queryable throughout.

What if I send below the minimum? The order does not complete. Validate the minimum before the user confirms.

Can any pair of networks be served? No, and it is not symmetric. Check the served pairs per direction before assuming.

Does it work for tokens other than USDT? The primary case is stablecoin across EVM networks. Served pairs and assets are listed in the product.

Next step

If you are still deciding between integrating and building, it is worth reading why a bridge is hard to run. If the decision is made, pairs and pricing are on the product page, and the documentation has the API reference.

Disclaimer: this content is informational and educational and does not constitute investment advice.