OmnisRouter

Inspiration

OmnisRouter was inspired by a simple frustration: cross-chain stablecoin payments still feel harder than they should.

Sending USDC across chains should not feel like planning airport transfers in a country where you do not speak the language. But today, users still have to think about networks, bridge routes, gas, relayers, token accounts, finality, and whether the recipient actually got paid.

That felt like the wrong product experience.

The user’s job should be simple:

Send USDC to this recipient.

The product’s job should be everything else.

So I built OmnisRouter around one belief:

Make the route invisible, but keep the proof visible.

The route should disappear from the user’s mental load, but the receipt should remain clear, verifiable, and owned by the wallet that made the payment.

What it does

OmnisRouter is an AI-assisted cross-chain USDC router between Solana and Injective.

It lets users move USDC across chains through a cleaner intent-driven flow. Instead of manually choosing bridge infrastructure, relayers, gas paths, and route mechanics, the user connects a wallet, enters or reviews a payment intent, approves the route, and gets a receipt after execution.

The current testnet version supports two working routes:

Solana → Injective
Injective EVM → Solana

For Solana → Injective, the user connects a Solana wallet and authorizes the USDC burn. OmnisRouter sponsors the route flow, waits for Circle Iris attestation, relays the message to Injective, and saves the receipt.

For Injective EVM → Solana, the user connects an Injective EVM wallet and signs an EIP-3009 USDC authorization. OmnisRouter submits the authorization, pays the Injective gas, burns and forwards the USDC through Circle CCTP, and Circle Forwarding Service handles the Solana-side mint.

OmnisRouter also includes wallet-scoped receipts. A user signs in with their wallet, and only sees receipts owned by that wallet.

I also integrated Novus AI so product behavior can be measured instead of guessed. For a product-focused hackathon, that mattered to me because shippedness is not just “the app loads.” It is whether people can land on the product, use it, and generate real behavior.

How we built it

OmnisRouter is built with Next.js, React, TypeScript, Supabase, RainbowKit, wagmi, viem, Solana tooling, Injective EVM, and Circle CCTP V2.

The product has a few core layers:

Intent layer
  ↓
Route detection
  ↓
Wallet connection
  ↓
Recipient validation
  ↓
Route approval
  ↓
CCTP execution
  ↓
Receipt persistence

The Solana route uses a connected Solana wallet and Circle CCTP manual relay. After the user authorizes the burn, OmnisRouter handles the attestation and Injective relay.

The Injective EVM route uses EIP-3009 authorization. This lets the user authorize USDC movement with a wallet signature, while OmnisRouter pays the gas and handles the CCTP forwarding path.

Supabase stores route receipts, wallet-auth challenges, and waitlist entries. Receipts are wallet-scoped, so users do not see a public global transaction log. They sign in with the wallet that owns the receipt.

On the frontend, I focused heavily on product clarity: real wallet balances, route-specific approval cards, clear recipient verification, visible execution state, toast feedback, and a clean production mode that hides demo/debug/server-funded tools.

Challenges we ran into

The hardest part was not just making CCTP work.

The harder part was making the product experience honest.

Early versions used server-funded testnet execution, which proved the route but did not fully match the product thesis. I wanted the user to own the source-side action, while OmnisRouter handled the complexity around gas, relay, and proof.

That led to a lot of iteration around wallet signing.

Solana was more straightforward because the transaction could be structured so the user authorizes the USDC burn while OmnisRouter sponsors the fee flow.

Injective EVM was more complex. Normal wallet transactions would make the user pay gas, which would break the experience I wanted. After researching Circle USDC authorization methods, I implemented an EIP-3009 flow where the user signs a USDC authorization and OmnisRouter submits it.

Another challenge was wallet UX. Solana wallets and Injective EVM wallets behave differently, and browser wallets can hijack provider state in confusing ways. I had to separate Solana wallet connection from Injective EVM wallet connection, add RainbowKit for supported EVM wallets, remove confusing native Injective wallet paths from the production flow, and make the dashboard show only real connected wallet states.

Receipts were also more complex than expected. It was not enough to save receipts. They needed to belong to the wallet that created them. So I added wallet-auth sessions and private wallet-scoped receipt access.

Accomplishments that we're proud of

I am proud that OmnisRouter is not just a mock UI.

It executes real testnet routes.

It connects real wallets.

It reads real balances.

It moves real testnet USDC.

It stores real receipts.

The two working routes are the biggest accomplishments:

Solana → Injective
Injective EVM → Solana

I am especially proud of the Injective EVM → Solana route because it shows the product thesis more clearly: the user signs an authorization, OmnisRouter pays the gas, and the route still completes through CCTP.

I am also proud of making receipts wallet-scoped. It makes the product feel less like a demo dashboard and more like a real payment product with personal payment history.

The other thing I am proud of is the production cleanup. Demo routes, server-funded executor tools, debug panels, and mock states are hidden from the public product. The live experience focuses only on working routes, real wallets, real approvals, and real receipts.

What we learned

The biggest lesson was that cross-chain payments are not just an infrastructure problem. They are a product problem.

A bridge can technically work and still feel bad to use.

A route can be correct and still confuse the user.

A transaction can succeed and still leave the user unsure whether the recipient got paid.

So I learned to think about the route as a product journey, not only a technical flow.

I also learned that “gasless” is not one thing. It depends heavily on the chain, wallet, token contract, and signing model. Solana and Injective EVM required very different approaches.

Finally, I learned that proof matters. When money moves across chains, users need more than a success message. They need receipts, transaction hashes, ownership, and a clear record of what happened.

What's next for OmnisRouter

The next step is route expansion.

I want to add support for:

Arc
Base
Arbitrum

But before adding more routes, the focus is to keep the product experience clean: real wallet states, real approvals, real receipts, and no confusing demo surfaces in production.

Upcoming improvements include: