Inspiration

Solana transactions fail at alarming rates — 48% from slippage issues, 36% from RPC failures, and 16% from blockhash expiry. During network congestion, success rates drop to 25-40%.

We watched traders lose money, developers struggle with unreliable infrastructure, and protocols suffer from poor user experience. The problem? Existing solutions are reactive — they look at what happened in the last minute to set slippage. By the time they react, it's already too late.

We asked: What if we could predict network chaos before it happens?


What it does

BELAY is a transaction reliability SDK for Solana that predicts if your transaction will fail and fixes it before you even send.

Core Features:

  • Market Anxiety Index — Monitors Polymarket sentiment + on-chain metrics to predict volatility 30-60 seconds ahead
  • Dual-Path Router — Races SWQoS (Helius/Triton) vs Jito Bundle simultaneously. First to land wins.
  • Smart Retry Engine — Fresh blockhash on every retry attempt with fast backoff (100-800ms)
  • ML Predictor — Random Forest model trained on 400+ real transactions to optimize compute units

The Result: 99% success rate vs 25-40% without BELAY during congestion.


How we built it

Two Independent Systems Working Together:

  1. Macro Prediction — Polymarket API (60%) + Solana on-chain metrics (40%) calculate an Anxiety Score (0-100). This determines slippage recommendations and routing strategy.

  2. Micro Optimization — ML model analyzes transaction structure (accounts, instructions, program type) to predict optimal compute units and priority fees.

Routing Logic Based on Anxiety:

  • 0-40% → Standard RPC only (Helius/Triton)
  • 40-85% → Dual-path racing (SWQoS + Jito)
  • 85%+ → Jito only (skip unreliable RPC)

Tech Stack: TypeScript, Next.js, Python, Scikit-learn, Solana web3.js, Polymarket API, Jito, Tailwind CSS


Challenges we ran into

  1. Polymarket API Limitations — Server-side requests were blocked (403). We pivoted to client-side fetching which actually improved real-time responsiveness.

  2. Oracle Reliability — Using Polymarket alone was risky. We implemented a dual-oracle system (60% Polymarket, 40% on-chain metrics) so they balance each other if one is manipulated.

  3. ML Model Training — Getting labeled transaction data was challenging. We built a custom data collection script to gather 400+ real Jupiter/Raydium transactions from mainnet.

  4. Confidence vs Landing Rate — We learned that ML confidence ≠ landing probability. Model confidence tells us how sure the prediction is, not how likely the transaction will land. This distinction matters.


Accomplishments that we're proud of

  • Dual-Oracle System — Polymarket + on-chain metrics balance each other, making the anxiety score manipulation-resistant
  • 82.5% ML Accuracy — Our Random Forest model correctly predicts compute unit requirements with high precision
  • Real-Time Demo — Live Polymarket data flowing into the UI, updating every 10 seconds
  • Clean Architecture — Two independent systems (macro prediction + micro optimization) that complement each other during execution
  • The One-Liner — "Jupiter sees the rain. BELAY sees the storm coming."

What we learned

  • Predictive beats Reactive — Looking 30-60 seconds ahead with market signals is more valuable than analyzing past volatility
  • Race, Don't Choose — Don't pick between fast (SWQoS) and reliable (Jito). Race both and take whichever wins.
  • Fresh Blockhash Matters — 80% of "validity expired" failures can be recovered by fetching a new blockhash on retry
  • Simple > Complex — Our 7-feature ML model at 82.5% accuracy beats complex solutions that are hard to debug

What's next for BELAY

  • Landing Rate Predictor — Train a model to output "this tx has X% chance of landing" with calibrated probabilities
  • More Oracles — Add Pyth price feeds, Birdeye volume data, Jito mempool analysis
  • Production SDK — Package as npm module with simple belay.send(tx) interface
  • Wallet Integration — Partner with Phantom/Backpack to show slippage recommendations before swaps
  • Scale — Process 10,000+ transactions and build specialized models for different failure types

Built With

Share this project:

Updates