Where we actually are
Internal. This is Part 4 of docs/investor-overview.md, kept out of the public build: a
component-by-component readiness matrix plus a register of open questions is a briefing for a
competitor on an indexable page. The public site says plainly that the product is pre-launch — that
much must never be hidden — but the breakdown lives here.
The honest status. This section exists because a document that blurs “built” and “proven in production” is worth nothing in diligence.
4.1 What has run live on mainnet
| Status | |
|---|---|
| Options showcase against live mainnet data | ✅ Running. 104 live tickers validated, zero schema deviations |
| PM2 subaccount creation | ✅ Live |
| Order acceptance by the exchange, response shapes | ✅ Measured live 2026-08-24 |
Full funding → placing path on the live market | ⚠️ Passed 2026-08-25: deposit executed, maker order posted — but the run relied on a stub that has since been removed, so it is no longer reproducible as it stands |
| Deposit detection and sweep | ⚠️ Exercised end to end on the live system against simulated bridge logs. That a real bridge Transfer is recognised, and that the sweep itself goes through, is verified by a real deposit and nothing else — and no real deposit has been made |
| Bridge routes, contract shapes, margin behaviour | ✅ Read and simulated on mainnet across all 11 routes |
4.2 What is built but has never run with real money
Since the previous version of this document the auto-wheel engine has been implemented and the conversion cycle now starts itself after an in-the-money settlement. Neither has been switched on.
| Status | |
|---|---|
| A live fill | Never observed. Everything downstream of the fill is written against spec and unit tests, not live observation |
| A full cycle through to settlement | Never completed — requires a position that survives to expiry |
| A live withdrawal | Never sent. Verified by simulation, contract reads and tests; the on-chain path itself is untested |
| A live swap | Never sent. No swap wallet exists — SWAP_WALLET_PRIVATE_KEY is a required variable and the example file carries a publicly known placeholder, so an accidental launch on the example value would send funds to an address anyone can drain. There is no ETH for gas and no WETH on Base either |
| The ITM conversion cycle | Never run. Verified by unit tests and one free integration run against live Base and live Derive with zero sends |
| The auto-wheel loop | Built, disabled. Runs behind a switch that defaults to off, because its own specification requires that a manual cycle and a conversion cycle each complete live at least once first — and neither has |
| Reconciliation | Scheduled, in observe mode. Reports divergences without writing to the journal until the noise floor is known (Risks §3.8) |
| Alerting | Telegram channel exists; it is off until credentials are configured, and falls back to the log |
| Platform fee | Rate is 0, and the mechanism is not wired into any step — gross → fee → net exists as a path, not as a running calculation |
Three blockers stand between the code and the first live conversion, and only one of them is code:
- No kill switch on the conversion cycle. It is registered unconditionally, so on deploy it would run for any in-the-money expiry of any user. There is nothing today to limit the first run to a single position.
- The public Base RPC node is not good enough (below).
- The swap wallet does not exist — no address, no key, no ETH on Base.
The first launch is explicitly a measurement exercise, not a product launch — on our own money, on mainnet, with no external users, to produce numbers (b) and (c) from Economics §2.5.
4.3 What comes next
Immediately ahead — prerequisites for the first live run
- A dedicated Base RPC provider. A public node returned
missing revert dataon 8 of 8 rapid sequential calls (0 of 8 with a 2-second pause). The conversion tolerates this — it distinguishes a read failure from a terminal one and pauses naturally — but the slippage ladder makes up to six calls back to back with a deadline in seconds and cannot be spaced out. Hard prerequisite. - A kill switch on the conversion cycle, so the first run can be limited to one position.
- A swap wallet — a fresh address, deliberately not derived from the master seed, so that a seed compromise does not hand over both.
- A real alert channel. Today nobody learns of an approaching liquidation unless they are watching the log.
Then
- Switching reconciliation from observing to enforcing, once the noise floor is measured.
- The first live conversion, then the first live full cycle, then turning the wheel on.
- BTC alongside ETH. The data model is already keyed on (user × asset), so this is configuration rather than redesign.
- Choosing the fee form against measured (b) and (c), and wiring it in.
Under consideration, explicitly not decided
- Perpetual-based side switching. The original architecture switches sides synthetically with a perpetual instead of physically swapping. We build the physical swap because it is simpler to reason about and because a perp cannot be treated as unliquidatable. But the alternative has a measured price attached: over 30 days of funding history the rate sat pinned near its floor with no negative readings, meaning a short ETH perp paid its holder roughly 11% annualised — about $8.90 a month on a 0.5 ETH notional at the ETH price of the time (~$1,890); the dollar figure scales with the price, the percentage does not. Not adopting this costs that money, and the decision should be revisited once the first measurements exist rather than settled by preference.
- An external audit of our own layer, which should precede holding third-party funds.
4.4 Open questions, listed rather than hidden
| # | Question |
|---|---|
| O3 | Minimum RFQ size — do market makers respond at 0.5 ETH? A valid RFQ quote has never been observed |
| O4 | API rate limits per wallet and session key, which bound scaling |
| O7 | What PM2 actually requires under our construction, in practice |
| Signal lifetime — closed by decision 2026-09-08: no expiry, because activity is defined by the matcher marking a strike rather than by the age of the webhook (Risks §3.11) | |
| O13 | Derive account owner address during interface onboarding |
| — | How often conversions actually occur. The swap wallet’s gas floor rests on an estimate, not a measurement |
| — | Whether the wheel should resume after stopping. Today a stop is permanent: no code path clears it |
| — | A lower bound on days-to-expiry. One exists in practice — the showcase only admits expiries at least 3 calendar days out, which also keeps four-digit annualised figures off the board — but it was chosen as an expiry-selection rule, not as a deliberate dte floor, and nobody has confirmed it is the right one |
Engineering detail behind each row lives in this section: the money paths under Architecture, what is declared but unwired under Traps, and the per-area “verified live / not verified” tables at the foot of Deposit, Withdrawal, Positions and Conversion.