Commit
Critical lifecycle events produce PoI commits: cryptographic records encoding operation metadata, supply delta, attestation hashes, and a link to the previous commit. Once committed, changes become detectable through replay and anchor checks.
Proof of
Integrity
A cryptographic accountability layer for tokenised assets, designed and built by StrikeX.
A New Standard
PoI is a StrikeX original
Conceived, designed, and built in-house as a new standard for verifiable tokenised assets. It makes every critical lifecycle event independently provable and tamper-evident, on any supported chain, so tokenised markets run on proof, not blind trust.
Chain
Commits are hash-linked in sequence, forming a continuous chain per provider. The chain starts at token creation and records supply changes, reconciliation, and resolution events. Any break is detectable by replay.
Anchor
PoI commits and batches are anchored through provider-scoped on-chain records. The anchored hash creates an immutable reference point that can be read without credentials or permissions.
The Commit
Anatomy Of A PoI Commit
What Makes PoI Different.
Origin
Learn about PoI
A StrikeX Original
PoI is StrikeX-built infrastructure for proving tokenised asset history beyond audit logs or periodic reports.
Tamper Evident By Design
Altering a commit changes its hash and breaks continuity with the next commit. Tampering is detectable through replay and anchor checks.
Permissionless Verification
Public PoI records can be replayed independently. Verifiers check continuity, batch inclusion, and supply against on-chain state.
Merkle-Anchored Batches
Batched operations anchor to a Merkle root. Individual commits can be proven against the batch without exposing unrelated operations.
Provider-Scoped Chains
Each provider maintains its own PoI chain and anchor records, separated across tokens, reconciliation records, and proof chains.
STRX Economics
PoI commits and batch anchors consume STRX under configurable provider, asset, and operation rules.
FAQs
Proof of Integrity
What is Proof of Integrity?
Proof of Integrity is StrikeX's cryptographic accountability layer for tokenised assets. It produces a PoI commit for every meaningful lifecycle event, including token creation, mints, burns, max supply updates, reconciliation checks, and mismatch resolutions. Each commit records the operation metadata, supply delta, attestation hashes, and the previous PoI hash.
Why does the PoI chain cover more than just mints and burns?
Because integrity is not only about supply changes. Token creation establishes the asset's genesis. Max supply updates record policy changes. Reconciliation commits prove that the system checked committed supply against provider attestation records at a specific point in time. Resolution commits prove that a mismatch was acknowledged, classified, and carried through an auditable workflow.
What is hash continuity?
Each PoI commit includes the previous PoI hash, forming an ordered chain from genesis to the latest commit. If a historical commit is changed, its hash changes and the next commit no longer points to it. That break can be detected by replaying the chain.
What is historical tampering and how does PoI expose it?
The risk is audit-trail tampering: a past record being changed, removed, or replaced after the fact. PoI makes that tamper-evident by hash-linking each commit to the previous commit and anchoring the chain on-chain. If a historical commit changes, its hash changes, downstream links no longer match, and the altered history fails replay and anchor checks.
Is Proof of Integrity an open standard?
No. PoI is purpose-built StrikeX infrastructure, not a third-party standard. The system itself is proprietary, while the verification model is designed to be public: commits, anchors, and expected verification behaviour can be checked independently.
Can PoI be disabled or bypassed?
No. Within the StrikeX Tokenisation Engine, operational execution and PoI commitment are coupled. Engine actions produce PoI commits, and valid PoI commits are produced through the engine's validation pipeline rather than as optional after-the-fact audit notes.
How does continuous reconciliation work?
The engine compares on-chain token supply against the provider's committed attestation records. If the values do not reconcile, the mismatch is classified with an explicit reason code and tracked through an auditable resolution workflow.
What types of mismatches can occur?
Mismatches are classified by reason, such as provider reporting lag, FX or denomination differences, pending corporate actions affecting supply, or a true mismatch requiring investigation.
How are mismatches resolved?
An administrator reviews the mismatch, assigns a resolution type, adds resolution notes, and files a resolution commit. The resolution becomes part of the PoI chain and is anchored on-chain, so the discrepancy and its handling remain visible in the audit trail.
Are reconciliation records provable?
Yes. Reconciliation records and resolution commits are part of the PoI chain, hash-linked to surrounding commits and anchored on-chain. They can be replayed, checked for continuity, and verified through the same public verification model as other operations.