GidiEngine — Advanced Infrastructure Challenge Submission

Builder@BigLateef
Live Demogidi-engine.vercel.app
GitHubBigLateef/GidiEngine
NetworkSolana Mainnet
StackRailway + Vercel + Multi-AI

What is GidiEngine?

GidiEngine is a production-ready Smart Transaction Stack built for the Solana mainnet. It combines a persistent slot-monitoring worker, a Jito MEV bundle engine, an AI-powered decision brain with multi-provider failover, and a real-time lifecycle tracker — all designed to be deployed and maintained entirely from a mobile phone with no laptop required.

The name comes from Gidi — Lagos street slang for the city itself. This is Nigeria building serious Solana infrastructure, from a phone, for the world.

Architecture Overview

Solana Cluster (slots)
        │
        ▼
┌─────────────────────┐  Railway — always-on persistent worker
│  Observer.js        │
│  Yellowstone gRPC ──┼── primary stream
│  Helius WS ─────────┼── auto-fallback if gRPC drops
└────────┬────────────┘
         │ slot event
         ▼
┌─────────────────────┐
│  Worker.js          │
│  CircuitBreaker ────┼── blocks after 3 consecutive failures
│  LeaderSchedule ────┼── only fires near Jito-connected validators
└────────┬────────────┘
         │
         ▼
┌─────────────────────┐  Vercel — serverless API layer
│  Agent.js           │
│  AIRouter ──────────┼── 🟣 Anthropic → 🟢 OpenAI → 🔵 Gemini → 🟡 Groq
│  StrategyProfiles ──┼── conservative / aggressive / sniper
└────────┬────────────┘
         │ decision: { profile, shouldExecute, params }
         ▼
┌─────────────────────┐
│  Retryer.js         │
│  Attempt 1: tip ×1.0│
│  Attempt 2: tip ×1.2│
│  Attempt 3: tip ×1.44
└────────┬────────────┘
         │
┌────────▼────────────┐
│  Executor.js        │
│  fetchJitoTip() ────┼── dynamic: 50th percentile + 25% buffer
│  buildBundle()  ────┼── Jito SDK programmatic construction
│  pollBundle()   ────┼── SUBMITTED→PROCESSED→CONFIRMED→FINALIZED
└─────────────────────┘
         │
  AlertHook.js → Slack + Discord
  LifecycleLogger.js → ms-precision timestamps
  Tracker.js → last 10 bundles stored, exposed via /api/tracker

Core Features Built

1. Dual Slot Monitoring

Observer.js maintains a persistent Yellowstone gRPC stream as primary. If the connection drops for any reason, it automatically activates a Helius WebSocket fallback within milliseconds — no manual intervention, no missed slots.

2. Leader-Aware Bundle Timing

LeaderSchedule.js fetches the upcoming validator leader schedule and only allows bundle submission within a configurable window (default: 4 slots) of a Jito-connected validator. This eliminates wasted tip spend against non-Jito leaders and dramatically improves win rate.

3. Jito Bundle Engine

Executor.js builds bundles programmatically using the Jito TypeScript SDK. Tip amounts are dynamic — fetched from Jito's live tip floor API at the 50th percentile, then bid 25% above median to stay competitive without overpaying.

4. AI Brain with Multi-Provider Failover

AIRouter.js is the key innovation. Instead of depending on a single LLM provider, GidiEngine maintains a 4-provider failover chain:

Priority Provider Model
1st Anthropic claude-sonnet-4-6
2nd OpenAI gpt-4o-mini
3rd Google Gemini gemini-1.5-flash
4th Groq llama-3.1-8b-instant

Each provider gets an 8-second timeout. On failure, the system alerts Slack/Discord and rolls to the next provider instantly. The getAgentDecision() function feeds the last 10 bundle lifecycle logs into whichever AI is available and receives back a structured execution decision:

{
  "shouldExecute": true,
  "reason": "Fast consensus trend, sniper window detected",
  "profile": "sniper",
  "overrides": { "priorityFee": 45000, "slippage": 8 }
}

5. Strategy Profiles

