MONARKFleetNarabiUkemiBellit abstains so DeFi can act.
Documentation menu
docs · overview

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 MONARK knife: one engine as the handle, the applications as the blades, the door as the ring.AI SIDE · THE ENGINE, THE HANDLEDEFI SIDE · THE APPLICATIONS, THE BLADESMONARK Belltokenized equities, off-hourssensors that attestShōgenMokugekiNarabiMONARK engineHikae, the gate: commit, defer or abstainB_t, the budget the caller carries, returned unchangedsix frozen contracts, no confidence fieldThe ring: the doorother agents hold,over MCP and HTTPattestcalibratecascadegateMONARK FirebreakVault LPMONARK WardenDAO / agentMONARK SoftlandingLeverageMONARK VerdictBetting deskMONARK BallastRate treasuryfolded: named applications,each one cleared bythe same gatebuiltupcomingOne handle. Several blades. The same grip for an AI agent and for DeFi.
The knife, adapted from the pitch deck and redrawn from the register: an open blade is an application the register marks built; a folded, dashed one is named. The contract count is read from the frozen schemas, the tools from the served harness.

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.

Four floors and two directions: a model's answer and an onchain flow enter through the same contract and meet the same gate.INFERENCE SIDETHE SAME DOORDEFI SIDESENSORSattestTHE GATEdecidesACTSexecute on commitTHE DOORlets other agents ina model’s answer, any provider;bring your own scoresone region per task class,never a scorethe agent’s own action,taken on commit onlyan agent calls a toolover MCP or HTTPboth sides become the samePredictionHikaeCoverageVerdictGateDecisionacts read the decisionand move on commit onlyGenkanserved today by the harness:attest · calibratecascade · gateattested onchain flows, a lendingbook at a block, tokenized fillsthe same region logic and budget,the same closed list of answersexit a range, ease a position,publish a record: on commita transfer, a swap, a signature:the same door, the same answerbuiltupcomingA model’s answer and an onchain flow enter through the same door.
Four floors and two directions. The contract titles are read from the frozen schemas; the gate and the door carry their register status.

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 classcalibrationfirst served clause
btc-dir-15ma synthetic fixture, declared as suchdeclared synthetic — a plumbing fixture, not a measured predictor
cascade-liquidable-24hno calibration committed: it abstainsno cascade calibration is committed; the gate abstains (under_calib) on this class
stable-run-velocity-24ha committed calibrationa committed stable-run velocity calibration for the USDe synthetic-dollar-whitelisted-redeem population
liquidation-eligible-coveragea committed calibrationa 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:

  1. A study first: a measurement on chain data, pre-registered where it can be, its artefacts committed and hashed.
  2. A frozen contract, if the piece speaks a new shape.
  3. A served surface that consumes its output: a tool, a published file, or a piece downstream, never only a test or a demo.
  4. 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.

Read next