Alex Kelly: Before standards like ERC-3643 existed, what typically went wrong when institutions tried to bring regulated assets on-chain?

Dennis O’Connell: I started my blockchain asset journey at Bank of America Merrill Lynch, working on a collateral tracking use case with R3 Corda. Back then, it became apparent that there were immediate issues, and many of those issues continue today.

The three key pivot points are identity, functionality, and data.

Identity means understanding which off-chain actor maps to which on-chain participant. It often gets overlooked, but it is a huge part of the solution and a major reason for the success ERC-3643 has had.

Functionality means the ability to overlay control mechanisms around the token and around the shared view of the ledger. It is not enough to have an account with a token balance.

The third is data and privacy: who can see the data, how fresh it is, how complex it can be, and how it can be brought onto a ledger at scale.

These three throughlines have challenged institutions for almost ten years, and institutions are now coming around to them as key requirements for tokenized assets.

Alex Kelly: For anyone new to the space who doesn’t understand what ERC-3643 actually enforces, how does on-chain ID fit into that framework, and what has adoption taught you so far?

Michael Steuer: It is fundamental. In ERC-3643, every actor around the architecture acts through a decentralized identity. Even the token itself has its own decentralized identity.

That identity layer creates a mechanism to store cryptographic claims, which can include KYC, accreditation, credit score, country code, or other eligibility requirements. It also allows different wallet addresses to be added to the same decentralized identity, which enables recovery, migration, and protection against lost or stolen wallets.

Then there is the registry layer, where different roles and claim permissions are delegated. This matters for asset owners, administrators, observers, and token holders.

When a transaction occurs, enforcement deeply integrates with on-chain ID. In the registry, on-chain ID is mapped to the user wallet and country code. But identity alone is not enough. Dynamic compliance rules are the second layer.

The on-chain ID is like your real-world wallet, with your IDs and credit cards. If you lose your driver’s license, you should not lose your citizenship. And if you show ID to enter a building, that does not mean you can open every door or go to every floor. That is where compliance rules come in.

The two work hand in hand: compliance rules and identity create the full framework around control and compliance.

Alex Kelly: Casper joined the ERC-3643 Association in 2025. Your latest Manifest puts compliant RWAs front and center. From a chain point of view, why is on-chain compliance so hard to get right, and why did Casper lean into it?

Michael Steuer: On-chain compliance is hard because most chains confuse “code is law” with “law is law.”

You write the code once. Regulation is a living obligation that changes by asset, investor type, jurisdiction, and over time. The moment you tokenize a real security, you inherit obligations that the chain itself usually cannot honor.

You need to freeze a bad actor, force a transfer under a court order, recover a lost key, patch a bug, restrict who can hold the asset, and do all that without leaking everyone’s identity to the public ledger.

Most chains are not designed for this. Contracts are immutable, so you cannot fix or comply. Finality is probabilistic, so settlement can technically reverse, which is a non-starter for regulators and issuers in many cases. Permissionless by default fights everything compliance needs.

So teams bolt compliance onto the app layer, where it can be bypassable and buggy, and call it solved. We believe it is not.

Casper leaned in because we were built for this from day one. Since 2018, we have had upgradable smart contracts natively, so you can freeze, force transfer, fix, and comply. We have deterministic finality, meaning settlement is final, with no forks and no reversals.

If you are an asset owner or issuer trying to transfer a billion-dollar asset, you do not want to wait for 64 confirmations to know whether it went through.

We also have native account permissions and key recovery, so a lost key is not lost security. Joining the ERC-3643 Association means Casper speaks the institutional standard for permissioned tokens, identity, transfer restrictions, and compliance primitives without reinventing it.

Alex Kelly: We have compliant ERC-3643 assets on-chain, but that is a single-chain view. Interoperability and multiple chains are inevitable. Compliance is built into the token, so why does it break when an asset moves to another chain, and what can be done to solve this?

Joachim Lebrun: The critical point is that when compliance rules are tied to a specific smart contract on a specific chain, they live in that chain’s storage. ERC-3643 has worked for six or seven years and has been used to tokenize a lot of assets, but the future is moving toward more chains.

