For the complete documentation index, see llms.txt. This page is also available as Markdown.

Bridge Workflow

This page shows the bridge flow from the user's point of view.

Start with a plain request

The user can describe the transfer in ordinary language:

  • “Bridge USDC from Solana to BSC”

  • “Move stablecoins from Ethereum to Tron”

  • “Send 5 USDC to this address”

If the chain or token is not known yet, start with the catalog tools:

  • list_supported_chains

  • list_supported_tokens

If you already know the pair and only need pricing or route comparison, use find_bridge_routes or quote_bridge_transfer.

Plan the route

Call plan_bridge_transfer with the source chain, destination chain, source token, amount, and any optional destination token.

The response tells you:

  • which route is available

  • which messenger is recommended

  • which fee option is available

  • what the user is expected to receive

  • what the next step should be

Check balances before execution

Before you build the execution job, call check_bridge_balances.

This verifies that the sender can cover:

  • the bridged amount

  • the selected fee

If the check fails, stop and ask the user to top up.

Build the execution job

Once the route and balances are confirmed, call create_bridge_execution_job.

The job gives you:

  • an ordered list of steps

  • raw transaction payloads

  • handoff metadata

  • wallet hints

  • transfer tracking details

If the intended local wallet is already known, pass walletId.

Prepare destination prerequisites

Some destination chains require setup before a user can receive the bridged asset.

Use these tools when the destination side needs an explicit prerequisite:

  • check_stellar_trustline

  • build_stellar_trustline_transaction

  • check_algorand_optin

  • build_algorand_optin_transaction

The setup transaction is still unsigned. If it needs a local signature, hand it to Local Signer MCP the same way as a bridge execution step.

Sign or broadcast

There are two valid ways to finish the job:

  • hand the unsigned step to Local Signer MCP

  • broadcast a payload that is already signed with Allbridge MCP

Choose the path that matches the step you received.

Track the transfer

After the source-chain transaction is sent, call get_transfer_status.

That lets the client follow the transfer until the receive side is confirmed.

In one sentence

Allbridge MCP plans the route, checks the balance, builds the job, and tracks the transfer; Local Signer MCP handles the local signing step when needed.

Last updated