StrategyProfiles.js defines three execution modes that the AI selects from based on log pattern analysis:

  • 🐢 Conservative — stable conditions, 30bps slippage, 2 retries
  • 🦅 Aggressive — volatile window, 100bps slippage, 3 retries, ×1.3 tip
  • 🎯 Sniper — perfect conditions, 10bps slippage, 1 attempt, ×1.75 tip

The AI can also override individual parameters within safe bounds — clamped to prevent runaway fees.

6. Smart Retry with Escalating Tip

Retryer.js wraps every bundle submission. On timeout, it re-submits with tip escalated by 20% per attempt (configurable), up to 3 attempts. On exhaustion it fires a critical alert and logs the failure for the AI to learn from next cycle.

7. Circuit Breaker

CircuitBreaker.js trips after 3 consecutive failures and blocks all execution for a configurable cooldown (default: 2 minutes). After cooldown it enters half-open state, sends one probe bundle, and resets if successful. This prevents burning SOL during degraded cluster conditions.

8. Lifecycle Tracking (10 Required Logs)

LifecycleLogger.js records every stage transition with ms-precision timestamps:

SUBMITTED  →  PROCESSED  →  CONFIRMED  →  FINALIZED
    0ms          +800ms       +2300ms       +4231ms

The delta between each stage lets you calculate cluster consensus health in real time. The last 10 bundles are persisted and exposed via /api/tracker.

9. Slack + Discord Alerts

AlertHook.js fires formatted alerts to both platforms for every meaningful event: circuit breaker trips, AI provider fallbacks, bundle finalization, retry exhaustion. Supports rich embeds on Discord and Block Kit on Slack.

10. Live Dashboard

A real-time web dashboard at the Vercel deployment URL shows:

  • Cluster consensus health (avg/min/max ms)
  • AI provider chain with ACTIVE / READY / NO KEY status per provider
  • Last bundle details including which AI made the decision
  • All connected services status
  • Auto-refreshes every 30 seconds

Deployment (Mobile-First, No Laptop Needed)

GidiEngine was designed and deployed entirely from a mobile phone using GitHub Mobile + Vercel + Railway.

Vercel hosts the serverless API layer (/api/health, /api/agent, /api/tracker) and the landing dashboard. Auto-deploys on every push to main.

Railway runs the persistent worker process (Worker.js) that maintains the gRPC stream and executes the bundle lifecycle. Also auto-deploys on push to main.

This hybrid architecture means:

  • The expensive always-on work (gRPC streaming) runs on Railway's persistent runtime
  • The stateless API calls (AI decisions, log reads) run on Vercel's serverless edge
  • Edits can be made from anywhere, deployed in seconds

File Structure

GidiEngine/
├── railway/           Persistent Railway worker
│   ├── Worker.js      Entry point + orchestration
│   ├── Observer.js    Dual slot monitoring
│   ├── Executor.js    Jito bundle engine
│   ├── Retryer.js     Smart retry with tip escalation
│   ├── LeaderSchedule.js  Leader-aware timing
│   ├── CircuitBreaker.js  Failure rate guard
│   ├── AlertHook.js   Slack + Discord alerts
│   └── LifecycleLogger.js  ms-precision tracker
│
├── api/               Vercel serverless functions
│   ├── Agent.js       AI decision engine
│   ├── Tracker.js     Log store + consensus API
│   └── HealthCheck.js /api/health endpoint
│
├── shared/
│   ├── AIRouter.js         Multi-provider failover
│   └── StrategyProfiles.js conservative/aggressive/sniper
│
└── public/
    └── index.html     Live dashboard

Every module is under 150 lines — intentionally kept small for mobile editing.

What Makes This Different

Most smart transaction stack submissions will implement the core requirements. GidiEngine goes further in three ways:

1. AI Redundancy — A 4-provider AI chain means the decision brain never goes down, even if Anthropic has an outage. No other submission likely has this.

2. Leader-Aware Firing — Skipping non-Jito leader slots isn't just an optimization, it's the difference between consistent wins and consistent losses. This is baked in at the architecture level, not bolted on.

3. Built from a Phone — The entire project was conceived, coded, and deployed from a mobile device. Every file is under 150 lines because that's what fits on a mobile screen. This proves the architecture is genuinely maintainable by one person with no infrastructure.