Every RWA tokenization platform development project starts with the same pitch: take an illiquid asset - real estate, private credit, treasury bills, invoices - and represent ownership as a token that can be split, traded, and settled on-chain. The pitch is simple. The engineering is not, and the part that trips up most teams has nothing to do with smart contracts.

Minting a token is the easy ten percent. The hard ninety percent is everything the token has to represent honestly: who's legally allowed to hold it, what happens when a regulator asks you to freeze a wallet, how the token's value stays pinned to an asset that lives entirely off-chain, and what happens the day someone wants their money back instead of their token. Get any of these wrong, and you're looking at a compliance incident or a broken peg.

This is a walkthrough of the decisions that actually shape an RWA tokenization platform, based on the tradeoffs we've navigated building them.

Token Standard: Why ERC-20 Is the Wrong Default

The instinct on Ethereum is to reach for ERC-20. It's the standard every wallet, exchange, and DeFi protocol already understands, and for a purely fungible asset with no transfer restrictions, it would be fine. Real-world assets rarely fit that description.

A tokenized security has to enforce who can hold it: accredited investor status, jurisdictional restrictions, lock-up periods, sanctions screening, all checked at transfer time, not just at issuance. Plain ERC-20 has no hook for that. Every restriction ends up bolted on as an off-chain process the smart contract knows nothing about, so the contract will happily execute a transfer your compliance team would have blocked.

ERC-3643 (T-REX) builds identity and transfer restrictions into the token standard itself. Every holder address links to an on-chain identity claim, verified against a registry of eligible investors, and every transfer runs through a compliance module before it settles. The restriction lives in the same place as the token logic instead of in a separate system that has to stay in sync with it.

The tradeoff is complexity. An ERC-3643 deployment involves an identity registry, a claims topic registry, trusted issuers, and a compliance contract, versus a single contract for plain ERC-20. For a platform that will actually be regulated, that complexity is the feature. We've watched teams try to ship the simple version first and bolt compliance on later. It doesn't retrofit cleanly, because the whole point of the standard is enforcing restrictions at the transfer layer itself, where a bolted-on contract was never designed to check them.

Chain Selection: Settlement Cost Is a Business Requirement

For a security token settling a handful of times a day, Ethereum mainnet gas costs are a rounding error. For a tokenized payments rail or a platform issuing fractional shares to retail users making frequent small trades, they're the business model.

Stellar, through Soroban, runs typical token transfers for fractions of a cent with finality landing in roughly three to five seconds. That fee profile matters directly for platforms built around frequent, small-value transfers: tokenized remittances, fractional real estate with active secondary trading, stablecoin-denominated payment rails. Stellar also ships with SEP-8 (Regulated Assets), a protocol-level mechanism for authorization-required and authorization-revocable assets. That gives you transfer-restriction primitives at the account level, without building an entire compliance layer from scratch the way you would on EVM chains.

XRPL offers a comparable cost and speed profile, plus native freeze and authorization flags on issued currencies, no smart contract required for the basic compliance primitives. That's attractive for simpler asset structures where you need the standard set of freeze and authorize controls and nothing more elaborate.

Ethereum and its L2s remain the default when a platform needs the deepest liquidity and DeFi composability, where the tokenized asset has to plug into lending markets, DEXs, or custody infrastructure already built for the EVM. You pay for that ecosystem depth in gas costs and settlement latency, even on an L2.

The right answer depends on which cost and composability profile matches how the asset will actually be used. A tokenized treasury bill that settles a few times a week and needs to sit as collateral in existing DeFi protocols belongs on Ethereum or an L2. A tokenized real estate platform doing frequent fractional trades among retail holders fits Stellar's fee structure far better.

Identity and Compliance: On-Chain Claims, Off-Chain Verification

The compliance layer splits into two problems that get conflated more often than they should: verifying who someone is, and enforcing what they're allowed to do once you know.

Identity verification (KYC documents, accredited investor attestations, sanctions screening) doesn't belong on-chain. It involves personally identifiable information, it changes over time, and it needs to integrate with providers like Sumsub or Persona that were never built with blockchain in mind. That stays off-chain.

