RWAs are having a moment.

Everyone suddenly wants to “tokenize assets” like it’s just another token deployment with more serious looking names attached to them.

It's not. An RWA system is:

• permissioned

• identity-aware

• compliance-heavy

• and very, very allergic to “just ship it” instincts that we've grown accustomed to

So let's try it. Let's build a demo tokenized stock using ERC-3643 — with identity, compliance, oracle-fed data, and a redemption path.

What you'll learn:

• How to restrict token transfers to verified investors only

• Why compliance needs to be modular (spoiler: regulations change)

• Why redemption can't be instant (spoiler: blockchains are synchronous, stock markets aren't)

• Where oracles fit (and where they don't)

What you won't learn:

• How to avoid securities regulations (you can't)

• How to launch this in production (you shouldn't, without serious infrastructure and security processes)

• How to get rich quick (wrong tutorial)

Let's go mah frens

---

Full disclosure: I built a fully functional version of this using Alpaca API for permissionless stock trading. It works elegantly. And I'm never shipping it publicly.

Why?

First of all, offering securities without proper licensing is a regulatory nightmare

"But it's decentralized!" is not a legal defense (ask the Luna folks), and Danki prefers devrelling over eating prison food.

Nevertheless, I still teach you the exact same architecture with mock infrastructure. You'll understand how ERC-3643 is implemented. We'll use commonly used compliance patterns. With real async redemption flow (because T+2 settlement is reality). We'll even use real oracle integration patterns.

The only difference is we'll have mock oracles instead of live API calls. When you're ready to go live (with proper licensing), you swap 50 lines of mock code for real API calls.

Oh, and a bonus: I'll show you how this applies to Philippine-based assets (PSE stocks, real estate tokens) where the regulatory path is clearer.

Before we build anything, let’s clean this up.

A synthetic RWA gives you exposure. A backed RWA gives you a claim.

If you back an RWA with something that lives onchain (eg. wBTC, ETH, USDC, LUNA), it's a synthetically backed asset. In synthetically backed RWA, you can't actually claim the asset, but you can claim the tokens backing the value that it represents.

If you're RWA is backed by the exact asset that it represents, then it's an asset-backed RWA. This type is enforceable, and should be redeemable. The downside is that it is reliant on oracles that brings your offchain data onchain.

For this tutorial, we’re modeling a backed RWA architecture.

That means:

• the token represents a claim

• the holder must be eligible

• transfers are restricted

• redemption exists

If any of those are missing… you already know

Before we touch code, we need to understand the moving parts.

┌─────────────────────────────────────────────────────────────┐
│  															                      StockToken                        											    │
│  											Main ERC20 token with identity and compliance integration 								│
└────────────┬────────────────────────────────────────────────┘
     						         │
		    ┌────────┴────────┬──────────────┬─────────────┐
		    │            									   │            						   	 │            						 │
  		    ▼             							       ▼           							▼          						    ▼
┌─────────┐   ┌──────────────┐  ┌─────────┐  ┌──────────────┐
│		Identity 		│   │ 			Compliance 	     │  │ 		Oracles	  │  │			 Redemption	     │
│		Registry		│   │			 (Modular)    	   	│  │        				 │  │ 			Manager  	         │
└─────────┘   └──────────────┘  └─────────┘  └──────────────┘

ERC-3643 is a suite, not a single contract.

At minimum, you’re working with:

• Token (StockToken) → the actual asset representation

• Identity Registry → who is allowed to hold

• Claim Topics Registry → what requirements exist (KYC, accreditation, etc.)

• Trusted Issuers Registry → who is allowed to verify users

• Compliance Contract → decides if transfers are allowed

Optional:

• Oracle contracts → price, reserves, events

• Redemption manager → where offchain meets reality

If your system is just:

mint( );
transfer( );

please close your laptop.

In ERC-3643 compliance means:

• wallets are mapped to identities who can carry claims

• claims come from trusted issuers

• compliance checks happen on every transfer

Which means:

your token doesn’t just care about balances
it cares about who is moving them

You don’t have “an oracle.” You have multiple.

For a tokenized stock, you might need:

• price oracle → “what is this stock worth?”

• reserve / attestation oracle → “is this actually backed?”

• compliance oracle → offchain KYC systems

• corporate actions oracle → dividends, splits, etc.

• settlement signal → redemption completed

Now, install your Foundry and Openzeppellin. They're our dependencies.

This will be our file structure:

/contracts
  /identity
  /compliance
  /oracle
  /redemption
  /token

/test
 	/integration 
	/unit

Map wallets to identity:

// src/identity/IdentityRegistry.sol
contract IdentityRegistry is AccessControl {
    bytes32 public constant AGENT_ROLE = keccak256("AGENT_ROLE");
   
    // Wallet → Identity contract mapping
    mapping(address => IIdentity) private _identities;
    mapping(address => uint16) private _investorCountry;
   
    function registerIdentity(
        address wallet,
        IIdentity identityContract,
        uint16 country
    ) external onlyRole(AGENT_ROLE) {
        require(wallet != address(0), "invalid wallet");
        require(address(identityContract) != address(0), "invalid identity");
        require(address(_identities[wallet]) == address(0), "already registered");
       
        _identities[wallet] = identityContract;
        _investorCountry[wallet] = country;
       
        emit IdentityRegistered(wallet, identityContract);
    }
   
    function isVerified(address wallet) external view returns (bool) {
        return address(_identities[wallet]) != address(0);
    }
   
    function deleteIdentity(address wallet) external onlyRole(AGENT_ROLE) {
        IIdentity oldIdentity = _identities[wallet];
        require(address(oldIdentity) != address(0), "not registered");
       
        delete _identities[wallet];
        delete _investorCountry[wallet];
       
        emit IdentityRemoved(wallet, oldIdentity);
    }
}

No identity = no participation

Some decisions I made:

1. Instead of storing KYC data on-chain (expensive, privacy nightmare), we store a reference to an identity contract. The identity contract holds claims issued by KYC providers.

2. Only authorized KYC providers can register identities. This isn't permissionless DeFi anymore.

3. I did a mock country tracking. Different countries have different rules. We need to know where investors are located.

What this does NOT do:

• Store KYC data

• Enforce transfer limits

• Check prices

We're all doing these somewhere else, because separation of concerns matters. I let each contract do one thing well.

Important note on identity:

The full ERC-3643 standard uses claims for verification:

interface IIdentity {
    function getClaim(bytes32 claimId) external view returns (
        uint256 topic,      // What type of claim (KYC, accreditation, etc.)
        uint256 scheme,     // Signature scheme
        address issuer,     // Who issued the claim
        bytes signature,    // Cryptographic proof
        bytes data,         // Claim data
        string uri          // Additional info
    );
}

And how it works in practice is:

1. User completes KYC with provider

2. Provider issues a claim (cryptographically signed)

3. Claim is stored in user's ONCHAINID contract

Token contract verifies claim before allowing transfers. Please don't skip this if you're using on prod. It's very important for future features because:

• KYC provider can revoke claims in case user gets sactioned

• Multiple providers can issue claims (no central provider)

• We have privacy-preserving considerations (claim data can be hashed)

  For this tutorial, we use simplified verification (just check if identity exists). Full claim verification can be added later without changing the architecture.

Different jurisdictions have different rules. Rules change over time. You can't hardcode compliance logic. So we'll have pluggable compliance modules

// src/compliance/ModularCompliance.sol
contract ModularCompliance is Ownable {
    IModule[] private _modules;
   
    function canTransfer(address from, address to, uint256 amount)
        external view returns (bool)
    {
        // Check ALL modules
        for (uint256 i = 0; i < _modules.length; i++) {
            if (!_modules[i].moduleCheck(from, to, amount, address(this))) {
                return false; // ANY module can reject
            }
        }
        return true; // ALL modules must approve
    }
   
    function transferred(address from, address to, uint256 amount)
        external onlyToken
    {
        // Notify ALL modules (for state updates)
        for (uint256 i = 0; i < _modules.length; i++) {
            _modules[i].moduleTransferAction(from, to, amount);
        }
    }
}

Notice we have two functions:

canTransfer() (view function): Pre-transfer validation. Returns true/false. No state changes.

transferred() (state-changing): Post-transfer state update. Modules update their internal state.

Why this pattern?

Because view functions can't change state. If modules need to track balances or daily limits, they need a separate function called AFTER the transfer succeeds.

This is the part that trips people up. Let me show you why it matters.

Here's an example module I created, Max Balance Limit (yor regular AMLA module):

// src/compliance/modules/MaxBalanceModule.sol
contract MaxBalanceModule is AbstractModule {
    uint256 public maxBalance;
   
    // Track balance per IDENTITY (not per wallet)
    mapping(address => uint256) public identityBalance;
   
    function moduleCheck(address /* from */, address to, uint256 amount, address /* compliance */)
        external view returns (bool)
    {
        address toIdentity = _getIdentity(to);
       
        // Check if receiver would exceed max balance
        if (identityBalance[toIdentity] + amount > maxBalance) {
            return false;
        }
       
        return true;
    }
   
    function moduleTransferAction(address from, address to, uint256 amount)
        external onlyBoundCompliance
    {
        address fromIdentity = _getIdentity(from);
        address toIdentity = _getIdentity(to);
       
        // Update balances
        if (from != address(0) && fromIdentity != address(0)) {
            identityBalance[fromIdentity] -= amount;
        }
       
        if (toIdentity != address(0)) {
            identityBalance[toIdentity] += amount;
        }
    }
}

Why track by identity, not wallet?

Because one person can have multiple wallets. If we track by wallet, they can bypass limits by using 10 different addresses.

And one more, here's a critical pitfall that will break your system:

Don't check sender balance in moduleCheck(). The module's internal balance is only updated AFTER the transfer. Checking sender balance in moduleCheck() creates a deadlock where transfers always fail.

// WRONG: This will always fail
function moduleCheck(address from, address to, uint256 amount) {
    address fromIdentity = _getIdentity(from);
   
    // This checks module's internal balance, which hasn't been updated yet!
    if (identityBalance[fromIdentity] < amount) {
        return false; // DEADLOCK MAH FREN
    }
   
    // ...
}

here's how to do it correctly:

// Token contract checks sender balance, module checks receiver limit
function moduleCheck(address /* from */, address to, uint256 amount) {
    address toIdentity = _getIdentity(to);
   
    // Only check receiver's limit
    if (identityBalance[toIdentity] + amount > maxBalance) {
        return false;
    }
   
    return true;
}

So you see, between the token and the modules, there is separation of functions:
Your Token contract: Validates sender has sufficient balance (ERC20 standard)

Your Compliance module: Validates business rules (receiver limits, daily caps, etc.)

Mix them up if you're having fun on test environments. But so far, this is what works.

Let's try another AMLA module

// src/compliance/modules/TransferLimitModule.sol
contract TransferLimitModule is AbstractModule {
    uint256 public dailyLimit;
   
    // identity => day => volume
    mapping(address => mapping(uint256 => uint256)) public dailyTransferVolume;
   
    function moduleCheck(address from, address /* to */, uint256 amount, address /* compliance */)
        external view returns (bool)
    {
        address fromIdentity = _getIdentity(from);
        uint256 today = block.timestamp / 1 days;
       
        uint256 currentVolume = dailyTransferVolume[fromIdentity][today];
       
        if (currentVolume + amount > dailyLimit) {
            return false;
        }
       
        return true;
    }
   
    function moduleTransferAction(address from, address /* to */, uint256 amount)
        external onlyBoundCompliance
    {
        address fromIdentity = _getIdentity(from);
        uint256 today = block.timestamp / 1 days;
       
        dailyTransferVolume[fromIdentity][today] += amount;
    }
}

Why daily limits?

• Prevents rapid liquidation (market manipulation)

• Complies with Reg D restrictions (limited resale)

• Detects suspicious activity (sudden large transfers = 🚨)

Auto-reset: Counters automatically reset when today changes (new day = new timestamp / 1 days).

We now have:

• a system that knows who is allowed to participate

• a compliance layer that enforces rules at transfer time

• and a clear separation between identity, policy, and token behavior

In Part 2, we’ll wire this system into the outside world:

• bring in oracle data

• implement token behavior that reflects regulatory constraints

• and design a redemption flow that doesn’t pretend blockchains can settle instantly

That's all for now. Danki will be egg hunting. I'll be back on Easter! 🐤🥚