Ethereum on Bitsy Services Wiki

ERC-20

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

ERC-20 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. Because wallets, DEXs, lending protocols, and aggregators all speak ERC-20, any token that implements the interface is instantly composable with the entire ecosystem.

The interface#

interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 amount) external returns (bool);
    function allowance(address owner, address spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address from, address to, uint256 amount) external returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

The two-step approve + transferFrom pattern is the standard way for a smart contract to spend tokens on behalf of a user. The user first approves a spending allowance, then the contract calls transferFrom to pull the tokens.

ERC-8004: Trustless Agents

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

The Problem#

AI agents are starting to do real work — booking services, managing portfolios, coordinating tasks across organisations. But when two agents from different companies need to work together, there is no standard way for them to answer three basic questions:

Who are you? — How does an agent prove its identity?
Can I trust you? — How does an agent build (or lose) a reputation?
Did you do the job right? — How does anyone verify an agent’s work?

ERC-8004 is a Draft ERC that answers these questions using Ethereum smart contracts. It gives AI agents — whether they speak MCP, A2A, or any other protocol — a shared trust layer that works across organisational boundaries without anyone needing to set up bilateral agreements in advance.

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-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 solves the fundamental two-step problem with ERC-20: the approve + transferFrom dance that requires two transactions, confuses users, and creates a window where tokens can be lost if the receiving contract doesn’t pull them.

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, making integration painful and error-prone. ERC-4626 fixes that – one interface, universal composability.

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.