Source-linked AI summary

Axient: Manifest-Bound Evidence for On-Chain Financial Protocols: Seven-Layer Derivation, Correlation, Tamper Rejection, and Reproducible Claim Promotion

Maksym Nechepurenko

arXiv:2610.02838v1q-fin.TRcs.DB

TL;DR

Hybrid financial protocols are often assessed with artifacts that do not establish a complete, independently derived workflow. Axient binds evidence to declared system identities and correlates seven evidence layers; its registered local cohort retains twelve assertions and 84 evidence positions. The paper’s scope remains bounded by what the committed source and schema establish.

  • Problem

    Receipts, screenshots, and matching hashes may not establish that evidence came from the intended command, approved system, or independent runtime layers.

    Source: §1 · p. 1, §2.2 · p. 3
  • Method

    Axient uses a sealed execution manifest, registered evidence derivations, and a shared correlation identity to bind protocol evidence across layers.

    Source: §1 · p. 2, §6 · p. 6
  • Results

    The registered local cohort retained 84 ACTUAL_EVIDENCE positions across twelve parent FIA assertions, with two matching clean materializations, a separately verified strict archive, and an ordered replay bound to it.

    Source: §1 · p. 2, §15 · p. 13
  • Takeaways & Limitations

    The paper presents end-to-end protocol evidence as a reviewable chain of custody from financial assertion to replay-bound package.

    Source: §1 · p. 2

    Tamper checks do not prove the committed source is truthful or detect omissions outside the schema, and without a trusted anchor a consistent replacement of files and checksums defeats unconditional detection.

    Source: §10.1 · p. 10

Abstract

from arXiv · show

Hybrid on-chain financial protocols are frequently evaluated with evidence that is individually useful but collectively insufficient: a unit test, transaction receipt, screenshot, service response, or several matching hashes may be presented as proof of a complete workflow even when the layers share one generated source or omit the financial authority that matters. This paper develops a manifest-bound evidence architecture for such systems. A sealed execution manifest binds declared system identities, roles, schemas, and release identity. Seven evidence layers are retained with registered derivations and linked by a common correlation identity. A conjunctive claim-promotion rule requires provenance, predicate-specific root conditions, negative controls, reproducible packaging, historical replay, and independent review in addition to hash equality. We formalize the evidence graph, prove that copied hashes cannot establish independent derivation, show how collision-resistant commitments make specified tampering detectable, define exactly-once financial-effect evidence, and distinguish original historical identities from later reproducibility attestations. The registered local case study records twelve parent Financial Interaction Assertions in one accepted cohort: 84 retained ACTUAL_EVIDENCE positions, two clean materializations with one byte-identical file index, a deterministic strict archive accepted by a separate verifier, and a selected ordered replay bound to that archive. FIA-011 is conjunctive and retains both stale-before-admission and book-epoch-change-mid-position subcases. The result demonstrates a reviewable chain of custody from financial assertion to replay-bound package while preserving the difference between observed evidence, interpretation, and future hypotheses.

1 Introduction

Evidence such as receipts, screenshots, and matching hashes can be useful without proving that one financial action traversed the full protocol. Axient proposes a manifest-bound, correlated evidence chain whose claims require registered derivations and additional checks.

1 Introduction

  • Receipts, screenshots, matching hashes, and bounded CI runs can be overclaimed when they do not establish the user command, approved deployment, derived projections, or actual state source.The paper characterizes this as a failure of claim typing, not a failure of the artifacts themselves.Source: §1 · pp. 1–2
  • Axient proposes a manifest-bound proof chain for hybrid financial protocols, generalizing an evidence architecture recorded in a twelve-parent local cohort.The companion records 84 retained evidence positions, two matching clean materializations, a strictly verified archive, and a selected ordered replay.Source: §1 · p. 2

2.1 What an E2E claim means

  • An end-to-end claim is a chain of related observations under a specific system identity, not a single Boolean test.Promotion requires registered derivations, a shared manifest and correlation identity, required root topology, rejected invalid mutations, and a reproducible, independently reviewable package.Source: §2.1 · p. 2

2.2 Adversarial evidence failures

  • Threats include spliced evidence, fixture data presented as actual state, inferred event ordering, duplicate financial execution, and promotion beyond a bounded test.The goal is an explicit, machine-checkable claim boundary, not an assertion that all evidence is impossible to forge.Source: §2.2 · pp. 2–3

3 Typed evidence and claim taxonomy

Axient distinguishes evidence by the predicate it supports and binds evidence to declared system identities through a sealed execution manifest. This prevents one evidence type from standing in for another and makes specified identity drift visible.

