An ERC20 token is self-contained. Its value, behavior, and rules live entirely onchain.

RWAs don’t work like that. RWAs are actual legal claims represented by a token. It’s something that even I am still finding difficult to grasp as a cryptonative.

Because if it’s a legal claim, it means my system is no longer just smart contracts and math. It’s:

• smart contracts + regulation and documents

• da government

• data pipelines

• and physical and legal constraints i can’t just require() away

Which makes me wonder how come all these cryptonative people seem to know and promote RWA when I’m still grappling with the idea that not all asset ownership can be fully decentralized. 

It turns out, it’s because a lot of people aren’t actually thinking about RWAs in their full complexity.

They’re thinking about it like fractional NFTs… where you take an asset, split it into tokens, and assume ownership just magically works because it’s onchain.

A lot of the hot air around RWAs goes like this: “we tokenize the asset and split it into shares”

That works for NFTs where the asset is the token. But if you’re planning to have that token to represent an asset that lives in the physical space, that gets a little more complex, innit?

My chad,

• the asset you’re trying to trade onchain, exists outside the chain

• tokens merely represent and it can depeg if you didn’t do it right

• ownership depends on whether someone offchain actually honors it

So… the question should not be “how do i represent this asset”? That is the easy part. The question is,  “What happens when I redeem this token?” and the answer should never be “There’s no path to convert it to its tangible version”

A tokenized RWA should always (and at all times) map the token to a real, enforceable claim. And we’re not done yet, there should always be a path to execute that obligation. Otherwise… you didn’t build an RWA. You built a token with really convincing, but false marketing.

Ok, let’s go back to dankying with code. 

This is where standards like ERC-3643 come in.

First of all, it’s not another NFT standard. You can actually use it alongside other core token standards.

It’s basically a way to introduce constraints that regular tokens don’t have. 3643 is useful when:

1. you can’t let just anyone hold the token

2. you need customized control over its circulation

3. you need identity, compliance, and restrictions baked into their transfers

And to hold those conditions true, you need an identity registry for that.

So your token now needs to care who you are and to whom you are transferring it to. Which  sounds so not cypherpunk… but who says cypherpunk technologies are only for us weirdos at the edges. They can do wonders in making traditional systems more efficient and secure too.

That doesn’t contradict the self-sovereign internet we’re building toward. If anything, this is how we get there.

Blockchains are deterministic. It’s incredibly good at verifying and enforcing rules on things that live inside them. Deploy a contract and the chain enforces it predictably, and everyone agrees on account balances, signatures, and state transitions. 

But what happens if your application needs info that doesn’t live inside the chain?

Your contract cannot tell if that building actually exists. It cannot confirm whether gold is sitting in a vault somewhere. It has no idea if a security is legally enforceable or if the issuer just decided to disappear one day. And to make things more complicated, it cannot limit the trading of these assets to only eligible entities if their identities are not verifiable onchain.

So RWAs end up depending on things that feel… uncomfortable for cryptonatives like Danki.

Because that means we’re going to rely on custodians to hold assets, oracles to report state, attestations to bridge user information, and legal agreements to actually enforce ownership. Suddenly, you’re not designing a trustless system anymore.

You’re designing a system that has a lot of trust assumptions. This is where I personally think regulators need to enter, not as a complication in the story, but as part of the design.

If you’re building RWAs seriously, you will run into:

• KYC / AML requirements

• jurisdiction restrictions

• transfer limitations

• licensing questions

And as an engineer, you will need help too. Let’s say Danki haz built the cleanest, most beautiful RWA smart contract ever. But my proof of reserve connects to a spreadsheet that manually updates every week

Or my oracle is an API that I just vibecoded with Claude

Or my token transfer requirements verify somebody’s eligibility through a digital pinkyswear.

My point being… the system is only as strong as its weakest offchain assumption. 

There are problems you cannot solve as a dev. It’s sometimes wise to work with institutions to minimize these risks. 

There’s also this instinct a lot of devs have: “we’ll deal with offchain integrations later.”

No, you won’t

Because by the time you’re thinking about integrations, you’ve already made design decisions that either support it or break it entirely. Who can hold the token, who can transfer it, where it’s allowed to move, how redemption works... These aren’t things you can easily undo for a token.

You don’t bolt compliance on top of an RWA system. By the time you deploy, whether it’s a purely onchain thing or not is already embedded into its logic. And pretending regulation doesn’t exist for your underlying asset doesn’t make your system more aligned with crypto ideals. It just means you’re launching a fractional memecoin, for the time being 😏

This is a personal opinion.

If we want our onchain systems to mature, I’m all for testing out where it can help with coordination, verifiability, and transparency. Not just inside our own ecosystems, but in places where things already matter.

I will support it for as long as it’s fair to the user’s right to privacy and digital autonomy.  

We’re already sitting on a $2.27 trillion onchain economy.

And the more it grows, the closer we get to financial systems that aren’t just parallel experiments but real, interconnected economies. Systems that can be audited, composed, and reasoned about in ways traditional infrastructure struggles to match. RWAs are one of the paths that push us in that direction.

With RWA, you’re no longer just a smart contract dev.

You’re designing financial infrastructure and trust models that extend beyond the chain. And we need more of that.

In the next 2 posts, we’re going to stop talking about ideas and actually build. 

Danki will walk you through:

• what “asset-backed” really means

• the core components of the ERC-3643 RWA standard

• let’s tokenize a security! (for educational purposes only)