ORACLE // ARCHITECTURE

The Flow of Telemetry

Mempool Oracle is intentionally decoupled to ensure institutional security. The execution engine is air-gapped from the public storefront, utilizing a strict, one-way pipeline from the P2P layer to your trading client.

  [ BITCOIN P2P NETWORK ]
             │
             │ (Raw 'inv' Firehose)
             ▼
  [ AWS BARE-METAL C-ENGINE ]
  ├─ O(1) RAM Hashmaps
  ├─ CPFP / RBF Resolution
  └─ Microburst Math Engine
             │
             │ (Internal Socket)
             ▼
  [ PYTHON API GATEWAY ]
  ├─ Single Port Access
  ├─ API Key Validation
  └─ Rate Limiting
             │
             │ (HTTPS SSE Stream)
             ▼
  [ CLIENT ALGORITHM ]

1. Bypassing RPC Bottlenecks

Standard node RPCs (like Bitcoin Core's getrawmempool) are bloated, heavily indexed, and completely unsuitable for High-Frequency Trading (HFT). Waiting for a standard node to index a transaction to a local database adds critical milliseconds of latency.

Mempool Oracle bypasses the RPC entirely. We deploy a custom C-Engine that initiates concurrent TCP sockets, masquerading as standard Bitcoin nodes. We execute raw version/verack handshakes and subscribe directly to the P2P inv firehose, catching transaction bytes before they are validated.

2. In-Memory Topology Resolution

Analyzing a single txid is useless without understanding its parent topology, especially during institutional UTXO consolidation or Child-Pays-For-Parent (CPFP) fee bumping.

Our engine utilizes a custom FNV-1a hashing algorithm to maintain an O(1) RAM-based Hashmap of active UTXOs. When a child transaction hits the mesh, we perform a "Ghost Interrogation"—instantly mapping the child's raw bytes back to the parent vout to calculate the true, aggregate fee density (Sats/vB) of the entire cluster in microseconds.

3. Stateless SSE Delivery

We do not use WebSockets. WebSockets require bi-directional "ping-pong" frames to keep the connection alive, resulting in TCP overhead.

We deliver telemetry via Server-Sent Events (SSE). It is a unidirectional firehose beamed securely over HTTPS. Your client maintains a passive listening socket, meaning zero packets are wasted transmitting data back to our server, shaving crucial latency off the execution window.