Blockchain Technology
An RWA tokenisation platform turns a legal and regulatory structure into running code: who can buy, how money is held, when tokens move, and what gets recorded. The hard part is not the blockchain. The hard part is making every one of those behaviours match a classification that was decided before a single contract was deployed.
Co-authored by Alessio Acco, CTO and Co-Founder at Arbit Technology, with Demis Buttigieg, Senior Legal Associate at A2CO.
This article looks at real world asset tokenisation from the platform side, as Arbit builds it. For the legal sequence that comes first, A2CO has published a companion guide on how to tokenise an asset in the EU.
The six layers of a tokenisation platform
A platform that issues regulated tokens is several systems working together. In Arbit’s architecture they fall into six layers:
| Layer | What it handles |
| Offer configuration | Asset details, token supply, offer dates, minimum cap, jurisdictions |
| Identity and eligibility | KYC, AML/CFT checks, investor declarations, whitelisting, wallet screening |
| Offer mechanics | The investor portal, purchases, escrow, refunds, release of proceeds |
| Token contract controls | Transfer rules, distributions, voting, freezing, minting and burning |
| Records | On-chain history, the off-chain register of verified holders, state changes |
| Operations | Monitoring, upgrades, integrations, and the token’s life until settlement |
Each layer is set by decisions made outside the platform, in the asset analysis and the legal classification. That dependency shapes everything below.
Technology offers options; compliance picks one
“The technological layer often opens many doors that are later chosen by the correct compliance setup,” says Alessio Acco. A smart contract can do far more than a regulated structure allows, so the platform’s job is to switch on only what the classification permits.
In practice, the effort sits upstream. Alessio’s experience is that working out the classification of the underlying asset under MiCA takes far more time than configuring the platform once that answer exists.
The configuration then differs sharply by token type. A token that passes economic benefit to holders needs distributions, escrow and holding-threshold logic. A token that gives a role, a right or access, with no revenue share, may need almost none of it.
Demis Buttigieg sees the dependency running both ways. “Regulation and technology need to work hand in hand,” he says. “There first needs to be a clear understanding of how the technology itself operates, including the blockchain being used and the functionality of the smart contracts involved.”
Identity, eligibility and wallet screening
Every investor on Arbit’s platform passes KYC and AML/CFT checks before they can buy. That means identity verification with facial recognition, and investors declare where their money comes from, what they do for a living and whether they hold, or are close to, a political role.
Issuers can narrow access further. Where an offer is meant only for certain individuals or legal entities, investors fill in an extra form or declaration, and the platform admits them through manual whitelisting.
The wallet gets its own due diligence. Registration asks for one address, and the platform can trace that address across the relevant blockchains for links to exchanges or projects that would rule the investor out.
Who is eligible in the first place is a legal question. Demis points out that it can turn on whether an investor is retail or professional, where they are based and how the token is classified, so the whitelist rules should come from that analysis and not from the platform’s defaults.
Offer mechanics: from portal to proceeds
The investor’s path through a token sale runs in a fixed order:
Inbound funds are handled mostly automatically. Moving the proceeds out is deliberately slower, because each release needs sign-off from the entities entitled to approve it.
| Stage | What happens on the platform |
| Discovery | The investor reads the offer documents and asset information in the portal |
| Registration | They register, complete KYC and are enabled to buy |
| Purchase | Once the offer opens, funds go into an escrow contract linked to the tokens being bought |
| Minimum cap | If the soft cap is not met, funds are returned and the project does not start |
| Close | The issuer closes the offer and tokens are distributed, either at purchase or at close, depending on the setup |
| Release | Proceeds move from escrow to the wallet of the asset owner or managing company |
Transfers after distribution are a setting, not a given. An issuer can lock them for a fixed period or allow them from day one. According to Alessio, early transferability can help a project’s marketing by creating a secondary market that draws in new investors.
The control set a regulated token needs
From Arbit’s backend, each function of the token can be turned on or off per project to suit its classification: restrictions on transfer, payouts to holders, voting, redemption, freezing of balances, and the creation or destruction of supply. Jurisdiction restrictions, extra identity checks and extra forms can be layered on, though not every project needs them.
For regulated projects, Alessio singles out these controls:
In Alessio’s view, the result reads much like the small print of a conventional financial product, with conditions that activate or switch off other conditions. Investors see most of this logic in the disclosures, and a few elements are shared with the regulator alone.
| Control | What it is for |
| Transfer eligibility | Only permitted holders can receive the token |
| Identity and whitelist integration | Eligibility decisions reach the contract automatically |
| Role-based access | Each administrative action is limited to the role that should perform it |
| Pause and emergency controls | The offer or transfers can be stopped if something goes wrong |
| Governance over new issuances | Supply changes follow an agreed process |
| Minting and burning controls | Supply cannot be created or destroyed outside that process |
| Credential recovery | A lost key does not mean lost holdings |
| Auditability | Audit results are transparent to those entitled to see them |
He also offers a comparison for why the order of work matters. Because a smart contract is set once and is hard to interrupt or change afterwards, “it reminds the robotics’ laws”. The rules have to be right before the machine starts, which is why an accurate compliance analysis comes first and an even more accurate setup follows.
Records: what the chain shows and what it does not
Every transfer sits on a public ledger and can be followed back to the issuing contract. The platform holds the matching off-chain view and can produce a full export of verified users, each with their wallet addresses and transaction history.
Changes of status are logged as well, such as a holder whose balance passes a level that entitles them to vote or to a higher payout rate.
A complete technical record still leaves legal questions open. Demis puts them plainly: “The key questions are who actually holds or controls the token, what legally constitutes the record of ownership, and what role any custodian plays.”
One design case needs settling early. Where the same asset is sold through conventional channels as well as on-chain, the issuer has to decide before issuance whether the two routes are alternatives or complements. A token might mirror an existing equity or debt instrument, or the issue might be divided, with one portion sold through each channel. Either way, the conventional offer documents should mention the tokenised route.
Transfers: the token moves, the rights follow verification
Technically, a token built on a widely used standard can move to any wallet or exchange that supports that standard, once any lock-up ends and if no transfer restriction applies. Exchange listing is the missing piece early in a token’s life, and it needs its own due diligence and classification under MiCA.
What does not move on its own is the holder’s entitlement. Voting rights and distributions go to holders who have completed KYC and met the issuer’s terms. A buyer on the secondary market owns the token straight away, but receives the benefits only once verified and whitelisted.
That has to be decided and disclosed at the start. Demis adds the legal side: “If secondary trading is contemplated, the analysis needs to go beyond the initial issuance.”
Running the platform after launch
Launch is the start of the operational work. Alessio’s list of what continues:
- Protocol monitoring. Base-layer protocols keep changing, and some variants are misused or attacked. Arbit stays on the most tested version so that an exploit in another variant cannot reach its tokens.
- Integrations. Secondary to security, but still part of the job.
- Lifecycle events. Settlement can come years later, or never, if the token is perpetual. It might mean repaying investors, exchanging tokens for shares, or selling the finished project.
The legal obligations run in parallel. “Ongoing compliance therefore needs to be considered as part of the structure from the outset,” Demis says.
Alessio is also realistic about the market. Tokenisation reaches a different kind of investor, so liquidity should not be assumed. The benefit he counts on is automation: ownership, distributions and compliance handled and tracked on-chain.
Choosing an RWA tokenisation platform: questions to ask
Drawing on these points, these are the questions Arbit would put to any tokenisation infrastructure provider, including itself:
- Can each function (transfers, distributions, voting, freezing, minting) be switched on or off to match the token’s classification?
- Does the platform run KYC, AML/CFT and wallet screening, and can the issuer add its own eligibility rules and whitelist manually?
- Does the offer flow support escrow, a minimum cap and automatic refunds?
- Are proceeds released only through an authorisation procedure?
- Can the full register of verified holders, addresses and transactions be exported?
- Are pause, emergency and credential-recovery controls in place?
- Which protocol versions does it run, and how are new variants assessed?
- Who acts as custodian? For a token under MiCA, Alessio’s view is that this must be an authorised crypto-asset service provider.
- Could the project move to another provider? Arbit designs for portability, so that no single interface or vendor holds the project in place.
Alessio’s three technical mistakes are the reverse of those questions: putting technology ahead of the numbers and the compliance analysis, treating a live contract as the end of the job, and depending on a platform the project cannot explain or leave.
Start with the analysis
Arbit’s platform is built for the stage after the structure is settled. If you are still deciding what the token is, start with the tokenisation readiness assessment, and read the four problems no smart contract can solve for the questions that come before code.
For the legal and regulatory side, A2CO’s guide covers how to tokenise an asset in the EU, from defining the rights to MiCA and MiFID II classification. When you are ready to build, see how Arbit approaches tokenisation.
