Solidity Developers Need to Stop Chasing Tools and Start Mastering ERC Standards

⋅

Most Solidity education focuses on syntax, patterns, and tools. Learn the language, deploy a contract, move on.

That used to be enough.

In 2026, every major ERC standard is its own ecosystem. Some have bundlers, paymasters, and SDKs. Others run compliance modules and identity registries. This isn’t even in the same category as ERC-20. Each standard is its own open system — a full-blown market for smart account tooling and integrations.

Trillions in real-world assets are heading onchain. The developers who capture that opportunity won’t be the ones who learned the most tools – they’ll be the ones who went deep on the right standards.

That’s where the leverage is now.

RWA & Compliance

Institutional blockchain with real volume is already here. Canton Network, a private permissioned chain built by a consortium of banks, processes over $280 billion in daily repo settlements through Broadridge’s Distributed Ledger Repo (DLR) platform. Over $3.6 trillion in tokenized real-world assets live on that network today. The catch: it’s a closed ecosystem. You don’t build on Canton the way you build on Ethereum, you need to be invited.

The open alternative is being written in ERCs. Tokenizing a US Treasury or a real estate fund isn’t like deploying an ERC-20. You need investor whitelisting, transfer restrictions, the ability to freeze assets, forced transfers for legal enforcement, and on-chain identity verification. Standard token interfaces have none of that. Two standards exist to fill that gap. One is the full compliance stack, the other is the universal language that lets DeFi talk to it.

ERC-3643 (T-REX)

ERC-3643, known as T-REX (Token for Regulated EXchanges), is the most battle-tested compliance standard on Ethereum. Final status. In production. Originally developed by Tokeny, it’s the architecture behind a significant share of institutional tokenized securities issuances today.

At its core are roughly nine contracts: the token itself, an identity registry mapping investor wallets to on-chain identities via ONCHAINID, a modular compliance engine defining the actual transfer rules, a trusted issuers registry controlling which claim issuers are authoritative, and a claim topics registry defining what claims matter: KYC status, accredited investor classification. When a transfer is attempted, the compliance module checks the identity registry. If anything fails — wrong jurisdiction, unverified investor, limit exceeded — the transaction reverts. Compliance logic is pluggable: swap modules for different jurisdictions without touching the token contract.

This is what makes T-REX genuinely useful for institutions. A single token can support multiple transfer restriction regimes simultaneously. If you’re planning to build in the RWA compliance space, this is the standard to go deep on first.

Resources ERC-3643

ERC-7943 (uRWA)

ERC-3643 solves compliance for issuers. ERC-7943 solves a different problem: DeFi protocols have no generic way to interact with compliant RWA tokens.

If a lending protocol wants to accept a tokenized treasury as collateral, how does it check whether a transfer is allowed? How does it detect frozen assets? Every RWA implementation today has its own interface. Protocols either build custom integrations per issuer, or ignore compliant assets entirely. Neither scales.

ERC-7943 — the Universal RWA Interface — proposes a minimal, implementation-agnostic surface that any RWA token can expose regardless of what compliance system it uses underneath: canTransact, canTransfer, getFrozenTokens, forcedTransfer, setFrozenTokens. Five functions. No opinion on identity systems, no mandated role structures, no specific KYC provider.

The result: a DeFi protocol implementing ERC-7943 support can interact with any compliant RWA token — whether it’s built on T-REX, a custom compliance system, or anything else. The two standards are complementary rather than competing. A T-REX token can expose the uRWA interface as its public-facing integration surface.

Important note: as of April 2026, ERC-7943 is in Last Call, not Final. The architecture is being built against it already, but mention that to any institutional counterpart you’re speaking with.

Resources ERC-7943

Vaults & Yield

It used to be that every DeFi protocol that handled yield had its own vault interface. Yearn had one. Aave had another. Compound had its own. Building an aggregator or any product that touched multiple protocols meant writing custom adapters for each one, getting each audited separately, and maintaining all of it when any protocol upgraded. That was the state of DeFi yield infrastructure as recently as 2022.

ERC-4626 fixed that. Over $15 billion in vault TVL across more than 2,700 vaults on Ethereum mainnet alone runs on this standard today. Yearn, Morpho, Euler, Ondo, Centrifuge and many other projects adopted it.

ERC-4626 (Tokenized Vault Standard)

ERC-4626 is a simpler standard than ERC-3643 in terms of surface area. It extends ERC-20 and adds a standardized interface for vaults: how you deposit assets, how you receive shares, how you redeem, how share-to-asset pricing is calculated. That’s the whole thing. But the composability that comes from that simplicity is the point.

When every vault speaks the same interface, a protocol integrating ERC-4626 support once can work with every compliant vault automatically. Yield aggregators, collateral managers, lending protocols — they all plug into the same surface. Vault shares are ERC-20 tokens, which means they can be traded, used as collateral, or deposited into other vaults. The ecosystem this created is what drove the TVL numbers above.

