A production RWA tokenization stack is not one contract but a small system of them, each with one job: a factory that deploys a new token per asset, a funding contract that runs the raise, a compliance layer that enforces eligibility, and a distributor that pays holders.

Separating these concerns makes the system auditable, reusable, and safer - a flaw in one part is contained, and you can deploy a new deal without rewriting everything. This is the reference architecture we have found works for repeatable, compliant issuance.

Why separate contracts

Putting everything in one monolithic contract is tempting and wrong. It makes auditing harder, bugs more dangerous, and every new deal a bespoke rewrite. Splitting the system into focused smart contracts with clear responsibilities is the standard engineering move - and it matters more when real money and compliance are on the line.

The payoff is reuse: once each component is audited, you deploy new deals by configuration, not by writing fresh risky code each time.

The factory

A factory contract deploys a new, standardized token (and its related contracts) for each asset or SPV. Instead of hand-writing a contract per property, you call the factory with the deal's parameters and it produces a consistent, pre-audited token.

This is how issuers scale to many deals safely. Every token comes off the same proven template, so you audit the factory and the template once, not each deployment.

The funding and compliance layers

The funding contract runs the primary issuance: it accepts investor subscriptions, often holds funds in escrow until the raise closes, and then issues tokens to buyers. Holding funds until close protects investors if the raise fails.

The compliance layer - commonly an identity registry and rules module, as in ERC-3643 - enforces the whitelist and transfer restrictions across the system, so every token inherits the same eligibility and resale logic.

The distributor and treasury

A distributor contract pays income to holders - rent, interest - in proportion to their holdings, pulling amounts from a treasury the SPV controls. Separating this from the token keeps payouts auditable and lets you change distribution logic without touching the token itself.

In practice this is where a controlled account like an SPV admin treasury feeds the distributor, with oracle-confirmed amounts so payouts match real collected income.

Putting it together

The pieces connect into a pipeline: the factory mints the token, the funding contract raises and issues, the compliance layer governs who can hold and transfer, and the distributor pays holders over the life of the deal - with oracles feeding real-world values where needed. Each is independently audited and reusable across deals. If you are earlier in the stack, step back to token standards first, then return here for how the whole system fits.

Where to go next

• Back to the hub: RWA smart contracts and tech stack.
• The foundation: token standards.
• Glossary: SPV admin treasury.

Sources: rwa.xyz; token-standard specifications, as of 2026.