The integrity layer
forTokenised Commodities

The Tokenisation Engine is the infrastructure layer that sits between asset providers and supported blockchains. It handles token creation, supply operations, corporate actions, reconciliation, and on-chain execution, with PoI commits recording the critical lifecycle events.

The engine is designed to be asset-agnostic. It can support equities, structured notes, funds, bonds, and other financial instruments where the provider can supply the required metadata, policies, and attestations. The enforcement model is based on signed provider instructions, hashed attestations, and configured supply rules, not a single hard-coded backing model.

The engine is designed for EVM-compatible networks and can be deployed across chains such as Ethereum, Arbitrum, and BNB Chain depending on the product and provider requirements.

Before any mint or burn is executed, the engine validates the requested supply change against the provider's signed instruction, committed attestation data, replay protection, and the configured supply rules for that asset. If the required checks fail, the operation is rejected before an on-chain transaction is constructed.

The operation is rejected with an explicit reason code before any on-chain transaction is broadcast. Because the rejected operation never reaches the chain, it does not create a token supply change or a valid PoI commit.

Corporate actions such as splits, redenominations, dividends, coupons, or distributions can be handled through configured workflows: snapshot holder balances, compute allocations, queue the batch operation, execute on-chain where required, and anchor the result through PoI. The exact workflow depends on the asset and provider policy.

Yes. The engine is multi-tenant by design. Providers are separated by scoped tokens, credentials, whitelists, reconciliation records, PoI chains, and STRX credit vaults. Provider data and operations are isolated from one another.

Mint and burn requests are checked against the provider's signed instruction, attestation hashes, replay controls, and configured supply rules before any on-chain transaction is constructed. Invalid operations are rejected before execution and returned with an explicit reason code.

Provider instructions are cryptographically signed. The engine verifies the signature, checks that the instruction belongs to the correct provider context, and rejects replayed or malformed requests before execution.

The Tokenisation Engine and PoI system are proprietary StrikeX infrastructure. Public verification is designed so that external verifiers do not need the engine source code: they can use published PoI records, on-chain anchors, and documented verification behaviour.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

STRX is the protocol token used to account for integrity work in the StrikeX Tokenisation Engine. Proof of Integrity activity consumes STRX and burns it, making integrity a measurable part of the tokenisation stack rather than an invisible operating cost.

Gas pays the blockchain network. STRX accounts for the integrity layer around the transaction. Using STRX keeps that layer separate from chain gas, avoids reliance on third-party stablecoin issuers, and ties integrity consumption directly to the StrikeX protocol.

Yes. Gas pays the underlying blockchain for transaction execution. STRX is consumed by the integrity layer that records and anchors material tokenisation events.

STRX costs are configured at the protocol level and can vary by provider, asset configuration, and operation type. The aim is to make the cost of producing integrity evidence proportionate to the activity being processed.

A credit vault is a provider-scoped STRX allocation used by the protocol to account for that provider's STRX consumption. Provider vaults are separate, so one provider's activity does not debit another provider's allocation.

No, StrikeX manages provider credit vaults at the infrastructure layer, so providers can use the tokenisation stack without operating STRX mechanics themselves.

Provider vaults can be StrikeX-managed, automatically topped up, or supported by an approved overage arrangement depending on the provider agreement. If all configured credit options were exhausted, the issue would be surfaced for operator action before integrity activity continued.

STRX used for Proof of Integrity is 100% burned. The burn amount linked to a PoI event is part of the public record.

Yes. Public verification can show the STRX burned for the relevant Proof of Integrity event alongside the commitment it relates to.

No. Public verification does not require holding STRX or paying a protocol fee.

StrikeX Technologies is a UK-based digital asset infrastructure company founded in 2021 and majority-owned by CMC Markets. StrikeX builds tokenisation, proof, verification, and DeFi infrastructure for digital assets.

CMC Markets (LSE: CMCX) first invested in StrikeX and later increased its holding to a majority 51% stake. CMC operates regulated trading and investing platforms across multiple jurisdictions, while StrikeX provides digital asset and tokenisation infrastructure within that strategic relationship.