The standard also solves something less obvious: consistent share pricing. Before ERC-4626, the exchange rate between a vault share and its underlying asset was calculated differently everywhere, which made it difficult for external protocols to reason about vault value without bespoke logic. convertToShares and convertToAssets standardize that math across every implementation.

One security consideration worth knowing: the inflation attack. A malicious first depositor can manipulate share pricing by donating assets directly to the vault before any real deposits. OpenZeppelin’s implementation and most production vaults address this with virtual shares, but it’s a pattern every developer building a new vault should understand before deploying.

Resources (ERC-4626)

ERC-7540 (Asynchronous ERC-4626 Vaults)

ERC-4626 assumes that deposits and redemptions settle in the same transaction. That works for liquid DeFi strategies but breaks immediately when you try to apply it to real-world assets. A tokenized treasury fund can’t redeem in one block — it has T+1 settlement. A real estate fund may need compliance checks before accepting a new investor. A private credit vault needs time to deploy capital off-chain.

ERC-7540 extends ERC-4626 with a request-and-claim pattern. Instead of depositing and receiving shares atomically, a user submits a request. The vault processes it asynchronously — running compliance checks, settling off-chain, computing NAV — and then the user claims their shares in a separate transaction when the vault is ready. The existing ERC-4626 interface is preserved for the claim step, meaning protocols that support ERC-4626 can support ERC-7540 with minimal additional work.

This is the standard that makes ERC-4626 actually usable for institutional RWA products. Lagoon, one of the larger vault infrastructure providers building across 18+ EVM chains, runs their entire stack on ERC-7540 for exactly this reason. The pattern also supports forward pricing, where the exchange rate is determined at settlement time rather than at request time — a requirement for many regulated fund structures.

ERC-7540 reached Final status. If you’re building anything vault-adjacent that involves real-world assets, off-chain settlement, or compliance-gated access, start here rather than trying to bend ERC-4626 into something it wasn’t designed for.

Resources (ERC-7540)

Account Abstraction

Every user on Ethereum today carries the same burden: a seed phrase, an ETH balance for gas, and a single point of failure. Lose the key, lose everything. Want to pay gas in USDC? Not possible. Need a corporate wallet with multi-sig approval flows and spending limits? Build it yourself from scratch.

Account abstraction changes this. The idea has been on Ethereum’s roadmap since the earliest days, but previous proposals all required consensus-layer changes that proved too politically difficult to ship. ERC-4337 took a different approach entirely: no protocol changes, no hard fork dependency. Just a higher-layer architecture built on top of what already exists.

ERC-4337 (Account Abstraction)

ERC-4337 went live on Ethereum mainnet on March 1, 2023. Over 40 million smart accounts have been deployed since, with nearly 20 million in 2024 alone. The standard has processed over 100 million UserOperations, a tenfold increase from 2023. Entire companies, Biconomy, Alchemy, Pimlico, have been built around its infrastructure.

The architecture has six core pieces worth understanding.

A UserOperation is the fundamental unit. It’s not a transaction in the traditional sense. It’s a pseudo-transaction object that describes what a user wants to do, including custom authentication logic, gas payment preferences, and batched calls. Users sign UserOperations, not raw transactions.

Bundlers are off-chain infrastructure that monitor a dedicated alt-mempool where UserOperations are submitted. A bundler collects multiple UserOperations, packages them into a single on-chain transaction, and submits it to the EntryPoint contract. Bundlers are the only participants in the ERC-4337 ecosystem that still need an EOA.

The EntryPoint is a singleton smart contract deployed at the same address across every EVM network. It is the trust anchor for the whole system. It receives batched UserOperations from bundlers, calls each account’s validateUserOp function to verify authentication, and executes the operations if validation passes.

The Smart Account is the user’s actual account contract. It implements validateUserOp with whatever logic the developer chooses: standard ECDSA, passkeys, multisig, biometric authentication, time-locked spending, session keys. The account defines its own security model.

Paymasters are optional contracts that cover gas on behalf of users. An application can deploy a Paymaster and fund it with ETH, letting users transact without ever holding native gas. This is what makes genuinely gasless onboarding possible, not just in theory but in production.

Aggregators handle signature aggregation for accounts that use schemes like BLS, where multiple signatures can be collapsed into one for gas efficiency.

One significant development to mention for readers keeping up: EIP-7702, shipped with Ethereum’s Pectra upgrade in May 2025, extends account abstraction to existing EOAs without requiring users to migrate to new addresses. EIP-7702 is complementary to ERC-4337, not a replacement. EOAs with EIP-7702 delegation can use the same bundler and paymaster infrastructure. The account abstraction stack now serves both new smart accounts and upgraded legacy EOAs.

Resources (ERC-4337)

ERC-6900 (Modular Smart Accounts)

ERC-4337 standardizes how accounts interact with the EntryPoint. What it does not standardize is what goes inside the account itself. ERC-6900 defines a standard interface for modular smart accounts: how validation modules attach, how execution modules hook in, how permissions are scoped. A plugin built to ERC-6900 spec can be installed into any compliant account, regardless of who built the account.

