ChadOnChain Docs
This demo app is the UI companion to our real arbitrage engine. We built it during the hackathon because external APIs and stable parsing signals were limited, and we still needed to validate end-to-end arbitrage behavior fast.
How the real engine works
- Ingest from multiple market sources: Python adapters fetch raw payloads from different APIs with inconsistent shapes.
- Parse and normalize with LLM assistance: local Ollama parsing maps noisy text, rules, and metadata into one canonical schema.
- Persist canonical snapshots: normalized data is written into JSON snapshots that the matcher can load deterministically.
- Run low-latency C++ matching: the engine scans for cross-platform overlaps, computes spreads, and scores opportunities in memory.
- Emit executable opportunities: results are exported to
arbs.jsonfor dry run evaluation or controlled execution. - Optional on-chain execution: execution tooling can route opportunities through contracts when explicit live mode is enabled.
What this demo validates
- Two similar markets can diverge in price and create measurable spread.
- An arbitrage loop can hedge exposure by buying YES on one market and NO on the other.
- Lifecycle states (active, resolved, claimable) can be observed clearly in one UI.
- Traders and judges can inspect behavior without waiting on full third-party API reliability.
Why we use only this smart contract set
- Single-contract scope: the demo uses only
BinaryPredictionAMM.solso all core actions (create market, buy/sell, resolve, claim) are transparent in one place. - Lower integration risk: fewer contract dependencies means fewer failure points during hackathon deployment and wallet interaction testing.
- Faster auditability: judges and contributors can verify pricing and settlement rules without tracing cross-contract call graphs.
- MVP fit: advanced modules (oracle adapters, upgrade proxies, LP share tokens) are intentionally excluded because they are not required to validate arbitrage behavior in this demo.
- Planned extensibility: once core behavior is stable, additional contracts can be added behind clear interfaces instead of shipping unnecessary complexity now.
Engine and repo references
- Root architecture and setup:
README.md - Ingestion and parser flow:
Ingestion/ - Canonical schema:
Data/schemas.py - Matching core:
Engine/src/ - Execution path:
Execution/run_arb.py