Sophie (@Chidimm06)

And yeah @fermah_xyz started with a problem that sits deep inside the ZK stack. Zero knowledge applications can prove that a computation was done correctly, but producing those proofs at scale takes serious infrastructure: specialised hardware, several proving systems, workload scheduling, and reliability and cost controls. A team building a ZK rollup, zkVM, bridge or coprocessor cannot simply ask for "a proof" and move on. Fermah's first answer was a universal proof generation layer. Provers with GPUs and other hardware supply capacity, applications that need proofs create the demand, and Fermah matches the two. That marketplace is now called Froben. The problem behind the proof Running this in production exposed something bigger. A proof is one step in a longer sequence. Something has to trigger the work, the work has to run, the result has to be verified, and then the result usually has to start the next action. Fermah's argument is that blockchains are good at recording state and weak at starting what happens next. Take a lending position that crosses its liquidation threshold. The chain records the fact, but nothing forces the liquidation. A keeper, bot or backend still has to notice the condition, build the transaction and submit it. Consensus settles what happened, and a human run service still decides what happens after. Fermah calls the missing piece protocol agency: a protocol's ability to act on a verifiable condition without depending on an outside operator. What Kernel does Kernel is Fermah's Protocol Agency Engine, and its pitch is short: Define. Execute. Attest. A developer defines a workflow, Kernel runs it, and the result is published onchain with a cryptographic proof. Three design choices matter here: -Typed nodes. Workflows are built from a library of verified building blocks such as HTTP calls, onchain reads, price feeds and math functions. The type system validates how they connect before anything runs. -Sandboxed execution. Workflows run in an isolated environment built for untrusted code, and the same inputs always produce the same output. - AI where it helps, code where it counts. Fermah says AI agents can compose workflows, but deterministic code executes them, with no LLM in the execution path. Kernel can work as an oracle too. A smart contract requests a workflow, Kernel runs it, and the contract receives the result with a proof that the workflow ran exactly as written. Froben and Flashcast Fermah did not walk away from ZK. Froben still runs, now on top of Kernel, and its paying customers include ZKsync Era and Abstract. In Froben, a workflow defines the proving pipeline and Kernel schedules the work across the prover fleet. Flashcast Social shows a different use of the same engine. A user posts a question, and within seconds it becomes a live prediction market. Kernel then runs the resolution workflow and settles the market automatically when the event happens, with no committee and no dispute window. Proof generation and market resolution have little in common on the surface. What they share is a condition that has to produce an action, and that is the workload Kernel is built around. Fermah also lists data aggregation, pricing oracles and cross chain coordination as things Kernel can run. Where agents fit Fermah's latest thinking extends this to autonomous software agents. An agent working onchain needs to find available actions, check whether it is allowed to run them, pay, execute, and use the output as the input to its next step. Fermah describes this as action manifests, which make actions machine readable across discovery, eligibility, execution, payment and output. The shift in one line The old question was how to generate ZK proofs efficiently at scale. The new one is how a protocol can turn a verifiable condition into a complete, executable sequence. Proving is still part of the system, but it is now one workload among several that Kernel coordinates.