Public Verification: Permissionless Proof For Tokenised Assets.

A tokenised asset should not ask the market to rely only on a dashboard, a statement, or a periodic report. A credible system should be independently checkable.

On-chain balances are visible, but balances alone do not explain how supply was created, whether a material event was committed into the asset’s operating history, or whether the token’s public record still agrees with on-chain state. Public verification is designed to close that gap.

The principle is simple. Any tokenised asset issued through the StrikeX Tokenisation Engine should be independently auditable by anyone, without permission and without depending on StrikeX to confirm the result. The tools to make that possible have been built and are planned for public launch.

 

What verification actually checks

Public verification rests on three connected checks, each testing a different property of the public record.

The first is replay. The Proof of Integrity chain is a hash-linked sequence of commits, with each commit declaring the hash of the previous one. A verifier can walk that chain from genesis and confirm its continuity directly. If any historical commit has been altered, the downstream links no longer line up, and the divergence becomes visible to anyone running the replay. Changes to old commits cannot be hidden by rewriting the chain, because the chain’s continuity is anchored on-chain.

The second is inclusion. Operations are grouped and anchored on-chain as a single cryptographic commitment, a Merkle root. A verifier can prove that a specific commit was included in that anchored batch without needing every other operation in the batch to be published. The audited operation is openly verifiable; the rest of the batch remains private. Disclosure is bounded to what the verifier is actually checking, which is what allows the system to be publicly provable without exposing unrelated activity.

The third is reconciliation. For supply-changing activity, expected token supply can be derived from the committed PoI operations and compared against live on-chain supply, per token and per provider. If the numbers agree, the public record and the blockchain are telling the same story. If they do not, the verifier has found a discrepancy. The mismatch does not, by itself, explain why; it may point to an operational issue, a delayed record or an event that needs investigation. Reconciliation and resolution events are themselves committed to the PoI chain with reason codes, so the trail from detection through resolution remains auditable.

Taken together, the three checks make disputes observable. Disputes can still happen, but they no longer remain hidden inside private systems.

 

How verification runs

The verification logic runs in the verifier’s browser. The browser reads public PoI commits, recomputes hashes, checks Merkle inclusion proofs against on-chain anchors, and compares derived supply against live contract supply. Each check is performed locally and the result is displayed locally.

Where a wallet or chain connection is used, it is read-only. The verifier does not sign messages, submit transactions, hold custody of anything, or give StrikeX control over the check. No API key, no account, and no relationship with the issuer is required. Anyone with a browser and a public chain connection can run the same checks an auditor would run, against the same public record.

A hosted verifier that returns “verified” still asks the user to trust the server. The StrikeX model takes a different approach. The verification logic is reproducible, and developers can perform the same checks independently using public PoI data, standard hashing and Merkle libraries, and read-only chain calls. StrikeX makes the activity discoverable, but the judgement is not StrikeX’s to make.

 

Why Merkle proofs rather than zero-knowledge proofs

The design requirement is public auditability: prove continuity, prove batch inclusion, prove that committed supply reconciles with chain state. Merkle proofs do all three directly and efficiently. Zero-knowledge proofs are useful when the underlying data must stay hidden, but PoI is built to make the relevant integrity data openly verifiable, so zero-knowledge would add complexity without strengthening the verification guarantee. The privacy boundary in this system runs around unrelated batched operations and confidential off-chain evidence, not around the verified operations themselves.

 

Public for verification, private for records

Institutional tokenisation cannot publish everything. Some evidence sits inside provider records, legal documents, custody arrangements or other confidential systems, and public verification does not require those records to be exposed wholesale. The public PoI record contains enough information to check whether material events were committed, anchored and reconcilable with chain state. Deeper evidence can still be reviewed by authorised parties through the appropriate process. The model is designed to make the public record checkable while keeping confidential operating records out of public data.

 

The principle

Public verification gives people outside the system a way to check whether the public record holds together. It is not a claim that the system is always correct; it is a way of making the system’s claims testable.

A tokenised asset should be more than a balance on a blockchain. It should have a public history that can be inspected, questioned and reconciled. When that history agrees with the chain, confidence rests on something stronger than trust: the ability to check.