MONARKFleetNarabiUkemiBellit abstains so DeFi can act.
Back to MONARK
MONARK Building

What is being built, now and next.

MONARK is one engine and the on-chain applications it powers. The labels say what exists today and what is only named. This page says what is under way now, what is in preparation next, and the direction beyond it: intentions with the date they were written down, never a promised date.

The trajectory of MONARK Building: what is under way now, what is in preparation next, and the direction beyond.Nowunder way, read from the served filesMONARK Bell serves its signed,hash-chained record: line 2,published 2026-09-24T08:41:21.864Z,for TSLAx, AAPLx, SPYx.Ukemi: a calibration of the classliquidation-eligible-coverage iscommitted and served through thegate.Narabi publishes one window a day:the committed capture holds 7windows and the tracker has stepped6 times.The documentation, written from theregister and the served files, andextended as each piece is served.Nextintentions stated 2026-09-24Anchor each published line of theBell timeline with OpenTimestamps,so anyone can show it existed beforea Bitcoin block.Commit the Ukemi strata that meetthe floor to the served class, as aseparate, recorded step.Publish the Bell collector's replaycode, so a record can be recomputedoffline from the same inputs.A gate class for the off-hours gapof Bell's record, calibrated perregime.A live demonstration on this site:two agents on the served class, oneacting on raw model calls, onethrough the gate, both logsrecomputable.Longer termdirection, unscheduledMore served task classes and moredistribution before more pieces.The named pieces, in the order ofdemand evidence, not of technicalelegance.The applications on the engine:MONARK Firebreak, MONARK Warden,MONARK Softlanding, MONARK Verdictand MONARK Ballast.Venues and oracles that consume averifiable record instead of a barenumber.Agents that keep the engine adapted:recalibrate, onboard protocols,track liquidation mechanics, watchdata sources.Solid: under way today, read from the register and the served files. Dashed: intentions and direction, with no promised date.

Now

  • MONARK Bell serves its signed, hash-chained record: line 2, published 2026-09-24T08:41:21.864Z, for TSLAx, AAPLx, SPYx.
  • Ukemi: a calibration of the class liquidation-eligible-coverage is committed and served through the gate.
  • Narabi publishes one window a day: the committed capture holds 7 windows and the tracker has stepped 6 times.
  • The documentation, written from the register and the served files, and extended as each piece is served.

Next

Intentions stated 2026-09-24. None carries a date; none is a promise.

  • Anchor each published line of the Bell timeline with OpenTimestamps, so anyone can show it existed before a Bitcoin block.
  • Commit the Ukemi strata that meet the floor to the served class, as a separate, recorded step.
  • Publish the Bell collector's replay code, so a record can be recomputed offline from the same inputs.
  • A gate class for the off-hours gap of Bell's record, calibrated per regime.
  • A live demonstration on this site: two agents on the served class, one acting on raw model calls, one through the gate, both logs recomputable.

Longer term

Direction, unscheduled.

  • More served task classes and more distribution before more pieces.
  • The named pieces, in the order of demand evidence, not of technical elegance.
  • The applications on the engine: MONARK Firebreak, MONARK Warden, MONARK Softlanding, MONARK Verdict and MONARK Ballast.
  • Venues and oracles that consume a verifiable record instead of a bare number.
  • Agents that keep the engine adapted: recalibrate, onboard protocols, track liquidation mechanics, watch data sources.

Four layers, at four maturities.

Layer one
Backbone: the gate
Hikae (coverage control) and the MONARK token budget; it turns a sensor reading into commit, defer, or abstain.
six frozen contracts (AttestedBook upcoming until served) · Hikae + Ukemi engines · CI
Built
Layer two
The smart pieces
Sensors that attest, the gate that authorizes, and acts that execute: one token across all of them.
Shōgen, Hikae, Ukemi and Narabi built · seven named

What is built and served is the attest tool: one committed witness, its bytes, its hash and its named residual hypotheses. The full Shōgen sensor, which produces continuous testimonies across sources, is under test and is not served yet.

Four built, seven on the roadmap
Layer three
Harness: reachable by other agents
The same engine made reachable by other agents over HTTP or MCP.
contracts frozen · public MCP endpoint and its four tools (attest, calibrate, cascade and gate) · listed in the MCP Registry
Built
Layer four
An engine that improves itself
Agents that rate, improve, and sell one another’s applications.
no date
Direction, unscheduled
Phase zero · closed
Contract freeze: the first schemas, closed keys, forbidden-key guard, vocabulary gate.
Phase one · closed
Hikae and Ukemi engines complete; interface frozen.
Phase two · in progress
Integration: the attested-price envelope on the served gate, its residual carried into the verdict, and the token budget B_t carried by the caller and echoed by the gate.

Built

Four agents are built and served piece by piece, composed on the gate path. Each says how it is served, and each has its panel on the fleet page. The documentation explains each one.

  • Shōgen

    built

    Attested perception — an attested price testimony.

    served through the MCP gate: its attested testimony's residual is carried into the verdict, replayed by an integration test

    Open its panel on the fleet page

  • Hikae

    built

    Coverage-controlled inference — the gate itself.

    the served gate itself: each reading is conformed into a coverage region then decided, replayed on the real wire, on the bring-your-own loop, and on the stable-run class by integration tests; its demonstration class runs on a committed synthetic calibration, a plumbing fixture, not a measured predictor

    Open its panel on the fleet page

  • Ukemi

    built

    Liquidation coverage, gated.

    feeds the served gate through the cascade tool, a transitional tool, to be replaced; it abstains by construction, and the gate serves an upper bound on the liquidable amount for the committed stratum of its liquidation class, calibrated on one recorded episode, while the other strata abstain; both legs replayed by integration tests

    Open its panel on the fleet pagepage →calibration course →

  • Narabi

    built

    Narabi senses redemption-run velocity from the attested onchain flow; its adaptive quantile tracker publishes a replayable daily timeline.

    a daily published timeline parsed by the site from the published files (its committed capture keeps each line's endpoint count only), and its attested flow carried into the served gate, both replayed by integration tests

    Open its panel on the fleet pagesee the published timeline →

Named, on the way

Named, not built. Each will attest, gate, or act on the same backbone.

  • Mokugeki

    upcoming

    Mokugeki attests the facts it extracts from a document or an event, without adding sentiment or interpretation.

  • Kaihi

    upcoming

    Kaihi exits a liquidity range — minting or burning it — ahead of toxic order flow.

  • Kessai

    upcoming

    Kessai routes a swap to a venue and issues a settlement receipt for the execution.

  • Kamae

    upcoming

    Kamae quotes both sides of a market from inventory, and stays silent when told to abstain.

  • Kyokusen

    upcoming

    Kyokusen fits a yield curve across maturities and gates rollovers and looped positions against it.

  • Koyomi

    upcoming

    Koyomi flattens leveraged exposure ahead of a recurring weekend trading-window closure.

  • Genkan

    upcoming

    Genkan is the point every transfer, swap, or signature passes through first, returning a commit, defer, or abstain decision along with the remaining budget.