Skip to main content
← Back to Learn

One Validator, Five Front Doors

Every surface that quotes a bridge — web widget, mini app, agent plugin, partner API — was about to get its own copy of the rules that keep a bad transaction from reaching your wallet. We chose to have one rulebook instead.

A bridge quote is a strange artifact: a third-party API hands you calldata and says "sign this." The safety of the whole flow depends on a checklist run between the API's answer and your wallet — is the target contract the real deployment, does the calldata actually name your address, is the approval a real approve() to a real spender, is the quote still alive?

We have that checklist. It was written in TypeScript, inside the web route — which meant it only existed where that route existed.

The trap in "just copy it"

Five surfaces need the same rules: the swap widget, the Farcaster mini app, the agent plugin, partner integrations, and whatever ships next. The obvious path — re-implement the checklist per surface — is how security checks quietly fork: one copy gets the fix, another doesn't, and six months later a user signs something the newest copy would have caught.

The checklist is deterministic, order-sensitive, and adversarial. It assumes the upstream can be wrong or malicious, because that's the job. That's exactly the kind of code you want written once, in a language built for it, behind one port.

What moved

The bridge gateway is now a small Rust service. It resolves the curated token set, fetches the quote upstream, and runs the full gauntlet before anything is returned: contract allowlists per chain, token echo checks, the distinction between "simulation failed because you haven't approved yet" and "simulation failed because this tx is bad," approval calldata decoded and verified against a trusted spender set, expiry and amount sanity.

The test suite is the parity spec — the same fixtures as the web implementation, including the failure matrix. Same addresses, same edge cases, same expected rejections. If the two implementations ever disagree, the fixtures are where you look first.

What stays at the door

The web routes keep their jobs: authentication, the paywall, telemetry, response shaping. Those are product concerns — they belong at the edge, in the framework the product is built in. What's gone from the edge is the part that was never a product concern: deciding whether a transaction is safe to show you.

That's the shape we keep converging on — thin doors, one strong room behind them.

Put it to work

The research above powers the product — try it or compare it: