# K Framework and Formal Verification *Note: This page explains what K Framework and formal verification add to Fast and to agentic payments. If you are building with the SDK, you do NOT need to understand any of this to send or receive payments. This page is about why this matters under the hood.* [K framework](https://kframework.org/) is the technology used to describe and verify how a system is supposed to behave — precisely enough that the specification itself can be executed and checked by a machine. In practice, this gives payment infrastructure an independent way to validate that critical execution logic is correct, not just that a network accepted the result. ### Why This Matters A blockchain can prove that: * a transaction was signed * a transaction was included * a state transition was finalized * the network accepted the result according to its current implementation Those are useful guarantees. But they answer only one question: *Did the system accept this result?* In many cases, that is not enough. The more important question is: *Was the system actually correct to accept it?* This is where K framework and formal verification adds value. It helps verify the rules and the implementation behind the result — not just the fact that the result was finalized. ### What K Framework Does K framework lets engineers write an executable specification of a system such as: * a virtual machine * a smart contract language * a bridge or relayer execution model * a protocol's state transition rules An executable specification is more than documentation. It is a precise model of how the system should behave, including edge cases. This matters because most systems are otherwise defined by a mix of code, prose specifications, tests, and implicit assumptions. K turns those rules into something machine-checkable. That makes it possible to compare a real implementation against a rigorous reference model. Compared to blockchain and consensus verification, K and formal verification adds additional values as below: | Blockchain verification tells you... | K and formal verification tell you... | | ------------------------------------ | ------------------------------------------------ | | This transaction was accepted | The implementation should have accepted it | | This block finalized | The execution rules were applied correctly | | This contract returned a result | This contract matches the intended specification | Consensus is very good at making many machines agree. It is not good at telling you whether they are all agreeing on the wrong thing. If every validator or execution node runs the same buggy logic, the network can still finalize the wrong result perfectly consistently. K and formal verification helps catch exactly that class of problem, including but not limited to: * implementation/spec mismatches * incorrect handling of edge cases * bugs introduced during protocol upgrades * incorrect gas or fee accounting * differences between a custom VM and the standard it claims to follow * relayer or bridge logic that depends on ambiguous behavior ### How This Matters More In Agentic Payments Agentic payments are different from ordinary user-initiated payments. In a normal payment flow, a human decides to send money, approves the transaction, and the system settles it. In an agentic payment flow, money often moves automatically because another machine claims that something happened: * a job completed * a service delivered a result * an API request consumed billable compute * a bridge observed an event on another network * a contract reached a state that should unlock payment So the question is often not just: Did a payment settle? It is: Was the thing that triggered the payment actually correct? That is where formal verification becomes more valuable. It adds assurance not just to the payment itself, but to the software execution and state transition that caused the payment to happen. ### Summary K framework and formal verification give Fast an additional layer of trust that ordinary blockchain verification does not provide. They make it possible to check: * whether implementations match intended semantics * whether upgrades preserve correctness * whether relayed or bridged execution results can be trusted * whether automated payment conditions rest on sound execution logic For agentic payments, that matters because money increasingly moves in response to software behavior, not human approval. The stronger the automation, the more important it becomes to verify not just that a result was finalized, but that it was correct. **Further Reading** * [FastSet Protocol](/advanced/fastset-protocol.md) — how the underlying Fast settlement protocol works * [AllSet Layer](/advanced/allset-layer.md) — how Fast connects to external networks * [K framework](https://kframework.org/) — official K Framework site --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fast.xyz/advanced/k-framework-and-formal-verification.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.