Proof-Carrying Change Objects

• The paper establishes a trust mechanism where a change proposal is accepted only after a trusted validator confirms its adherence to a declared semantic contract.
• It details various frameworks—ranging from source rewrites to blockchain transactions—each employing tailored evidence forms like certificates, theorems, or structured witnesses.
• Empirical evidence, such as the Scratch system’s 94.3% acceptance rate and negligible certification overhead, demonstrates the practical viability and efficiency of these approaches.

Searching arXiv for recent and relevant papers on proof-/certificate-carrying change mechanisms and adjacent frameworks. Proof-Carrying Change Objects are change artifacts whose acceptance is conditioned on machine-checkable evidence evaluated by a trusted validator rather than on trust in the producer. In the literature, the carried object may be a source-to-source rewrite, a logical transformation, a blockchain transaction, or a branch-scoped repair proposal; the accompanying evidence may be an explicit certificate, a theorem, or a structured witness whose semantic obligations are reconstructed by the consumer. What unifies these systems is a common trust discipline: an untrusted producer proposes a change, a small trusted component validates that specific change against a declared policy or semantic contract, and deployment is fail-closed if validation does not succeed (Si et al., 1 Jul 2026, Garchery, 2021, Bjørner et al., 2024, Tagliabue et al., 10 Oct 2025).

1. Conceptual definition and lineage

The core idea descends from the proof-carrying tradition in which a producer is not trusted because of identity or implementation pedigree, but because the delivered artifact is accompanied by evidence that a consumer can check independently. Recent work extends that pattern from whole-program acceptance to change acceptance. In "Certificate-Carrying Transformation of Event-Driven Block Programs" (Si et al., 1 Jul 2026), the relevant object is a proposed rewrite to a Scratch project. In "A Framework for Proof-carrying Logical Transformations" (Garchery, 2021), it is a proof-task transformation. In "Theorem-Carrying-Transaction: Runtime Certification to Ensure Safety for Smart Contract Transactions" (Bjørner et al., 2024), it is a blockchain transaction. In "Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse" (Tagliabue et al., 10 Oct 2025), it is an agent-proposed pipeline repair gated by deterministic verification.

This broader notion is not identical to classic Proof-Carrying Code. A recurrent misconception is that proof-carrying change necessarily requires an explicit derivation term attached to every update. The literature does not support that as a universal requirement. The Scratch system explicitly states that its certificate is “a set of hints, a locator and not a proof object,” yet it still serves the trust function because the checker recomputes every side condition from the before and after programs themselves (Si et al., 1 Jul 2026). The lakehouse architecture likewise uses a deterministic verifier of type $Branch \rightarrow bool$ rather than a formal proof language (Tagliabue et al., 10 Oct 2025). By contrast, the logical-transformation framework develops an explicit certificate language, and TCT uses the language of theorems carried by transactions (Garchery, 2021, Bjørner et al., 2024).

An earlier antecedent appears in incremental Abstraction-Carrying Code, where a producer provides a modified version of a previously validated program together with incremental certificates and an incremental checking algorithm for untrusted updates [0701111]. This suggests that proof-carrying change is not a single mechanism but a family of architectures centered on change-local validation and reuse of a previously trusted baseline.

2. Change carriers, certificate forms, and validator interfaces

Across domains, a proof-carrying change object has three stable components: a change carrier, an evidence form, and a validator interface. The table summarizes representative instantiations discussed in the recent literature (Si et al., 1 Jul 2026, Garchery, 2021, Bjørner et al., 2024, Tagliabue et al., 10 Oct 2025).

Domain	Change carrier	Evidence and validation interface
Event-driven block programs	Proposed rewrite plus family/lens metadata and locator	Checker recomputes obligations from before/after programs
Logical proving	Transformation from one proof task to derived tasks	Certificate language with holes checked by a third-party tool
Smart contracts	Transaction / state-transition request	Theorem $\tau=(f,\varphi(v,s),ph)$ checked before execution
Agentic lakehouse repair	Branch-scoped candidate repair and resulting branch state	Deterministic verifier $Branch \rightarrow bool$ before merge

