Truth Contracts in Formal Verification

• Truth Contracts are formal mechanisms that convert informal contract intent into verifiable proof obligations, ensuring enforceability and auditability.
• They encompass multiple models including logical, event-structure, and blockchain-based semantic conformance for smart contracts and distributed systems.
• Research explores practical implementations such as theorem-carrying transactions, runtime certification, and evidence-gated belief revision to maintain contract integrity.

Searching arXiv for recent and foundational papers related to “truth contracts,” including contract logic, smart-contract conformance, theorem-carrying transactions, and preregistered belief revision protocols. Truth contracts are formal mechanisms that make a contract’s operative commitments auditable, enforceable, or provably realizable, rather than leaving them as informal intent. Across the literature, the term does not denote a single standardized formalism. Instead, it spans several research programs: contract models that connect agreement to provability in logic (Bartoletti et al., 2013); event-based semantics that identify duties and culpability relative to execution state (Bartoletti et al., 2013); calculi for realizability and honesty in adversarial distributed systems (Bartoletti et al., 2012); smart-contract workflows whose correctness is defined as semantic conformance to a formal policy (Wang et al., 2018); runtime-certified blockchain execution via theorem-carrying transactions (Bjørner et al., 2023, Bjørner et al., 2024); language-and-proof-stack approaches for constructing provably secure contracts (Chait-Roth et al., 2024); and protocol-level constraints on belief revision that separate social communication from admissible epistemic change (Alqithami, 16 Apr 2026). A unifying theme is that the “truth” of a contract is relocated from informal expectation to a formally checkable object: a proof obligation, a provability condition, a conformance theorem, a culpability judgment, or a validated evidence witness set.

1. Conceptual scope and main lineages

The literature exhibits at least four distinct senses in which a contract can be made “truthful.” In logical and game-theoretic contract theory, truth is tied to whether obligations can be jointly discharged and whether participants possess winning strategies. In distributed calculi with dishonest agents, truth is tied to realizability and honesty: whether an advertised contract can be upheld without permanent culpability in arbitrary contexts (Bartoletti et al., 2012). In blockchain systems, truth is often operationalized as semantic conformance to a workflow policy, proof-backed execution against invariants, or implementation-level safety under adversarial conditions (Wang et al., 2018, Bjørner et al., 2023, Bjørner et al., 2024, Chiang, 2020). In deliberative multi-agent systems, truth contracts are protocol rules that require belief changes to be licensed by preregistered evidence triggers rather than by social influence alone (Alqithami, 16 Apr 2026).

This diversity matters because several superficially similar claims are formally distinct. A contract may admit an agreement without guaranteeing that every participant will remain honest in every context. A smart contract may satisfy low-level safety checks without semantically conforming to its intended business process. A transaction may preserve specified invariants on a concrete path without establishing a global all-path theorem. A belief-revision protocol may prevent “wrong-but-sure” cascades without guaranteeing correctness of the underlying evidence layer. The literature therefore treats “truth” not as a monolithic property but as a family of formally delimited guarantees.

A plausible implication is that truth contracts are best understood as a design pattern in formal methods and protocol design: the contract’s intended semantics are externalized into a checkable artifact, and system execution is constrained by that artifact.

2. Logical and event-based foundations

A foundational line of work models contracts either as event structures with circular causality or as formulas in Propositional Contract Logic (PCL), and then proves a correspondence between the two (Bartoletti et al., 2013, Bartoletti et al., 2013). In the game-theoretic model, a contract is a pair

$C = (\mathcal{E}, \Phi)$

where $\mathcal{E}$ is a CES and $\Phi$ assigns each participant a set of payoff traces (Bartoletti et al., 2013). A CES is a triple

