02

Apps & workflows

Built with Fermah

Apps, agents and automations built on Kernel by anyone outside the core team. The engine leaves the slot open — “if it can be measured, triggered or sequenced, Kernel can run it” — and this page tracks what fills it.

Add your project Open board
—ENTRIES
1OPEN SLOT
0PLACEHOLDERS

THE PROJECT REGISTRY STAYS EMPTY UNTIL SOMETHING REAL SHIPS

Submit

Add your project.

Anything that works on Fermah's architecture — a workflow on Kernel, a service pulling proofs from Froben, a market on Flashcast, a tool, a model, a dashboard. Every submission is reviewed by hand before it appears; nothing goes live automatically.

Submitting opens a pre-filled GitHub issue — that is the moderation queue. No account? Use email. Either way a human reads it before anything is published.

Starting points

What could you build?

Development ideas grounded in Fermah's October posts. These are not shipped products or confirmed production integrations.

BUILD SCENARIO

An agent pays for an API.

Keep an API-payment action stable while its execution route evolves.

  1. API payment intent
  2. Payment requirements
  3. Policy and routing
  4. Settlement and API result

x402 is the payment protocol; Fermah Pay now documents a Stellar batch-settlement binding on testnet. This build scenario is still an idea, and the community reference model below does not inherit that deployment status.

Reference: proofmarket-x402 ↗Community reference model; signing and settlement are modelled.

Discuss on Board ↓Oct 16, 2026 post ↗

BUILD SCENARIO

A market with more than one condition.

Resolve whether event A happened before event B crossed a defined threshold.

  1. Define events and sources
  2. Collect timestamped evidence
  3. Evaluate order and threshold
  4. Produce a defined outcome

A build scenario, not a listed market. It needs explicit deadlines, timestamp rules and missing-data handling before it can resolve safely.

Discuss on Board ↓Oct 13, 2026 post ↗

BUILD SCENARIO

An output becomes the next input.

Compose two protocol actions without tying the caller to one executor endpoint.

  1. Identify the program
  2. Prepare execution inputs
  3. Return a verified result
  4. Consume it in the next action

An architectural scenario, not a production integration. Define result validation, permissions and failure behavior for each handoff.

Discuss on Board ↓Oct 17, 2026 post ↗

Fermafia Board

Ideas become builds.

A structured board for ideas, work in progress, help and research around Fermah. No timeline, no empty hype — leave one useful record for the people building next.

Leave a record ↓
IDEAS—
BUILD—
HELP—
RESEARCH—

Post to the board

Leave a useful trace.

One clear idea, question or research note per entry. Posts are public and short; use Add your project above for a shipped project.