The token contract is the smallest part of the build. In the projects we deliver, on-chain code is usually 15–25% of the engineering effort. The rest is the machinery around it: investor onboarding, an identity and accreditation registry, subscription and payment handling, the compliance rules engine, reconciliation against an off-chain register, corporate actions, and reporting that an auditor will accept.
That ratio is the single most common estimation mistake we see. A team scopes "an ERC-3643 token and a dashboard", ships in two months, and then spends six more building the parts that make it usable by an actual issuer — because a security that cannot be subscribed to, reported on, or reconciled is not a product.
A working platform has seven moving pieces:
- Token contracts encoding the instrument and its transfer restrictions
- An identity registry mapping verified investors to wallet addresses
- A compliance module that evaluates every transfer before it settles
- An investor portal for onboarding, subscription, documents, and holdings
- An issuer/admin console for approvals, allocations, and corporate actions
- Integration with the transfer agent, fund administrator, and custodian
- Reporting and audit trails, on-chain and off
ERC-3643, ERC-1400, or a custom standard — which one fits?
ERC-3643 (T-REX) is the default answer for most permissioned instruments. It pairs an on-chain identity registry with a modular compliance contract, so eligibility lives in a separate, upgradable module rather than being hard-coded into the token. It has an active ecosystem and a maintained reference implementation, which matters when a custodian or a secondary venue has to integrate with you.
ERC-1400 and its partition model suit instruments with genuinely distinct tranches — different lock-ups, different rights, or different classes that must be tracked separately on the same token. Tooling around it is thinner than it was, so budget for writing more of the surrounding code yourself.
ERC-4626 is not a securities standard, but it is the right base when the tokenized thing is a yield-bearing pool with share accounting rather than a registered instrument. Vault share math is a solved problem; reimplementing it is how rounding bugs get shipped.
A custom standard is defensible when your transfer rules genuinely do not fit the above — but understand the cost: every integrator, custodian, and venue then has to write bespoke code against you, and each of those is a negotiation and a delay. We recommend custom only when it buys something specific, and we say so when it does not.
How does compliance get enforced on-chain instead of in a spreadsheet?
Every transfer passes through a compliance check before it settles. The token asks a rules module whether this sender, this receiver, this amount, at this moment, is permitted. If the answer is no, the transaction reverts — the non-compliant trade never happened, rather than being discovered in a reconciliation two weeks later.
The rules themselves are ordinary business logic, written against the structure your counsel defines: verified-identity checks on both sides, jurisdiction allow-lists, accreditation status with expiry, lock-up and holding-period windows, per-investor and per-jurisdiction holding caps, and investor-count limits where the exemption you are relying on imposes one.
Regulated issuers also need paths that crypto purists dislike: freezing an address, forcing a transfer, and reissuing to a new wallet. Courts order asset freezes and investors lose keys, and a platform with no answer to either is not deployable by a regulated entity. We build these as explicitly permissioned, fully logged operations, usually behind multi-signature approval, so the capability exists and every use of it is evidence.
We encode the rules; your counsel defines them. We work directly with your legal advisors during design and translate their structure into the contract and the orchestration layer — we do not offer legal advice on which exemption or wrapper you should be using.
What has to connect to your transfer agent, fund administrator, and custodian?
Most RWA work is integration, not greenfield. The issuer already has a register, an administrator calculating NAV, and a custodian holding assets. The platform has to fit that, not replace it.
Concretely: subscriptions and redemptions flow between the portal and the administrator; NAV updates arrive on a schedule and drive on-chain pricing where pricing is on-chain at all; distributions have to be computed against holders at a record date and paid through whichever rail actually moves the money; corporate actions — splits, conversions, redemptions in kind — need a defined on-chain representation.
The design decision that matters more than any of the plumbing is which system is authoritative. If the off-chain register is the legal record and the chain mirrors it, reconciliation failures resolve one way. If the chain is the register, they resolve the other. Platforms that never answer this question explicitly are the ones that end up with a cap table that two systems disagree about and no rule for which one wins.
On the identity and screening side we have shipped production integrations with SumSub for KYC and Chainalysis for transaction screening, plus MPC custody and institutional settlement rails in a live exchange environment — see the CoinPappa build below.
Which blockchain should a regulated issuer deploy on?
Network choice is a business decision constrained by your counterparties, not a technical preference. The binding question is almost never throughput — it is which chain your custodian supports, and which chains your investors' custodians support. A technically superior network that your custodian will not hold assets on is not an option.
Ethereum mainnet remains the default for instruments with low transfer frequency: the deepest custody support, the most mature tooling, and settlement costs that are irrelevant when a position moves a few times a year. L2s such as Arbitrum, Base, and Polygon make sense when the product involves frequent operations — but check custodian coverage before committing, because it lags the ecosystem by a wide margin.
Permissioned networks including Canton and Hyperledger are the right substrate when counterparties require privacy at the ledger level and are already participants. Purpose-built RWA networks such as Plume are worth evaluating when their ecosystem services genuinely shorten your build; we have deployed on Plume and can speak to what that actually saves and what it does not.
Multi-chain issuance with a single compliance layer is workable and increasingly requested. It is also a meaningful increase in scope — one identity registry, several deployments, and a rule for how supply is accounted across them.
How do you prove the token is actually backed by the off-chain asset?
Two different things get conflated here. Legal enforceability comes from the wrapper — the SPV, the trust, the fund structure, the contractual claim your counsel builds. The chain cannot create a right to an asset. What the chain does well is evidence: it makes supply, holders, and history publicly verifiable and hard to revise after the fact.
What we build on the evidence side: proof-of-reserve reporting on a defined cadence, oracle integration where an attestation needs to reach the contract, supply reconciliation that flags any divergence between on-chain tokens and the recorded backing, and immutable audit trails for issuance, redemption, and every administrative action.
The questions worth settling before writing code are who attests, how often, and what happens when an attestation is late or fails. An attestation pipeline with no defined failure behaviour reads as a control until the first time it breaks.
How long does an RWA platform take to build, and what does it cost?
A first production platform — one instrument, one jurisdiction, an established token standard, investor portal, compliance module, and a single administrator integration — is typically 3–4 months with a team of five to six engineers, in the $90K–$180K range.
A full multi-jurisdiction build with several instrument types, transfer-agent and fund-administrator integration, custodian connectivity, secondary-transfer support, and reporting an auditor will sign off on generally runs 6–9 months and $200K–$400K. Where a project lands inside that band is driven by how many external systems have to be integrated and how settled the legal structure is.
We quote fixed-price per milestone after a paid scoping phase, rather than an hourly estimate against a specification nobody has written yet. The scoping output is an architecture, an integration list, and a milestone plan you own regardless of whether we build it.
The most common cause of schedule slip on these projects is not engineering. It is legal structure that is still moving while the code is being written — transfer rules that change because the exemption changed. Freezing the compliance rules before implementation starts is worth more to your timeline than any technology choice.
What does Aegas bring to an RWA build?
We have delivered 100+ projects since 2017 with a senior-only team, and we work as an outsource partner rather than rented seats — we own architecture, delivery, QA, DevOps, and deployment end-to-end, and hand over a system your team can run without us.
The directly relevant experience is tokenization with legal-wrapper enforcement (iLicensing, KyivBrand), credit issuance and retirement with fiat escrow (WaterDAO), and exchange-grade KYC/KYT with MPC custody (CoinPappa). The adjacent experience that matters is operating high-volume production systems: Privex has processed $22B in platform volume across 8M trades.
What we are not: your counsel. We do not advise on which exemption, wrapper, or jurisdiction to use, and we will not pretend a technical control substitutes for a legal one. We encode the structure your lawyers design, and we tell you when something you have asked for will not hold up operationally.