The Scratch system gives the most explicit structural account of the change carrier. Its “change object” is the proposed rewrite plus family/lens metadata and a locator; the certificate additionally includes SHA-256 digests of the before and after byte streams. The checker then re-hashes bytes, re-parses both programs, resolves the lens and rewrite family from fixed tables, recomputes every family-specific side condition, and accepts only if every obligation is proved (Si et al., 1 Jul 2026). The system emphasizes two structural protections: a registered-family discipline, which prevents the optimizer from inventing proof rules, and a single-allowed-delta obligation, which proves that the only program difference is the declared edit class.

The logical-transformation framework makes the certificate itself a first-class object. It defines a certificate language whose constructors record the local proof-theoretic reason a transformation step is sound, and it supports certificates with holes so that unfinished obligations remain explicit and compositional. The transformation producer is instrumented independently of the checker, and correctness is delegated to an external skeptical validator (Garchery, 2021).

TCT uses a more transaction-centric interface. The carried object is a transaction that mutates global blockchain state, and the attached theorem has the form $\tau=(f,\varphi(v,s),ph)$, where $f$ is the entry function, $\varphi(v,s)$ is a hypothesis over arguments and blockchain state, and $ph$ is a path hash identifying the concrete execution trace. Nodes check theorem applicability and path agreement before allowing the state change to take effect (Bjørner et al., 2024).

The lakehouse case is more implicit. The candidate branch, its code and environment changes, and the branch-local materialized outputs jointly function as the change carrier. The verifier outcome is the decisive evidence, but the paper does not package the evidence into a formal certificate object; rather, it operationalizes a verify-then-merge discipline in which reproducibility metadata, branch lineage, logs, and branch-local outputs support the merge decision (Tagliabue et al., 10 Oct 2025).

3. Semantic contracts and preservation criteria

Proof-Carrying Change Objects are defined not only by syntactic structure but by the semantic contract that the validator checks. Those contracts differ sharply across domains.

For Scratch rewrites, preservation is observational and lens-relative. The paper states that refinement is inclusion of observable trace sets under a lens, so a rewrite preserves behavior under lens $L$ when the transformed program refines the original under that lens, informally written as $P' \sqsubseteq_L P$ (Si et al., 1 Jul 2026). The observation lens is therefore part of the certification interface rather than an afterthought. The player lens observes rendered frames, sounds, answer prompts, visible variable/list monitor values, and termination, whereas a finer debug/editor lens additionally observes comments and layout. A rewrite may thus be valid under one lens and invalid under another.

The central semantic theorem in that system is the cooperative-frame theorem. It formalizes a dead-store elimination rule for Scratch’s cooperative, event-driven concurrency model: if a write is overwritten before any thread observes it and within a window in which no thread yields, deleting the earlier write refines the original program under the player lens. Admissibility of the pending window is characterized by the side condition

$\mathrm{read}(o)\cap \{r\}=\emptyset$

for every observation step $\tau=(f,\varphi(v,s),ph)$0 in the window, together with the condition that the overwriting write does not read the old value of $\tau=(f,\varphi(v,s),ph)$1 (Si et al., 1 Jul 2026). This theorem is then instantiated to both variable state and renderer state.

In the logical-transformation setting, the semantic contract is proof-theoretic rather than operational. A transformation from an initial task to derived tasks is correct when validity of the resulting tasks implies validity of the original task. The framework formalizes this by a certificate semantics in which, if the certificate judgment holds for a task and a certificate, then validity of each leaf of the certificate implies validity of the initial task (Garchery, 2021). Here the “behavior” preserved by a change is not runtime behavior but sequent validity.

TCT adopts a path-sensitive transactional semantics. A theorem $\tau=(f,\varphi(v,s),ph)$2 means that for any transaction started by invoking $\tau=(f,\varphi(v,s),ph)$3, when $\tau=(f,\varphi(v,s),ph)$4 is satisfied, if execution completes and the path hash equals $\tau=(f,\varphi(v,s),ph)$5, then the assertions along that execution are guaranteed to hold (Bjørner et al., 2024). The relevant properties are contract invariants, function postconditions, inherited behavioral constraints, and cross-contract relational properties. Its worked ERC20 invariant,

$\tau=(f,\varphi(v,s),ph)$6

illustrates that the contract is semantic: the theorem is about preservation of supply-consistency and bounded balances, not about forbidding named low-level bug patterns (Bjørner et al., 2024).

