Bridge Finder

Context

Bridge Finder (formerly known as TooManyBridges) is a side project I built to solve a problem I kept running into while working on Catalyst. The crypto ecosystem has 50+ cross-chain bridges, each supporting a different subset of the total 250+ networks, and there was no single place to ask "which bridges can take me from chain A to chain B?"

I wanted to build the simplest possible answer to that question, something anyone could use without needing to know bridge names or manually check tables.

Problem

Finding the right bridge is surprisingly painful. A user wanting to move assets from Base to Arbitrum has to manually check each bridge's docs or UI to see if it supports both chains. Power users build mental maps of which bridges work where, but that knowledge doesn't scale and it breaks every time a new bridge or chain launches.

The existing solutions were either manually maintained static lists (which became quickly outdated) or aggregators like LI.FI that only had a subset of chains supported. There was a gap for a simple discovery tool that comprehensively answers "what are my options?".

Solution

I built Bridge Finder as a natural language search tool. You type something like "I want to go from Ethereum to Solana" and it returns every bridge that supports that route, with direct links to each bridge's UI.

The stack is Next.js 14, TypeScript, Tailwind, PostgreSQL with Prisma, and a single OpenAI API call for intent parsing.

The architecture splits the work into two layers.

• GPT-3.5-turbo handles the natural language parsing, extracting source and destination chain names from freeform text and returning them as structured JSON
• A deterministic database query then matches those chains against a curated dataset of 50+ bridges and 250+ networks, including an alias system so that "AVAX" and "Avalanche C-Chain" both resolve to the same network

The key design decision was keeping the AI narrow. The LLM only extracts two chain names from the user's input. Everything after that is a standard database lookup, which keeps the results fast, deterministic, and cheap to run.

The dataset itself was compiled by scraping every bridge for chain support, which was held in CSV files and later migrated into PostgresDB. This makes the data easy to update without touching application code, which matters because bridges add new chain support constantly.

For the UI, I leaned into a deliberately over-the-top Y2K aesthetic with the Wojak mascot and bold typography. The project was a weekend build and I wanted the presentation to match that energy.

Reflections

This was a small project but it reinforced a few things I keep coming back to.

• Use AI for the smallest possible surface area. GPT handles intent parsing and nothing else. The temptation is always to let the model do more, but constraining it to one job made the results reliable and the costs negligible.
• Alias systems beat LLM normalisation. Rather than asking GPT to guess chain nicknames (which it gets wrong often enough to be a problem), I built a hand-curated alias table. More work upfront, but deterministic results.
• Side projects should ship fast. The initial version went from idea to deployed in a weekend. I could have built a more polished product, but the goal was to validate whether the concept was useful, and shipping quickly let me do that.