Validation
Mint and burn requests are validated against signed provider instructions, attestation hashes, replay controls, and configured supply rules before any on-chain transaction.
Tokenisation
Engine
Issue, manage, and reconcile tokenised assets with cryptographic proof at every step.
How It Works
The StrikeX Tokenisation Engine
Most tokenisation platforms stop at issuance. The Engine handles what comes after: validation against signed provider instructions, on-chain execution, and reconciliation against custody. Every step recorded against the chain.
Execution
Approved operations can be batched for gas efficiency and anchored on-chain with a Merkle root covering action metadata and provider attestations.
Reconciliation
On-chain supply is compared against committed provider attestation records. Mismatches are classified with explicit reason codes.
The Engine
Core capabilities
Under The Hood.
Economics
Learn about STRX
STRX Integrity Burn
Engine activity is metered. Every commit, every attestation, every reconciliation consumes STRX from a provider-scoped credit vault, which is then burned on-chain.
STRX is the economic cost of integrity. The more the Engine proves, the more it burns.
Merkle-Anchored Proofs
Batched operations are anchored on-chain with a single Merkle root. Individual operations can be proven against the anchored root without needing engine cooperation.
Pre-Execution Validation
Mint and burn requests are checked against signed provider instructions, attestation hashes, replay controls, and supply rules before execution.
Proof of Integrity Chain
Lifecycle events produce hash-linked PoI commits, creating a tamper-evident chain per provider anchored on-chain.
Continuous Reconciliation
On-chain supply is compared against committed provider attestation records. Mismatches are classified with reason codes and tracked to resolution.
Provider Isolation & Access Control
Provider contexts separate scoped tokens, whitelists, API credentials, address controls, reconciliation records, PoI chains, and STRX credit vaults.
FAQs
Tokenisation Engine
What is the StrikeX Tokenisation Engine?
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.
What types of assets can be tokenised?
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.
What blockchains does the engine support?
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.
What are the supply and custody invariants?
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.
What happens if a mint or burn request is invalid?
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.
How does the engine handle corporate actions?
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.
Can multiple providers use the engine simultaneously?
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.
How does pre-execution validation work?
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.
How does the engine authenticate provider instructions?
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.
Is the code open source?
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.