---
title: Proof-Carrying Change Objects
url: https://www.emergentmind.com/topics/proof-carrying-change-objects
type: topic
---

# Proof-Carrying Change Objects

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 [2607.00563][2107.02352][2408.06478][2510.09567].

## 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" [2607.00563], the relevant object is a proposed rewrite to a Scratch project. In "A Framework for Proof-carrying Logical Transformations" [2107.02352], it is a proof-task transformation. In "Theorem-Carrying-Transaction: Runtime Certification to Ensure Safety for Smart Contract Transactions" [2408.06478], it is a blockchain transaction. In "Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse" [2510.09567], 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 [2607.00563]. The lakehouse architecture likewise uses a deterministic verifier of type $Branch \rightarrow bool$ rather than a formal proof language [2510.09567]. By contrast, the logical-transformation framework develops an explicit certificate language, and TCT uses the language of theorems carried by transactions [2107.02352][2408.06478].

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 [2607.00563][2107.02352][2408.06478][2510.09567].

| 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 [2607.00563]. 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 [2107.02352].

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 [2408.06478].

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 [2510.09567].

## 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$ [2607.00563]. 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 $o$ in the window, together with the condition that the overwriting write does not read the old value of $r$ [2607.00563]. 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 [2107.02352]. 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)$ means that for any transaction started by invoking $f$, when $\varphi$ is satisfied, if execution completes and the path hash equals $ph$, then the assertions along that execution are guaranteed to hold [2408.06478]. The relevant properties are contract invariants, function postconditions, inherited behavioral constraints, and cross-contract relational properties. Its worked ERC20 invariant,
$$
(\forall x:address \mid 0 \le balances[x] \le totalSupply)\ \wedge\ \left(\sum_x balances[x]=totalSupply\right),
$$
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 [2408.06478].

The lakehouse setting adopts the weakest formal interface but still fits the same pattern. Business logic is treated as functions of type $Table(s)\rightarrow Table$, and branch promotion is governed by a deterministic verifier of type $Branch \rightarrow bool$. The acceptance rule is simply verify-then-merge: a branch may merge into production only if the outer-loop verifier returns true [2510.09567]. 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 [2607.00563]. 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 [2107.02352].

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 [2408.06478].

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 [2510.09567].

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 [2607.00563]. On 300 public Scratch projects, the checker accepts at least one rewrite on $283/300 = 94.3\%$ of projects, with 95% confidence interval $[91.1,96.4]$. 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 [2607.00563]. 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` [2107.02352]. 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 [2408.06478]. 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 [2408.06478].

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 [2510.09567]. 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 [2607.00563]. 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 [2510.09567]. TCT, while theorem-centric, still leaves the exact proof-object format underdeveloped and discusses future proof-object generation as unfinished work [2408.06478]. 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 [2607.00563]. 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 [2107.02352]. TCT is path-sensitive, so unseen paths may require new theorems, and the paper identifies theorem summaries and multiple carried theorems as future work [2408.06478].

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 [2607.00563]. Lakehouse acceptance depends on a business-contextual verifier whose predicates are not formalized as a compositional logic [2510.09567]. 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 [2408.06478].

Finally, composition across independently validated changes remains unevenly developed. Certificates with holes in the logical-transformation framework are an explicit compositional mechanism [2107.02352]. 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 [2510.09567][2408.06478].

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 [2607.00563][2107.02352][2408.06478][2510.09567].

Source: https://www.emergentmind.com/topics/proof-carrying-change-objects