EVM トークン標準（ERC-20・ERC-721・ERC-1155・ERC-4626）

EVM（Ethereum Virtual Machine）上でトークンを発行する際の「共通言語」が ERC（Ethereum Request for Comments）標準である。ERC-20 が代替可能トークンの事実上の基盤となって以来、NFT・マルチトークン・Vault・Proxy パターンへと標準が拡張された。標準化された ABI（Application Binary Interface）を介して、ウォレット・DEX・Lending プロトコルが同一インターフェースでトークンを扱える点が DeFi の「コンポーザビリティ」の技術的根拠となっている。情報カットオフ ~2025-08、confidence: medium 固定（2026-06 時点での外部再検証は未実施）。

ERC-20：代替可能トークンの基盤

ERC-20（EIP-20、2015 年）は代替可能トークン（FT）の最小インターフェースを定義した標準である。6 つの必須関数と 2 つのイベントで構成される。

totalSupply()          → uint256  // 総発行量
balanceOf(address)     → uint256  // 残高照会
transfer(to, amount)              // 直接移転
approve(spender, amount)          // 承認（allowance 設定）
transferFrom(from, to, amount)    // 承認済み移転
allowance(owner, spender) → uint256 // 残余承認量

event Transfer(from, to, value)
event Approval(owner, spender, value)

approve + transferFrom の組み合わせにより、スマートコントラクト（DEX・Lending 等）がユーザーの代わりにトークンを扱う「委任引き出し」が可能になる。USDT・USDC・WETH・DAI など、主要なオンチェーン資産のほぼすべてが ERC-20 準拠である。

ERC-20 の既知の問題点として、transfer と approve+transferFrom の二重経路に起因するリエントランシーリスク、不意の送金による ERC-20 トークンの消失（transfer はコントラクトへの受信を通知しない）がある。後者の解決策として ERC-777 が提案されたが、リエントランシー攻撃事例が多発し、ERC-20 の safeTransfer ラッパー（OpenZeppelin SafeERC20）で対応するパターンが主流になっている。

ERC-721：非代替性トークン（NFT）

ERC-721（EIP-721、2018 年）は各トークンに一意の tokenId（uint256）を付与し、所有権を個別追跡する非代替性トークン標準である。

ownerOf(tokenId)       → address  // 所有者照会
transferFrom(from, to, tokenId)    // 移転
approve(to, tokenId)               // 個別承認
setApprovalForAll(operator, bool)  // 全 token 一括承認
tokenURI(tokenId)      → string   // メタデータ URI

tokenURI が返す URI（通常 IPFS または HTTPS）が JSON メタデータ（名前・説明・画像 URL・属性）を指す。多くの NFT プロジェクトが IPFS に固定コンテンツアドレスを使用し、URI 先のコンテンツ変更を防ぐ。ただし tokenURI 自体のオンチェーン不変性は保証されず、コントラクトオーナーが書き換え可能なケースも存在する。

ERC-721 の拡張規格として、ERC721Enumerable（全 tokenId 列挙）・ERC721URIStorage（tokenId ごとに URI を storage 管理）・ERC721Royalty（EIP-2981 ロイヤリティ）が OpenZeppelin ライブラリで提供されている。

ERC-1155：マルチトークン標準

ERC-1155（EIP-1155、2019 年）は 1 つのコントラクトで FT と NFT を同時に管理できるマルチトークン標準である。ゲーム（通貨・武器・キャラクターを単一コントラクトで管理）や SFT（Semi-Fungible Token：チケットの「カテゴリ」は同一だが使用後は一意になるケース）に適している。

balanceOf(account, id)           → uint256
balanceOfBatch(accounts, ids)    → uint256[]
safeTransferFrom(from, to, id, amount, data)
safeBatchTransferFrom(from, to, ids, amounts, data)

バッチ転送が 1 トランザクションで複数 ID を扱えるため、ガスコストを大幅に削減できる。受信コントラクトは IERC1155Receiver を実装し、受信拒否（revert）の意思を表明できるため、ERC-20 の誤送信問題を回避する。

ERC-4626：トークン化 Vault 標準

ERC-4626（EIP-4626、2022 年）は「利回りを生む Vault」のインターフェースを標準化した ERC-20 の拡張規格である。DeFi の Vault（Yearn Finance yVault・Compound cToken・Aave aToken 等）はそれぞれ異なるインターフェースを持っており、統合コストが高かった。ERC-4626 はこの差異を吸収する。

asset()                → address  // 基礎資産のアドレス
totalAssets()          → uint256  // Vault が管理する基礎資産総量
convertToShares(assets) → shares  // 資産 → シェア変換
convertToAssets(shares) → assets  // シェア → 資産変換
deposit(assets, receiver)         // 入金
withdraw(assets, receiver, owner) // 出金

shares は Vault への持ち分を表す ERC-20 トークンで、時間とともに基礎資産に対する価値が上昇（利回りが蓄積）する。ERC-4626 準拠 Vault は sUSDe・sUSDS・多くの RWA Vault で採用されており、集約 UI（Yearn v3・Morpho）が統一的に扱える基盤となっている。

ERC-1967・ERC-2535：Proxy とアップグレード可能コントラクト

スマートコントラクトはデプロイ後に変更できないが、Proxy パターンを使うと実装（ロジック）コントラクトを差し替えてアップグレード可能にできる。

ERC-1967（Transparent Proxy Standard、2020 年）は Proxy コントラクトが実装アドレスを格納するストレージスロットの位置を標準化した。Etherscan 等のツールがこのスロットを読んで実装コントラクトを表示できる。OpenZeppelin の TransparentUpgradeableProxy と UUPSUpgradeable の 2 種類のパターンが広く使われる。

ERC-2535（Diamond Standard、2020 年）は 1 つの Proxy が複数の「Facet」（ロジックコントラクト）を選択的に呼び出せるモジュラー設計である。関数セレクタ単位でルーティングし、24KB のコントラクトサイズ上限（EIP-170）を回避できる。大規模 DeFi プロトコルや L2 コアコントラクトで採用されている。

標準化の意義と相互運用性

ERC 標準がもたらす最大の価値は相互運用性である。ERC-20 準拠であれば、MetaMask・Uniswap・Aave・Compound のいずれもが追加実装なしにトークンを扱える。ERC-4626 準拠であれば、Vault アグリゲータが統一 API でリバランスできる。この標準層がなければ DeFi の「コンポーザビリティ（マネーレゴ）」は成立しない。

一方で、標準はあくまでインターフェースの合意であり、実装の安全性は別問題である。ERC-20 準拠であっても再入可能攻撃・整数オーバーフロー・フィッシングトークン（approve 詐欺）のリスクは存在する。標準への準拠は最低限の相互運用条件であり、セキュリティ監査（Certik・OpenZeppelin・Trail of Bits 等）が別途必要となる。