RWA tokenization
Real-world assets, verifiably owned.
Permissioned security tokens with compliance enforced on-chain, escrowed issuance, and income that pays out to whoever held the shares when it was earned. Built to be audited, and documented before anyone asks.
N° 01Positioning
Compliance in the contract, not the interface
A tokenized real-world asset is a security in most jurisdictions. That single fact decides the architecture: eligibility cannot be a frontend check, because a frontend check is bypassed by a direct call, a DEX, or any integrator who reads your ABI.
So the restriction goes in the token's transfer hook, where every movement passes through it — mint, transfer and burn alike. A wallet that is not on the register cannot receive shares, and there is no path around it. Everything else in the system is downstream of that decision.
We build the on-chain half. The legal wrapper — the SPV that actually holds title, the offering exemption, the transfer agent — is counsel's work, and no amount of contract correctness substitutes for it. Any agency that tells you otherwise is selling you a problem.
N° 02The reference build
We built one before selling it
REChain is a tokenized real-estate system we built end to end: a permissioned ERC-20 with compliance enforced in _update, an identity registry recording country, accreditation, KYC expiry and sanctions status, a configurable rule engine, escrowed USDC issuance with a soft cap and refunds, and snapshot-based rent distribution.
It is deployed to Base Sepolia and readable by anyone. 131 tests, 98.3% line coverage, seven stateful invariants at 256 random sequences each, zero static-analysis findings at medium severity or above, with linting and Slither gating CI.
It has not been audited, and the site says so. That is the point of showing it: you can read what we claim, check it against a public chain, and judge the work before you commission any.
N° 03What we found
Eleven defects, in our own code
We put that build through an adversarial review whose job was to break it, and it did — eleven times. Sending shares to yourself counted as a new holder, so any investor could pin the holder tally to its regulatory cap and lock everyone else out of the raise. A cancelled raise burned the shares you originally bought rather than the ones you still held, so one ordinary transfer stranded your money in escrow permanently. Sweeping unclaimed rent closed the books but not the claim path, so a late claim was paid out of a different quarter's money.
Two of the eleven were introduced by the fix for another. That is the honest argument for reviewing a fix as adversarially as the code it repairs, and it is why every invariant we write is mutation-tested — we reintroduce the bug deliberately and confirm the right test fails.
We are telling you this because the alternative is an agency that has never found a bug in its own work, which means either the work is trivial or nobody looked.
N° 04Process
Four phases, fixed timeline
01
Structure
One to two weeks, alongside your counsel. Which exemption, which jurisdictions, which rules actually bind. This is a legal input to the code, not an engineering preference, and getting it after the build means rebuilding.
02
Contracts
The longest phase. Solidity, tests written alongside rather than after, invariants documented as they are discovered, static analysis from the first commit rather than the week before review.
03
Application
Wallet connection, the subscription flow, the issuer console, and the indexer behind the cap table. Permissioned tokens deliberately never enumerate holders, so that data has to be built rather than read.
04
Handover
Testnet deployment, verified source, the specification and threat model an audit firm asks for, and a role handover to your multisig that is verified on-chain rather than assumed.
N° 05Chain choice
The transaction shape decides the chain
Distributions are pull-based, which means every holder sends their own transaction to collect. On Ethereum L1 the gas to claim a quarter's income on a small position can exceed the income. That quietly kills the product, and it is decided at architecture time rather than fixed later.
We default to Base for that reason, and because it now enforces RWA token primitives — transfer policies, allow and block lists, role-gated mint and burn, supply caps — in the node rather than in bytecode, which is a migration path worth having.
Solana is a rewrite, not a port, and its RWA gravity is treasuries and private credit rather than permissioned property equity. We will say so rather than bill you for the rewrite.
N° 06What we do not do
The boundary, stated up front
We do not audit contracts. Preparing a codebase for review and reviewing it are different jobs, and doing both is a conflict of interest — the party that wrote the code is the worst party to sign off on it. We prepare, you commission an independent firm, we fix what they find.
We do not give legal or investment advice, form your SPV, or tell you which exemption to file under. We work alongside your counsel and treat their answer as the specification.
We do not deploy to mainnet on your behalf without an independent audit and a multisig holding the privileged roles. If that is not the plan, we are the wrong studio.
What we build
Every platform, covered.
Investment
Fixed scope. No drift.
From $45,000 — contracts, tests, and the documentation an audit firm asks for.
- Permissioned token with compliance enforced in the transfer hook
- Identity registry and configurable rule engine
- Documented invariants with stateful fuzz testing
- Static analysis and linting gating CI
- Written specification, threat model and role matrix
- Testnet deployment with verified source
- Role handover runbook for your multisig
- Fixed-scope proposal after the structuring phase
- 30-day defect warranty
Questions
The answers we give most often.
- Do we need a legal structure before you can start?
- You need one before you launch, and it is better to have the outline before we start. The token represents membership interests in an entity that holds the asset — without that wrapper it conveys nothing at all. We can build and demonstrate on a testnet while your counsel works, but the offering exemption determines the compliance configuration, so the code cannot be finished before that answer exists.
- Can you audit the contracts you write?
- No, and you should be wary of anyone who says yes. We prepare the codebase to the standard firms ask for — written specification, documented invariants, a role and trust matrix, a threat model, a known-issues list, high coverage, clean static analysis — and then you commission an independent reviewer. We fix what they find. Preparing and reviewing are separate jobs for a reason.
- What does an audit cost, and how long does it take?
- For a codebase around 900 lines expect roughly a five to six day review window plus two to three weeks of judging, fixes and the final report. Price it as low-end DeFi rather than a simple token: escrowed custody plus a distribution contract is not a $5,000 engagement. Firms quote against a frozen commit, which is why the preparation matters — an unfrozen repository or a missing specification gets billed back to you in review hours.
- Which token standard do you use?
- Usually an ERC-3643-shaped design: identity, rules and token as three separate contracts with enforcement in the transfer hook. Whether to implement ERC-3643 exactly is a real decision rather than a default. Tokeny's T-REX is the audited reference implementation and it is GPL-3.0, which is a licensing choice a commercial platform should make deliberately rather than inherit by accident.
- Can the issuer freeze or seize tokens?
- Yes, and for a regulated security that is a requirement rather than a flaw. A court can order a transfer, and an investor who loses a key still legally owns the asset — a cap table that cannot be corrected stops matching the register. We separate those powers rather than bundling them, so the key that can move someone's shares is not the same key that can mint, freeze, or pause, and each sits behind a different signing threshold.
- How do you handle income distribution to a changing holder set?
- By snapshot. Paying whoever holds the token on payout day is the obvious approach and it is wrong — someone who sold last week still earned last quarter's income, and a buyer should not receive income from a period they did not own. Each distribution pins a timestamp and reads entitlement from the token's balance history at that instant. Claims are pull-based, because the holder list is unbounded and a payout that iterates it can be bricked by its own success.
- Do you work with our existing developers?
- Often. The common split is that we own the contracts and the audit-readiness work while your team owns the application, or the reverse where you have blockchain people and need the indexer, API and cap-table layer built around them. We document to a standard that assumes someone else will maintain it.
Next step
Compliance retrofitted after launch means redeploying and migrating every holder.
Tell us the asset, the jurisdictions, and whether counsel is already engaged.