One engine, two sides.
MONARK is a coverage-controlled decision gate, the pieces that read and act around it, and the on-chain applications it powers. The gate answers commit, defer or abstain against a budget the caller carries, and never a probability of being right. These pages explain each part with a schema, show what is served today, read from the served files, and say how to check it yourself.
One engine, two sides
Think of a pocket knife. The handle is the engine, the AI side: the gate and its budget, the sensors that attest to what happened on chain, the six frozen contracts they speak, and the harness through which other agents reach it. The blades are the DeFi side: the on-chain applications the engine powers, each grown from a study of on-chain data before it is served. MONARK Bell is built; every other application is upcoming, each cleared by the shared gate.
The ring is how other agents hold the knife: one public endpoint over MCP, and a plain HTTP mirror, with no account, e-mail or wallet. The integration page shows calls recorded over the transport, request and answer.
The floors
The engine has four floors. Sensors attest: they carry bytes, a hash and named residual hypotheses, never a truth claim. The gate decides: it turns a reading into a region and the region into one word. Acts execute, and only on commit. The door lets other agents in. A language model’s answer and an onchain flow take different roads to the same contract, Prediction, and meet the same gate.
What you will see if you call it today
The served gate knows the task classes below, each with the state of its calibration and the first clause it serves, as read from the served harness at 2026-09-25T03:26:05.861Z. A population outside a committed class gets an abstention with the reason under_calib: that is the design, not an outage.
| task class | calibration | first served clause |
|---|---|---|
| btc-dir-15m | a synthetic fixture, declared as such | declared synthetic — a plumbing fixture, not a measured predictor |
| cascade-liquidable-24h | no calibration committed: it abstains | no cascade calibration is committed; the gate abstains (under_calib) on this class |
| stable-run-velocity-24h | a committed calibration | a committed stable-run velocity calibration for the USDe synthetic-dollar-whitelisted-redeem population |
| liquidation-eligible-coverage | a committed calibration | a conformal upper bound on the liquidable amount for the calibrated class; the lower edge is 0 by construction, not a calibrated bound; abstains (under_calib) outside it |
What the labels mean
Every piece and every application carries one of two labels, read from the fleet register, never typed on a page. Four of the eleven pieces of the engine are marked built and seven are marked upcoming. A label moves only when a piece meets all of these:
- A study first: a measurement on chain data, pre-registered where it can be, its artefacts committed and hashed.
- A frozen contract, if the piece speaks a new shape.
- A served surface that consumes its output: a tool, a published file, or a piece downstream, never only a test or a demo.
- An end-to-end integration test that replays the composition, and a deployment check where a host is served.
The pieces page draws every piece in the style of its label, and each piece page says what is served for it today.