Ethereum on Bitsy Wiki

EIP and ERC

Mon, 01 Jan 0001 00:00:00 +0000

An Ethereum Improvement Proposal (EIP) is the design document through which every change to Ethereum is proposed, argued over, and ratified. An Ethereum Request for Comments (ERC) is one category of EIP — the category covering application-level conventions such as token interfaces.

The two names get used interchangeably in casual writing. They are not two processes: ERC is a subset of EIP, and both draw from the same number sequence, so the standard filed as EIP-20 is called ERC-20 everywhere else.

Blobs

Mon, 01 Jan 0001 00:00:00 +0000

A blob is 128 KiB of data that an Ethereum block commits to and then forgets. It rides alongside a transaction rather than inside it: the EVM cannot read it, no contract can store it, and consensus clients delete it after about 18 days. EIP-4844, an Ethereum Improvement Proposal shipped in the Dencun upgrade on 13 March 2024, added them to give rollups somewhere to publish transaction data other than calldata, which every node stores forever and which costs 16 gas per non-zero byte.

ERC-20

Mon, 01 Jan 0001 00:00:00 +0000

ERC-20 — the twentieth Ethereum Request for Comment — is the standard interface for fungible tokens on Ethereum. Proposed by Fabian Vogelsteller in 2015 (EIP-20), it defines six functions and two events that every compliant token must implement. Wallets, DEXs, lending protocols, and aggregators all speak ERC-20, so a token that implements the interface is tradeable and usable as collateral on the day it deploys, without asking any of them to add support for it.

ERC-8004: Trustless Agents

Mon, 01 Jan 0001 00:00:00 +0000

ERC-8004 is a Draft ERC defining three on-chain registries — identity, reputation, and validation — that give AI agents a shared trust layer across organisational boundaries, with no bilateral agreement arranged in advance. It is protocol-agnostic: an agent speaking MCP, A2A (agent-to-agent), or anything else uses the same registries.

The three questions#

Agents from different companies that need to work together have no standard way to settle three things, and one registry answers each:

ERC-667

Mon, 01 Jan 0001 00:00:00 +0000

ERC-667 was an early proposal to add transferAndCall functionality to ERC-20 tokens on Ethereum. It predates the similar and much more widely known ERC-677, and the two are frequently confused.

What it proposed#

Like ERC-677, ERC-667 aimed to solve the two-step approve + transferFrom pattern by combining a token transfer with a smart contract callback in a single transaction. The core idea was identical: call a function on the receiving contract immediately after transferring tokens, so the recipient can react atomically.

ERC-677

Mon, 01 Jan 0001 00:00:00 +0000

ERC-677 is an ERC-20 extension that adds a single function – transferAndCall – enabling a token transfer and a callback to the recipient in one transaction. It was proposed in 2017 and is best known as the standard behind Chainlink’s LINK token.

Like ERC-1363, ERC-677 exists to solve the two-step approve + transferFrom problem inherent in ERC-20. Where they differ is scope: ERC-677 is a minimal extension (one function, one receiver interface), while ERC-1363 adds approval callbacks and uses the magic-value return pattern for safer recipient validation.

ERC-721

Mon, 01 Jan 0001 00:00:00 +0000

ERC-721 is the standard interface for non-fungible tokens on Ethereum. Where ERC-20 tracks a balance per address, ERC-721 tracks an owner per token ID — so a transfer names a specific token rather than an amount.

The interface#

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {IERC165} from "@openzeppelin/contracts/utils/introspection/IERC165.sol";

// IERC165 supplies supportsInterface(bytes4) -> bool.
interface IERC721 is IERC165 {
    function balanceOf(address owner) external view returns (uint256);
    function ownerOf(uint256 tokenId) external view returns (address);

    function safeTransferFrom(address from, address to, uint256 tokenId) external;
    function safeTransferFrom(address from, address to, uint256 tokenId, bytes calldata data) external;
    function transferFrom(address from, address to, uint256 tokenId) external;

    function approve(address to, uint256 tokenId) external;
    function setApprovalForAll(address operator, bool approved) external;
    function getApproved(uint256 tokenId) external view returns (address);
    function isApprovedForAll(address owner, address operator) external view returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
}

The is IERC165 is not decoration. supportsInterface(0x80ac58cd) returning true is how a marketplace, a receiver contract, or a router decides it is looking at an ERC-721 at all, and the spec makes it mandatory. Note also that the declarations above follow OpenZeppelin’s IERC721; the EIP itself marks the transfer and approve functions payable. Payability is not part of the selector, so this makes no difference at the call site — but it will look like a typo if you diff against the spec.

ERC-1155

Mon, 01 Jan 0001 00:00:00 +0000

ERC-1155 is a multi-token standard: one contract holds many token IDs, and each ID carries its own supply. An ID with a supply of one behaves like an ERC-721 token; an ID with a supply of a million behaves like an ERC-20. The standard does not require choosing between the two up front.

What it buys#

One deployment for a whole catalogue. A game with a thousand item types deploys one contract rather than a thousand.
Batch operations. safeBatchTransferFrom moves several IDs in a single call, which is the main gas argument for the standard.
Both token shapes at once. Fungible currency and non-fungible items can live in the same contract and be transferred together.

The balance mapping is two-dimensional — balanceOf(account, id) — which is the structural difference from both of the standards it merges.

ERC-1363

Mon, 01 Jan 0001 00:00:00 +0000

ERC-1363 is an ERC-20 extension that adds callback hooks to token transfers and approvals. It removes ERC-20’s two-step problem: approve + transferFrom costs two transactions and leaves an allowance standing between them, while a plain transfer to a contract that was not expecting it leaves the tokens sitting there with nothing to trigger the deposit.

With ERC-1363, a token holder can transfer tokens and notify the recipient in a single transaction. The standard was formalized as EIP-1363 and has an OpenZeppelin implementation.

ERC-4626

Mon, 01 Jan 0001 00:00:00 +0000

ERC-4626 is the Ethereum standard for tokenized vaults. It extends ERC-20 with a uniform interface for depositing assets, receiving shares, and redeeming those shares for the underlying asset plus any yield the vault has earned. Before this standard, every protocol invented its own vault API and every integrator wrote separate accounting code per protocol.

The share/asset model#

A vault holds a pool of a single ERC-20 asset (e.g. DAI, USDC, WETH). Users deposit that asset and receive vault shares in return. The shares are themselves ERC-20 tokens, so they can be transferred, traded on a DEX, or used as collateral in other protocols.