The standard is currently in Draft, not Final, which is worth knowing. But it already has meaningful adoption. Alchemy’s Modular Account V2 is built on ERC-6900. The Ethereum Foundation’s Pectra documentation explicitly calls out ERC-6900 as the standard mechanism for dApps to access smart account capabilities. For institutional deployments where audit reusability and module composability matter, ERC-6900 would be a solid choice.

There is also ERC-7579, a more minimalist alternative to ERC-6900 that standardizes the same interfaces with fewer constraints. The two coexist and there is active debate in the community about which approach wins long-term. Both are worth understanding; which you build against depends on whether you need ERC-6900’s comprehensive framework or ERC-7579’s lighter surface area.

Resources (ERC-6900)

AI Agents

AI agents are no longer just chatbots. They execute transactions, and coordinate with other agents but how does one agent trust another it has never interacted with before?

Off-chain, this problem is solved by centralized platforms. The same centralization problem that Ethereum solved for tokens and DeFi now applies to the emerging agent economy.

Two ERCs address different layers of this problem. ERC-8004 is the identity and reputation layer. ERC-8001 is the coordination primitive. Together they define what it means for agents to work together on-chain in a trustless way.

ERC-8004 (Trustless Agents)

ERC-8004 was proposed in August 2025 by a group that reads like a who’s who of the agent stack: Marco De Rossi from MetaMask, Davide Crapis from the Ethereum Foundation, Jordan Ellis from Google, and Erik Reppel from Coinbase. It went live on Ethereum mainnet in January 2026. The architecture is three lightweight registries, designed to be deployed as singletons per chain.

The Identity Registry is built on ERC-721. Each agent gets minted an NFT whose tokenURI points to a registration file, an agent card containing the agent’s name, capabilities, supported protocols (MCP, A2A, ENS, DID), and payment address. The on-chain component anchors identity. The off-chain card provides context. Identifiers follow CAIP-10 so agents have globally unique, chain-agnostic addresses that work consistently across networks.

The Reputation Registry standardizes how feedback gets posted and queried on-chain. A client that hired an agent can post structured feedback tied to that agent’s identity token. Scoring and aggregation happen both on-chain for composability and off-chain for more sophisticated algorithms. The design explicitly expects a layer of specialized reputation aggregators, auditor networks, and insurance pools to emerge on top.

The Validation Registry handles heavier trust requirements. It provides hooks for requesting and recording independent third-party verification, whether that’s cryptographic proofs, TEE attestations from trusted execution environments, or economic staking. High-value agent interactions can require validator sign-off before execution.

One technical thing worth noting for developers: ERC-8004 deliberately excludes payment mechanics. That is handled by x402, an HTTP-layer payment protocol governed by Coinbase and Cloudflare that lets agents pay for services automatically as part of normal request-response flows. ERC-8004 plus x402 is the two-piece stack most agent infrastructure is being built on.

Status flag: ERC-8004 is on mainnet and actively deployed, but formally still carries Draft status in the EIP repository. The spec is stable enough to build on, and the Ethereum Foundation’s dAI team has it on their 2026 roadmap, but flag this when explaining it to anyone who asks about formal ratification.

Resources (ERC-8004)

ERC-8001 (Agent Coordination Framework)

ERC-8004 answers “how do agents identify and trust each other,” ERC-8001 answers “how do multiple agents agree to act together without a coordinator in the middle.”

The problem it solves is specific. Existing intent standards on Ethereum, ERC-7521, ERC-7683, and others, define single-initiator flows. One party wants something done and broadcasts an intent. That covers most DeFi use cases but breaks when multiple agents need to jointly commit to a coordinated action before any of them executes. A DeFi trading strategy that requires three agents to simultaneously agree before entering a position. A DAO treasury rebalance that needs sign-off from multiple autonomous actors. A multi-agent system that should only fire when all participants have confirmed their legs are ready.

ERC-8001 defines the minimal primitive for that: an initiator posts an AgentIntent signed with EIP-712, the required participants each submit an AcceptanceAttestation, and the intent is executable only once all valid acceptances are present and unexpired. Replay protection comes from EIP-712 domain binding and monotonic nonces. Everything is compatible with both EOA and smart contract wallets via ERC-1271.

The standard is deliberately narrow. Threshold policies, bonding, privacy, and cross-chain semantics are all explicitly out of scope, expected to be added as optional modules on top. This is the same design philosophy as ERC-4626: define the minimal interface that everyone can agree on and let the ecosystem build the rest. ERC-8001 reached Final status but has lower adoption than ERC-8004.

Resources (ERC-8001)

The standards in this article are not equally mature, equally complex, or equally close to production money. But all of them are pointing at the same thing: Ethereum is becoming the settlement layer for things that actually matter. The developers who understand this infrastructure deeply, not just how to write Solidity, but how these systems are designed and why, are going to be the ones building it.

I’m personally working on tooling and monitoring for ERC-3643 deployments. I believe the compliance layer of on-chain finance is the highest-leverage place to be right now.

Liked Liked