The lakehouse setting adopts the weakest formal interface but still fits the same pattern. Business logic is treated as functions of type $\tau=(f,\varphi(v,s),ph)$7, and branch promotion is governed by a deterministic verifier of type $\tau=(f,\varphi(v,s),ph)$8. The acceptance rule is simply verify-then-merge: a branch may merge into production only if the outer-loop verifier returns true (Tagliabue et al., 10 Oct 2025). This suggests a proof-carrying change architecture in which the semantic policy is supplied by the platform owner rather than by a domain-generic theorem library.

4. Architectures of trust, skepticism, and fail-closed acceptance

The most important architectural feature of proof-carrying change is concentration of trust in a validator whose job is sharply simpler than that of the producer. The recent literature repeatedly adopts a skeptical architecture.

In the Scratch system, the checker is “the sole authority” and the optimizer is explicitly untrusted. The paper describes the discipline as LCF-style: “the optimizer proposes and the checker disposes.” Because the checker resolves rewrite families from a fixed registry, binds each family to a compatible observation lens, recomputes every side condition, and proves a single-allowed-delta obligation, an optimizer bug cannot mint an unsound acceptance given a correct checker and the stated model-to-VM assumptions (Si et al., 1 Jul 2026). This is a particularly crisp formulation of a proof-carrying change boundary.

The logical-transformation framework adopts the same skeptical stance. Transformations are instrumented independently, produce certificates, and rely on a third-party checker for validation. This shrinks the trusted base relative to trusting the entire transformation layer of a proof assistant or deductive verifier, and it permits composition through certificates with holes rather than through trust in a monolithic transformation engine (Garchery, 2021).

TCT transfers that pattern to decentralized runtime enforcement. The producer of the theorem may be any user, typically a programmer or transaction issuer, but nodes are responsible for checking theorem validity, theorem applicability, and execution-path agreement before accepting the state transition. Once a theorem is accepted into the repository, future transactions can reuse it, but reuse does not bypass checking: current-state hypotheses and path hashes must still match (Bjørner et al., 2024).

The lakehouse design similarly treats the agent as untrusted. Its safety rests on API mediation, branch isolation, declarative environments, transactional runs, and the outer deterministic verifier. All writes occur on copy-on-write branches, functions are isolated processes with no internet access, package policy can be checked from decorators, and production is modified only by merge. The paper explicitly notes that removing merge-to-main permissions can force human review, showing that the acceptance function can remain under human or platform control even when generation is automated (Tagliabue et al., 10 Oct 2025).

A plausible implication is that proof-carrying change objects are best understood as trust-partitioning devices. They do not eliminate trust; they move it from complex synthesis engines to a smaller interface consisting of a checker, an explicit specification of admissible evidence, and a declared semantic policy.

5. Representative realizations and empirical evidence

The strongest fully developed realization in the supplied literature is the Scratch checker for six rewrite families: comment cleanup, unused-asset cleanup, dead-broadcast removal, dead-code elimination, variable dead-store elimination, and visual dead-store elimination. Three of these carry mechanized theorem support in Lean: the two dead-store families via the cooperative-frame theorem and comment cleanup via canonical core equality (Si et al., 1 Jul 2026). On 300 public Scratch projects, the checker accepts at least one rewrite on $\tau=(f,\varphi(v,s),ph)$9 of projects, with 95% confidence interval $Branch \rightarrow bool$0. Certification costs are under one tenth of a second per project; median accepted check time is 2 ms, the 95th percentile is 66 ms, and the slowest single check is 1.3 s. A cross-family adversarial campaign of 4,278 perturbed rewrites yields zero false accepts, and an ablation that strips semantic side conditions produces rewrites that the virtual machine confirms change behavior, while the full checker rejects every such rewrite (Si et al., 1 Jul 2026). These results are unusually direct evidence that semantic obligations are load-bearing rather than decorative.

The logical-transformation framework provides a different kind of empirical support. It implements the full chain of certificate generation and verification in Why3, with both an OCaml checker and a Lambdapi checker, and reports that the formalization exposed real bugs in existing transformations such as destruct and case (Garchery, 2021). The practical lesson is that certificate-carrying change can serve not only as a deployment gate but also as a diagnostic lens on trusted transformation code.