3 Typed evidence and claim taxonomy

  • Reconstructed projections cannot substitute for an observed canonical transaction or state transition, and unit tests cannot substitute for historical replay when replayability is claimed.The evidence types assert different predicates, so evidence of one type cannot establish a logically distinct missing predicate.Source: §3 · p. 3

4 Sealed execution manifest

  • The manifest anchors the exercised system with source, chain, contract, authority, adapter, schema, client, dependency, and toolchain identities.Its digest is stored outside the manifest body.Source: §4 · p. 4
  • Under collision resistance, changing a declared address, bytecode, ABI, role, selector, adapter, schema, or client identity changes the manifest digest.A result under the changed system cannot retain the old manifest identity without a hash collision or verifier defect.Source: §4 · p. 4

5 Seven retained evidence layers and registered derivations

Seven retained evidence layers are linked through registered derivations and shared manifest and correlation identities; matching hashes alone do not establish that layers independently observed the claimed state. Correlation validation also checks cohort membership and rejects cross-cohort substitutions.

5 Seven retained evidence layers and registered derivations

  • A registered derivation records each layer’s inputs, transformation, root ancestry, runtime identity, canonical output projection, digest, and manifest/correlation bindings.Heterogeneous artifact digests need not be equal; a registered semantic projection provides the common comparison, but registration alone does not establish independence.Source: §5 · p. 4
  • Multi-root corroboration passes only when the claim’s registered failure model and policy requirements for source origin, failure domain, and processing path are evidenced.Copies or relabelings do not create another root, and graph cuts alone do not establish statistical independence.Source: §5 · pp. 4–5
  • Copied fixture hashes provide no evidence that any actual layer observed or reconstructed the claimed state.Equality follows from copying alone; independently participating runtime layers would additionally require multi-root corroboration, which was not evaluated in the registered local cohort.Source: §5 · p. 5

6 Correlation identity

  • Correlation binds the scenario across user, service, chain, and audit records, but the ledger is not itself financial authority.Its purpose is to expose the exact authority path and fail when a required observation is missing.Source: §6 · p. 6
  • The no-splice gate checks that required records and derivations resolve to one cohort identity rather than mixing runs, manifests, correlations, or parent records.Under collision resistance, a trusted fixed cohort commitment, and complete identity validation, substituting a foreign layer changes a checked digest or violates an identity predicate.Source: §6 · p. 6
  • A foreign cohort layer fails no-splice validation when checked run, manifest, correlation, scenario-record, and root identities are validated against a trusted cohort commitment.The gate also requires each scenario correlation exactly once and each layer to be reachable from the cohort’s manifest and ledger root.Source: §6 · p. 6

7 Evidence graph and independence model

The evidence graph represents retained observations, registered derivations, and review relationships while preserving their root ancestry. Its independence model distinguishes dependency topology from independent runtime participation, and its package-completeness test is relative to registered gates and a fixed verification context.

7.1 Directed evidence graph

  • Every non-root evidence item must name its load-bearing parents, use typed edges, bind to the scenario’s correlation and approved manifest, and belong to an acyclic derivation graph.A layer claiming an independent runtime root cannot rely solely on the compared layer’s normalized output.Source: §7.1 · p. 7
  • If all actual-layer records derive deterministically from one artifact without an independent financial-state observation, the package establishes consistency with that artifact, not runtime participation.Replacing the real system with a generator emitting the same artifact leaves the derived records unchanged.Source: §7.1 · p. 7

7.2 Independence classes

  • Syntactic, implementation, runtime, verifier-process, and operator separation are distinct independence classes, and none implies the next.Two processes under one operator establish process separation, not operator independence.Source: §7.2 · p. 7
  • The framework rejects an L4 service object relabeled as L5 when it lacks an authenticated API observation and distinct registered derivation.The negative control was specified but not evaluated in the registered local cohort.Source: §7.2 · p. 8

7.3 Evidence completeness and inclusion-minimal core

  • A claim-complete core preserves the registered gate-result vector with every required gate defined, relative to a fixed verification context.Inclusion-minimality means no proper subset preserves that vector; this is not minimum cardinality or byte size, and a single-file deletion check proves only single-deletion irredundancy absent additional assumptions.Source: §7.3 · p. 8

8 Predicate classes and claim promotion

Promotion gates fall into classes with different behavior as evidence is appended, so promotion language must match the predicates actually established. A claim is promoted only when every required gate is positively established; extra passing tests cannot compensate for a failed required gate.