$(\#, \vdash, \Vdash)$

with conflict, ordinary enabling, and circular enabling. The relation $X \vdash e$ expresses ordinary obligation after $X$ has occurred, whereas $X \Vdash e$ permits $e$ to be performed “on credit,” assuming $X$ will eventually happen (Bartoletti et al., 2013).

The logical side extends intuitionistic propositional logic with contractual implication. In the Horn fragment, clauses have the forms

$\alpha \to a \qquad \text{and} \qquad \alpha \to a$

where $\mathcal{E}$0 is a conjunction of atoms (Bartoletti et al., 2013). The key bridge is that ordinary enabling maps to ordinary implication and circular enabling maps to contractual implication. For conflict-free CES and Horn PCL, the literature proves three correspondences: agreement corresponds to provability, proof traces correspond to prudent plays, and urgent atoms yield prudent or winning strategies (Bartoletti et al., 2013).

The central agreement theorem states that if $\mathcal{E}$1 and $\mathcal{E}$2 is a reachability payoff induced by a predicate $\mathcal{E}$3, then

$\mathcal{E}$4

(Bartoletti et al., 2013). A related theorem shows that for a play $\mathcal{E}$5,

$\mathcal{E}$6

and another constructs the canonical strategy

$\mathcal{E}$7

from urgent atoms (Bartoletti et al., 2013).

The event-based model sharpens these results by making duties state-dependent (Bartoletti et al., 2013). A contract is a 6-tuple

$\mathcal{E}$8

and satisfaction is given by $\mathcal{E}$9, meaning participant $\Phi$0 is satisfied if all events in $\Phi$1 have occurred (Bartoletti et al., 2013). Configurations resolve circularity by requiring that each event in an ordered set be justified either by prior events through $\Phi$2 or by the whole configuration through $\Phi$3. This makes mutual-credit configurations possible, as in

$\Phi$4

for which $\Phi$5 is a configuration (Bartoletti et al., 2013).

The same paper defines duties $\Phi$6 relative to the current state $\Phi$7, prioritizing $\Phi$8 over $\Phi$9. A participant is culpable in state $(\#, \vdash, \Vdash)$0 iff she has at least one duty there (Bartoletti et al., 2013). Its main logical theorem states that reachable events are exactly the provable atoms of the PCL translation: $(\#, \vdash, \Vdash)$1 (Bartoletti et al., 2013).

These results establish a precise formal sense in which a contract can be true: not merely syntactically well formed, but supported by a proof-theoretic structure that corresponds to executable, strategically justified interaction.

3. Realizability, honesty, and blame in dishonest systems

A separate line asks whether contractual promises remain meaningful when participants may violate them after agreement (Bartoletti et al., 2012). The key shift is from compliance of abstract contracts to realizability in adversarial distributed systems. Unilateral contracts describe one participant’s promised behavior, while bilateral contracts

$(\#, \vdash, \Vdash)$2

describe interaction between two parties (Bartoletti et al., 2012). Compliance is defined so that no reachable configuration forces either side into the failure contract $(\#, \vdash, \Vdash)$3, and every $(\#, \vdash, \Vdash)$4-free contract has a dual-like compliant partner $(\#, \vdash, \Vdash)$5 with

$(\#, \vdash, \Vdash)$6

(Bartoletti et al., 2012).

The core notion is culpability. Participant $(\#, \vdash, \Vdash)$7 is culpable in $(\#, \vdash, \Vdash)$8, written $(\#, \vdash, \Vdash)$9, iff

$X \vdash e$0

(Bartoletti et al., 2012). This makes blame explicit at each step of a computation. The paper proves an exculpation result: if $X \vdash e$1 is culpable in a bilateral contract with $X \vdash e$2-free left contract, then there exists an $X \vdash e$3-solo trace $X \vdash e$4 with $X \vdash e$5 such that

$X \vdash e$6

(Bartoletti et al., 2012).

These contract semantics are embedded in the calculus $X \vdash e$7, where participants can advertise latent contracts, fuse compliant contracts into sessions, perform actions, and query fulfillment (Bartoletti et al., 2012). Agreement formation occurs when latent contracts include a compliant pair, after which a fresh session is created carrying the bilateral contract.

The decisive notion for truth contracts in this setting is honesty. A participant realizes contract $X \vdash e$8 at session $X \vdash e$9 in system $X$0 if, across all reachable states and fair solo traces, there is some point where the participant is no longer culpable in that session (Bartoletti et al., 2012). Honesty in a system means realizing every contract in that system, and honesty simpliciter quantifies over all admissible contexts. Since dishonesty is r.e. and honesty is not recursive, the paper gives a sound sufficient criterion, canonicity, and proves: $X$1 (Bartoletti et al., 2012).

This framework makes a strong distinction between agreement and truthfulness. Agreement means compliant contracts can be fused. Truth, in the stronger sense, means a participant’s advertised contract is realizable even in dishonest environments. This suggests that any encyclopedia treatment of truth contracts must include not only satisfiability and proof correspondence, but also blame assignment and contextual realizability.

4. Truth as semantic conformance in smart contracts

In enterprise smart contracts, truth is often defined as conformance between implementation and an explicit workflow policy rather than as absence of low-level bug patterns. A representative formulation is semantic conformance for Azure Blockchain Workbench contracts (Wang et al., 2018). A Workbench application policy is a pair $X$2, where $X$3 is a set of global roles and $X$4 is a set of workflows. A workflow is a finite-state machine with access control, and semantic conformance is reduced to validity of Floyd-Hoare triples for the constructor and each function (Wang et al., 2018).

The two central obligations are initiation and consecution. For a workflow $X$5, initiation is

$X$6

and each transition $X$7 must satisfy

$X$8

(Wang et al., 2018). The verifier VeriSol instruments Solidity contracts with assertions, infers invariants $X$9, and attempts to prove

$X \Vdash e$0

(Wang et al., 2018).

The significance of this approach lies in what it counts as correctness. The contract is trustworthy when it is proven to semantically conform to its formal workflow policy, including correct initial state, correct transitions, and correct access control (Wang et al., 2018). This is close to a truth-contract interpretation in which the authoritative object is the formal business workflow, not the source code itself.

The evaluation supports the practical force of this definition. VeriSol analyzed all 11 sample applications shipped with Workbench and the PoA governance contract. It found 4 previously unknown defects in the sample contracts, including incorrect state transitions and incorrect initial states, and after fixes all 11 were fully verified (Wang et al., 2018). The broader claim is narrow but important: consensus does not make a blockchain application trustworthy if its contract does not semantically match the intended policy.

A related but distinct notion of truth appears in benchmark design for LLM-generated smart contracts. In SmartEval, the expert-written implementation paired with a natural-language requirement and formal FSM specification serves as the ground-truth contract against which generated contracts are judged (Goel et al., 10 May 2026). The composite score

$X \Vdash e$1

measures functional completeness, variable fidelity, state-machine correctness, business-logic fidelity, and code quality (Goel et al., 10 May 2026). Here, truth is not a runtime theorem but a reference implementation serving as a semantic anchor. This suggests a broader use of the term in software evaluation: the truth contract may be the human-authored implementation that is already known to realize the specification.

5. Runtime-certified and proof-carrying smart contracts

A more ambitious blockchain line makes truth contractual at execution time by requiring a formal certificate for each transaction. Theorem-Carrying-Transaction (TCT) proposes that every transaction must carry a theorem proving adherence to specified safety properties in the invoked contracts (Bjørner et al., 2023, Bjørner et al., 2024). The theorem is path-specific and hypothesis-specific. In one formulation,

$X \Vdash e$2

where $X \Vdash e$3 is the invoked function, $X \Vdash e$4 is a Boolean condition over transaction inputs and blockchain state, and $X \Vdash e$5 identifies the concrete execution path (Bjørner et al., 2023). In a later formulation,

$X \Vdash e$6

where $X \Vdash e$7 is a Keccak-256 path hash over the exact EVM code trace (Bjørner et al., 2024).

The theorem states that if the transaction invokes $X \Vdash e$8, the hypothesis holds, and execution follows the identified path, then the specified assertions or invariants are preserved (Bjørner et al., 2023, Bjørner et al., 2024). The runtime checks theorem applicability and trace identity before execution. This combines concrete execution with symbolic proof. The proof obligation is constructed by translating the observed path into a straight-line Boogie program and proving postconditions or invariants with SMT support (Bjørner et al., 2023, Bjørner et al., 2024).

For ERC20-like tokens, the motivating invariant is

$X \Vdash e$9

(Bjørner et al., 2024). In the overflow example, a theorem is valid only under a range restriction such as

$e$0

(Bjørner et al., 2023). Malicious inputs outside this hypothesis cannot reuse the theorem. In the reentrancy example, the malicious callback yields a different trace hash, so a theorem for the non-reentrant path does not apply (Bjørner et al., 2024).

The later TCT prototype reports runtime overheads of 0.20% for TrfrProxy and NoRntrcy, 0.52% for AddLqdty, 0.58% for RmvLqdty, and 0.57% for Swap, and states that the runtime overhead is negligible (Bjørner et al., 2024). It also reports about 64 bytes per transaction in the common case for theorem-related communication (Bjørner et al., 2024). These are implementation claims, but conceptually the important result is stronger: once a property is specified in a contract, it can be treated confidently as an unconditional guarantee made by the contract (Bjørner et al., 2024).

Another trust-by-construction approach is Asp, which integrates a programming language, a defensive compiler, and a proof checker (Chait-Roth et al., 2024). The source language is state-machine-based and uses mathematical abstract types such as int, nat, coin, token, address, and timer (Chait-Roth et al., 2024). Arithmetic overflow is ruled out in the source semantics; reentrancy attacks are blocked with $e$1; and the compiler inserts runtime checks for overflow, undefined operations, reentrancy, and coin conservation (Chait-Roth et al., 2024). The main compilation theorem states:

Every successful transaction of the compiled contracts corresponds to a successful cascade of the Asp contracts. (Chait-Roth et al., 2024)

This approach differs from TCT. TCT certifies actual runtime paths in an existing Ethereum-like execution model. Asp instead narrows the programming model so that common vulnerabilities are prevented by semantics and compilation, while functional correctness and higher-level security claims are discharged by deductive proofs (Chait-Roth et al., 2024). Both, however, instantiate the same idea: truth is attached to a contract through independently checkable formal evidence.

Implementation-level verification for Bitcoin contracts introduces yet another form of truth. Bitcoin Trace-Net generates an executable symbolic model from the underlying contract implementation and checks a Trustless Execution Property (Chiang, 2020). A Trace-Net model is

$e$2

and combines a Petri Net with a Dolev-Yao-like actor knowledge model (Chiang, 2020). The central safety intuition is that a safe smart contract implementation should ensure that each participant can always append a contract transaction to the blockchain in order move the contract towards secure completion (Chiang, 2020). This is a truth-contract notion at the protocol level: truthful means that the honest party always retains a safe continuation strategy, even under delays, finite-depth reorganizations, and hidden cryptographic subprotocols.

6. Epistemic truth contracts and evidence-gated belief revision

A newer usage of the term appears in deliberative multi-agent systems, where the concern is not code correctness but conformity-driven epistemic failure. Preregistered Belief Revision Contracts (PBRC) separate open communication from admissible epistemic change (Alqithami, 16 Apr 2026). A PBRC contract for agent $e$3 is

$e$4

with first-order triggers $e$5, revision operators $e$6, a priority rule $e$7, and a fallback policy $e$8 (Alqithami, 16 Apr 2026).

A non-fallback step is accepted only if it cites a preregistered trigger label and provides a nonempty witness set of externally validated evidence tokens. The certificate is

$e$9

with fallback encoded as $X$0 (Alqithami, 16 Apr 2026). Witnessing is defined by token-restricted satisfaction: $X$1 so the trigger must be checkable using only the validated evidence in $X$2 (Alqithami, 16 Apr 2026).

The main safety theorems formalize the contract’s truth-preserving role under social pressure. If fallback is non-amplifying, then in a trigger-inactive round

$X$3

(Alqithami, 16 Apr 2026). If fallback is argmax-preserving and non-amplifying, then across any interval of trigger-inactive rounds, the top hypothesis does not change and confidence does not increase; therefore, a “wrong-but-sure” cascade cannot be created by social-only interaction (Alqithami, 16 Apr 2026). Another theorem states that if the fallback preserves the argmax, then any change in top hypothesis must occur at a step accepted with a nonempty witness set $X$4 (Alqithami, 16 Apr 2026).

This is a different sense of truth contract from smart-contract verification. The contract does not guarantee that beliefs become correct. It guarantees that belief changes are attributable to validated evidence rather than to agreement, prestige, majority size, or rhetorical force. The paper is explicit that PBRC does not guarantee correctness if the evidence layer itself is compromised (Alqithami, 16 Apr 2026). The truth claim is therefore procedural and auditable, not semantic in the sense of logical truth.

7. Ground truth, vulnerabilities, and unresolved issues

Research on smart-contract analysis introduces yet another relevant notion: truth as benchmark ground truth. Because tool evaluations often rely on small or inconsistent datasets, one line of work consolidates 13 publicly available benchmark or ground-truth sets into a unified Ethereum weakness corpus (Angelo et al., 2023). The resulting unified set contains 4,859 entries total, with 4,559 entries (93.8%) containing Solidity source, and the consolidated set retains 20,498 cleaned assessments after matching, deduplication, and contradiction handling (Angelo et al., 2023). This does not define a truth contract directly, but it clarifies the empirical infrastructure required to evaluate systems that claim to establish contract truthfulness.

Another security-oriented perspective comes from state-reverting vulnerabilities. SmartState models rollback semantics as part of the attack surface and introduces assertion-related state dependency and temporal-ordered state dependency in a state-dependency graph

$X$5

with edge labels in $X$6 (Liao et al., 2024). The framework reports Precision: 87.23% and Recall: 89.13% on a manually annotated dataset containing 91 SRVs, and identifies 406 new SRVs from 47,351 real-world smart contracts (Liao et al., 2024). The relevance to truth contracts is indirect but important: even if a contract satisfies some explicit specification, reverting behavior can become an adversarial control mechanism if the specification does not capture it. This suggests that truth guarantees are only as strong as the abstraction boundary chosen by the formalism.

Several recurring misconceptions are addressed by the literature. First, truth contracts are not synonymous with ordinary smart contracts. In most formulations, they add a proof layer, a logic layer, or an auditable evidence layer beyond raw execution semantics. Second, truth contracts do not necessarily guarantee factual correctness. PCL-based agreement theorems characterize provability and prudent execution, not truth in the model-theoretic sense (Bartoletti et al., 2013, Bartoletti et al., 2013). PBRC blocks purely conformity-driven belief revision but does not guarantee correctness of the evidence substrate (Alqithami, 16 Apr 2026). TCT enforces specified invariants, but only properties that have been correctly specified become guaranteed (Bjørner et al., 2024). Third, trustless execution and honesty are distinct: a Bitcoin contract can preserve a safe path for an honest participant without proving universal contextual honesty in the sense of distributed contract calculi (Chiang, 2020, Bartoletti et al., 2012).

The main unresolved issue across these traditions is compositional scope. Logical contract models provide strong correspondences in tractable fragments, but practical systems must deal with evolving codebases, dynamic reference topology, hidden subprotocols, and incomplete specifications. Runtime certification addresses some of this by certifying actual paths rather than full programs (Bjørner et al., 2024). Event-based and realizability models address blame and adversarial behavior, but they abstract away many engineering contingencies (Bartoletti et al., 2013, Bartoletti et al., 2012). This suggests that future truth-contract systems may need hybrid architectures combining specification conformance, path-level certification, and audit logs over evidence-bearing interaction.

In the broadest synthesis, truth contracts are formal commitments whose meaning is stabilized by a verification regime. Depending on the domain, that regime may be provability in Horn PCL, duty and culpability in event structures, honesty in dishonest systems, semantic conformance to a workflow, theorem-carrying execution, proof-carrying compilation, implementation-level safe continuation, or evidence-gated belief revision (Bartoletti et al., 2013, Bartoletti et al., 2013, Bartoletti et al., 2012, Wang et al., 2018, Bjørner et al., 2023, Bjørner et al., 2024, Chait-Roth et al., 2024, Chiang, 2020, Alqithami, 16 Apr 2026). What unifies them is the rejection of unenforced promises: the contract is made true, in the relevant formal sense, only when the surrounding system can check, synthesize, or audit the conditions under which its commitments may be relied upon.