Skip to Content
EngineeringWhere we actually are

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 fillNever observed. Everything downstream of the fill is written against spec and unit tests, not live observation
A full cycle through to settlementNever completed — requires a position that survives to expiry
A live withdrawalNever sent. Verified by simulation, contract reads and tests; the on-chain path itself is untested
A live swapNever 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 cycleNever run. Verified by unit tests and one free integration run against live Base and live Derive with zero sends
The auto-wheel loopBuilt, 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
ReconciliationScheduled, in observe mode. Reports divergences without writing to the journal until the noise floor is known (Risks §3.8)
AlertingTelegram channel exists; it is off until credentials are configured, and falls back to the log
Platform feeRate is 0, and the mechanism is not wired into any stepgross → 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:

  1. 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.
  2. The public Base RPC node is not good enough (below).
  3. 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 data on 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
O3Minimum RFQ size — do market makers respond at 0.5 ETH? A valid RFQ quote has never been observed
O4API rate limits per wallet and session key, which bound scaling
O7What PM2 actually requires under our construction, in practice
O10–O12Signal 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)
O13Derive 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.