ERC Standards You Should Know Beyond ERC-20 and ERC-721

ERC-20 and ERC-721 are table stakes. The standards that define how serious DeFi protocols, account abstraction systems, and real-world asset platforms are built in 2026 go much further. Here's what every dapp developer should understand , and when to reach for each one.

Why ERC Standards Exist and How They Evolve

Ethereum Request for Comment (ERC) standards are interface agreements. They define a common API that contracts can implement so that other contracts, frontends, and protocols can interact with them predictably , without needing to know anything about the underlying implementation.

The process: a developer or team identifies a recurring pattern or need, proposes a standard through the EIP process, the community iterates through discussion and reference implementations, and eventually a standard reaches "Final" status. Some reach wide adoption before finalization; others finalize and see limited use.

Knowing which standards are worth building on , versus which are experimental or superseded , is a meaningful competitive advantage for dapp developers. What follows covers the ones that matter most right now.

ERC-1155: Multi-Token Standard for Games and Bundles

ERC-1155 allows a single contract to manage multiple token types , both fungible and non-fungible , under one address. Where ERC-20 is one contract per fungible token and ERC-721 is one contract per NFT collection, ERC-1155 consolidates multiple token types into a single deployment.

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract GameItems is ERC1155 {

uint256 public constant GOLD = 0; // fungible

uint256 public constant SILVER = 1; // fungible

uint256 public constant SWORD = 2; // semi-fungible

uint256 public constant RARE_SHIELD = 3; // non-fungible (max supply 1)

constructor() ERC1155("https://api.mygame.io/metadata/{id}.json") {

_mint(msg.sender, GOLD, 10**18, "");

_mint(msg.sender, SILVER, 10**18, "");

_mint(msg.sender, SWORD, 1000, "");

_mint(msg.sender, RARE_SHIELD, 1, "");

}

}

The key advantage is gas efficiency for batch operations , ERC-1155 supports safeBatchTransferFrom, which can transfer multiple token types in a single transaction. For gaming, NFT platforms, and any protocol managing heterogeneous assets, this matters significantly.

When to use it: gaming assets, multi-token reward systems, mixed fungible/non-fungible collections, any scenario where managing many token types under one contract simplifies your architecture.

ERC-4626: Tokenized Vaults , The Backbone of Modern DeFi Yields

ERC-4626 standardizes yield-bearing vaults. Before this standard, every lending protocol, yield aggregator, and staking contract had its own interface for depositing assets, tracking shares, and withdrawing. Integration required custom code for each protocol.

ERC-4626 defines a uniform interface: deposit assets, receive shares; redeem shares, receive assets plus yield.

import "@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol";

contract YieldVault is ERC4626 {

constructor(IERC20 asset)

ERC20("Yield Vault Token", "yvTKN")

ERC4626(asset) {}

// deposit() and redeem() inherited from ERC4626

// Override _deposit and _withdraw to add yield logic

function totalAssets() public view override returns (uint256) {

// Return current value of all assets including accrued yield

return IERC20(asset()).balanceOf(address(this)) + accruedYield();

}

}

// Interacting with any ERC-4626 vault uniformly

IERC4626 vault = IERC4626(vaultAddress);

// Deposit 100 USDC, receive shares

uint256 shares = vault.deposit(100e6, msg.sender);

// Preview how much you'd get back before redeeming

uint256 assets = vault.previewRedeem(shares);

// Redeem shares for underlying assets

vault.redeem(shares, msg.sender, msg.sender);

When to use it: any yield-bearing vault, staking contract, lending pool share token, or savings product. If you're building something where users deposit assets and receive shares representing a claim on those assets plus yield, ERC-4626 is the right foundation.

ERC-2612: Permit-Based Approvals and Gasless UX

ERC-2612 adds a permit function to ERC-20 tokens that allows approvals to be set via a signed message rather than an on-chain transaction. This enables gasless approvals , users sign a message off-chain, and the protocol submits both the approval and the action in a single transaction.

// User signs a permit off-chain, protocol submits it on-chain

function depositWithPermit(

uint256 amount,

uint256 deadline,

uint8 v, bytes32 r, bytes32 s

) external {

// Single transaction: approve + deposit

IERC20Permit(token).permit(

msg.sender,

address(this),

amount,

deadline,

v, r, s

);

IERC20(token).transferFrom(msg.sender, address(this), amount);

_processDeposit(msg.sender, amount);

}

When to use it: any protocol that requires token approvals. ERC-2612 eliminates the two-transaction approval flow that creates friction for users. Most major DeFi tokens (USDC, DAI, UNI) already implement it.

ERC-6900: Modular Smart Accounts and Account Abstraction Plugins

