Proof Desk Field Dispatch 08
Premise Plates Explore Kernel
Four interactive panels running
Applications enabled by Fermah Kernel

The four that don't exist yet.

Fermah's own applications board shows six slots. Two hold products that are live in production. The other four are labelled only "enabled by Kernel" - application shapes that become buildable the moment a protocol can run a whole sequence on its own. This is a spec sheet for those four, written from the outside. The panels are yours to drive.

Subject
Protocol agency
Engine
Fermah Kernel
Status of slots
2 live · 4 open
Issued
July 24, 2026
Register of applicationsTwo live · four enabled by Kernel
01Flashcast Social Tweet-to-create prediction markets on anything, resolved automatically. Live1M+ markets resolved 02Fermah Froben The universal proof market. Any proof system, any chain, any VM. Live2.8M+ proofs · 99.7% 03DeFi automation Strategies that run themselves on any condition, including off-chain ones. EnabledPlate 01 → 04Programmable liquidity LP positions that adapt to volatility, macro events and cross-chain flow. EnabledPlate 02 → 05Price feed construction Any verifiable stream becomes a feed, and any feed becomes tradeable. EnabledPlate 03 → 06Cross-protocol sequencing One verified condition triggers a multi-step workflow across protocols. EnabledPlate 04 →
Section 01 / Premise

Software got agency in 2024. Protocols never did.

A model that only does inference reads a prompt and returns one answer. Powerful, but it stops there. An agent plans, calls tools, and carries a task to the end. That upgrade happened to software two years ago.

Protocols are still on the old side of that line. A smart contract reads a condition and emits a value, then nothing. Whatever happens next depends on a server someone pays for, a cron job someone forgot to monitor, or a person holding a key. Kernel is that missing continuation: observe a verifiable condition, run the workflow in a sandbox, attest the result on-chain.

AI · upgraded in 2024
From one answer to a finished task
reads prompt→one answer→no continuation
reads prompt→agent plans, calls tools→delivers result
The second row is what everyone now calls agentic. It is simply the ability to run the next step.
Protocols · still waiting
From one value to a settled sequence
condition on-chain→one value→no next action
condition on-chain→Kernel orchestrates→settles on-chain
Same upgrade, one layer down. The four plates below are what the second row unlocks.
Step the four rows forward and watch which two stop.
Fermah's own analogy: Kernel is to protocols what TCP/IP was to machines.
TCP/IP made computation composable across networks. Kernel makes action composable across protocols. Useful framing, and a high bar to clear, which is exactly why the empty slots are worth taking seriously.
Section 02 / Plates 01-04

Four specs, written from the outside.

Each plate has the same shape: what the application is, how a Kernel workflow would express it, and why it cannot be built cleanly today. The panels are interactive illustrations of the mechanism, not live products. Set the thresholds, fire the triggers, break a step and watch what stops. None of these four ship yet.