Every exchange and big financial institution is launching its own chain. Thinking everything will happen on one chain is no longer realistic.

When an asset is bridged to another chain, most bridges only move the balance value of the token. They do not move the full compliance context: the ERC-3643 compliance contracts, identity contracts, on-chain ID, and eligibility rules.

That is what T-REX is looking to solve. We want to create a reference ledger for ERC-3643 assets, where the identities, compliance rules, and eligibility rules live. Assets can then be distributed to other chains while still consuming compliance validation from the T-REX chain.

Whenever a transaction needs to happen on another chain, it first requests a check on T-REX to see if everything is compliant with the ERC-3643 standard. Then that validation can be consumed on the other chain.

The idea is to unleash these assets on all chains in a compliant way. That last part is the most important.

We are building on top of standards, including ERC-3643 and ERC-7579, for account abstraction modules. We also have Apex Group as a major anchor partner, committed to bringing $100 billion of assets onto this chain in the next year, with the intent to tokenize even more in the coming years.

Alex Kelly: Casper isn’t built on the same technology as Ethereum. It has built its own ERC-3643 equivalent natively. Why take that on?

Michael Steuer: When we founded Casper in 2018, we looked at the original Ethereum Foundation work on the Casper proof-of-stake protocol. Ethereum had started that work years earlier, but it was clear the move from proof of work to proof of stake would take much longer. The merge ended up happening about five years later.

With ERC-3643, we see something similar. There are gaps that institutions and the market need addressed faster than the EVM ecosystem can potentially bring to market.

Take instant finality. Once a transaction is included in a block on Casper, it is final. When you are transacting in very large amounts, you do not want a Schrödinger’s transaction where ownership is unclear for several minutes. You want to know that once the transaction is sent, it no longer belongs to the seller and now belongs to the buyer.

Casper offers this today. On Ethereum’s roadmap, single-block finality is still years out, which is a long time given the growth expected in tokenization.

Quantum safety is another example. Large institutions are already reading the same reports everyone else is reading. Casper already supports multiple key algorithms on mainnet and can add more. As part of the Manifest roadmap, we are adding quantum-safe cryptographic keys and a transition path for existing account holders.

Account abstraction and smart accounts are also things Casper solved years ago. So a lot of what institutions need in the future is something Casper can bring to the table today.

That is why we built ERC-3643 natively on Casper: because we think we can move things forward faster, and in many cases better, than the alternative.

Alex Kelly: You are also building a full EVM engine alongside your existing setup, basically allowing Ethereum tools and contracts to work on Casper directly. What does that mean for an institution or developer who is looking at building on Casper?

Michael Steuer: Casper, as a Layer 1, is not an EVM chain. Our native execution environment is WebAssembly-based. The primary language is Rust, but developers can use anything that compiles to WebAssembly.

Since Casper 2.0, we have been a multi-VM environment, meaning we can support multiple execution environments on the same Layer 1. They are not added as Layer 2s or rollups. Each VM and execution environment is a full equal citizen on the blockchain.

We are adding EVM mainly for developer accessibility. There is a large EVM developer base, and we believe Casper has a lot to offer them that they cannot always find in other ecosystems.

Native EVM execution means developers can bring over OpenZeppelin-audited contracts, launch them on Casper, and benefit from instant finality and other Casper features.

We are also building a native token registry on Layer 1. Fungible tokens, including ERC-3643 tokens, become first-class citizens rather than being walled into the contract layer. That enables fixed costs for many operations, rather than costs based on congestion or contract complexity.

It also opens up native hooks. From a compliance perspective, you can hook in pre-transfer and settlement checks that handle much of the compliance inherent to ERC-3643.

Dennis O’Connell: I really love what Casper is doing, and I am a huge fan of it.

Solidity, in my view, is a challenged language. It was built for a specific purpose and was never envisioned for heavy compute or general institutional application complexity. It was always more of a cryptographic state machine than a general application layer.

When I took over the presidency of ERC-3643, one of the things I mentioned to the team was that we needed to embrace different native implementations. Even though the association is around the ERC proposal, the real meat of the standard is functional. It is about interfaces, rules, and control mechanisms.

