Real-world asset tokenization is one of the categories most-talked-about and least-shipped in Web3. The 2025 wave finally produced some real products — BlackRock’s BUIDL, Ondo, Maple, Centrifuge, Backed — and the architectural patterns that work in production are now visible.

We’ve worked with teams tokenizing fund interests, private credit, and real estate. This is the architecture we’d recommend for institutional RWA products in 2026, and the gotchas that show up only when you actually try to ship.

The split that matters

The most useful architectural lens: an RWA product is two systems duct-taped together. The on-chain system manages tokens, transfers, and compliance enforcement. The off-chain system manages the legal entity, custody of the underlying asset, and the operational machinery (NAV calculation, distributions, reporting). Most failures we’ve seen are at the seam where these two systems meet.

The on-chain part is the easier engineering problem. The off-chain part is the harder business and operations problem. Teams routinely overinvest in the first and underinvest in the second.

The on-chain layer: ERC-3643 and friends

For institutional-grade RWA tokens, ERC-3643 (formerly T-REX) has emerged as the de facto standard. It extends ERC-20 with two critical features: every transfer is gated by an on-chain compliance check, and every wallet has on-chain identity attestations.

The compliance check is the interesting bit. When a user tries to transfer 1,000 tokens to another wallet, the contract calls the compliance module: “is this transfer permitted?” The module evaluates the rules — sender’s KYC status, recipient’s KYC status, jurisdiction restrictions, holding period, total holdings caps — and returns a yes/no. If no, the transfer reverts.

This sounds restrictive and is. It’s also what regulators want. The compliance is enforced on-chain, atomically, with no possibility of an off-chain rule check getting bypassed.

The pattern looks like:

function transfer(address to, uint256 amount) public override returns (bool) {
    require(compliance.canTransfer(msg.sender, to, amount), "Not compliant");
    return super.transfer(to, amount);
}

The compliance contract is updateable (with multisig governance) so the rules can evolve as regulation changes. New jurisdictions can be added. New restrictions can be applied to specific token classes.

The complementary piece is the identity registry — an on-chain mapping from wallets to attestations. “This wallet belongs to a KYC’d US accredited investor as of 2026-03-15, signed by KYC provider X.” The compliance module reads from the registry. The registry is updated by the KYC providers as users go through verification.

ERC-3643 isn’t the only standard (ERC-1400, ERC-1404, custom designs all exist), but it’s the one with the most institutional adoption. We’d default to it for new builds.

The off-chain layer: where the complexity lives

The off-chain side of an RWA product is the part that sinks projects.

The token represents a claim on something — a fund interest, a piece of debt, a fraction of a real-world asset. That claim has to exist legally somewhere. For most institutional products, this means a special purpose vehicle (SPV) or a trust that owns the underlying asset, and the token represents a beneficial interest in the SPV.

Setting up an SPV in a friendly jurisdiction (Cayman, BVI, Liechtenstein, Switzerland) costs $20–80k upfront and $20–50k per year ongoing. Setting up in the US costs more and brings more regulatory overhead. Pick the jurisdiction with care; legal counsel should drive this choice.

Custody of the underlying

Where does the underlying asset actually live? For a tokenized fund, it lives in the fund’s custodian (BNY, State Street, Northern Trust). For tokenized real estate, it’s held by a property-managing entity. For tokenized debt, it’s serviced by a debt servicer.

The on-chain token is only as good as the legal claim it represents on the off-chain custodian. If the custodian goes bankrupt or refuses to honor the claim, the token is worthless. The token’s value depends on:

  • The legal robustness of the structure (lawyers).
  • The financial soundness of the custodian (counterparty due diligence).
  • The operational reliability of the link between on-chain state and off-chain state (your engineering).

For products with periodic NAV calculations (funds, especially), the NAV needs to flow from the off-chain calculation engine to the on-chain price oracle. The pattern: a trusted operator (or a multisig) signs the daily NAV; an on-chain contract verifies the signature and updates the price.

This is a centralization point. It’s also the only practical way to do it for products where the NAV is computed off-chain by an administrator. The mitigation is process: NAV calculation is auditable, signed by multiple parties, and published with delays for transparency.

For distributions (dividends, coupon payments), funds flow from the off-chain source to a distribution contract that allocates pro-rata to token holders. The distribution contract pulls a snapshot of token balances at a record date, allocates the inflow, and lets users claim. This is mostly straightforward; the gotcha is record-date snapshots in the presence of secondary trading. Pick a clear cutoff and document it.

Compliance is a continuing job, not a setup

Most teams treat compliance as a one-time integration: connect to a KYC provider, get users verified, ship. In production, compliance is a continuing operational job:

  • Periodic re-verification. KYC isn’t permanent. Users need to be re-verified every 1–2 years.
  • Sanctions monitoring. New names get added to OFAC lists. Existing users may become sanctioned. The compliance system needs to react.
  • Source-of-funds reviews. For larger transfers, you need to validate where the money came from.
  • Reporting obligations. Depending on the jurisdiction and product, you may have ongoing reporting to regulators (FATCA/CRS, AIFMD, etc.).
  • Suspicious activity reviews. Pattern detection for things that look like layering, wash trading, or other AML concerns.

Plan for a compliance officer headcount. For a serious RWA product, you’ll want someone dedicated to this within the first 12 months.

Liquidity is harder than tokenization

A tokenized asset that nobody trades is worse than the un-tokenized version. You’ve added complexity without unlocking liquidity. Most RWA tokens trade thinly because:

  • The pool of compliant counterparties is small. The token can only move between wallets the compliance module approves. That’s a small market.
  • The asset is genuinely illiquid in the underlying. Tokenizing a private credit fund doesn’t make the underlying credits more liquid.
  • Secondary market infrastructure isn’t yet in place at scale.

The patterns that are working for liquidity:

Dedicated venues. Permissioned DEXes (Securitize, Ondo, Backed) where compliance is enforced at the venue level. Pool of buyers and sellers all pre-vetted.

OTC desks. Over-the-counter markets with a compliance layer. Less price transparency, more flexibility on size.

Redemption from the issuer. The issuer offers periodic redemption windows where holders can redeem at NAV. This is the dominant liquidity mechanism for tokenized funds; “secondary trading” plays a smaller role.

For a new RWA product, expect that 90%+ of the volume in year one will go through redemption windows or directly with the issuer. Building for that flow is more important than building for a vibrant secondary market.

Where to start

If you’re scoping an RWA tokenization project:

  1. Lawyer first. The structure (jurisdiction, entity type, regulatory regime) is the foundation. Don’t write a line of code until this is settled.
  2. Pick the asset class carefully. Highly liquid assets (treasuries, money market funds) are easier; illiquid assets (real estate, private credit) are harder. Start with the easier end.
  3. Choose ERC-3643 or equivalent. Don’t roll your own compliant token standard.
  4. Plan for the off-chain ops. NAV calculation, custodian integration, compliance officer — these are real ongoing costs.
  5. Don’t over-build secondary trading. Start with primary issuance and redemption. Add secondary venues once volume justifies it.

If you’re scoping an RWA project and want a structured architecture review including the off-chain machinery, we run this exercise with institutional clients.