Tokenised ownership that still agrees with the legal record.
A token is a claim about who owns what. The engineering is keeping that claim reconciled with the register a court would actually look at, and enforcing eligibility at the moment of transfer rather than in a quarterly review.
Why tokenisation projects fail their first audit.
The token is rarely the problem. What fails is the relationship between the token and the records it is supposed to represent, and that failure is usually invisible until someone reconciles.
The token and the legal record silently diverge
Two systems of truth will drift. Both sides event-sourced and reconciled on a schedule turns a divergence into a blocking exception that pauses issuance, instead of a discrepancy nobody sees until audit.
Eligibility is dynamic but the contract is immutable
Accreditation lapses, sanctions lists change, jurisdictions move. The contract should hold no investor data at all — it calls an eligibility registry at transfer time, so a status change takes effect immediately with nothing redeployed.
Distribution maths cannot be reproduced
A waterfall recomputed next quarter must produce the same number to the cent. Fixed-point arithmetic with the full input set snapshotted makes re-running a historical distribution byte-identical rather than approximately right.
Jurisdiction rules differ per asset class and change without notice
Rules encoded in application logic cannot be reviewed by the people responsible for them. Declarative, versioned rules per jurisdiction and class let a change trigger a re-sweep of affected holders and gate transfers that no longer pass.
Auditors need to reconstruct a position at an arbitrary past date
Nothing can be updated in place. An append-only ownership ledger means any historical cap table is a replay rather than a reconstruction argued from backups.
Recovery and forced transfers were never designed
Real registries need to handle a lost key, a court order or a mistaken allocation. Those paths belong in the design with their authorisation rules explicit, not bolted on once the situation arises.
How we build one.
The separation between the token and the registry is the whole architecture. Eligibility changes constantly; contracts should not.
- 01
Permissioned token
Eligibility-gated transfers and forced-transfer controls, holding no investor data of its own.
- Solidity
- ERC-1400 patterns
- 02
Compliance registry
KYC and KYB orchestration, accreditation state, jurisdiction rules and sanctions screening, called at transfer time.
- Declarative rules
- Versioned policy
- 03
Registry core
Asset records, an append-only ownership ledger, valuation history and scheduled reconciliation against chain state.
- Event sourcing
- Append-only ledger
- 04
Issuance engine
Supply configuration, lockups, vesting schedules and distribution waterfalls computed on fixed-point decimals.
- Fixed-point maths
- Snapshotted inputs
- 05
Indexing
Event indexing for cap-table reconstruction and auditor lineage, so any past state is replayable.
- Reorg-safe indexing
- Cap-table replay
- 06
Issuer console
Registry management, issuance configuration, distribution runs and the reporting an administrator actually needs.
- Next.js
- Audit log
We have already built this.
ATLAS RWA is our asset registry: a permissioned token whose transfers are gated by a compliance registry held deliberately outside the contract, an append-only ownership ledger reconciled against chain state, and distribution waterfalls that reproduce to the cent. It is a MaatX demonstration rather than a client deployment, and the mechanisms above are running in it.
Questions we get asked.
Can you handle the regulatory and legal side?
No, and that boundary is important. Your counsel defines what the rules are; we make those rules enforceable, versioned and auditable in software. Anyone offering both is selling you something they cannot stand behind — the engineering question is how a rule is enforced at transfer time, not whether it is the right rule.
Which token standard do you use?
Permissioned transfer patterns in the ERC-1400 family for EVM chains, but the standard matters less than where the eligibility logic lives. Keeping investor state out of the contract and in a registry it queries is what lets compliance change without a redeployment, and that choice outlasts any particular standard.
Can a transfer be blocked after the token is issued?
Yes, and it has to be. Eligibility is evaluated at transfer time against live investor status, so a lapsed accreditation blocks a transfer at the moment it is attempted rather than surfacing in a later review.
What does an engagement look like?
Discovery and Architecture first, almost always. The reconciliation model and the boundary between contract and registry are the two decisions that are expensive to reverse, and both should be settled before anything is deployed.
What it costs, and what you are agreeing to.
The commercial answers in one place, so none of them has to wait for a call.
Typical route in
Blockchain Engineering
Typically $25,000–120,000
Scoped per system
The contract is one layer of eight. Most of what decides whether an on-chain system survives production lives in the indexing, the risk model and the reconciliation.
A starting point for the scope described, not an estimate for your project. Ongoing engineering runs at $75 per hour blended.
Who owns what you build?
You do. On full payment of the fees for an engagement, the intellectual property in everything built specifically for you is assigned to you.
Our pre-existing tools, libraries and internal infrastructure stay ours — but where a deliverable uses them, you get a perpetual, worldwide licence to run, modify and extend it. Nothing we hand over needs us to keep operating it. Open-source and third-party components keep their own licences, and we tell you which ones and what they require.
We also will not name you as a client, describe your project, or publish a case study about it without your written agreement.
What happens if it does not work out?
Either of us can end an engagement with 30 days written notice, or immediately if the other commits a material breach and does not remedy it within 15 days. You pay for work properly performed up to that point, and we hand over completed work along with every deliverable you have paid for.
Two limits worth stating before you ask. We are engineers, not advisers: nothing we deliver is legal, regulatory, tax or financial advice, and a system built to your specification is not an opinion that it is lawful in your jurisdiction. And where our work includes reviewing or auditing code, the findings cover the scope and time agreed — an absence of findings is not a guarantee that nothing is there.
What do you need from me to start?
Not a specification. Discovery exists precisely because most people do not have one — an idea, or a technical problem you cannot yet size, is enough to begin.
What the work does assume: timely access to the people, systems, credentials and environments it touches; decisions and approvals at roughly the pace the timeline assumes, since delays on your side move both dates and cost; and that you have the right to give us whatever you give us, including data, code and third-party material.
Why you rather than the alternative?
Against hiring a senior engineer in-house: sourcing one takes months and commits you permanently. Discovery runs 1–3 weeks, and you keep the architecture whichever way you then go — including if the answer is to make that hire.
Against the cheapest contractor available: you will pay less per hour. Our argument is that the architecture decision is the one that is expensive to reverse, which is why we sell it first, separately, and at a price you can say yes to before committing to a build.
Against a larger firm: there is no account layer. The people who scope the work are the people who build it.
And when not to hire us: if a no-code or off-the-shelf tool still fits what you are doing, stay on it. We are worth paying once you have hit a ceiling you cannot engineer around from where you are.
These are summaries. The binding version of the ownership, exit and liability terms is in our Terms of Service. A person reads every enquiry. We usually reply within a few hours.
Start a technical assessment
Tokenizing real assets where the on-chain record has to reconcile to the legal one?
Send us the architecture or the problem. We will come back with the technical risks we can see and a sensible path forward, free, and tell you if we are not the right people for it.