A permissionless verification model for independently checking provider tokenisation history.
Public Verification is the principle that any tokenised asset issued through the StrikeX Tokenisation Engine should be independently auditable by anyone, with no permission and no reliance on StrikeX. We've built the tools to make that possible.
Public verification is designed to require no API key, account registration, or relationship with StrikeX. Once launched, the verifier will let anyone check published PoI records and on-chain anchors without permission from StrikeX or the asset provider.
Verification is designed to run in the verifier's browser against public PoI records and chain state. PoI continuity is replayed from commit data, supply is checked against live contracts, and the verifier does not rely on an issuer-supplied pass/fail result.
The verification model covers the committed lifecycle, from token creation through mints, burns, reconciliation, and resolution events. The PoI chain is designed to be replayable from genesis to the latest published commit.
Published PoI data and chain records provide the inputs for independent checks.
Raw commit data and hash rules are recomputed independently. Any mismatch fails integrity checks.
Each commit declares its previous PoI hash. Replay from genesis confirms the sequence is unbroken.
Published PoI hashes are compared with anchored chain state. Divergence indicates record drift.
PoI burn amounts can be checked against the public record per transaction.
Supply is checked per token and provider, then compared with live on-chain totals.
Yes. Public verification is designed to be permissionless. Once the StrikeX Verify browser is launched, anyone will be able to use it to check token history without an account, API key, or relationship with StrikeX. The same model also allows developers to reproduce the checks directly from public PoI data and chain state.
The three methods are chain replay, Merkle inclusion, and supply cross-check. Chain replay verifies the hash-linked PoI history from genesis. Merkle inclusion proves a specific commit was included in its anchored batch. Supply cross-check derives expected token supply from committed operations and compares it against live on-chain token supply.
A mismatch means the PoI-derived supply and the live on-chain supply disagree, so the verifier has found a discrepancy rather than a pass. Reconciliation and resolution events are themselves committed to the PoI chain with reason codes, leaving an audit trail from detection through resolution.
The intended normal tool is the StrikeX Verify browser, which has been built and is planned for a later public launch. It uses the verifier's own wallet connection for the relevant chain and does not require signing, transactions, an account, or an API key. Developers can also reproduce the checks independently with public PoI data, standard hashing and Merkle libraries, and read-only chain calls.
Operations are batched and anchored on-chain as a single Merkle root. A verifier can prove one commit belongs to that batch without publishing every other operation in the batch. The design is still transparency-first: the verified operation is meant to be auditable, while unrelated batched operations do not need to be exposed for that proof.
The requirement is public auditability: prove continuity, prove batch inclusion, and prove that committed supply changes reconcile with chain state. Merkle proofs do that directly and efficiently. Zero-knowledge proofs are useful when the underlying data must stay hidden; PoI is designed to make the relevant integrity data openly verifiable, so ZK would add complexity without improving the core verification guarantee.