Plate 01
DeFi automationNot built yet
A strategy that runs itself on any verifiable condition, including conditions that never touch a price oracle: a funding-rate flip, a governance vote passing, an inflation print landing.
Workflow spec
TriggerFunding rate crosses your threshold on a named venue, verified from source
StepsClose the long leg, open the hedge, rebalance collateral, record the position
ExecutionSandboxed container, no keeper bot, no server to keep alive
OutputAttested on-chain: the condition, the actions, the resulting state
Why it needs Kernel: today this is a bot on someone's VPS holding a hot key. The strategy is only as reliable as that machine and as trustworthy as its operator. Neither property is verifiable by the people whose money it moves.
Strategy watcher Interactive
Funding rate, 8h+0.014%
Statusarmed
Close
long leg
Hedge
open short
Rebal
collateral
Attest
on-chain
Your parameters
0.000%
watching the rate, nothing to do yet
Plate 02
Programmable liquidityNot built yet
An LP position whose range is a function, not a setting. It widens when volatility spikes, tightens when the market calms, and shifts on events the pool itself cannot see.
Workflow spec
InputsRealized volatility, a macro calendar, cross-chain flow into the pair
RuleRange width scales with volatility; re-center when price leaves the band
StepsCompute the new range, withdraw, re-mint at the new bounds
OutputAttested on-chain: inputs used, range chosen, position after the move
Why it needs Kernel: adaptive LP management exists, but it lives off-chain in a manager's infrastructure. The depositor has to trust that the rule was followed. An attested workflow makes the rule itself checkable.
Adaptive range Interactive
Realized volatility18%
Range width±4.0%
Rebalances this run0
price band
Your parameters
18%
0.62
band adapts as volatility moves
Plate 03
Price feed constructionNot built yet
Most things people care about have no oracle, because no one would run one. Kernel builds a feed from any verifiable source, and a feed is the only thing standing between a number and a tradeable instrument.
Workflow spec
SourceAny verifiable stream: a public API, an on-chain counter, a signed dataset
StepsSample on a schedule, verify each reading, aggregate, publish the point
ResultA continuous feed that contracts can reference like any price
ThenA market or a perp opens on it, settled by the same engine that built it
Fermah's own live trace uses this exact case: a stream called creator growth rate, with the note that no oracle exists for it. Why it needs Kernel: feeds are expensive social objects. Someone must run nodes, agree on a spec, and keep it alive for years. If constructing one is a workflow instead of an institution, the long tail becomes tradeable.
Feed builder Interactive
Verified samples0
Rejected readings0
Feed statusbuilding
Your actions
sampling the stream and verifying each reading
Plate 04
Cross-protocol sequencingNot built yet
One verified condition triggers a chain of actions across protocols that were never designed to talk to each other: borrow, swap, stake, settle, as a single attested unit.
Workflow spec
TriggerOne verified condition, on-chain or off
SequenceBorrow on A, swap on B, stake on C, settle back to the user
FailureA failed step stops the sequence; nothing downstream fires
OutputOne attestation covering the whole sequence, not four separate receipts
Why it needs Kernel: today this is a script with four API calls and a human watching it. Every hand-off is a place to fail silently. Sequencing as a primitive means the whole chain either happened or did not, and the proof says which.
Sequence runner Interactive
Trigger conditionwaiting
Borrow
protocol A
→
Swap
protocol B
→
Stake
protocol C
→
Settle
attested
Break it on purpose
no failure injected - click any step to break it
one condition, four protocols, a single receipt
Section 03 / Evidence

The engine is not a promise. It is already carrying load.

Speculative applications are cheap to write about. What makes these four worth specifying is that the layer underneath them is in production today, on two very different workloads.

2.8M+proofs settled through Froben, paying customers include ZKsync Era and Abstract Chain
1M+markets resolved on Flashcast, zero human intervention
99.7%reliability under production load
0humans in the loop, by design
A closed case study: one month, one tournament
In an earlier dispatch I tracked every official World Cup market on Flashcast from first whistle to last. Final tally: 364 markets created, 363 settled on-chain, average lag from event trigger to resolution under a minute, 46,414 players, 4.38M in stakes. No committee, no dispute window, no stuck settlement across the whole run. That is the same engine the four plates above would run on. See the full board ↗
Section 04 / Method

Define. Execute. Attest.

Every plate on this page reduces to the same three moves. The interesting work is picking a condition worth watching.

01 / Define
Name the condition
Any verifiable thing: an on-chain event, a deadline, a rate crossing zero, a counter reaching a number. If it can be checked, it can trigger.
02 / Execute
Write the sequence
The steps that should follow, running in a sandboxed container rather than on a server you have to keep alive and defend.
03 / Attest
Return the proof
The result lands on-chain as a cryptographically verified artifact. Not a log entry someone could have written by hand.
Compose a workflowYour spec
01 / Define the condition
02 / Pick the steps that follow
03 / The manifest this produces
The schema below is illustrative. Fermah has not published a workflow spec for Kernel, so this is how such a manifest would reasonably look, not an official format.
Build on Kernel ↗ Read the docs

Sources and method

  1. Fermah - Protocols That Act: the applications board with two live products and four shapes enabled by Kernel, the single-shot versus agentic framing, the TCP/IP analogy, and the live counters quoted above. fermah.xyz
  2. Fermah Kernel - the Protocol Agency Engine: define, execute, attest. fermah.xyz/kernel
  3. Fermah Froben - the universal proof market, live on mainnet. fermah.xyz/froben
  4. Flashcast Social - prediction markets, live. flashcast.social
  5. World Cup settlement data collected by this desk over the tournament. settledcup.live

The four plates on this page are written independently by this desk, not published by Fermah. Fermah names the four application shapes and marks them "enabled by Kernel" on its applications board; the workflow sheets, the reasoning about why each is hard today, and the panels are mine. All four are interactive illustrations of a mechanism, not live products, and every number in them is generated in your browser rather than read from a market. Counters and customer names reflect fermah.xyz as of July 23, 2026.