Every non-EVM language has a different approach, with different strengths and weaknesses. As an application-layer standard, you are also at the mercy of the protocol underneath. When people ask what happens if a wallet gets hacked, if there is a fork, or if there is MEV, those are protocol-level questions.

That is why I have been a big fan of diversity of implementation. Casper has absolutely led the way in developing a non-EVM version of ERC-3643.

ERC-3643 is already on its sixth generation of updates and iterations. A lot has changed since the first snapshot. We want to come to ecosystems with open hands and make sure the standard can be implemented natively.

We do not want ERC-3643 to exist only on contrived EVM Layer 2s. We want it as deep in the protocol as possible, because that helps the protocol, the ecosystem, and interoperability.

Ultimately, ERC-3643 is a standard, a series of functions and rules, and a paradigm approach to control. It is not one specific implementation.

Alex Kelly: Once you have the same standard living on both Ethereum or Casper or some other non-EVM protocol, how does the ledger keep the compliance rules identical across chains? The asset needs to behave the same way wherever it sits, so how are you solving that problem?

Joachim Lebrun: That comes back to identity.

The whole standard is identity-centric. Whether you use one wallet or another to interact with the tokens does not matter, as long as your wallet is linked to an identity contract.

On the T-REX ledger, we can track the compliance state for that specific investor and make sure the transaction is compliant based on who the sender is, who the recipient is, the amount, and the compliance rules for that specific asset.

Each investor will have an identity, and then they can have as many wallets as they want. Investors can whitelist wallets themselves instead of asking the issuer or agent to add every new wallet.

That is much better than classic wallet whitelisting. The checks are done at the identity level, not the wallet level.

We are also going to use ERC-7930 for wallet representation across chains and different key types, including WebAuthn keys. That means we can link different wallets, whether Solana, Stellar, Ripple, Canton, or others, to an on-chain identity on T-REX and process compliance based on that identity.

Michael Steuer: We support multiple key algorithms for our wallets and accounts. Currently, we support Ed25519 and Secp256k1, which should be standard to integrate. We are also planning to integrate quantum-safe algorithms over the next year.

Alex Kelly: With ERC-3643, the T-REX ledger, and Casper underneath, what can an institution do with all three that they couldn’t do before?

Dennis O’Connell: There are two layers.

First is issuance. Institutions can now issue permissioned RWAs and digital securities with a standard that has been battle-tested by institutions. When issuers go to regulators, including the SEC in the U.S., they can point to a standard that is known and named. The path has been lit for them.

They can enable interoperability and allow participants from other chains to come onto Casper Network.

But the better part is what happens after issuance. The ERC-3643 ecosystem includes projects like T-REX and Ascend. Ascend is an on-chain tri-party credit lending facility that enables collateralization under a tri-party model at scale.

If you have a permissioned RWA or digital security minted on Casper using the standard, you inherit the benefits of identity, control, and compliance. That asset can then become high-quality collateral, because you can see the state of the asset and the ownership registry.

This enables more complex lending, repo-like structures, orderly defaults, unwinds, and orchestration. It unlocks liquidity and creates a bridge into DeFi.

We are around $80 billion in assets, and we see nearly $220 billion in assets being issued using the standard by this time next year, at the very least. All those assets being issued need to do something on-chain, whether through T-REX, Ascend’s liquidity engine, or Casper’s native support.

Joachim Lebrun: To unlock this liquidity and bring tokenization on-chain, we need standardization.

If every actor builds in silos and reinvents the wheel, this revolution will not happen by itself. ERC-3643 is open source, has always been open source, and will always be open source.

The value is not in creating a new standard. The value is in bringing good assets on-chain.

We are improving the standard and increasing its reach through the T-REX cross-chain system, while keeping the same interfaces. It will still work the same way as ERC-3643.

It is important to build on standards. The telecom industry works today because it was built on standards. Otherwise, every country would have had its own system, and interaction would have been complicated.

That is the point: standardize and bring this revolution into action.

Michael Steuer: Standardization is key, and telecom is a great example.