What goes on-chain is the claim itself. A trusted issuer, your KYC provider or a licensed verification partner, signs an attestation that a wallet address belongs to a verified, eligible holder, and that signed claim gets registered against the identity contract. The smart contract checks that claim without ever touching the documents behind it. This is the model both ERC-3643's identity registry and Stellar's SEP-8 authorization flags are built around: sensitive data stays off-chain, the yes/no answer sits on-chain where the transfer logic can actually use it.

The failure mode we've seen most often is teams trying to keep the on-chain and off-chain systems perfectly synchronized in real time. Don't. Design for eventual consistency instead: a claim gets issued or revoked, propagation to the chain happens within a defined window, and the transfer logic checks the claim's current state at the moment of transfer. A revoked claim should make the next transfer fail immediately, even if the revocation happened five minutes ago and the wallet hasn't tried to move funds since.

Custody and the Peg: Proving the Token Is Worth What It Says

A tokenized asset is a claim on something that lives off-chain: a bank account, a title deed, a basket of treasuries. The token is only as trustworthy as the mechanism proving that claim is real, and this is where a lot of platforms are quietly weaker than they look.

The minimum viable version is a proof-of-reserve attestation: a custodian or auditor periodically confirms the off-chain asset backing matches the on-chain supply, published as a signed message or a Merkle root anchored on-chain. That's better than nothing, but it's a snapshot. The gap between attestations is exactly where problems hide.

A stronger design reports backing data through an oracle network on a schedule, rather than relying entirely on periodic manual attestation. Chainlink's Proof of Reserve feeds are the most established example: a decentralized oracle network independently verifies custodial balances and pushes that data on-chain, where the token contract can check it directly and pause minting if reported reserves fall below circulating supply. Chainlink markets this specifically as "Secure Mint": the reserve check sits inside the mint function itself, so the contract simply refuses to mint past what's backed. That turns a manually reviewed attestation into a system with an automated circuit breaker.

For real estate or private credit, where the underlying asset doesn't have a real-time price feed the way a treasury bill does, full real-time proof of reserve isn't achievable, and platforms that claim otherwise are overselling it. What you can build instead is a published valuation methodology, an independent appraiser or administrator, and a defined cadence for updating the on-chain NAV. Being explicit about what's actually verifiable on-chain builds more trust than pretending an illiquid asset has a live price feed it doesn't have.

Redemption: The Feature Everyone Designs Last

Issuance gets the design attention. Redemption, turning the token back into cash or the underlying asset, usually gets bolted on afterward, and it's the part that determines whether holders trust the platform during stress.

The core design question is whether redemption is synchronous or queued. A tokenized money market fund backed by highly liquid treasuries can support near-instant redemption: burn the token, wire the cash, inside the settlement window of the underlying instrument. A tokenized real estate fund can't. Redemption has to queue against actual liquidity events: a property sale, a refinancing, a matching secondary buyer. The platform needs to be honest about that timeline instead of implying instant liquidity it can't deliver.

Getting this wrong cuts both ways. Overpromise liquidity the underlying asset can't support, and you end up with a run you can't honor. Underdeliver on a genuinely liquid asset and you're forcing unnecessary queuing on holders who didn't need it. The redemption mechanism should be sized to the actual liquidity profile of what's backing the token, decided at the architecture stage, not patched in after the first redemption request exposes the gap.

The chain constrains which compliance primitives are available natively. The token standard determines how deeply identity checks are embedded versus bolted on. The redemption design only works if the reserve verification underneath it is trustworthy enough for holders to believe the queue is real rather than a stall tactic. None of these decisions get made in isolation on a platform that actually survives contact with a regulator or a market downturn.

The tooling already exists: ERC-3643, SEP-8, Chainlink's Proof of Reserve. None of it is exotic anymore. What's still genuinely hard is choosing the right combination for the asset in front of you, and saying no to the shortcuts that look fine until the first redemption request or the first regulator inquiry arrives.

Rumble Fish has built tokenization infrastructure across Stellar, XRPL, and EVM chains, and spent enough time in the gap between "the token works" and "the token is defensible" to have opinions about it. If you're scoping an RWA tokenization platform and want to talk through the compliance and custody architecture before you commit to a chain or a standard, get in touch.