Leakage Contracts in Security

• Leakage contracts are formal abstractions that define what information systems may reveal, particularly at the ISA level for microarchitectural side channels.
• They provide a framework for synthesis, verification, and testing to ensure implementations leak only as permitted while balancing soundness and precision.
• In blockchain and mechanism design, leakage contracts help mitigate sensitive exposure, secure smart contracts, and achieve leakage-resilient equilibria.

Searching arXiv for the cited papers to ground the article in current literature. arXiv search query: "Leakage contracts LeaVe LeaSyn PartitionGPT rug pull leakage-aware" Leakage contracts are security abstractions that specify, constrain, or operationalize what information a system may reveal while remaining acceptable for a given semantics, attacker model, or deployment task. In the literature, the term is used most explicitly for ISA-level descriptions of processor side-channel leakage, where a contract exposes selected architectural facts as proxies for microarchitectural observables (Wang et al., 2023). Closely related work extends the idea to contract synthesis, verification, testing, and fuzzing for RTL processors (Wang et al., 8 Sep 2025), and adjacent blockchain, cryptographic, and economic literatures use the same leakage-centered logic to delimit sensitive state exposure, preserve private verifiability, or characterize equilibrium robustness under uncontrolled information flow (Liu et al., 20 Feb 2025). Across these settings, the recurring issues are causal admissibility of observations, soundness versus precision, and the need to separate permitted leakage from impermissible side effects (Shoaei et al., 11 Mar 2026).

1. ISA-level leakage contracts and their semantics

In processor security, a leakage contract is an ISA-level abstraction that describes what information a processor may leak through microarchitectural side channels. The central motivation is that software is written against the ISA, whereas leakage is generated by microarchitectural features such as timing, caching, speculation, forwarding, and alignment behavior. Leakage contracts therefore provide an intermediate specification layer between architectural functionality and implementation-level observables (Wang et al., 2023).

A standard formalization models a contract as a set of contract atoms. In one formulation, an atom is a pair

$A=(\pi_A,\phi_A),$

where $\pi_A$ is an applicability predicate over architectural states and $\phi_A: ArchState \to CtrObs$ is a leakage function. For a template $T$, any subset $S \subseteq T$ induces contract semantics

$${}_S(\sigma) := \{ \phi_A(\sigma) \mid (\pi_A,\phi_A)\in S \wedge \pi_A(\sigma)\},$$

and the induced trace is the sequence of these observations across architectural states (Wang et al., 8 Sep 2025). A closely related synthesis-oriented formulation enriches atoms to

$A=(\pi_A,\tau_A,\phi_A),$

where $\tau_A$ identifies the leakage source; the resulting contract is a selected subset of atoms evaluated over ISA traces (Mohr et al., 2024).

The key semantic property is contract satisfaction: if two executions are equivalent under the contract, then an attacker should not distinguish them through implementation-level observations. One statement of this requirement is