TCT supplies runtime evidence from blockchain settings. The 2024 paper reports negligible runtime overhead, quantified as 0.20% for token transactions and 0.52%–0.58% for Uniswap transactions, with swap at 0.57%; it characterizes this as two orders of magnitude lower than a state-of-the-art approach (Bjørner et al., 2024). The proof obligations are discharged off the hot path through theorem generation and theorem reuse, so runtime checking reduces largely to hypothesis checking, theorem lookup, and path-hash comparison. The case studies show that design-level token invariants can block both overflow-based inflation and reentrancy-based corruption without having to enumerate those attack patterns in the property language (Bjørner et al., 2024).

The lakehouse paper presents a proof-of-concept rather than a comparable quantitative evaluation, but its significance lies in showing that the same architecture can be applied to AI-generated changes: agents inspect logs, query lake state, propose code and environment repairs on branches, and promotion to production occurs only after deterministic verification in an outer loop (Tagliabue et al., 10 Oct 2025). This suggests that proof-carrying change is not limited to compilers or formal verification tools; it can also function as a governance layer for agentic systems.

6. Boundaries, misconceptions, and open research problems

The literature also makes clear that proof-carrying change objects are not a single solved technology. Their current realizations differ in proof expressiveness, semantic scope, and trusted-base assumptions.

First, many systems are certificate-carrying rather than proof-term-carrying in the strict PCC sense. The Scratch certificate is deliberately weak—family tag, lens, locator, and digests—and the semantic burden lies in checker recomputation (Si et al., 1 Jul 2026). The lakehouse paper does not define a proof language, an explicit change-object schema, or persistent attestations; it relies instead on branch-local verification and merge gating (Tagliabue et al., 10 Oct 2025). TCT, while theorem-centric, still leaves the exact proof-object format underdeveloped and discusses future proof-object generation as unfinished work (Bjørner et al., 2024). A common misconception is therefore that explicit proof objects are the only legitimate form of proof-carrying change. The current literature instead spans a continuum from explicit certificates to structured witnesses checked by skeptical consumers.

Second, supported change classes are often finite and registry-bound. The Scratch checker supports only six families, and only three have mechanized theorem support; its current architecture is best suited to local rewrites with family-specific validators (Si et al., 1 Jul 2026). The logical-transformation framework remains incomplete for difficult cases such as polymorphism elimination and algebraic data type elimination, and its kernel certificates can become verbose (Garchery, 2021). TCT is path-sensitive, so unseen paths may require new theorems, and the paper identifies theorem summaries and multiple carried theorems as future work (Bjørner et al., 2024).

Third, soundness is frequently relative to a model, lens, or policy. Scratch soundness depends on the chosen observation lens and on two explicit model-to-VM conformance assumptions; a rewrite sound under the player lens may be unsound under a finer editor/debug lens (Si et al., 1 Jul 2026). Lakehouse acceptance depends on a business-contextual verifier whose predicates are not formalized as a compositional logic (Tagliabue et al., 10 Oct 2025). TCT focuses on safety properties, not liveness, and its guarantees are only as strong as the NatSpec annotations and infrastructure assumptions that connect source-level properties to EVM execution (Bjørner et al., 2024).

Finally, composition across independently validated changes remains unevenly developed. Certificates with holes in the logical-transformation framework are an explicit compositional mechanism (Garchery, 2021). Incremental ACC already framed the problem of validating untrusted updates to a previously trusted program [0701111]. By contrast, the lakehouse paper explicitly lacks merge semantics for combining multiple validated changes, and TCT does not yet provide a full meta-theory for independently certified transaction classes under complex long-term evolution (Tagliabue et al., 10 Oct 2025, Bjørner et al., 2024).

Taken together, the available work supports a precise but plural understanding of Proof-Carrying Change Objects. They are not defined by one certificate syntax or one proof formalism. They are defined by an operational principle: a proposed change becomes admissible only when accompanied by enough structured evidence for a trusted validator to establish that this exact change satisfies a declared semantic contract. Recent systems show that this principle can be realized for event-driven source rewrites, proof-task transformations, blockchain state transitions, and AI-generated data repairs, but they also show that expressiveness, compositionality, and end-to-end formalization remain active research problems (Si et al., 1 Jul 2026, Garchery, 2021, Bjørner et al., 2024, Tagliabue et al., 10 Oct 2025).