← All posts

Trustware: How to Accept Crypto Deposits From Any Chain Without Building Your Own Bridge Integration

TL;DR: Building bridge integration yourself means picking chains to support, wiring wallet detection for each, and maintaining that surface as chains and wallets change. Trustware's SDK replaces that with configuration: set a destination chain and token once, drop in a widget or call a headless API, and the routing and wallet detection are handled underneath.

What does "accepting deposits from any chain" actually require?

Technically, it requires wallet detection across ecosystems, a route from whatever the user holds to whatever the app wants to receive, transaction submission, and status tracking until settlement, repeated reliably across every chain and wallet combination a user might show up with.

How to accept deposits from any chain with Trustware

Step 1, install the SDK and set your destination

Install @trustware/sdk and define your TrustwareConfigOptions: an API key, and a routes object specifying toChain and toToken, the destination your app actually wants to receive, regardless of what a user starts with.

Step 2, pick the integration style that matches your app

If you don't already manage wallet state, drop in TrustwareProvider with TrustwareWidget for the full flow, wallet selection through success or error, with no custom UI required. If your app already manages a connected wallet through Wagmi or another adapter, pass that wallet into the provider instead so Trustware doesn't take over wallet discovery. If you're building a fully custom interface, use the headless core API directly.

Step 3, let the SDK resolve the route

Whichever style you choose, the same underlying flow runs: build a route from the user's held asset to your configured destination, get a quote, submit the transaction, and track status until it settles. The headless API exposes this directly as buildRoute, getQuote, and runTopUp for teams that want the routing without the prebuilt UI.

Step 4, handle events and errors instead of building your own retry logic

The SDK emits status, quote, and error events, and includes configurable retry behavior for rate limiting, throwing a typed RateLimitError when retries are exhausted. Handling these is a matter of subscribing to events and catching a known error type, not building a bespoke retry system per chain.

The Trustware view, bridge integration work doesn't scale linearly with chain count

Building bridge support yourself typically means each new chain is its own integration project: new wallet detection, new testing, new maintenance surface. Configuring a destination once and letting a routing layer resolve any source chain underneath removes that per-chain scaling problem entirely from the app's own codebase.

A contrarian take, "which chains do you support" is the wrong question to ask your own roadmap

Teams that build bridge integration in-house often end up maintaining a running list of supported chains as a visible roadmap item. With routing infrastructure underneath the app, that list becomes the provider's concern, not a recurring line item on the app's own sprint planning.

What to ask before building bridge integration yourself

  • Does adding a new chain require new code in your app, or only new configuration?
  • Do you need to build separate wallet detection for EVM and non-EVM ecosystems, or does a layer already handle both?
  • Who owns maintaining that integration when a chain's RPC behavior or wallet standard changes?
  • Does your team have the bandwidth to build and maintain retry logic, rate-limit handling, and status polling per chain?
  • Would a widget, a host-wallet bridge, or a headless API best fit your existing wallet architecture?

See the Trustware docs and @trustware/sdk on npm for current integration details.

FAQ

Do I need to write custom code for every chain I want to support?

No, the destination chain and token are set through configuration once; the SDK resolves whatever source chain and asset the user holds against that destination.

What's the difference between the widget and the headless API?

The widget provides a full prebuilt UI, wallet selection through success or error; the headless API exposes the same routing (buildRoute, getQuote, runTopUp) for a fully custom interface.

Can I use my app's existing wallet connection instead of the SDK's?

Yes, the provider accepts a host-managed wallet, for example through Wagmi, so the SDK doesn't take over wallet discovery your app already handles.

What happens if I hit a rate limit during high volume?

The SDK's retry configuration handles this with configurable auto-retry and backoff; if retries are exhausted, it throws a typed RateLimitError your app can catch.

Does adding Solana support require a separate integration?

The SDK includes Solana wallet detection for wallets like Phantom, Solflare, and Backpack as part of its wallet layer, alongside EVM wallet support.

Is the routing itself custodial?

No, Trustware is built as non-custodial routing and settlement infrastructure.

How to decide if this replaces building it yourself

If your team is weighing building bridge integration in-house against integrating a routing layer, compare the ongoing maintenance cost, per-chain wallet detection, retry logic, status polling, against a one-time configuration and integration effort.

See trustware.io for current integration options.