Solution
Tokenisation infrastructure that keeps on-chain and off-chain records aligned
We engineer the technology that represents real-world assets as tokens: the asset record, the permissioned token contracts, custody, investor onboarding and the reconciliation that binds the on-chain register to the off-chain facts.
The problem space
Tokenising a real-world asset means representing a claim on something that exists off-chain, such as a fund unit, a bond, a property interest or a receivable, as a token on a blockchain. The token is the easy part. The asset continues to live in the physical and legal world: it is valued, it pays income, it is held by a custodian, and the people permitted to own it are defined by rules that exist outside any contract. The infrastructure has to keep the token and that reality in agreement at all times.
This makes a tokenisation platform mostly an off-chain system with an on-chain register. The larger share of the engineering is in asset data management, investor identity and eligibility, the controls that restrict who can hold and transfer a token, the processing of distributions and redemptions, and the reconciliation and reporting that let an issuer, administrator and auditor trust the numbers. Smart contracts are a small, critical component within that.
This page describes engineering only. Starone makes no claim about the returns, value, legality or regulatory status of any tokenised asset or structure, and holds no licences in this area. The legal structuring of an offering, the rights a token confers and the regulatory treatment in each jurisdiction are the domain of the client and their legal counsel. We build systems designed to enforce and evidence the rules they define.
Why it is hard
Engineering challenges
Tokens that diverge from the asset
If the on-chain supply or holder register does not match the off-chain record of units issued and owned, the token no longer represents what it claims to. Divergence arises from failed mints, manual corrections made on one side only, and corporate actions applied inconsistently. It must be detected mechanically, not discovered in an audit.
Transfer restrictions enforced in the wrong place
A restriction checked only in a front-end or an off-chain service is bypassed by anyone who calls the contract directly. Eligibility rules have to be enforced by the token contract on every transfer. They also have to be updatable as an investor's status changes, without redeploying the token.
Investor identity linked to wallet addresses
The contract sees addresses; the rules concern verified people and entities. Binding the two requires an onboarding process, a secure registry and handling for lost keys, changed wallets and expired verification. Personal data must not be written to a public chain in the process.
Corporate actions at scale
Distributions, redemptions, splits and maturities must be calculated against the holder register as it stood at a precise record point and applied to every holder exactly once. Transfers continue while this happens. An off-by-one-block snapshot or a batch that fails midway produces payments that are difficult to unwind.
Upgradeable contracts and administrative power
Rules change and bugs are found, so contracts usually need an upgrade or administration path. That path is also the most sensitive control in the system: whoever holds it can alter balances or behaviour. It needs multi-party authorisation, time delays and transparent logging.
Dependence on off-chain data
Valuations, payment confirmations and custody attestations originate off-chain and are published to contracts or to investors. A wrong or stale value propagates into pricing, issuance and redemption. The sources, signing and update cadence of that data need the same rigour as the contracts themselves.
How we build it
Architecture
The platform pairs an off-chain system of record for assets, investors and cash with permissioned token contracts that act as the ownership register, joined by an orchestration layer and continuous reconciliation.
- 01
Asset registry and data service
Each asset is onboarded as a structured record: its identifiers, terms, supporting documents, valuation history and lifecycle state. Documents are stored off-chain with their cryptographic hashes anchored on-chain, so their integrity can be verified without publishing the content. Changes to an asset record go through an approval workflow and are versioned.
- 02
Permissioned token contracts
Tokens are implemented on established standards for permissioned assets, such as ERC-3643 or ERC-1400 on EVM networks, or their equivalents elsewhere. The contract consults a compliance module on every transfer and rejects any that breach the configured rules. Functions for mint, burn, freeze, forced transfer and pause exist where the client's legal structure requires them, each behind role-based access.
- 03
Identity registry and compliance rules
An on-chain registry maps wallet addresses to verified investor identities and attributes such as jurisdiction and investor category, storing references and claims without personal data. Compliance rules are modular contracts covering allow-lists, jurisdiction limits, holder caps and lock-up periods. Rules are configured per asset to reflect the terms the client and their counsel specify, and can be updated without replacing the token.
- 04
Investor onboarding service
An off-chain workflow collects investor information, integrates with identity verification and screening providers, and records eligibility decisions made under the client's policy. On approval it registers the investor's wallet in the identity registry. It handles re-verification, wallet replacement and revocation, and holds personal data in an encrypted store subject to access control and retention rules.
- 05
Custody and key management
Issuer and administrative keys are held in hardware security modules or split with multi-party computation and governed by multi-approver policy. Investor holdings can be self-custodied or held through an integrated custodian, depending on the design. Contract administration and upgrades sit behind a multisignature arrangement with a time lock, so changes are visible before they take effect.
- 06
Issuance, redemption and corporate actions engine
An orchestration service runs lifecycle operations as durable workflows. Subscriptions are matched to received funds before tokens are minted; redemptions burn tokens and trigger payment instructions. For distributions the engine takes a holder snapshot at a defined block, computes entitlements, and executes payments in idempotent batches that can be resumed after a failure.
- 07
Reconciliation and reporting
An indexer reads every token event and rebuilds the on-chain holder register, which is compared on a schedule with the off-chain register and with cash and custody records. Any difference is raised as an exception with an owner. Reporting produces holder registers, transaction histories and position statements for issuers, administrators and auditors, each traceable to on-chain events and source records.
Off-chain
- 01
Asset onboarding
Legal structure and documents
- 02
Investor KYC
Identity and eligibility checks
- 03
Asset registry
Record of ownership and rights
- 04
Reconciliation
Registry matched to chain state
- 05
Reporting
Statements, audit and disclosures
On-chain
- 01
Token issuance
Mint against the registered asset
- 02
Allowlist
Only verified wallets can hold
- 03
Transfer controls
Rules enforced in the contract
- 04
Settlement
Atomic transfer against payment
- 05
Lifecycle events
Distributions, redemption and burn
What an engagement delivers
- Asset data model and onboarding workflow
- Permissioned token and compliance contracts with test suite
- Identity registry and investor onboarding integration
- Custody design and contract administration controls
- Issuance, redemption and distribution workflows
- On-chain indexer and three-way reconciliation
- Issuer and administrator reporting, with audit support material
Before you start
Decisions to make early
- Public, permissioned or private chain
- A public network offers broad wallet and infrastructure support and independent verifiability, with transfer control enforced at the token level. A permissioned or private network gives control over participants, fees and data visibility, and limits interoperability. The choice depends on who must be able to hold and verify the asset, the privacy required and the expectations of the relevant regulator, which the client and their counsel should confirm.
- Which token standard to use
- Use an established permissioned-token standard in preference to a bespoke contract. Standards bring audited reference implementations and compatibility with custodians and tooling. Select on whether you need on-chain identity claims, partitioned balances for different share classes, or document management, and on what the intended custodians and venues support.
- Where the authoritative register lives
- Either the chain is the definitive ownership record and off-chain systems mirror it, or an off-chain register is definitive and the token reflects it. This is a legal determination with direct engineering consequences for how discrepancies and lost keys are resolved. The platform must implement whichever position the client's legal structure establishes and reconcile continuously in both cases.
- How much administrative control to build in
- Functions such as freeze, forced transfer and recovery are often required for regulated assets, to respond to court orders or lost keys. Each one is also a risk if misused. Include only those the legal structure calls for, place each behind multi-party approval, and log every use on-chain.
FAQ
Common questions
Does Starone advise on whether an asset can be tokenised?
No. Whether and how an asset can be tokenised, what rights the token carries and which regulations apply are legal questions for the client and their counsel. Starone engineers the infrastructure to implement the structure they define, and makes no statement about legality, regulatory status or investment merit.
Is investor personal data stored on the blockchain?
It should not be. The design keeps personal data in an encrypted off-chain store and places only wallet addresses, identity references and eligibility claims on-chain. This allows the contract to enforce rules without exposing who an investor is, and allows personal data to be corrected or deleted under applicable data-protection rules.
What happens if an investor loses access to their wallet?
Where the legal structure provides for it, the token contract includes a recovery function that moves the holding to a new verified address after the investor's identity is re-established. The operation requires multi-party approval and is recorded on-chain. The procedure and its preconditions are defined by the client.
Are the smart contracts audited?
Contracts are built on established standards and libraries and tested with unit, integration, fuzz and invariant tests. We recommend an independent external security audit before any contract that represents value is deployed, and again after material changes. Arranging the audit is part of the delivery plan.
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.