Key takeaways
- The platform is in production. Chromatic decodes every live proposal on the Futarchy program directly from the chain, replays every closed window trade by trade, and keeps the result as a versioned, citable record.
- The record is a formal ontology, not a dashboard. Ontology release 2.1.0 defines 68 core classes and 24 receipted verbs, so every finding can be cited by a stable address and checked against the version that produced it.
- Reviews are independent by design. Six bounded reviews are filed against each window while it can still be acted on. They are never combined into a single score, and a reading without evidence is withheld rather than reported as low risk.
- People and agents read the same record. The Desk serves people; a public API with 23 documented paths and an MCP endpoint with 22 tools serve machines.
- The next stage is commercial. No outside organization has yet run a decision through the record. Verifying execution and accepting a customer-filed review are the next components to ship.
Architecture
The platform has four layers. Sources are decoded and replayed from the chain, the record holds them as versioned objects and verbs, the reviews are filed against the record, and the surfaces serve it to people and agents. The counts in the figure are read from the platform's registries each time the site is published, so they cannot drift from the code.
Data sources
Every live proposal on the Futarchy program is decoded directly from the program accounts, so prices, thresholds and time-weighted averages come from the source rather than from a summary of it. Closed windows are replayed from the chain, trade by trade. The observation record holds 30 registered series across eight coverage lanes, each recorded with its provenance method and the depth of history it has actually accumulated. Treasuries are cited from their sources, and a figure that cannot be sourced is left blank rather than filled from a weaker reading.
Where a reading cannot be made, it is withheld, and the withholding carries its reason. This rule keeps every aggregate honest: an input that stops without explanation would silently distort the totals built on it. The same discipline refuses, at publication, any derivation the record has already ruled out.
The record
The record is a versioned ontology. Release 2.1.0, the latest of 19, holds 68 core classes, each with a stable address, so a finding, a window, a market state or an outcome can be cited and later checked against the version that produced it. Every published finding carries its contract version, the review roster it was filed under, and the cutoff of the sources it used.
The actions that change the record are registered as well. The action registry, release 1.3.0, defines 24 receipted verbs, describing what a person, an automated job or an agent may do to the record and what each leaves behind. Automated jobs that touch a decision write a receipt, never a decision. The one verb open to outside parties is the filing, which an organization submits under its own scoped key.
The warehouse beneath the record is bitemporal. It keeps both what was known and when it was known, so any reading can be reconstructed as of any date, and every publication is timestamped.
Review process
Six bounded reviews (Attack, Evidence, Playbooks, Claims, Market, Learning) are filed against a window while it can still be acted on, under roster release 1.3.0. They are never combined into a single score. Each states what it can and cannot see, and where evidence is missing, the reading is withheld rather than defaulting to low risk. The Attack review draws on a versioned library of 11 attack vectors, of which four are monitored live. The review contracts, the vector library and the published cases are on the Methodology page.
Distribution: people and agents
People read the record on the Desk, which ranks open windows by stage and shows each tracked organization with its cited treasury, every proposal, and a dated log of events. Machines read the same record. The public API documents 23 paths in a single OpenAPI document. The MCP endpoint serves 22 tools, 21 of which require no key, together with five registry documents as resources, so an agent participating in a market reads the same evidence as a person. One tool, which returns a single review's findings for a window, is metered. Metering is not yet switched on. Once it is, each caller receives ten free requests a day, after which each request costs $0.02 in USDC, payable on Base or Solana. The full inventory is on the agent surface.
Current usage
Our read of the program excludes eight test organizations that never drew five wallets to a window. On that basis, 19 organizations have run a market, 12 of them more than once, across 53 proposals. Of the 37 closed windows with enough prices to model, 32 passed. Because the verdict forms inside the window, the record is kept continuously rather than as a snapshot; the Thesis shows how agreement with the final decision builds over the window.
The measure we manage the business to is the number of decisions made by outside organizations with a Chromatic record attached before the window closes. It is currently zero. The infrastructure is in place; acquiring the first customers is the work ahead.
Roadmap: what is not yet built
- Execution check. Approval is not proof of execution. Verifying what the treasury did against what passed is the next component of the record.
- A customer-filed review. The pre-window review exists in the ontology and as a working scaffold, but no organization has yet filed one.
- Metering in operation. The payment rails are built and charge nothing until they are switched on, which requires only a receiving address.
- Coverage beyond one venue. The record decodes the Futarchy program today. Solana's governance votes and a venue outside Solana follow the first paid window.
The revenue model, and the controls that keep the record independent of anyone who trades on it, are set out in Capital.