ERC-6900 defines a standard for modular smart accounts , accounts that can be extended with plugins to add new functionality. Built on ERC-4337 (account abstraction), it allows developers to build reusable account modules: session keys, spending limits, recovery mechanisms, automated strategies.

// Installing a plugin on an ERC-6900 account

IModularAccount(account).installPlugin({

plugin: address(sessionKeyPlugin),

manifestHash: keccak256(abi.encode(sessionKeyPlugin.pluginManifest())),

pluginInstallData: abi.encode(

sessionKey,

block.timestamp + 1 days, // session expiry

maxSpendPerSession

)

});

When to use it: building smart wallet infrastructure, account abstraction plugins, or protocols that want to offer programmable account features to users. This is the standard that the smart account ecosystem is converging on.

ERC-7540: Asynchronous Vaults for RWA and Slow-Settlement Assets

ERC-4626 assumes synchronous deposits and redemptions , you deposit, you immediately receive shares. This breaks for real-world assets (RWAs), tokenized funds, and any asset where settlement takes time (hours, days, or settlement cycles).

ERC-7540 extends ERC-4626 with asynchronous request flows: users submit a deposit or redemption request, the request is fulfilled when the underlying asset settles, and shares or assets are claimed after fulfillment.

// ERC-7540 asynchronous deposit flow

IERC7540Vault vault = IERC7540Vault(vaultAddress);

// Step 1: Submit deposit request

uint256 requestId = vault.requestDeposit(amount, controller, msg.sender);

// Step 2: Wait for fulfillment (off-chain settlement occurs)

// Step 3: Claim shares after fulfillment

uint256 shares = vault.deposit(amount, receiver);

When to use it: tokenized real-world assets, tokenized funds, any vault where the underlying asset has non-instantaneous settlement. If you're building RWA infrastructure, ERC-7540 is the standard to build on.

ERC-7579: Minimal Modular Smart Account Interface

Where ERC-6900 is comprehensive, ERC-7579 is minimal. It defines a lightweight interface for modular smart accounts that's designed to be easy to implement and interoperable across different smart account implementations. Think of it as the lowest common denominator standard for account modularity , more likely to achieve widespread adoption because of its simplicity.

// ERC-7579 module installation

IMSA(account).installModule(

MODULE_TYPE_VALIDATOR, // validator, executor, hook, or fallback

address(myModule),

initData

);

When to use it: building modules that need to work across multiple smart account implementations. ERC-7579 is the interoperability layer for the account abstraction ecosystem.

How to Evaluate Whether a New ERC Is Production-Ready

Not every ERC is ready to build on. Before adopting a standard:

Check its EIP status: Draft → Review → Last Call → Final. Only build production systems on Final or widely-adopted standards with stable reference implementations.

Review the reference implementation: Is there a battle-tested implementation (OpenZeppelin, Solmate, etc.)? If only the author's implementation exists, proceed with caution.

Assess adoption: are major protocols or audit firms engaging with this standard? Adoption signals stability.

Review audit history: has the standard's reference implementation been audited? By whom?

Implementing and Extending Standards Safely

When implementing any ERC standard, prefer audited reference implementations over writing from scratch:

// Prefer composition over reimplementation

import "@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol";

import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";

// Combine standards safely

contract MyVaultToken is ERC4626, ERC20Permit {

constructor(IERC20 asset)

ERC20("My Vault", "mvTKN")

ERC20Permit("My Vault")

ERC4626(asset) {}

}

When extending a standard, be explicit about which functions you're overriding and why. Unintentional overrides of standard behavior are a common source of subtle bugs.

Key Takeaways

• ERC-1155 combines fungible and non-fungible tokens in a single contract, reducing gas costs for batch operations.
• ERC-4626 standardizes yield-bearing vaults, making DeFi composability significantly easier.
• ERC-2981 provides on-chain royalty information for NFTs, though marketplace enforcement remains voluntary.
• Account abstraction standards (ERC-4337, ERC-6900, ERC-7579) are enabling smarter wallets with programmable transaction logic.
• Building on established ERC standards reduces audit surface, improves interoperability, and accelerates developer adoption.

Conclusion: Standards Are Shared Infrastructure , Contribute Back

ERC standards represent collective knowledge about how to solve recurring problems in smart contract development. Building on them means your users benefit from composability, your integrators spend less time on custom code, and your auditors can focus on your protocol's unique logic rather than re-auditing standard patterns.

As your experience with these standards grows, consider contributing back , through bug reports, EIP comments, or reference implementations. The standards that matter most in 2026 got there because developers engaged with them seriously.

Autheo supports deploying and managing contracts built on any ERC standard , giving you the deployment infrastructure to ship standards-compliant protocols to mainnet with confidence.