FortiBlox LogoFortiBlox Docs
AXIO Block Engine

Architecture

Technical architecture of the AXIO block engine — components, data flow, and deployment topology.

Architecture

AXIO runs as a set of co-located services on the same server as the Tachyon validator. This single-server deployment eliminates network hops in the critical path and achieves sub-5ms end-to-end latency.

System Overview

YOUR SERVER (32+ cores, 256GB RAM):
├── Tachyon Validator (3.0.14 fork with forti-bundle crate)
│   └── Banking stage injection: SimPool, Auction, Sequential Execution
├── AXIO Engine (Docker, Rust)
│   ├── gRPC Server (port 7440) — searcher API
│   ├── Evaluator (16 workers) — validates + simulates bundles
│   ├── Auctioneer → Relay (WebSocket)
│   ├── Internal Arb Scanner (XDEX + forti-amm)
│   ├── Encrypted Bundles (X25519 + ChaCha20)
│   ├── Multi-Relay Failover
│   ├── Searcher Reputation
│   ├── Alerting + P&L + ML/RL Control
│   └── Mempool Monitor
├── AXIO Relay (Docker, TypeScript)
│   └── Multi-validator broadcast
├── Sandwich Bot (Docker, TypeScript)
│   └── Pre-computation + slot subscription + multi-victim (4-5 tx)
├── Settlement (Docker) → Postgres + ClickHouse
├── Redis (ACL per-service)
└── Monitoring: Prometheus, Grafana, wallet-monitor

Data Flow

Bundle Lifecycle

  1. Submission — Searcher submits a bundle via gRPC (port 7440). The bundle contains 1-5 base64-encoded transactions plus a tip amount.

  2. Validation — The gRPC server validates the bundle: transaction count (max 5), total size (max 50KB), tip bounds, base64 encoding integrity, and rate limits.

  3. Evaluation — The evaluator pool (16 workers) simulates each bundle against current on-chain state using persistent TCP connections to the validator's simulation bank. Simulation must complete in < 20ms.

  4. Scoring — Each bundle receives an EV score: EV = (Tip + Extracted Value) × Success Probability. The scoring engine factors in the searcher's reputation and historical landing rate.

  5. Auction — The continuous auction runs every 400ms (one per slot). It selects the best non-conflicting bundle set that maximizes total EV. A BestSetCache stores the winning set and updates incrementally as new bundles arrive — zero recomputation at the T-0 leader slot boundary.

  6. Delivery — The relay delivers winning bundles to the validator via WebSocket. Multi-relay failover ensures delivery even if the primary relay is unhealthy.

  7. Execution — The validator's forti-bundle crate injects bundles into the banking stage as a priority lane before mempool transactions. Bundles execute sequentially with full state carryover (critical for multi-tx sandwich bundles).

  8. Settlement — The settlement service monitors on-chain confirmations via Redis pub/sub, records results to Postgres, and streams analytics to ClickHouse.

Component Details

gRPC Server

PropertyValue
Port7440
ProtocolgRPC (HTTP/2)
AuthAPI key + searcher reputation
Rate limitToken bucket (configurable per searcher)
ConcurrencyConfigurable (default: 100 streams)
EncryptionOptional X25519 + ChaCha20-Poly1305 per-session

Evaluator Pool

  • 16 worker threads, each with a persistent TCP connection to the simulation bank
  • Connection keep-alive eliminates TCP handshake overhead (was 26K handshakes/sec before fix)
  • Bundles validated before simulation: tx count, tip bounds, base64, size limits
  • Failed simulations are not retried — the bundle is scored with success probability 0

Auctioneer

  • Continuous auction with BestSetCache — incrementally updates the winning bundle set
  • Conflict detection via write-set intersection (two bundles conflict if they write to the same account)
  • Per-strategy feedback: each MEV type (sandwich, arb, liquidation) has independent tip tuning
  • Advanced tip curves: Linear, Sigmoid, Exponential, PID controller
  • Dynamic tip floor: EIP-1559-style base fee that adjusts with block space demand

Relay

  • WebSocket server (port 4002)
  • Multi-validator broadcast (delivers to N validators simultaneously)
  • HMAC authentication on connection upgrade
  • Automatic NOGROUP recovery (Redis consumer groups recreated on restart)
  • Health checking with ordered failover

Settlement

  • Monitors bundle confirmations via Redis pub/sub
  • Records to Postgres (structured data) and ClickHouse (analytics)
  • P&L accounting per strategy with hourly snapshots
  • Alerting: Slack/webhook for 7 alert types (low balance, high error rate, etc.)

Redis

  • ACL-separated users per service (engine, relay, bot, settlement, dashboard)
  • Streams for bundle flow: axio:bundles, axio:scored, axio:deliveries, axio:results
  • Pub/sub channels: axio:tip-update, axio:bundle-confirmations

On-Chain Programs

ProgramAddressPurpose
axio-stake-pool4aawPPTLmh1kEBqYm2CGS32p4kfpuBf4CBcDipF94c2GStake pool management
forti-tips7dWho2FmC68LZBirmAf68GsrEJSFjpaVTF5pYPqVDCugTip distribution (8 rotating PDAs)
forti-ammFfDk3LsXG2JqwMJdErzp8vikjmW4J23qBbnThL9h7THRAutomated market maker
aXNT MintGhQHapUR1V2Lh2rxQnpxeXVAvUMwXkm1DNbGaC6xM2WZLiquid staking token mint
Pool PDAB7VEbXbG2Z69tEadmjUaPRWFskmbsairXHygHS939eRPStake pool authority

Security

  • 2 red team rounds completed, 41 issues found, all CRITICAL/HIGH fixed
  • Redis ACL separation (least-privilege per service)
  • Postgres DDL revoked from application user
  • UFW hardening (RPC/Geyser restricted to Tailscale)
  • Encrypted bundle submission (optional, per-session keys)
  • File permissions: .env chmod 600, identity keys chmod 600
  • gRPC input validation on all endpoints (unary + streaming)