9 Claim promotion as a conjunctive predicate

  • The claim-promotion ladder adds distinct predicates at each stage, unlike a weighted maturity score that could obscure a missing required layer.The figure cautions against applying later-stage claim language prematurely.Source: Figure 3 · p. 9, §9 · p. 9

8 Predicate classes and claim promotion

  • Promotion gates may be monotone, terminal-closure, absence-negative-control, recomputed-comparison, or multi-root-corroboration predicates, and several classes can change as evidence is appended.Package closure can fail with an extra member, an absence gate can fail when a prohibited event arrives, and comparisons or root topology can change.Source: §8 · pp. 8–9

9 Claim promotion as a conjunctive predicate

  • A full local end-to-end claim requires gates spanning manifest and command identity, canonical receipt or rejection, state, seven derivations, correlation, controls, packages, replay, review, and scoped authority.The registered gate set also includes a no-splice cohort-identity condition.Source: §9 · p. 9
  • Passing additional tests cannot compensate for a failed required safety or provenance gate under the conjunctive promotion rule.A conjunction is false if any required conjunct is false, regardless of how many others pass.Source: §9 · p. 9

10 Tamper and drift controls

Tamper controls combine a fixed expected commitment with validation of declared fields and policy predicates, while retained packages and historical replay preserve separately reviewable identities. These guarantees have explicit boundaries: canonicalized harmless differences, unvalidated omissions, and claims of retroactive historical identity are not covered.

10.1 Mutation families

  • Mutation tests target identity, receipt and event ordering, stale projections, spliced cohorts, package contents, forbidden authority, duplicate settlement, and recovery failures.Independent implementations, differential testing, and property-based testing provide complementary validation, but none alone proves a claim.Source: §10.1 · p. 10, §10.2 · p. 10
  • A changed committed input or a violation of a checked schema or policy predicate is rejected, except with negligible collision probability, when validation uses a fixed independent commitment.Replacing a candidate's own checksum cannot make it match the trusted expected commitment.Source: §10.1 · p. 10
  • The detection result does not establish that committed source material is true, reject harmless canonicalized differences, or detect omissions outside the schema.A self-consistent replacement of files and checksums is a counterexample when no trusted anchor exists.Source: §10.1 · p. 10

11 Retained evidence package

  • A retained package uses allowlisted payloads and a deterministic archive with a member manifest; two clean packages are byte-identical only when raw runtime fields permit that comparison.When fields vary, the policy must justify exclusions and distinguish normalized semantic identity from byte identity.Source: §11 · p. 11

12 Historical replay provenance

  • A later reproducibility attestation binds an existing source boundary to a replay wrapper, reconstructed pinned environment, and new result; it is not the original release identity.If no historical aggregate hash existed, it remains null with a reason rather than being backdated or invented.Source: §12 · p. 11

13 Exactly-once recovery evidence

Exactly-once recovery evidence tracks a committed financial effect across checkpointing, process replacement, and replay, rather than treating application availability or message delivery as sufficient. The FIA case study also treats parent assertions as conjunctive evidence contracts, with required subcases that cannot be substituted by a passing sibling.

13 Exactly-once recovery evidence

  • Recovery evidence retains a chain-confirmed transaction and receipt, pre-termination durable checkpoint, old and fresh process identities, replay records, one committed effect, and rebuilt projections.The tested fixture may record the narrower one-transaction criterion where applicable.Source: §13 · p. 12
  • The safety property counts committed effects per stable operation, key, and payload—not transaction submissions—and does not claim exactly-once delivery or unconditional eventual completion.A checkpoint-only trace does not test every earlier crash window.Source: §13 · p. 12

14 FIA case study

  • The twelve FIA cases cover evidence questions, including whether trader residual and collateral release once after canonical debt-clearance eligibility and whether authorized liquidation request/execution and the hard-flat transition are bound to one correlation.Source: §14 · p. 12
  • FIA-011 closes only when both stale-before-admission and book-epoch-change subcases meet the retained evidence contract; one passing subcase cannot close the parent.The parent remains blocked while either evidence path is incomplete.Source: §14 · p. 13

15 Registered local evidence result

The registered local cohort documents a bounded chain from parent financial assertions through retained evidence, clean materialization, strict packaging, and ordered replay. The paper distinguishes those observations from interpretation and from future claims requiring new evidence contracts.

15 Registered local evidence result

  • 12 parent FIA assertions retained 84 ACTUAL_EVIDENCE positions; two clean trees shared one file-index identity, and a strict archive was separately verified before selected replay binding.The reported result is bounded to the registered local cohort and uses aggregate identities and counts.Source: §15 · pp. 13–14
  • FIA-011 requires both stale-capability-before-admission and later book-epoch-change subcases, with retained raw and normalized evidence and explicit per-subcase coverage.A one-receipt placeholder or another FIA case cannot satisfy the parent assertion.Source: §15 · p. 14

