IPPANCENT Independent Verification

Status: Production pilot. Reports below are from the operator-controlled host. External-party Level 2 verification is enabled by the artifacts in level2/. Level 3 full-replay verification is restricted to selected institutional auditors.

IPPAN defines decentralization as independent verifiability: external parties can verify ledger state and anchor commitments without controlling the writer or accessing private keys.

Latest Verified Production State

Field	Value
State root	`3f70b1c29b4180808b59f60f4a076da0ed3c05555c72632208c384b87747a6dc`
Last finalized block	2,693,817
Last batch hash	`4f6e14eb5cbeb06a4c206ccc4ee22eb68fd5121ca2afa159f776bdb88575d3b1`
Anchor count	101
Anchor log SHA-256	`155a018269459864f2106e9a596ac6fc30982d1dcf538135d1b004166f0de436`
Latest anchor hash	`f3c90efba85d40d12600bd5ee0f0865917cdd28ff270a45ab53ca04107d06f35`
Snapshot boundary	`snapshot-00000000000002693760` (batch 2,693,760)
Last verifier run	2026-05-10 17:50 UTC
Verdict	PASS (strict, `--no-isolation`, `NoPersist` read-only replay)
Production mutation during verification	none

Strict Verification Result

The Phase 2E-Strict-Rerun verifier run independently re-derived the production state root by replaying 57 sealed batches and 14,259 transactions from the snapshot boundary forward, producing exactly the operator’s published state root. All 101 anchor commitments were independently re-derived from canonical bytes and matched their persisted anchor_hash.

The same verifier binary, run again under ippancent-verifier.service after Phase 2F-Polish bundle refresh, produced an identical PASS verdict with zero production mutation.

Verifier Release

Field	Value
Release	`ippancent-verifier-v0.1.0`
Binary SHA-256	`e30d67674a24c36ec7a3d3690cb999710455ab82f29ed64e16a05fc7ed2f2c41`
Build target	`x86_64-unknown-linux-gnu`
rustc	1.95.0
Signing key fingerprint	`D2AD75EB4632EA23B7F4AD27F1C07293D3D25A43`
Long Key ID	`F1C07293D3D25A43`
Signing key algorithm	EDDSA / Ed25519
Operator anchor key used?	NO — dedicated release-signing key, separate custody

How To Verify The Release

# 1. Import the dedicated release public key
gpg --import RELEASE_SIGNING_PUBLIC_KEY.asc

# 2. Verify the SHA256SUMS signature
gpg --verify SHA256SUMS.asc SHA256SUMS
# Expected: Good signature from "IPPANCENT Verifier Release Signing Key v1 …
#                                using EDDSA key D2AD75EB4632EA23B7F4AD27F1C07293D3D25A43"

# 3. Verify all artifact checksums
sha256sum -c SHA256SUMS

# 4. Run the verifier
chmod +x ippancent-verify-x86_64-unknown-linux-gnu
./ippancent-verify-x86_64-unknown-linux-gnu --help

Level 1 Evidence

This site publishes the operator’s verification reports plus their checksums. With Level 1 alone, an external party can confirm the verifier binary they download has the SHA-256 the operator claims, that the operator’s reports are signed and consistent over time, and that the operator continues to publish PASS verdicts on the recurring weekly cadence.

Artifact	Description
`evidence/snapshot-tail-strict-PASS.json`	Operator’s latest strict snapshot-tail report (JSON)
`evidence/snapshot-tail-strict-PASS.md`	Same, Markdown
`evidence/anchor-verification-PASS.json`	Operator’s latest anchor verification report (JSON)
`evidence/anchor-verification-PASS.md`	Same, Markdown

The full strict-rerun evidence tarball is available on request:

p2e-strict-rerun-20260510T165449Z.tar.gz — SHA-256 f1d7ffca3e337b54348f2da8880944048c597e284f12ad53335cc365f5ace6e9

Level 2 Evidence

Level 2 publishes the public artifacts an external party needs to independently verify all 101 anchor commitments without requiring the ~42 GB monolithic replay logs.

Artifact	Description
`level2/anchor_log.jsonl`	Production anchor log (101 entries)
`level2/anchor-log-tip.json`	Tip metadata (sequence, last hash, file SHA)
`level2/bundle_manifest.json`	Verifier bundle manifest with expected values
`level2/genesis.json`	Genesis accounts
`level2/snapshot-00000000000002693760.json`	Snapshot boundary state
`level2/expected-anchor-log-sha`	Operator’s committed anchor-log SHA-256