$${}_S((\phi(\sigma))) = {}_S((\phi(\sigma'))) \implies Atk((\sigma)) = Atk((\sigma')),$$

where $\phi$ is the retirement predicate relating microarchitectural cycles to architectural steps (Wang et al., 8 Sep 2025). Another formulation casts the contract as a monitoring circuit composed with the ISA, and the attacker as a combinatorial monitoring circuit over the implementation; equal contract traces must imply equal attacker traces (Wang et al., 2023).

This literature distinguishes sharply between soundness and precision. A contract is sound if it captures all leaks observable to the attacker; it is precise if it does not expose substantially more than the implementation actually leaks. The tension is fundamental: a contract that exposes all instruction operands may be sound but too coarse to support secure software development, whereas an underspecified contract may hide a real leak and mislead the programmer into a false security claim (Wang et al., 8 Sep 2025).

Secure-speculation work presents the same idea as a labeled ISA semantics. Contracts are defined by an observer mode and an execution mode. The observer modes include $\pi_A$0, which exposes program counter and memory access addresses, and $\pi_A$1, which additionally exposes loaded values; the execution modes include $\pi_A$2 for sequential execution and $\pi_A$3 for always-mispredict speculative execution over a bounded window (Guarnieri et al., 2020). A related black-box testing framework uses observation clauses such as MEM, CT, and ARCH, and execution clauses such as SEQ, COND, BPAS, and COND-BPAS, making the contract an explicit leakage allowance rather than an undifferentiated notion of “security” (Oleksenko et al., 2021).

Related work on leakage containment models does not use the exact phrase “leakage contract,” but it provides an axiomatic hardware-software security contract vocabulary derived from memory consistency models. There, leakage is defined as a mismatch between architecturally implied microarchitectural behavior and actual microarchitectural communication, especially through memory-system relations such as comx and speculative order tfo (Mosier et al., 2021). This suggests that leakage contracts and LCMs occupy the same conceptual space: both aim to make microarchitectural observability explicit at a level software can reason about.

2. Verification, synthesis, and automated discovery

Once leakage contracts are treated as formal specifications, the main technical questions become how to verify that an RTL implementation satisfies a contract and how to synthesize a contract that is both sound and precise. LeaVe addresses the first problem by verifying open-source RTL processor designs against ISA-level leakage contracts. Its core ingredients are a decoupling theorem separating ISA compliance from microarchitectural security verification, a stuttering product circuit that aligns two executions on a retirement predicate, and inductive reasoning over relational abstractions learned by a Houdini-style invariant elimination loop (Wang et al., 2023).

The decoupling theorem is central because it isolates functional correctness from security verification. Under ISA compliance with respect to a retirement predicate $\pi_A$4, checking leakage against the ISA contract is equivalent to checking an implementation-only leakage ordering. This allows contract satisfaction proofs without folding full ISA-correctness reasoning into the side-channel proof itself (Wang et al., 2023). Empirically, LeaVe established contract satisfaction results for multiple open-source RISC-V processors, including DarkRISCV, Sodor, and several Ibex variants, with strongest verified contracts that expose different combinations of instruction, branch, operand, alignment, and memory information.

LeaSyn addresses the synthesis problem by alternating empirical characterization, ILP-based candidate construction, and formal verification. Starting from a user-provided contract template, it generates test cases, classifies them as attacker distinguishable or indistinguishable, and determines which atoms distinguish them. An integer linear program then selects a subset of atoms that distinguishes all attacker-distinguishable test cases while minimizing false positives on attacker-indistinguishable ones; bounded verification via self-composition and bounded model checking searches for counterexamples, and final unbounded verification with LeaVe certifies soundness if no further counterexamples exist (Wang et al., 8 Sep 2025). On six open-source RISC-V CPUs, LeaSyn synthesized sound contracts for all targets, with precision above 0.99 for all targets except the Ibex variant with a single-line cache, and did so in under 48 hours.

A semi-automatic synthesis methodology for RISC-V processors makes the template design space more explicit. It organizes atoms into instruction leakages, register leakages, memory leakages, alignment leakages, branch leakages, and data-dependency leakages. With dependency distance $\pi_A$5, the full template contains 762 atoms (Mohr et al., 2024). Applied to Ibex and CVA6, the method synthesized contracts with 82 atoms and 77 atoms respectively; for Ibex, the final contract achieved 99.93% sensitivity after template refinement revealed alignment leakage, branch-timing leakage, and data-dependency effects (Mohr et al., 2024). The same work reports that simulation, rather than ILP computation, is the dominant cost, especially for CVA6.

These results establish a characteristic workflow for leakage contracts in hardware: choose or synthesize a template, characterize distinguishability empirically, optimize for precision, and then recover soundness through formal verification. This suggests that leakage contracts function not merely as specifications but as search objects in a finite design space.

3. Testing and fuzzing against leakage contracts

Formal verification is strong but often expensive, and several works therefore recast leakage contracts as executable testing or fuzzing specifications. Revizor does this for commercial black-box CPUs. It defines a speculation contract through an observation clause and an execution clause, computes a contract trace using an executable emulator model, measures hardware traces through side channels such as L1 data cache behavior, and checks the relational compliance condition

$\pi_A$6

for all explored programs, inputs, and contexts (Oleksenko et al., 2021).

Revizor’s methodology is Model-based Relational Testing. Rather than comparing one execution to a golden architectural output, it groups inputs by equal contract trace and checks whether hardware traces are also equal inside each group (Oleksenko et al., 2021). That design makes the object of search a counterexample to contract compliance rather than a functional bug. The framework surfaced Spectre, MDS, and LVI, as well as several previously unknown variants, demonstrating that contract violations can be found empirically even when the CPU is treated as a black box (Oleksenko et al., 2021).

Pre-silicon fuzzing pushes the same idea into RTL exploration. A coverage-guided framework for open-source processors uses self-composition: two copies of the same processor execute the same program with different data sections, and only pairs that are contract-indistinguishable under a Sail-based contract simulator are forwarded to RTL simulation (Geier et al., 11 Nov 2025). Leakage is then operationalized as microarchitectural divergence under contract-equivalent inputs. The central coverage metric, Self-Composition Deviation (SCD), records which internal registers differ between the two executions and hashes successive deviation vectors into a large coverage structure (Geier et al., 11 Nov 2025).

The studied contract family includes seq-ct, seq-ct-b, and seq-arch. Under seq-ct, the contract leaks the program counter and effective memory addresses of loads and stores; seq-ct-b additionally leaks branch outcomes; seq-arch further exposes loaded values (Geier et al., 11 Nov 2025). On the in-order Rocket core, no additional leakage beyond what the contracts allow was found in the reported campaigns, whereas on the out-of-order BOOM core the fuzzer consistently found contract violations associated with speculative and out-of-order behavior (Geier et al., 11 Nov 2025). Weighted Feedback achieved the highest cumulative coverage and found the first leak fastest on average and median in the 100-run BOOM experiments.

Testing and fuzzing therefore complement verification in a precise way. Verification aims to prove that the implementation leaks no more than the contract allows; testing and fuzzing aim to find a concrete witness that it does.

4. Smart contracts, sensitive state exposure, and leakage-driven manipulation

In blockchain systems, “leakage” often refers not to a hardware side channel but to the public exposure of economically sensitive contract state. A prominent formulation argues that manipulation vulnerabilities in smart contracts are fundamentally leakage problems: because the blockchain is transparent, attackers can observe sensitive variables and use them to shape transaction ordering, reserve imbalance, randomness, or timing (Liu et al., 20 Feb 2025). The paper’s examples include token reserves in liquidity pools, internal auction bids, confidential balances and allowances, the Jimbo variables activeBin, triggerBin, and floorBin, and random seeds or state used in on-chain randomness.

PartitionGPT treats this exposure as a partitioning problem. Given contract source code and developer-provided annotations of sensitive state variables, it uses taint analysis over Program Dependence Graphs to identify sensitive functions and privileged statements, slices each function into privileged and non-privileged parts, inserts a priv_invoke node to preserve inter-procedural flow, and uses an LLM as a Solidity-to-Solidity refactoring engine to generate a public function, a privileged subfunction such as XXX_priv, and, if needed, a callback such as XXX_callback (Liu et al., 20 Feb 2025). The public part can remain on-chain, while the privileged part can be deployed inside a TEE.

Its security boundary is formalized by partitioning constraints that prohibit privileged statements from remaining in public code and preserve internal dependencies and cross-boundary control/data flow (Liu et al., 20 Feb 2025). Because LLM-generated rewrites may be syntactically or semantically wrong, PartitionGPT also performs iterative repair using compiler feedback and verifies equivalence with symbolic execution and Z3 over state changes and return values (Liu et al., 20 Feb 2025).

The evaluation covers 18 annotated smart contracts containing 99 sensitive functions. PartitionGPT successfully partitioned 76 functions, corresponding to a 78% success rate and precision 0.76; compared with function-level partitioning, the trusted or privileged codebase was reduced by about 30% (Liu et al., 20 Feb 2025). On nine real-world manipulation attacks with a total loss of about $25 million, it mitigated eight, including Jimbo, and failed on BelugaDex because the exploit came from flawed withdrawal logic rather than simple exposure of the sensitive state (Liu et al., 20 Feb 2025). The paper also reports moderate runtime gas overhead, with 61% to 103% gas increase for most sensitive functions due mainly to cross-environment communication and callback transactions.

A distinct but related use of “leakage” in smart-contract analysis concerns value leakage rather than information leakage. MAIAN characterizes prodigal contracts through a general trace-vulnerability predicate $\pi_A$7, instantiated so that an arbitrary outsider sending zero Ether can nevertheless induce a CALL, DELEGATECALL, or SUICIDE that transfers value or control to that outsider (Nikolic et al., 2018). This literature treats leakage as careless outflow along multi-transaction traces rather than disclosure of hidden state. The distinction is important: in smart-contract ecosystems, leakage may denote observable state, transferred value, or both.

5. Leakage-aware blockchain analytics, private verification, and leakage-resilient cryptography

Blockchain research also uses leakage-centered reasoning in operational monitoring and privacy-preserving verification. A leakage-aware rug-pull detector identifies temporal data leakage as the inclusion of post-withdrawal features—such as drained liquidity, collapsed transaction activity, or dead-token price and volume behavior—during training or evaluation (Shoaei et al., 11 Mar 2026). The resulting models appear accurate offline but are non-causal and “fail catastrophically” in deployment because they learn the consequences of the attack rather than its precursors (Shoaei et al., 11 Mar 2026).

The proposed remedy is a strict temporal constraint: $\pi_A$8 for all features of project $\pi_A$9, so that prediction is framed as pre-event forecasting under temporal causality (Shoaei et al., 11 Mar 2026). The hand-labeled dataset contains 1,000 token projects spanning DeFi and non-DeFi settings, combines on-chain behavioral metrics with temporally aligned OSINT features such as tweet volume and Google search hits and trends, and uses a temporally isolated 20% holdout for evaluation (Shoaei et al., 11 Mar 2026). Under this regime, TabPFN achieved approximately 0.982 accuracy, 0.982 F1, 0.997 ROC AUC, and 0.997 PR AUC, with the lowest MSE, MAE, Brier score, and LogLoss among the compared methods and a confusion matrix containing only 1 false negative and 1 false positive (Shoaei et al., 11 Mar 2026). The dead-token aftermath used for labeling is defined by zero liquidity, near-zero transactions, and undefined or untraceable price and volume persisting for at least 72 hours (Shoaei et al., 11 Mar 2026).

A separate line of work formulates a secrecy-verifiability paradox for smart contracts: contract content may need to remain private, yet its existence, authenticity, or compliance must remain publicly verifiable (Nguyen, 2022). The proposed architecture keeps secret content $\phi_A: ArchState \to CtrObs$0 off-chain and stores only evidence $\phi_A: ArchState \to CtrObs$1 on-chain, with later verification performed through a zero-knowledge proof of knowledge. The paper gives an illustrative protocol with $\phi_A: ArchState \to CtrObs$2, repeated challenge-response rounds, and informal claims of soundness, completeness, and zero-knowledge (Nguyen, 2022). It explicitly states that the method is not designed to verify contract termination and modification, and that multiple-contract SVP remains future work (Nguyen, 2022).

Leakage resilience also appears in cryptocurrency authentication. LRCoin replaces ordinary Bitcoin transaction signing with a continual-leakage-resilient ECDSA-like signature over bilinear groups, using split secret-key state, state refresh, and a verification condition

$\phi_A: ArchState \to CtrObs$3

derived from bilinear pairing equations (Yu et al., 2018). The security proof is in the generic bilinear group model under continual leakage, and the implementation reports Setup, KeyGen, Sign, and Verify timings on both a laptop and an Android phone (Yu et al., 2018). Here the “contract” is implicit rather than policy-like: the scheme remains secure as long as leakage per signing round stays within the modeled bound.

Taken together, these works show that leakage-centered design on blockchain spans at least three levels: preventing training-time leakage in detection pipelines, preserving secret contractual content while retaining verifiability, and tolerating bounded cryptographic leakage during transaction authentication.

6. Leakage-proof institutions, recurring tensions, and open problems

Information leakage also changes the theory of mechanisms. In a finite extensive-form game with a leakage order $\phi_A: ArchState \to CtrObs$4, a faster player can observe the concurrent actions of slower players, so private histories incorporate leaked actions (Häfner et al., 1 Nov 2025). The relevant equilibrium notion is leakage-proofness: along the path of the default strategy profile, each player’s action must remain equal to the default action even after any leaked information. This requirement is distinct from ex-post incentive compatibility. Pure-strategy EPIC implies leakage-proofness, mixed-strategy EPIC does not in general, static leakage-proofness implies EPIC, and dynamic leakage-proofness does not in general (Häfner et al., 1 Nov 2025).

The main implementation theorem states that a mechanism implements a social choice function under leakage if and only if it admits a leakage-proof equilibrium implementing that function (Häfner et al., 1 Nov 2025). In auctions, the classification is sharp: second-price and ascending auctions are leakage-proof, first-price auctions are not, and whether descending auctions are leakage-proof depends on tie-breaking (Häfner et al., 1 Nov 2025). Efficient auctions must therefore be leakage-proof, while revenue-maximizing ones need not be robust to all leakage beliefs.

Across domains, several tensions recur. First is soundness versus precision: coarse contracts over-approximate leakage and constrain secure behavior unnecessarily, whereas unsound ones suppress real attacks (Wang et al., 8 Sep 2025). Second is formal assurance versus scalability: LeaVe provides proofs, but fuzzing and black-box relational testing were developed precisely because verification struggles to scale to complex designs (Geier et al., 11 Nov 2025). Third is explicit versus implicit boundary definition: processor work encodes leakage as formal observations, whereas smart-contract work often begins from developer annotations of sensitive variables or from strict event-time cutoffs (Liu et al., 20 Feb 2025). Fourth is causality: the blockchain forecasting literature treats leakage not merely as a statistical artifact but as a threat to causal validity, insisting that prediction use only pre-event evidence (Shoaei et al., 11 Mar 2026).

The limitations are equally persistent. Sequential leakage contracts do not yet cover more general multi-instruction or speculative leakage phenomena in full generality (Wang et al., 8 Sep 2025). Some verification frameworks assume passive attackers, single-issue retirement, manually supplied retirement predicates, or manually supplied contract atoms (Wang et al., 2023). PartitionGPT does not support declassification annotations, depends on manual sensitive-variable annotation, and treats composite data types conservatively as sensitive wholes (Liu et al., 20 Feb 2025). The secrecy-verifiability proposal is explicitly underspecified as a production cryptographic construction (Nguyen, 2022). Fuzzing frameworks may restrict the ISA, focus on terminating executions, or omit exceptions (Geier et al., 11 Nov 2025). These constraints suggest that leakage contracts remain an active synthesis point rather than a closed theory.

In that sense, leakage contracts are best understood as a family of abstractions for governing observability. In hardware, they delimit microarchitectural side effects at the ISA boundary. In smart-contract systems, they motivate partitioning, leakage-aware evaluation, and privacy-preserving verification. In mechanism design, they determine whether equilibrium behavior survives uncontrolled information flow. What unifies these literatures is not a single formalism, but a shared insistence that security depends on specifying exactly what may be observed, when it may be observed, and why that observation is admissible.