15.1 Observed, interpreted, and future claims

  • The paper separates observed identities and counts from its chain-of-custody interpretation; external venues, public networks, real custody, terminal settlement, and production operations remain future hypotheses.Those broader settings require new evidence contracts rather than reinterpretation of this cohort.Source: §15.1 · p. 14

16.1 Scenario evidence record

  • Scenario records group identity and command data with chain, state, application projections, negative controls, recovery fields when applicable, and a verdict.The verdict records the gate vector, missing layers, classification, and reviewer notes.Source: §16.1 · p. 14

16.2 Release index

  • The release index records artifacts and deliberate absences, while package building rejects unsafe paths and members outside policy allowlists.A null historical expected-output hash with a reason is preferable to inventing a value.Source: §16.2 · p. 15, §16.3 · p. 15

17 Independent review protocol

Independent review combines mechanical checks of the retained package with semantic checks that the evidence supports the claimed language. Review outcomes constrain permitted claims, while the tamper matrix and evidence-to-language examples support that discipline.

17.1 Mechanical verification

  • Mechanical review checks archive integrity, member metadata, schemas, identities, gates, clean-run comparison, replay provenance, and privacy and license boundaries.Source: §17.1 · p. 15

17.2 Semantic verification

  • Semantic review asks whether receipts, browser state, recovery reports, projections, and declared scope support the actual claim.Source: §17.2 · p. 15
  • Review outcomes are PASS, PASS_WITH_LIMITATIONS, or FAIL_CLOSED, with a finding registry that constrains claims without changing evidence.Source: §17.2 · p. 15

18 Detailed tamper matrix

19 Claim-language governance

  • Table 5 gives representative mappings from technical evidence to approved language, preventing narrow results from becoming misleading public claims.Source: §19 · p. 16, Table 5 · p. 17

A.1 Predicate-class-aware monotonicity

Predicate classes determine whether adding evidence preserves or requires reevaluation of a gate, while hash integrity alone does not ensure semantic completeness or independent observation. The publication record supports registered provenance and package-level reproducibility within a bounded local cohort, not independent runtime corroboration.

A.1 Predicate-class-aware monotonicity

  • Valid, non-contradictory append-only witnesses preserve a positive gate, but closure, negative-control, comparison, and multi-root predicates must be reevaluated when evidence or topology changes.Source: §A.1 · p. 17

A.2 Hash soundness versus semantic completeness

  • Collision resistance detects changes relative to a fixed commitment, but omitted load-bearing fields can leave hashes stable as system meaning changes.Mutation testing and independent review are part of the evidence model.Source: §A.2 · p. 17

A.3 Independence is relational

  • Independence is relational across derivation paths and failure modes; the paper reports independence classes rather than treating layers as independent in isolation.Source: §A.3 · p. 17

B Public evidence archive

  • The public companion retains sanitized manifests, schemas, provenance, checksums, and an offline verifier, but omits raw runtime payloads and cannot validate full schemas or reconstruct unpublished roots.Source: B Public evidence archive · p. 18

C Relation to assurance and distributed-systems work

  • The framework builds on assurance and distributed-systems work, while its novel emphasis is binding financial authority, runtime identity, derivation, packaging, and claim language; related work adds no cohort here.Source: C Relation to assurance and… · p. 18

D Publication and reproducibility record

  • The registered common-cohort record supports provenance and package-level reproducibility identities, but raw roots are unpublished and broader deployment and successor experiments follow separate processes.Source: D Publication and reproducibility record · p. 18

E Limitations

The framework's evidence is bounded: it cannot establish several external truths or unknown vulnerabilities, and production performance and external behavior remain untested. The conclusion frames its contribution as a reproducible boundary between observed evidence, reconstruction, replay, and future hypotheses.

E Limitations

  • The framework cannot establish oracle truth, venue solvency, uncompromised keys, absence of unknown contract vulnerabilities, or legal enforceability.Source: E Limitations · p. 18
  • Hashes detect changed bytes under specified assumptions, not semantic omissions beyond the schema; production performance, real custody, external-venue behavior, settlement, and usability remain open empirical questions.Source: E Limitations · p. 19

F Conclusion

  • The architecture requires retained derivations, shared correlation, tamper rejection, reproducibility, historical provenance, and independent review before claims are promoted.Its conclusion distinguishes observed evidence, reconstruction, replay, and future hypotheses.Source: F Conclusion · p. 19

Data and Code Availability

Loading 2610.02838v1…