Disclosure size: ~200 KB total.

To independently verify Level 2 anchor commitments:

./ippancent-verify-x86_64-unknown-linux-gnu verify-anchors \
    --anchor-log level2/anchor_log.jsonl \
    --expected-count 101 \
    --expected-sha 155a018269459864f2106e9a596ac6fc30982d1dcf538135d1b004166f0de436 \
    --expected-latest-hash f3c90efba85d40d12600bd5ee0f0865917cdd28ff270a45ab53ca04107d06f35 \
    --markdown

Expected: verdict: PASS, commitment_re_derivation_passed: true, sequence_dense: true, no_duplicate_hashes: true.

What You Can Verify Independently (Level 1 + Level 2)

The verifier binary is exactly the operator’s published binary.
The signature on SHA256SUMS is from the operator’s published release key.
The anchor log has exactly 101 entries with the operator’s published SHA-256.
Every entry’s anchor_hash equals SHA-256(canonical_bytes(commitment)) — i.e., anchor records are tamper-evident.
The anchor sequence is dense (no gaps).
There are no duplicate anchor_hash values.
The bundle manifest is well-formed and references the exact expected values.
The genesis file is the public, immutable account list.
The snapshot file at boundary 2,693,760 carries 32 accounts and the published state_root.

What Requires Controlled Level 3 Access

Independent re-derivation of the state root by replaying the 57 post-snapshot batches and 14,259 transactions. This requires the ~42 GB batch_log.bin and round_log.bin. Level 3 transfer is governed by Phase 3C (NDA + pre-signed bucket URLs).

Limitations

See docs/PUBLIC_VERIFIER_LIMITATIONS.md for the full register. Short summary:

Snapshot-tail only (no genesis-to-head CLI yet)
Reference-level operator key check (current anchor format does not embed Ed25519 signatures)
~42 GB Level 3 disclosure is not public yet
Verifier currently runs on the operator-controlled host between Level 2 publications
No multi-operator comparison
No liveness proof

Security Notes

The published staging directory was scanned with the verifier’s own scan-secrets and returned clean: true, 0 findings, 20 files before this page was generated.
Files explicitly excluded from publication: operator_signing.key, *.pem, SSH/TLS keys, admin tokens, unredacted server config, .env files, batch_log.bin, round_log.bin, all Phase 2 evidence tarballs that contain operator-side environment metadata, and proprietary writer source.
A pre-publication go/no-go checklist (PHASE3B_PUBLICATION_GO_NO_GO_CHECKLIST.md) gates every public release.

Download Links

(To be populated when published. Currently placeholders.)

Artifact	Link
Verifier binary	`https://github.com/dmrl789/ippancent-verifier-releases/releases/download/ippancent-verifier-v0.1.0/ippancent-verify-x86_64-unknown-linux-gnu`
Release SHA256SUMS	`https://github.com/dmrl789/ippancent-verifier-releases/releases/download/ippancent-verifier-v0.1.0/SHA256SUMS`
Release SHA256SUMS.asc	`https://github.com/dmrl789/ippancent-verifier-releases/releases/download/ippancent-verifier-v0.1.0/SHA256SUMS.asc`
Release public key	`https://github.com/dmrl789/ippancent-verifier-releases/releases/download/ippancent-verifier-v0.1.0/RELEASE_SIGNING_PUBLIC_KEY.asc`
Latest evidence tarball	`https://dmrl789.github.io/ippancent-verifier-releases/p2e-strict-rerun-20260510T165449Z.tar.gz`
Level 2 anchor log	`https://dmrl789.github.io/ippancent-verifier-releases/level2/anchor_log.jsonl`
Level 2 manifest	`https://dmrl789.github.io/ippancent-verifier-releases/level2/bundle_manifest.json`

Contact / Auditor Access

For Level 3 (full replay bundle, ~42 GB) access under transfer agreement, contact the operator via the project’s official channels. (Placeholder; production publication will list real addresses.)

Verification Cadence

A weekly automated verification runs every Sunday at approximately 03:30 UTC (with up to 30 minutes of randomized jitter). Each run produces JSON + Markdown reports and an evidence tarball. Reports will be published here within 24 hours of each PASS run, beginning when this page goes live.