Dennis and the Foundation are defining what you can do with this. Joachim and T-REX are working on standardization and interoperability, making sure it works everywhere. Casper is looking to be the how you do this, or at least the how you do this best.

We want to be a reference implementation of what this can be when a Layer 1 protocol supports the required primitives natively, rather than bolting them on afterward.

Casper has those building blocks natively: instant finality, upgradable contracts, built-in access controls, native multisig, multiple key algorithms, account abstraction, native token registry with compliance hooks, gasless transactions, and transaction privacy.

Transaction privacy is important. If you are a hedge fund, you do not want competitors to see what you are doing on-chain. But complete and total privacy does not exist legally in the real world. You need selective disclosure and proof of innocence built into the privacy protocol.

That is what we are doing as part of the Manifest, compliant privacy rather than absolutist privacy. For us, it is about showing how this should be done on a Layer 1.

Dennis O’Connell: ERC-3643 has 160 members, 12 working groups around the world, and is active across 23-plus jurisdictions. The working groups cover technical, legal, regulatory, privacy, identity, and more.

The association is community-driven. It is not astroturfed, and members are not held hostage to fees. It is very much a “you get what you give” kind of model.

ERC-3643 is the number one RWA standard in the world. It is not even close. But that is not good enough. We need to focus on the why: why standards matter, why we promote this, and what concrete commercial, industrial, and market impact comes from it.

The goal is to make sure ERC-3643 is not only a standard, but a living and breathing standard with a living and breathing ecosystem.

Alex Kelly: What do you think is the biggest misconception institutions have about compliant tokenization today?

Joachim Lebrun:
The biggest misconception is that to make a permissioned token, institutions need to work on a permissioned chain.

Many institutional players believe that if they want a compliant token with rules like whitelisting, they need a private network. But rules at the network level are not great, because they are one-size-fits-all and not specific to the asset.

Each asset has different rules depending on the asset type, issuing jurisdiction, and target investor jurisdictions.

The only argument for private chains used to be privacy. But saying you need a private chain for privacy is like saying you do not go to the internet because you prefer an intranet. That works only if you interact with your own applications.

With our partner Zama, we are implementing FHE, homomorphic encryption, on public permissionless chains. This means we can enforce compliance and confidentiality at the asset level under ERC-3643, while still being on public infrastructure and interoperable with DeFi.

I do not think there is any reason anymore to stay on a private network. Institutions need to join networks that are open and can interact with the world.

Michael Steuer: The biggest misconception is that safe means popular.

Institutions look at the chain with a brand-name logo and the one everybody else picked, then assume the crowd de-risks them. It feels prudent because nobody ever got fired for choosing the most popular option.

But in regulated finance, that is backwards. The risk is not being early or different. The risk is building real securities with legal obligations on infrastructure that cannot meet them.

A chain that cannot freeze a sanctioned account, fix a bug in a deployed contract, honor a court order, or provide final settlement is problematic.

Popular does not protect you. Real safety is structural. It is whether the chain can do the unglamorous things that regulated assets demand every day, including on the bad days where it is actually needed.

Safe is not where everyone is standing. Safe is the chain that can still obey a court order on a Tuesday.

Dennis O’Connell: There are two big misconceptions.

The first is that standards do not matter, or that standards are optional. Standards are incredibly important. They are not about one institution’s absolute opinion. They are about solving a problem in common, well enough that the market can move on and solve the next problem.

The idea that a custom ERC-20 permissioned token is “close enough” really is not right. There are big differences, and standards matter.

The second misconception is that Crypto Twitter reflects the reality of institutional tokenization. It does not.

A lot of institutional activity is private. Many members use the standard quietly or discreetly. Many issuers do not want assets disclosed on public dashboards. We work with RWA.xyz, Dune, and others behind the scenes, and there are billions more of issued assets that are not publicly visible.

We recently spoke with more than 200 issuers and institutions using the standard, and the overwhelming answer was NDA, privacy, and keeping quiet. What you see on dashboards is not the full picture.

As RWAs and standards become more visible, there is more misinformation, agenda-driven commentary, and paid content. People should take what they read with a strong grain of salt.