glossary.txt

51% attack: A type of attack where a group gains control of the majority of nodes. This would allow them to defraud the blockchain by reversing transactions and double spending ether and other tokens.  In Ethereum proof-of-stake this would be achieved by accumulating more than half of the total staked ether. This would allow an attacker to decide which new blocks are added to the blockchain. However, to revert the chain or double-spend an attacker would require at least 66% of the total staked ether.

51% Attack: If more than half the computer power or mining hash rate on a network is run by a single person or a single group of people, then a 51% attack is in operation. This means that this entity has full control of the network and can negatively affect a cryptocurrency by taking over mining operations, stopping or changing transactions, and double-spending coins.

account: A public and private keypair that gives you access to, and control over, the tokens held under a specific address. The blockchain itself keeps track of what tokens are held in by each account; the tokens aren’t “in” the wallet or account, but we often talk that way because the metaphor makes sense.In Ethereum- compatible blockchains, a Secret Recovery Phrase (SRP) can generate a number of accounts that approaches infinity. Each one of these accounts has its own keypair, but all of them can be controlled by the SRP.Just like your Reddit account has a username (public) and password (private), so does your Ethereum account; the difference being that you are the custodian of your Ethereum keys, while Reddit holds your login information for their site. For additional security, you can use a password to encrypt your private key which would result in a username (public) and password (private) and password for that password (private + more secure). See also ‘keystore file’, ‘Secret Recovery Phrase’.

Account: An Ethereum account is a digital identity on the Ethereum blockchain, allowing users to send, receive Ether, and interact with smart contracts.  Technical: Its an object containing an address, balance, nonce, and optional storage and code. An account can be a contract account or an externally owned account (EOA).

Address: An Ethereum address is a unique identifier used for receiving tokens, functions similar to a bank account number for cryptocurrencies. Its used to identify your Ethereum account.  It is the rightmost 160 bits of a Keccak hash of an ECDSA public key.

address: Used to send and receive transactions on a blockchain network, and to identify different users; also referred to as a ‘public key’ . An address is an alphanumeric character string, which can also be represented as a scannable QR code. In Ethereum, the address begins with 0 x. For example: 0x06A85356DCb5b307096726FB86A78c59D38e08ee

air-gapping: A method for securing computers in which the device does not connect to the internet or any other open networks. Many hardware wallets use air-gapping as a security mechanism to keep users’ private keys or Secret Recovery Phrase offline, and thus safer from any kind of attack.

airdrop: A token distribution method used to send cryptocurrency or tokens to wallet addresses.  Sometimes airdrops are used for marketing purposes in exchange for simple tasks like reshares, referrals, or app downloads.

altcoin: As Bitcoin was the first cryptocurrency, the term ‘altcoin’ was created to refer to ‘any cryptocurrency other than Bitcoin’ . The term is less used in Ethereum or smart contract- enabled blockchain communities. Many altcoins are forks of Bitcoin with minor changes (e.g., Litecoin). See also ‘fork’

AML (Anti-Money Laundering): A set of international laws enacted to diminish the potential for criminal organizations or individuals to launder money. These rules and laws are applied to cryptocurrencies with varying effects in different jurisdictions.

Anti-Sybil: Are ways to stop people from pretending to be many users at once on the internet, ensuring each user is a real, separate person. This helps keep online interactions fair and honest.  Application Programming Interface (API) An Application Programming Interface (API) is a set of definitions for how to use a piece of software. An API sits between an application and a web server, and facilitates the transfer of data between them.

API (Application Programming Interface): A predefined set of requests that one program can make to another in order to transfer information between them. When you hear someone saying that an application is “getting information from” another source, it’s often doing so through an API.

AppChain: As interest in using public blockchains for different applications has grown, developers have begun creating app-specific chains that are custom-made and optimized for their application’s needs; these are therefore known as appchains. An appchain is generally not a full-blown blockchain, but offers an optimized execution environment for the application, while still relying on an underlying “Layer 1” blockchain for consensus. Sometimes referred to as a “Layer 3” , or “L3” . See also: “blockchain trilemma” , “modular blockchain” , “Layer 2”.

Application Binary Interface (ABI): A JSON file that defines the functions and variables included in a smart contract. The ABI allows bytecode to be mapped into human-readable formats.

APR: APR, or Annual Percentage Rate, reflects the yearly cost of borrowing money, including interest and fees, as a percentage.

ASIC (Application Specific Integrated Circuit): ASICs are silicon chips designed to do a specific task. In ASICs used for mining cryptocurrencies, the ASIC will perform a calculation to find values that provide a desired solution when placed into a hashing algorithm.

ASIC: Application-specific integrated circuit. This usually refers to an integrated circuit, custom-built for cryptocurrency mining.

assert: In Solidity, `assert(false)` compiles to `0xfe`, an invalid opcode, which uses up all remaining gas and reverts all changes. When an `assert()` statement fails, something very wrong and unexpected is happening, and you will need to fix your code. You should use `assert()` to avoid conditions that should never, ever occur.

Attestation: A claim made by an entity that something is true. In context of Ethereum, consensus validators must make a claim as to what they believe the state of the chain to be. At designated times, each validator is responsible for publishing different attestations that formally declare this validator's view of the chain, including the last finalized checkpoint and the current head of the chain.

attestation: Under the Proof of Stake mechanism (on Ethereum Proof of Work), every validator other than the one proposing a new block will provide an attestation, or vote, in favor of a block with which it agrees, hereby forming consensus and confirming the block and the transactions it contains. See also ‘Proof of Stake’.

Base fee: Every block has a reserve price known as the 'base fee'. It is the minimum gas fee a user must pay to include a transaction in the next block.

Beacon Chain: The Beacon Chain was one element built in the infrastructure being built to scale Ethereum. It was the foundation for a transition from a Proof of Work (PoW) consensus mechanism to Proof of Stake (PoS).

Beacon chain: The Beacon Chain was the blockchain that introduced proof-of-stake and validators to Ethereum. It ran alongside the proof-of-work Ethereum Mainnet from December 2020 until the two chains were merged in September 2022 to form the Ethereum of today.

Big-endian: A positional number representation where the most significant digit is first in memory. The opposite of little-endian, where the least significant digit is first.

Bitcoin / bitcoin (BTC): The first cryptocurrency based on a Proof of Work (PoW) blockchain. Bitcoin was created in 2009 by Satoshi Nakomoto — a pseudonym for an individual whose real identity is unknown — and the concept of cryptocurrency was outlined in a white paper titled “Bitcoin: A Peer-to-Peer Electronic Cash System.  ” Use “Bitcoin” for the blockchain/network; “bitcoin” for the cryptocurrency. The plural of bitcoin is just bitcoin; the abbreviation is BTC, with a space: I have 250 BTC.

Block explorer: An interface that allows a user to search for information from, and about, a blockchain. This includes retrieving individual transactions, activity associated with specific addresses and information about the network.

Block header: The block header is a collection of metadata about a block and a summary of the transactions included in the execution payload.

block height: The number of blocks connected together in the blockchain. For example, Height 0 would be the very first block, which is also called the Genesis Block.

Block propagation: The process of transmitting a confirmed block to all other nodes in the network.

Block proposer: The specific validator chosen to create a block in a particular slot.

Block reward: The amount of ether rewarded to the proposer of a new valid block.

block reward: The reward given to a miner or validator after it has successfully hashed a transaction block.  Block rewards can be a mixture of coins and transaction fees. The composition depends on the policy used by the cryptocurrency in question, and whether all of the coins have already been successfully mined. The current block reward for the Bitcoin network is 12.5 bitcoins per block.

Block status: The states that a block can exist in. The possible states include: proposed: the block was proposed by a validator scheduled: validators are currently submitting data missed/skipped: the proposer did not propose a block within the eligible time frame orphaned: the block was reorg'd out by the fork choice algorithm.

Block time: The time interval between blocks being added to the blockchain.

block time: When we talk about ‘block time’ , we’re referring to how long it takes for a block of transactions (see ‘block’) to be confirmed by the network, either by miners under PoW or by validators under PoS. See also ‘Proof of Work’ , ‘Proof of Stake’.

Block validation: The process of checking that a new block contains valid transactions and signatures, builds on the heaviest historical chain (meaning the one that has accumulated the most attestations in its history), and follows all other consensus rules. Valid blocks are added to the head of the chain and propagated to others on the network. Invalid blocks are disregarded.

Block: A block is where transactions or digital actions are stored. Once a block is full, it gets linked to the previous one, creating a chain of blocks or a "blockchain".  A block is a bundled unit of information that includes an ordered list of transactions and consensus-related information. Blocks are proposed by proof-of-stake validators, at which point they are shared across the entire peer-to-peer network, where they can easily be independently verified by all other nodes. Consensus rules govern what contents of a block are considered valid, and any invalid blocks are disregarded by the network.  The ordering of these blocks and the transactions therein create a deterministic chain of events with the end representing the current state of the network.

block: Think of a blockchain as consisting of a ledger that is being constantly updated, and those changes synced between any number of different nodes (in fact, “distributed ledger technology” is another phrase used to describe it).After a certain number of transactions have been added to the ledger and consensus has been reached among the nodes that the transactions are valid, they are then cryptographically locked into a “block” and officially recorded. This “block” forms the basis for the next one; in this way, they are all linked together in a chain, hence – blockchain.

blockchain explorer: A blockchain explorer is an application, most often a website along with a corresponding API, that displays information about blockchain activity in a more human-friendly way. While a blockchain is designed to keep information forever, and be “readable by anyone” , finding the specific information you’re interested in may require indexing data off the blockchain– that is, sorting it according to given categories (sender address, token type, etc) into a separate database which can then be queried by the user; this essential function is provided by blockchain explorers. A prominent example is etherscan, which also offers explorers on a number of other networks.

blockchain trilemma: The “blockchain trilemma” , as the name implies, is a difficult decision based on three elements: decentralization, security, and scalability (or speed). These are three elements that are either necessary or desireable in public distributed networks, and often, designing a system that optimizes for one compromises on another.

Blockchain: A blockchain is a database of transactions, duplicated and shared on all computers in the network, ensuring data cannot be altered retroactively.  A sequence of block , each linking to its predecessor all the way to the genesis block by referencing the hash of the previous block. The integrity of the blockchain is crypto-economically secured using a proof-of-stake- based consensus mechanism. What is a blockchain?

blockchain: A digital ledger comprised of unchangeable, digitally recorded data in packages called blocks. Each block is ‘chained’ to the next block using a cryptographic signature. Ethereum is a public blockchain, open to the world; its digital ledger is distributed, or synced, between many nodes; these nodes arrive at consensus regarding whether a transaction is valid before encrypting it, along with a number of other valid transactions, into a block. For more on blockchain technology, see here. See also ‘block’.

Bootnode: The nodes which can be used to initiate the discovery process when running a node. Bootnodes 'introduce' new nodes to other existing nodes so that they can quickly gain peers, rather than having to search for an initial peer. The endpoints of these nodes are usually provided in Ethereum client source code, but users can provide their own list of bootnodes.

bounty / bug bounty: A reward offered for exposing vulnerabilities and issues in computer code.

brain wallet: A blockchain account generated from a seed phrase or password or passphrase of your choosing. Humans are not capable of generating enough entropy, or randomness, and therefore the wallets derived from these phrases are insecure; brain wallets can be brute forced by super fast computers. For this reason, brain wallet are insecure and should not be used. See also ‘Seed phrase / Secret Recovery Phrase’.

Bridge: A blockchain bridge is used to transfer assets from one blockchain network to another. For example you can use bridge to transfer ETH from the main Ethereum network to cheaper Layer 2 scaling solutions.

bridge: A bridge is a tool built to move assets from one network to another. It’s also a verb, used to describe that action: “I bridged my ETH from Ethereum mainnet to Arbitrum.  ” Not all bridges are created equal, and you should be informed about what you’re doing before you use one.

BUIDL: Ostensibly coined (see what we did there) by Gitcoin’s Kevin Owocki. It reflects the Ethereum-focused mindset of not just investing in a cryptocurrency as a store of value, but rather investing in it as an ecosystem and a platform for public goods and software; it complements, in this sense, the now-infamous HODL.

bytecode: Bytecode is a “low-level” computer language, that is, meant to be processed by a computer, rather than a “high-level” , more human- readable, language. In Ethereum, higher-level Solidity is compiled into Ethereum bytecode, which is read by the Ethereum Virtual Machine (EVM).

Bytecode: Code expressed in a compact, numeric form so that it can be executed efficiently by the EVM.

Byzantine fault tolerance: A Byzantine fault, or failure, is one of the most difficult failures to deal with in computer systems; this is because it takes into account the possibility that the information used to determine the current state of the system may– or may not–be reliable.While applicable in many realms of technology, this becomes of particular interest in public blockchain systems: how do we ensure that we can agree on the current state of the network when there is an incentive, often a significant financial incentive, to subvert the state of the network for one’s own profit?  On a more basic level, if we’re coordinating a network running around the world on all kinds of different hardware and software, there are all kinds or problems that can occur that hinder the network’s ability to reach consensus on its current state. Therefore, a network that has been designed and implemented to be resistant to these sorts of failures, either due to malicious intent or technical failure, is said to be Byzantine Fault Tolerant.

Byzantium fork: A “hard fork” in the Ethereum network that occurred in October of 2017. For detailled information, see here; see also “hard fork”.

Byzantium fork: The first of two hard forks for the Metropolis development stage. It included EIP-649 Metropolis Difficulty Bomb Delay and Block Reward Reduction, where the Ice Age was delayed by 1 year and the block reward was reduced from 5 to 3 ether.

Casper FFG: Casper-FFG is a proof-of-stake consensus protocol used in conjunction with the LMD-GHOST fork choice algorithm to allow consensus clients to agree on the head of the Beacon Chain.

Checkpoint: The Beacon Chain has a tempo divided into slots (12 seconds) and epochs (32 slots). The first slot in each epoch is a checkpoint. When a supermajority of validators attests to the link between two checkpoints, they can be justified and then when another checkpoint is justified on top, they can be finalized.

client (Ethereum or other compatible blockchain): In computing in general, a ‘client’ is a program, running on a local computer, that is accessing data made available by a remote computer. In public blockchain networks, a ‘client’ is the software that actually does the work of syncing block data, confirming transactions, and participating in network consensus. A client usually includes a cryptocurrency software wallet. Consensys has supported efforts to maintain the Ethereum clients of Besu and Teku.

Codefi: Derived from “Commerce & Decentralized Finance”, Codefi, part of Consensys, is builds applications for commerce and financial use cases.

coin: The term ‘coin’ has some nuances. Strictly speaking, a ‘coin’ could be defined as: A fungible token (all of them identical) issued on a blockchain, either as the network’s transactional token, or through a smart contract deployed to that network. Some people may use ‘coins’ as shorthand for ‘bitcoin’; the immortal aphorism ‘not your keys, not your coins’ refers to bitcoins. Another thing to keep in mind is that, while coins are put forward as some sort of representation of value, that value can vary wildly from one ‘coin’ to another. A coin may represent the value of the computational resources of the network, or it may be ‘pegged’ to represent fiat currency value, or it may float according to the value placed on immaterial resources like NFTs, membership, or digital goods, to name a few.

cold wallet / cold storage: An offline wallet that is never connected to the internet. These wallets protect cryptocurrencies from getting hacked online.

Committee: A group of at least 128 validators assigned to validate blocks in each slot.  One of the validators in the committee is the aggregator, responsible for aggregating the signatures of all other validators in the committee that agree on an attestation. Not to be confused with sync committee.  Computational infeasibility. A process is computationally infeasible if it would take an impracticably long time (e.g. billions of years) to do it for anyone who might conceivably have an interest in carrying it out.

Compiling: Converting code written in a high-level programming language (e.g., Solidity) into a lower-level language (e.g., EVM bytecode).More on compiling smart contracts

confirmation: A confirmation happens when a network has verified a blockchain transaction. Under a Proof of Work (PoW) consensus mechanism, this happens through a process known as mining; under Proof of Stake (PoS), the process is known as validation. Once a transaction is successfully confirmed, it theoretically cannot be reversed or double spent. The more confirmations a transaction has, the harder it becomes to perform a double spend attack.

Consensus client: Consensus clients (such as Prysm, Teku, Nimbus, Lighthouse, Lodestar) run Ethereum's proof-of-stake consensus algorithm allowing the network to reach agreement about the head of the Beacon Chain. Consensus clients do not participate in validating/broadcasting transactions or executing state transitions. This is done by execution clients. Consensus clients do not attest to, or propose new blocks. This is done by the validator client which is an optional add-on to the consensus client.

Consensus layer: Ethereum's consensus layer is the network of consensus clients.

Consensus rules: The block validation rules that full nodes follow to stay in consensus with other nodes. Not to be confused with consensus.

consensus: The process used by a group of peers, or nodes, on a blockchain network to agree on the validity of transactions submitted to the network.  Dominant consensus mechanisms are Proof of Work (PoW) and Proof of Stake (PoS).

Consensus: When more than 2/3 of the computers in a network agree that they have the same set of records, making sure everyone is on the same page. This isn't about the rules they follow, but making sure they all have the same information.

Consensys: Short for Consensus Systems, Consensys is the software engineering leader of the blockchain space. But you’re here, so you already knew that.

Constantinople fork: One of the “hard forks” made to the Ethereum network, in February 2019. See also “hard fork”.

Constantinople fork: The second part of the Metropolis stage, originally planned for mid-2018.  Expected to include a switch to a hybrid proof-of-work/proof-of-stake consensus algorithm, among other changes.

Contract account: An account containing code that executes whenever it receives a transaction from another account (EOA] or contract).

Contract creation transaction: A special transaction that includes a contract's initiation code. The recipient is set to `null` and the contract is deployed to an address generated from the user address and `nonce`. that is used to register a contract and record it on the Ethereum blockchain.

contract: See ‘smart contract’.

crypto bounties: Bounties paid for in cryptocurrency. See also “bug bounties”.

crypto-: Even though this prefix is originally Greek, our current usage comes from cryptography.  Technologies that are referred to with the blanket term of “crypto” tech are underlain by cryptographic tools and processes (such as public/private key pairs) that enable innovative functionality and security. Of course, “cryptocurrency” often gets shortened to simply “crypto” , so this emerging field is full of instances where something “crypto” is being added to or shortened. With the emergence of the term “Web3” , arguably a distinction has begun to be made between “crypto” , referring to DeFi and other financial use cases of the technology, while “Web3” refers to the transition of Internet-based activities to more decentralized practices and platforms.

crypto-compliance: A blanket term used to refer to ensuring crypto projects conform with applicable regulations and laws.

cryptoassets: A useful blanket term that covers on-chain assets: cryptocurrencies, NFTs, and other, still emerging, products.

cryptocurrency: Digital currency that is based on mathematics and uses encryption techniques to regulate the creation of units of currency as well as the verification of funds transfers. Cryptocurrencies operate independently of a central bank, and are kept track of through distributed ledger technology.

cryptoeconomics: The economic analysis of decentralized finance; notably, the MIT Cryptoeconomics Lab.

Cryptoeconomics: The study of mathematical and economic principles to design secure and trustworthy digital platforms. The goal is to ensure that all participants follow the rules and are rewarded for contributing to the network's security and operation.

cryptography: In its broadest sense, cryptography is the art of ‘hidden writing’ — using some sort of code to encrypt writing. In modern times, it often refers to the application of this concept within computing, communication, and data transfer through computers and computer networks.  Cryptography has been protected as free speech in the United States, and provides the technological foundation that allows blockchain networks to be pub l i c: despite the ledger being open and accessible by all, control over the state of the ledger and the ability to move assets on it is mediated through cryptographic tools, such as the Secret Recovery Phrase.

Cryptography: It is the practice of securing communication and data through the use of codes, so that only those for whom the information is intended can read and process it.  It involves techniques for encryption (converting readable information into an unreadable format) and decryption (converting it back into a readable format), ensuring confidentiality.

DAG: DAG stands for Directed Acyclic Graph. It is a data structure composed of nodes and links between them. Before The Merge, Ethereum used a DAG in its proof-of-work algorithm, Ethash, but is no longer used in proof-of- stake.

DAO: A Digital Decentralized Autonomous Organization (DAO, pronounced like the Chinese concept) is a powerful and very flexible organizational structure built on a blockchain.Alternatively, the first known example of a DAO is referred to as T h e DAO.  The DAO served as a form of investor-directed venture capital fund, which sought to provide enterprises with new decentralized business models. Ethereum-based, The DAO’s code was open source. The organization set the record for the most crowdfunded project in 2016.  Those funds were partially stolen by hackers.  The hack caused an Ethereum hard-fork which lead to the creation of Ethereum Classic.

Dapp: A dApp is a decentralized application that runs on a blockchain network, offering services without a central controlling authority. At a minimum dapp has a smart contract connected to a web interface. In addition, many dapps include decentralized storage and/or a message protocol and platform.

Data availability: Any node can independently verify transactions on a blockchain in order to maintain transparency and trust in the system.

Decentralization: The concept of moving the control and execution of processes away from a central entity.

decentralization: The transfer of authority and responsibility from a centralized organization, government, or party to a distributed network.

decentralized application (dapp): An open source software application with backend (not user-facing) code running on a decentralized peer-to-peer network, rather than a centralized server. You may see alternate spellings: dApps, DApps, Dapps, and Đapps.

Decentralized autonomous organization (DAO): A DAO is a digital organization run by rules coded on a blockchain, where decisions are made by member votes, not a central authority. Each member's voting power often tied to the number of tokens they hold.  DAOs aim to democratize decision-making and operations, focusing on transparency and community governance.

decentralized exchange (DEX): A decentralized exchange is a platform for exchanging cryptocurrencies based on functionality programmed on the blockchain (i.e., in smart contracts). The trading is peer-to- peer, or between pools of liquidity. This is in contrast with a centralized exchange, which is more akin to a bank or investment firm that specializes in cryptocurrencies. Additionally, there are so-called on-ramp providers, who could be compared to currency brokers, exchanging traditional “fiat” money for cryptocurrencies, and do not hold customer’s funds “on deposit” the way a centralized exchange does. There are important technical and regulatory differences between these, which are constantly evolving.

Decentralized exchange (DEX): A type of Ethereum app that lets you swap tokens with peers on the network. DEXes are not subject to geographical restrictions like centralized exchanges – anyone can participate.

DeFi: A broad category of Ethereum apps aiming to provide financial services backed by the blockchain, without any intermediaries.

DeFi: If cryptocurrency is Web3’s monetary system, its financial system is DeFi. This includes familiar concepts like loans and interest- bearing financial instruments, as well as so- called “DeFi primitives” , novel solutions like token swapping and liquidity pools.

Deposit contract: The gateway to staking on Ethereum. The deposit contract is a smart contract on Ethereum that accepts deposits of ETH and manages validator balances. A validator cannot be activated without depositing ETH into this contract. The contract requires ETH and input data. This input data includes the validator public key and withdrawal public key, signed by the validator private key. This data is needed for a validator to be identified and approved by the proof-of-stake network.

deposit: In most web3 contexts, ‘depositing’ refers to the act of transferring some amount of token(s) to an address other than one’s own, most often to a smart contract controlled by a ‘protocol’ , such as a decentralized exchange, video game or multiverse, DAO, etc. Generally, the user will receive something in return for their deposit, and the deposit can be claimed at the user’s discretion, or upon completion of given conditions. Compare with ‘stake’.

derive / derivation: To derive something is to obtain it from an original source. In the context of crypto- technology, we often discuss “deriving” wallets and accounts from seed phrases (aka Secret Recovery Phrases, or SRPs). This is literally true: the SRP represents a cryptographic key which is used to derive account addresses deterministically, meaning they will be derived the same way each time. Another, more technical, way of referring to this technology is to refer to “hierarchical deterministic” wallets.

Devcon: This is shorthand for the Ethereum Developers’ Conference.

Difficulty bomb: Planned exponential increase in proof-of-work difficulty setting that was designed to motivate the transition to proof-of-stake, reducing the chances of a fork. The difficulty bomb was deprecated with the Merge.

difficulty bomb: The difficulty bomb, along with the Beacon Chain and others, was a key element of Ethereum’s upgrade to Ethereum 2.0 and a Proof of Stake (PoS) consensus mechanism. As the name indicates, the difficulty bomb was a software mechanism that increased block verification difficulty, making it more expensive and difficult–eventually, prohibitively so–to mine a new block. Through economic incentive, and later, the raw limitations of computing power, this forced the shift to PoS consensus. See also ‘Proof of Stake’ , ‘the Merge’.

Difficulty: A network-wide setting in proof-of-work networks that controls how much average computation is required to find a valid nonce. The difficulty is represented by the number of leading zeroes that are required in the resulting block hash for it to be considered valid. This concept is deprecated in Ethereum since the transition to proof-of-stake.

difficulty: The concept outlining how hard it is to verify blocks in a blockchain network during Proof of Work mining. In the Bitcoin network, the difficulty of mining adjusts every 2016 blocks.  This is to keep block verification time at ten minutes.

digital asset: A digital commodity that is scarce, electronically transferable, and intangible with a market value.

digital identity: An online or networked identity adopted by an individual, organization, or electronic device.

digital signature: A code generated by public key encryption and attached to an electronically transmitted document in order to verify the contents of the document.

Digital signature: A short string of data a user produces for a document using a private key such that anyone with the corresponding public key, the signature, and the document can verify that (1) the document was "signed" by the owner of that particular private key, and (2) the document was not changed after it was signed.

Discovery: The process by which an Ethereum node finds other nodes to connect to.  Distributed hash table (DHT) A data structure containing `(key, value)` pairs used by Ethereum nodes to identify peers to connect to and determine which protocols to use to communicate.

Distributed Denial of Service (DDoS) Attack: A type of cyber-attack in which the perpetrator continuously overwhelms the system with requests in order to prevent service of legitimate requests.

distributed ledger: A type of database which spreads across multiple sites, countries, or institutions. Records are stored sequentially in a continuous ledger.  Distributed ledger data can be either “permissioned” or “unpermissioned” , determining who can view it. This term is used, often, to refer in general to public blockchain technology, as ‘crypto’ has come to mean ‘cryptocurrency’ , ‘web3’ is the collective community, and ‘blockchain’ , after all, is “just” the data structure used to sync the distributed ledger itself .

Double spend: A deliberate blockchain fork, where a user with a sufficiently large amount of mining power/stake sends a transaction moving some currency off- chain (e.g. exiting into fiat money or making an off-chain purchase) then reorganizing the blockchain to remove that transaction. A successful double spend leaves the attacker with both their on and off-chain assets.

double spend: The ‘double spend’ is the benchmark security concern of blockchain networks: how do we ensure that someone doesn’t send the same transaction to two different entities, essentially “spending their money twice”? This is the cornerstone of the consensus m ech ani sm, ensuring that all nodes of the network are “in agreement” about which assets are allocated to which addresses, on an ongoing basis, to prevent malicious actions such as a double spend.

Ð: Ð (D with stroke) is used in Old English, Middle English, Icelandic, and Faroese to stand for an uppercase letter “Eth”. It is used in words like ÐEV or Ðapp (decentralized application), where the Ð is the Norse letter “eth”.  The uppercase eth (Ð) is also used to symbolize the cryptocurrency Dogecoin. This is commonly seen in older Ethereum literature but is used less often today.

EIP (Ethereum Improvement Proposal): The EIP process is a public and open process through which suggestions are made as to how to change (and hopefully, improve) the way the Ethereum network functions as a whole; the official repository is here. Individual EIPs are referred to by the name assigned to them in the repository, for example, EIP-1559. Keep in mind that as it is an iterative, lengthy process, some EIPs never get fully approved, and some do, and many end up somewhere in a gray area of ‘partially implemented’.

Elliptic Curve Digital Signature Algorithm (ECDSA): A cryptographic algorithm used by Ethereum to ensure that funds can only be spent by their owners. It's the preferred method for creating public and private keys. Relevant for account address generation and transaction verification.

encrypted vs unencrypted keys: As discussed elsewhere, public and private cryptographic key pairs are one of the technologies that underpins cryptocurrencies and “crypto” tech in general. In MetaMask, an unencrypted private key is 64 characters long, and it is used to unlock or restore wallets. An encrypted key is also 64 letters long and is a regular private key that has gone through the process of encryption. Usually, encrypted private keys are kept within the extension or device they are encrypted by, and they remain out of sight from the user. This is meant to add another layer of security to keep a user’s wallet information safe.By way of example: if the world ‘Apple’ was your private key, then it was encrypted three letters down the alphabet, your new encrypted key would be ‘Dssoh’ . Since you know the way to encrypt this key, you could derive the original private key from it by reversing the method of encryption.

encryption: Encrpytion, literally ‘in a hidden place’, is the art and science of encoding information to control who can read it, or how it is to be read.  Encryption occurs in natural (human) languages, as well as in machine and computer languages.  Highly complex, and therefore difficult to decipher, encryption is an essential element enabling blockchain networks to be simultaneously public and secure.  Enterprise Ethereum Alliance (EEA) A group of Ethereum core developers, startups, and large companies working together to commercialize and use Ethereum for different business applications.

Encryption: Encryption is the conversion of electronic data into a form unreadable by anyone except the owner of the correct decryption key.

ENS: The Ethereum Name Service is a protocol, managed by a DAO, which assigns human- readable and easy-to-remember addresses to Ethereum addresses and assets, homologous to the traditional internet’s DNS.

Entropy: In the context of cryptography, lack of predictability or level of randomness. When generating secret information, such as private keys, algorithms usually rely on a source of high entropy to ensure the output is unpredictable.

entropy: In the context of cryptography, ‘entropy’ refers to ‘randomness’; generally, the more random something is (the more entropy it has), the more secure it is.

Epoch: A period of 32 slots, each slot being 12 seconds, totalling 6.4 minutes.  Validator committees are shuffled every epoch for security reasons. Each epoch has an opportunity for the chain to be finalized. Each validator is assigned new responsibilities at the start of each epoch.

epoch: An epoch, in general, is a measure of time, or of blockchain progression, on a given blockchain.  In Ethereum Proof of Stake, an epoch consists of 32 slots, each lasting 12 seconds, for a total of 6.4 minutes per epoch. There is additional functionality built upon the epoch measure in the Beacon Chain to help ensure security and proper operation of the Chain.

Equivocation: A validator sending two messages that contradict each other. One simple example is a transaction sender sending two transactions with the same nonce. Another is a block proposer proposing two blocks at the same block height (or for the same slot).

ERC-1155: ERC-1155 is a newer type of Ethereum token standard similar to NFT (like unique collectible items) that also allows to create interchangeable items (like currency) within a single smart contract.  This makes it easier and more efficient to manage various types of digital assets, especially for applications like video games or digital collections.

ERC-20 Token Standard: ERC is the abbreviation for E t h ereum R e quest f or C omm ent and is followed by the assignment number of the standard. ERC-20 is a technical standard for smart contracts which is used to issue the majority of tokens (in particular, cryptocurrency tokens) extant on Ethereum. This list of rules states the requirements that a token must fulfill to be compliant and function within the Ethereum network.

ERC-20: ERC-20 is the standard that most tokens on Ethereum network use for their creation.  Popular examples are stablecoins like DAI and USDC or exchange tokens like UNI from Uniswap. Akin to any form of alternative moneys that we have in traditional systems… ie. rewards points, credit systems, or even stocks, etc.

ERC-721 Token Standard: As stated above, this is another standard for Ethereum smart contracts, which allows for the issuance of a n on-f un gi b l e t ok en: this is the standard that created what we all now know as an NFT. This token standard is used to represent a unique digital asset that is not interchangeable, as opposed to the ERC-20 (or other equivalent) standard, which issues identical, interchangeable tokens.

ERC-721: NFTs (non fungible tokens) are created using a standard set of rules referred to as ERC-721.  NFT tokens can represent ownership of anything unique, like digital art or collectibles, with each token having its own special characteristics and value. Each NFT is unique and easily distinguishable from any other NTF.

ERC: Ethereum Request for Comment, or ERC, is a bit of a misnomer, as it is used to refer to suggestions for modifications that have already made it through the Ethereum Improvement Protocol (EIP) process and have been made standard on Ethereum. An ERC is, essentially, a set of standards for a given operation or topic on the Ethereum network.

Eth1: 'Eth1' is a term that referred to Mainnet Ethereum, the existing proof-of- work blockchain. This term has since been deprecated in favor of the 'execution layer'. Learn more about this name change.

Eth2: 'Eth2' is a term that referred to a set of Ethereum protocol upgrades, including Ethereum's transition to proof-of-stake. This term has since been deprecated in favor of the 'consensus layer'. Learn more about this name change.

Ethash: A proof-of-work algorithm that was used on Ethereum before it transitioned to proof-of-stake. Read more

ether (denominations): There are a number of denominations of the currency we know as ‘ether’ or ETH; for the definitive explanation.

ether (ETH): Ether is the native currency of the Ethereum blockchain network. Ether—also referred to as ETH (pronounced with a long “e” , like “teeth” without the “t”)—functions as a fuel of the Ethereum ecosystem by acting as a medium of incentive and form of payment for network participants to execute essential operations.  The cryptocurrency of Ethereum has a lowercase e. The plural of ether is just ether; its abbreviation is ETH, with a space: I have 10 ETH. (nice!)

Ether: The native cryptocurrency of Ethereum, commonly referred to as “ETH”. It is used to cover transaction fees when using Ethereum ecosystem and applications.

Ethereum Improvement Proposal (EIP): A design document providing information to the Ethereum community, describing a proposed new feature or its processes or environment (see ERC). Introduction to EIPs

Ethereum Name Service (ENS): Ethereum Name Service is like an internet phonebook for Ethereum addresses. Instead of using long wallet addresses, ENS lets you use simple names like "john.eth" to send and receive digital money and assets.  Technical: The ENS registry is a single central contract that provides a mapping from domain names to owners and resolvers, as described in EIP-137. Read more at ens.domains.

Ethereum Request for Comments (ERC): ERC (Ethereum Request for Comments) is a type of technical documentation used in the Ethereum community to propose new standards of usage for the Ethereum network.  These proposals can cover a wide range of topics, including new token standards (like ERC-20 used for tokens and ERC-721 for NFTs).

Ethereum Virtual Machine (EVM): A stack-based virtual machine that executes bytecode. In Ethereum, the execution model specifies how the system state is altered given a series of bytecode instructions and a small tuple of environmental data. This is specified through a formal model of a virtual state machine.

Ethereum: A public blockchain network and decentralized software platform upon which developers build and run applications. As it is a proper noun, it should always be capitalized.

Etherscan: A popular website for analyzing activity on the Ethereum blockchain. See ‘blockchain explorer’.

Events: Allows the use of EVM logging facilities. Dapps can listen for events and use them to trigger JavaScript callbacks in the user interface.

EVM (Ethereum Virtual Machine): The EVM is a virtual machine that operates on the Ethereum network. It is Turing complete and allows anyone, anywhere to execute arbitrary EVM bytecode. All Ethereum nodes run on the EVM. It is home for smart contracts based on the Ethereum blockchain.

EVM assembly language: A human-readable form of EVM bytecode.

exchange: A place to trade cryptocurrency. Centralized exchanges, operated by companies like Coinbase and Gemini, function as intermediaries, while decentralized exchanges do not have a central authority.

Execution client: Execution clients (formerly known as "Eth1 clients"), such as Besu, Erigon, Go-Ethereum (Geth), Nethermind, are tasked with processing and broadcasting transactions and managing Ethereum's state. They run the computations for each transaction using the Ethereum Virtual Machine to ensure that the rules of the protocol are followed.

Execution layer: Ethereum's execution layer is the network of execution clients.

Externally owned account (EOA): Externally Owned Accounts (EOAs) are the most common type of Ethereum account. They are controlled by a person through private keys/recovery phrase.

Fallback function: A default function called in the absence of data or a declared function name.

faucet: A faucet is an application, sometimes a very simple website, other times more complex, that dispenses cryptocurrency. While some networks, especially those in early launch stages, offer “real Mainnet” tokens via faucets, it is much more common for a faucet to be present on a test network, or testnet. These faucets are used by developers to test out dapps or smart contracts before deploying them on Ethereum Mainnet, or users who want to practice an action on the blockchain with no risk. Tokens dispensed by a test faucet stay on the test networks and cannot be exchanged for mainnet equivalents.

Faucet: A service carried out via smart contract that dispenses funds in the form of free test ether that can be used on a testnet.

fiat currency: Government-issued currency. For example, US Dollars (USD), Euros (EUR), Yuan (CNY), and Yen (JPY).

final, finality: A transaction is considered “final” once it can no longer be changed. In a sense, this happens once there are sufficient confirmations of the transaction, but for all intents and purposes, a transaction is final once the block that contains it is mined or validated. Keep in mind that this reflects a fundamental rule of blockchains: unlike traditional financial systems where charges can be “reversed” , there is no “undoing” a transaction on the blockchain.  Once finality is reached, the transaction is immutable.

Finality: Finality is the guarantee that a set of transactions cannot be changed without a huge amount of ETH being lost.

Finney: A denomination of ether. 1 finney = 1015 wei. 103 finney = 1 ether.

finney: A denomination of ether. See ether (denomination).

Fork choice algorithm: The algorithm used to identify the head of the blockchain. On Ethereum the head of the chain is identified as the fork with the greatest 'weight' of attestations. The weight is the product of the number of attestations and the effective balance of the attesting validators. This means the true head of the chain is the one that most staked ether has voted for. On the consensus layer the fork choice algorithm is called LMD GHOST.

Fork: A change in protocol causing the creation of an alternative chain.

fork: ‘Forking’ is a term that comes from the world of collaborative software development, and refers to the action of copying an existing application or set of code and modifying it to create an alternate version. At the blockchain protocol level, a ‘fork’ creates an alternative version of a blockchain. Forks are often enacted intentionally to apply upgrades to a network.  Soft Forks render two chains with some compatibility, while Hard Forks create a new version of the chain that must be adopted to continue participation. In the instance of a contentious Hard Fork, this can create two versions of a blockchain network. See also “hard fork”.

Fraud proof: A security model for certain layer 2 solutions where, to increase speed, transactions are rolled up into batches and submitted to Ethereum in a single transaction. Other network participants can re-execute the transactions to check that they were executed honestly. If they uncover a discrepancy between the posted data and their own version they can post a cryptographic proof that demonstrates where some fraud took place.  Some rollups use validity proofs.

Frontier: The initial test development stage of Ethereum, which lasted from July 2015 to March 2016.

gas limit: The gas limit is the maximum amount you’re willing to pay for any given transaction to go through the Ethereum network. Another way of looking at it is as a “rough estimate” of how much computing power your transaction will take.

Gas limit: The maximum amount of gas a transaction or block may consume.

Gas price: Price in ether of one unit of gas specified in a transaction.

gas price: The gas price is what it sounds like: the cost the network is paid for the computational work being performed in a given transaction. It is paid in units of ETH called gwei. Depending on network congestion, the gas price may vary significantly.

gas: A measure of the computational steps required for a transaction on the Ethereum network. This then equates to a fee for network users paid in small units of ETH specified as gwei. See also “ether (denominations)”.

Gas: Gas is the fee paid for transactions and smart contracts on a blockchain, like Ethereum.

Genesis block: The first block in a blockchain, used to initialize a particular network and its cryptocurrency.

genesis block: The initial block of data computed in the history of a blockchain network.

Geth: Go Ethereum. One of the most prominent implementations of the Ethereum protocol, written in Go. Read more at geth.ethereum.org

gwei: A minuscule and common denomination of ETH, and the unit in which gas prices are often specified. See ‘ether (denominations)’ entry for more information.

Gwei: Short for gigawei, a denomination of ether, commonly utilized to price gas.  1 gwei = 10^9 wei. 10^9 gwei = 1 ether.

halving: Many cryptocurrencies have a finite supply, which makes them a scarce digital commodity.  For example, the total amount of bitcoin that will ever be issued is 21 million. The number of bitcoins generated per block is decreased 50% every four years. This is called “halving.  ” The final halving will take place in the year 2140.

hard fork: A hard fork occurs when there is a change in the blockchain that is not backward compatible (not compatible with older versions), thus requiring all participants to upgrade to the new version in order to be able to continue participating on the network. See also “fork”.

Hard fork: A permanent divergence in the blockchain; also known as a hard-forking change. One commonly occurs when nonupgraded nodes can't validate blocks created by upgraded nodes that follow newer consensus rules. Not to be confused with a fork, soft fork, software fork, or Git fork.

hardware wallet: A hardware wallet is a physical device that is used to store cryptographic keys, and generally, sign transactions. Some hardware wallets can be connected physically or through software to internet connectivity; others are ‘air-gapped’ , receiving transaction requests and sending transaction approvals through a mechanism such as a QR code. The overall goal of using a hardware wallet to manage keys and signatures is to reduce the likelihood of your keys or Secret Recovery Phrase from being somehow stolen or compromised, due to being connected to the Internet.

Hash rate: The number of hash calculations made per second by computers running mining software.

Hash: A fixed-length fingerprint of variable-size input, produced by a hash function. (See keccak-256).

hash: In computing, ‘hashing’ is an operation performed on lists or sets of data to create a reliable index for that data. A particular datum, or a reference to it, is fed into an algorithm, which transforms the datum and returns a standardized, and generally unrecognizable, ‘hash’ of it, sometimes referred to as that datum or file’s “digital fingerprint.  ” Each block in a blockchain contains the hash value that validated the block before it, followed by its own hash value (this is how the continuity of the ‘chain’ is constructed). Hashes can be used to confirm that blockchain transactions are complete and valid. You may see references to the “transaction hash” or “tx hash”; this should be understood as “unique identifier of the transaction”.

HD wallet: Hierarchical Deterministic wallets were first created for Bitcoin, and enable the creation of a very large number of accounts based on an initial seed phrase. This technology was later adopted in Ethereum wallets; when restoring a MetaMask wallet from the Secret Recovery Phrase, for example, if you “create” accounts, they will be the same accounts as previously created from that same phrase; they are derived from it.

hexadecimal: Hexadecimal is a base 16, rather than base 10, counting system. Used all over Ethereum for a variety of things, a hexadecimal string is comprised of the numbers 0 1 2 3 4 5 6 7 8 9 and letters A B C D E F.

Holographic consensus: Refers to how a big group decision is made by letting a smaller group of representative people vote. Then everyone else agrees to go along with it, as long as they trust the small group did a good job.  It's used in some online communities to make decisions quickly without needing everyone to vote on everything, while still making sure the decisions are fair and represent what most people want.

Homestead: The second development stage of Ethereum, launched in March 2016 at block 1,150,000.

hot wallet / hot storage: A wallet that is directly connected to the internet at all times; for example, one that is held on a centralized exchange. Hot wallets are considered to have lower security than cold storage systems or hardware wallets.

Hyperledger: Hyperledger is an ecosystem of open-system tools, libraries, and products designed to enable and support enterprise-grade blockchain technology. In general, the products focus on creating solutions for permissioned blockchains–that is, non-public blockchains, with alternative consensus mechanisms other than Proof of Work (PoW) or Proof of Stake (PoS).That said, there are use cases where such institutions would want to integrate with public blockchains, and for that reason Hyperledger Besu and Hyperledger Burrow are actively developed projects, the former being a Java- based Ethereum client, the latter being a smart contract platform which supports EVM bytecode.

ICO: An Initial Coin Offering (also called ICO) occurs when a new token project sells advance tokens in exchange for upfront capital. These have been a vehicle for fraud and scams, and as such are subject to ever-evolving regulation and legislation.

Identicon / AddressIdenticon / AddressIcon: The colorful blob of colors that corresponds to your address in MetaMask. It is an easy way to see if your address is correct. More specifically, you can choose between jazzicons (created by the MetaMask team!) or blockies.

immutability: The inability to be altered or changed. This is a key element of blockchain networks: once written onto a blockchain ledger, data cannot be altered. This immutability provides the basis for commerce and trade to take place on blockchain networks.

Immutable deployed code problem: Once a contract's (or library's) code is deployed, it becomes immutable.  Standard software development practices rely on being able to fix possible bugs and add new features, so this represents a challenge for smart contract development.

Index: A network structure meant to optimize the querying of information from across the blockchain by providing an efficient path to its storage source.

Infura: Part of Consensys, Infura offers backend access to the Ethereum network over established HTTP and WebSockets technology. Prior to Infura, developers were obligated to run their own nodes of the networks with which they wanted to interact; Infura provides that access through a set of APIs. This enables developers of dapps and websites seeking to interact with the Ethereum blockchain to do so, and at scale.

Integrated development environment (IDE): A user interface that typically combines a code editor, compiler, runtime, and debugger.

Internal transaction: A transaction sent from a contract account to another contract account or an EOA (see message).

internal transaction: An internal transaction on the Ethereum network is one that occurs between smart contracts, rather than between addresses.  Notably, they are not included on the blockchain, and therefore do not incur gas fees, but they are often crucial to carrying out the action in question, and can be viewed on Etherscan. For more detail, see MetaMask’s article on the topic.

InterPlanetary File System (IPFS): A decentralized file storage and referencing system for the Ethereum blockchain, and the internet as a whole. IFPS is an open source protocol that enables storing and sharing hypermedia (text, audio, visual) in a distributed manner without relying on a single point of failure. This distributed file system enables applications to run faster, safer and more transparently.

Issuance: The minting of new ether to reward block proposal, attestation and whistle-blowing.

JSON-RPC: JSON-RPC is, quite simply, a method used to move data around computer systems, and predates public blockchain technology. It was chosen as a standard for moving data between blockchain networks and Internet browsers and wallets, with the result that these networks have come to be called ‘RPC networks’ , despite JSON-RPC not being their defining technical feature.

Keccak-256: Cryptographic hash function used in Ethereum. Keccak-256 was standardized as SHA-3.

Key derivation function (KDF): Also known as a "password stretching algorithm," it is used by keystore formats to protect against brute-force, dictionary, and rainbow table attacks on passphrase encryption, by repeatedly hashing the passphrase.

Key: In the context of Ethereum, keys are digital codes: a public key for receiving transactions and a private key for accessing and sending funds.  Public keys: These can be shared openly.  Private keys: These are kept secret by the owner.

keystore file: A keystore file is a special, encrypted version of a private key in JSON format. See also ‘private key’.

Keystore: Every account’s private key/address pair exists as a single keyfile in an Ethereum client. These are JSON text files which contains the encrypted private key of the account, which can only be decrypted with the password entered during account creation.

Know Your Customer (KYC): A process in which a business must verify the identity and background information (address, financial details, etc.) of their customers. For example, current regulations and laws require banks and other financial institutions to keep and report customers’ personal information and transactions.

Layer 1: Layer 1 refers to the main blockchain in a multi-level blockchain network.  For example, Ethereum and Bitcoin are layer one blockchains. Many layer two blockchain offload resource-intense transactions to their separate blockchain, while continuing to use Ethereum's or Bitcoin's layer one blockchain for security purposes.

Layer 2: A Layer 2 network, or L2, is a blockchain that is built specifically to scale another network. For a full understanding of how this is achieved, see here. Some popular examples of this in the Ethereum ecosystem are Arbitrum, Optimism, and StarkNet. These chains are specifically built to handle a large number of transactions quickly by relying on Ethereum Mainnet for security functions, while optimizing for speed and scale. These networks are considered “scaling solutions” while not being part of Ethereum’s protocol-level scaling efforts. See also “blockchain trilemma” , “modular “Serenity” . Contrast with blockchain” , “sidechain”.

Layer 2: Layer 2s are another networks built on top of Ethereum main network to make transactions faster and cheaper.

Library: A special type of contract that has no payable functions, no fallback function, and no data storage. Therefore, it cannot receive or hold ether, or store data. A library serves as previously deployed code that other contracts can call for read-only computation.

Light client: An Ethereum client that does not store a local copy of the blockchain, or validate blocks and transactions. It offers the functions of a wallet and can create and broadcast transactions.

light client: In computing, a ‘client’ is a software that runs or accesses a program made available by a remote computer. With blockchain networks, then, clients are the programs that sync blockchain data and participate in network consensus.A light client downloads only a small part of the blockchain, allowing users of low- power or low-storage hardware like smartphones and laptops to maintain almost the same guarantee of security as a full node, despite only downloading part of the entire network state.

Liquid Democracy (Delegative Democracy): A government system where votes can be delegated or proxied to other individuals such as friends, politicians, or subject matter experts.  For example, in a liquid democracy, Bernadette could give Ahmad her vote and Ahmad would then vote for both himself and Bernadette.  Liquid democracy is used at times as a governance mechanism for Decentralized Autonomous Organizations (DAOs) wherein every participant is able to vote or delegate their vote to another individual.

Liquidity tokens: Liquidity tokens (LST) are digital tokens issued to participants who deposit assets into a liquidity pool, which is a collection of funds locked in a smart contract and used to facilitate trading on a decentralized exchange (DEX).  These tokens represent the participant's share of the pool and can be redeemed later for the initial deposit plus a portion of the trading fees generated by the pool's activity. Essentially, liquidity tokens serve as a proof of ownership or stake in a liquidity pool, allowing holders to earn rewards while providing the necessary liquidity for others to trade different cryptocurrency pairs efficiently.

liquidity: An asset is considered more ‘liquid’ if it can easily be converted into cash, and therefore, ‘liquidity’ refers to the availability of assets to a company or market. Conversely, the harder it is to turn an asset into cash, the more illiquid the asset. For example, stocks are considered relatively liquid assets, as they can be easily converted to cash while real estate is considered an illiquid asset. The liquidity of an asset affects its risk potential and market price.

Liquidity: Liquidity is how quickly and easily an asset can be converted into cash or another asset. Decentralized exchanges like Uniswap have multiple liquidity pools where asset holders can deposit their assets where traders can buy and sell them in a decentralized way in exchange for rewards.

LMD-GHOST: The fork-choice algorithm used by Ethereum's consensus clients to identify the head of the chain. LMD-GHOST is an acronym standing for "Latest Message Driven Greediest Heaviest Observed SubTree" which means that the head of the chain is the block with the greatest accumulation of attestations in its history.

Mainnet: Short for "main network," this is the main public Ethereum blockchain.

mainnet: The primary network where actual transactions take place on a specific distributed ledger. For example, The Ethereum Mainnet (capitalized in this case) is the public blockchain where network validation and transactions take place.

market cap: Short for ‘market capitalization’ , this refers to the total value held in a particular industry, market, company, or asset. For a publicly traded company, the market cap is the total dollar market value of a company’s outstanding shares. For Bitcoin or Ethereum, the total market cap is a reflection of the current existing supply times the market price.

Max Fee Per Gas: The Max Fee is the absolute maximum amount a user is willing to pay per unit of gas (gwei) to get a transaction included in a block.

Maximal Extractable Value (MEV): Originally known as Miner Extractable Value, MEV is a broad complex topic that refers to the inclusion, exclusion, and reordering of transactions within a block in order to extract more value from it, generally in excess of what a validator (or miner, on PoW networks) would earn from producing the block. MEV includes activities such as frontrunning, arbitrage, and what could be considered malicious actions to profit off of other users’ transactions. This is a very active topic of research that is changing rapidly.

Maximal Extractable Value (MEV): The maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block.

memory pool: Often abbreviated as “mempool” . See “transaction pool”.

Merge, the: Finalized in September 2022, the Merge was the culmination of years of work involved in transitioning Ethereum from a Proof of Work consensus model, to Proof of Stake, all while keeping the network live. This was successful, and reduced the network’s carbon footprint by more than 99.9%.

Merkle Patricia Tree (MPT): A data structure used in Ethereum to efficiently store key-value pairs.

Merkle Patricia trie: Often referred to simply as a “Merkle trie” (pronounced “tree”), a Merkle Patricia trie is a data structure in which a single hash code function (see ‘hash’) splits into smaller branches. In a similar way to a family tree, where a parent branch splits into child branches, which are then extrapolated into grandchild branches, a Merkle Patricia trie keeps a record of the filiation and history of each element. This type of data structure enables for faster verification on a blockchain network.

Merkle Root: A Merkle root is the single top hash of a Merkle tree. It verifies all transactions within a block.

Mesh: Consensys Mesh is a network of loosely coupled, tightly aligned teams, products, and investments advancing the Ethereum ecosystem and the arrival of web3.

Message call: The act of passing a message from one account to another. If the destination account is associated with EVM code, then the VM will be started with the state of that object and the message acted upon.

Message: An internal transaction that is never serialized and only sent within the EVM.

MetaMask: MetaMask, either in its mobile app form on iOS and Android, or in its browser extension form, is a tool to access and interact with blockchains and the decentralized web. It allows users to manage their digital identity and the permission of others to interact with that identity; its functions include that of a wallet, a dapp permissions manager, and access to token swaps. It is an open-source project that encourages developers from other projects to build on top of it through MetaMask Snaps.

Miner: A network node that finds valid proof-of-work for new blocks, by repeated pass hashing (see Ethash). Miners are no longer part of Ethereum - they were replaced by validators when Ethereum moved to proof-of-stake.

mining: The process by which blocks or transactions are verified and added to a blockchain using a Proof of Work (PoW) consensus mechanism. In order to verify a block, a miner must use a computer to solve a cryptographic problem.  Once the computer has solved the problem, the block is considered “mined” or verified. On Bitcoin or other PoW blockchains, the first computer to mine or verify the block receives bitcoin, or the equivalent network token, as a reward.

Mining: The process of repeatedly hashing a block header while incrementing a nonce until the result contains an arbitrary number of leading binary zeros.  This is the process by which new blocks are added to a proof-of-work blockchain. This was how Ethereum was secured before it moved to proof-of-stake.

Mint: Minting is the process of creating new tokens and bringing them into circulation so that they can be used. It's a decentralized mechanism to create a new token without the involvement of the central authority.

mnemonic phrase: This is an alternative way of referring to a Secret Recovery Phrase, also known as a ‘seed phrase’: a series of words that correspond to a very long cryptographic key, used to generate and control all the addresses of a crypto wallet.

modular blockchain: Bitcoin is an example of a monolithic blockchain: all of the functions of the network (consensus, execution, data availability, and settlement) are run on one chain. This has significant drawbacks (see “blockchain trilemma” for more). A modular blockchain, on the other hand, separates some or all of these functions into separate chains, each one optimized for its specific function, and relying on the other chains for the other functions.Ethereum is currently moving towards modularization, both on a protocol level beginning with the Merge, which split consensus and execution into two chains, and at the level of “Layer 2” networks which provide optimized execution environments, and then “roll up” their data to Ethereum for its consensus functionality.

multi-signature wallet (multisig): A crypto-asset wallet which requires multiple keys in order to access and transact. Typically, a specified number of individuals are required to approve or “sign” a transaction before they are able to access the wallet. This is different from most wallets, which only require one signature to approve a transaction.

Multisig: Multisig (multi signature) refers to a digital wallet or account that requires multiple signatures or approvals to execute transactions, enhancing security.  This adds extra security compared to traditional single-signature accounts where only one person's approval is needed.

Network hashrate: The collective hashrate produced by an entire mining network. Mining on Ethereum was switched off when Ethereum moved to proof-of-stake.

Network: Referring to the Ethereum network, a peer-to-peer network that propagates transactions and blocks to every Ethereum node (network participant).

NFT aggregator: In the initial wave of interest in buying and selling NFTs, a number of NFT marketplaces– websites where you can buy and sell NFTs–were created. As the market matured, aggregators appeared, which offer the user the ability to view available stock and price, buy, and sell across marketplaces from a single unified application. Similar to familiar web2 shopping portals, these have come to be known as NFT Marketplace Aggregators, or just NFT Aggregators.

NFT: When discussing Non-Fungible Tokens (NFTs), “fungibility” refers to an object’s ability to be exchanged for another. For example, an individual dollar is considered fungible, as one dollar is fully interchangeable with another.  Artwork is usually deemed non-fungible, as paintings or sculptures are likely to be unequal between them in quality, value, or other attributes. A non-fungible token is a type of token that is a unique digital asset and has no equal token. This is in contrast to cryptocurrencies like ether that are fungible in nature.

node (full node): Public blockchains consist of a network of computers which sync the network’s data, coordinate transaction requests, and participate in consensus regarding the validity of those transactions; each one of these computers is called a ‘node’ . A full node is a computer that can fully validate transactions and download the entire data of a specific blockchain. In contrast, a “lightweight” or “light” node does not download all pieces of a blockchain’s data, and uses a different validation process.

Node: A software client that participates in the network.

Non-fungible token (NFT): A unique digital item you can own, like art or collectibles, verified by blockchain technology.

Nonce: In cryptography, a value that can only be used once. An account nonce is a transaction counter in each account, which is used to prevent replay attacks.

nonce: The word ‘nonce’ has a few different meanings, and in different contexts, it ends up getting used a lot of different ways. Originally formed from a contraction of a phrase meaning “not more than once”, on the Ethereum Mainnet, “nonce” refers to a unique transaction identification number that increases in value with each successive transaction in order to ensure various safety features (such as preventing a double-spend). Note that due to its broader use in cryptography, you may encounter ‘nonce’ being used differently on other sidechains or decentralized projects.

Off-Chain: Off-chain means any transaction or data that exists outside the blockchain. Because committing every transaction on-chain can be expensive and inefficient, third-party tools like oracles that handle pricing data, or layer 2 solutions that execute a higher throughput of transactions, handle a bulk of the processing work off-chain, and will submit information on-chain at less frequent intervals.

Ommer (uncle) block: When a proof-of-work miner finds a valid block, another miner may have published a competing block which is added to the tip of the blockchain first. This valid, but stale, block can be included by newer blocks as ommers and receive a partial block reward. The term "ommer" is the preferred gender-neutral term for the sibling of a parent block, but this is also sometimes referred to as an "uncle". This was common for Ethereum when it was a proof-of-work network. Now that Ethereum uses proof-of-stake, only one block proposer is selected per slot.

ommer block: Under the Proof of Work (PoW) consensus mechanism, miners received rewards for being the first to mine a new block. However, at times a block would be mined just after, and in competition with, the last block. This block, known as an ommer and previously as an uncle, could get rolled into subsequent blocks and the miner of the original ommer would get a partial block reward. All of this functionality was deprecated as of the launch of the Beacon Chain.

On-Chain: Refers to actions or transactions that happen on the blockchain and are publicly available.  Think of it as writing something in a big, shared notebook that everyone can see and check, making sure that whatever is written (like sending digital money or making a contract) is permanent and can't be changed or erased.

on-ramp, off-ramp: Based on a metaphor from the American highway system, “on-ramp” refers to a tool, or a service provider, or the action, of converting fiat currency into tokens on a blockchain.  Conversely, “off-ramp” refers to exchanging on- chain assets for their value in a given fiat currency. There are many providers of such services, and MetaMask users have access to them through the “Buy Crypto” feature.

optimistic rollup: A rollup that assumes the validity and good faith of transactions, and only runs a fraud proof in the case of fraud being alleged. See also ‘rollup’.

Optimistic rollup: Optimistic Rollup is a Layer 2 solution that speeds up transactions on Ethereum, assuming they're valid by default unless challenged.

oracle: An oracle is a bridge between the blockchain and the real world. They act as on-chain APIs that can be queried for information and used in smart contracts.

oracle: Typically, an oracle is any entity or person that is relied on to report the outcome of an event.  In a blockchain network an oracle (human or machine) helps communicate data to a smart contract, which can then be used to verify an event or specific outcome.

P2P (peer-to-peer): P2P refers to interactions that happen directly between two parties, usually two separate individuals, and have been present in Internet technology in different ways for some time.  These interactions are often coordinated through some sort of app or network, which can consist of any number of individuals. Public blockchains can be considered to have a high degree of P2P functionality, as individuals are able to transact or interact with each other without relying on an intermediary or single point of failure.

parity: In a general sense, to say that something ‘has parity’ with another thing means ‘equal in features or other important quality’ , and is a phrase often used by software developers and computer scientists.Parity Technologies is the name of a blockchain technology company that is developing a number of significant projects in the blockchain space. One of its first projects was an Ethereum client, known as Parity; its name was changed to Parity Ethereum, and then was spun out as a DAO-owned and operated project called Open Ethereum, which has also been deprecated. See also ‘client’.

Peer-to-peer network: A network of computers (peers) that are collectively able to perform functionalities without the need for centralized, server-based services.  This setup is often used for sharing files (I.e. Bit torrent), information, or digital currencies, allowing for more direct and potentially more efficient exchanges between users.

Peer: Connected computers running Ethereum client software that have identical copies of the blockchain.

permissioned ledger: A blockchain network in which access to ledger or network requires permission from an individual or group of individuals, as opposed to a public blockchain. Permissioned ledgers may have one or many owners. Consensus on a permissioned ledger is conducted by the trusted actors, such as government departments, banks, or other known entities.  Permissioned blockchains or ledgers contain highly-verifiable data sets because the consensus process creates a digital signature, which can be seen by all parties. A permissioned ledger is much easier to maintain and considerably faster than a public blockchain. For example, Quorum or Hyperledger Besu are permissioned ledgers that can be more easily set up for large enterprises. In contrast, the public Ethereum blockchain is a permissionless ledger which anyone can access.

Permissionless: Permissionless means anyone can join and use a system like Ethereum.  It's open for everyone to participate and doesn't require any approval.

Plasma: An off-chain scaling solution that uses fraud proofs, like optimistic rollups.  Plasma is limited to simple transactions like basic token transfers and swaps.

Plasma: ‘Plasma’ is a term that is used to refer to one of the solutions being built and deployed in order to securely scale the Ethereum network. A Plasma network functions similarly to an optimistic rollup, inasmuch as it relies on Ethereum Mainnet to maintain the record of transactions, and as the source for arbitration or fraud resolution. However, a Plasma network differs in other important technical ways from rollups, and is currently limited to simple operations, such as swaps and token transfers.

PoA, PoS, PoW: Acronyms standing for Proof of X consensus mechanisms: Authority, Stake, Work. The “o” is lowercase since you wouldn’t capitalize “of” when writing out the phrase. See also ‘consensus’ , ‘Proof of Authority’ , ‘Proof of Stake’ , ‘Proof of Work’.

POAP: Proof of Attendance Protocol is used to create a digital collectible (NFT) that proves you attended a specific event or activity.

PoS/PoW Hybrid: A hybrid consensus model that utilizes a combination of Proof of Stake (PoS) and Proof of Work (PoW) consensus. Using this Hybrid consensus mechanism, blocks are validated from not only miners, but also voters (stakeholders) to form a balanced network governance.

private blockchain: A blockchain or distributed ledger that has a closed network wherein participants are controlled by a single entity. A private blockchain requires a verification process for new participants. A private blockchain may also limit which individuals are able to participate in consensus of the blockchain network. See also ‘permissioned ledger’.

Private chain: A fully private blockchain is one with permissioned access, not publicly available for use.

private currency: A currency or token issued by a private individual or firm. Typically, the token or currency is limited to use within the network of that particular firm or individual. This is not to be confused with a “privacy cryptocurrency” , which are cryptocurrencies with specific privacy features, such as hidden user identities.

Private key: A private key is a secret code that proves you own your digital money and lets you spend it, like a PIN for your account. DO NOT SHARE IT.

private key: A private key is an alphanumeric string of data that, in MetaMask, corresponds to a single specific account in a wallet. Private keys can be thought of as a password that enables an individual to control a specific crypto account.  Never reveal your private key to anyone, as whoever controls the private key controls the account funds. If you lose your private key, then you lose access to, and control over, that account.

Proof of Authority (PoA): A consensus mechanism used in private blockchains, granting a single private key the authority to generate all of the blocks or validate transactions.

Proof of Stake (PoS): A consensus mechanism in which an individual node, or “validator” , validates transactions or blocks. Validators lock up a certain amount of cryptocurrency, such as ether, into a ‘stake’ , in order to be able to participate in consensus. If the node validates a block (group of transactions) correctly, then the validator receives a reward. Conversely, if the validator behaves poorly by validating incorrect transactions or by not maintaining sufficient network connectivity, the cryptocurrency they staked can be ‘slashed’ , or taken from them and put out of circulation (‘burned’). PoS requires a negligible amount of computing power compared to Proof of Work consensus.

Proof of Work (PoW): A consensus mechanism in which each block is ‘mined’ by one of the nodes, or a group of nodes, on the network. The computational process involved in committing a series of transactions into a block on the network, known as ‘hashing a block’ , is technically quite simple, and therefore subject to attack. Under PoW, each miner must solve a math problem to find a set, difficult variable in order to be able to propose their block to the network as the next to be ‘mined’ . In effect, the process of hashing each block becomes a competition. This addition of solving for a target increases the difficulty of successfully hashing each block, and consequently the security of the network.For each hashed block, the overall process of hashing will have taken some time and computational effort. Thus, a hashed block is considered Proof of Work, and the miner that successfully hashes the block first receives a reward, in the form of cryptocurrency. PoW is singificantly more energy-intensive than other consensus mechanisms, such as Proof of Stake.

Proof-of-stake (PoS): A method by which a cryptocurrency blockchain protocol aims to achieve distributed consensus. PoS asks users to prove ownership of a certain amount of cryptocurrency (their "stake" in the network) in order to be able to participate in the validation of transactions.

Proof-of-work (PoW): A security mechanism for blockchains that requires nodes to expend energy in the form of computation to find a certain value.

Proto-Danksharding: A new transaction type which accepts "blobs" of data for Ethereum. This "blob" data is temporarily stored on the beacon chain for 4096 epochs (~18.2 days), and can optionally be pruned after to help reduce hardware requirements for node operators.

protocol: Formally speaking, a ‘protocol’ is a set of rules governing how a process is carried out. This concept is used throughout public blockchain networks and web3 to refer to the way smart contracts execute their functionality in the same way regardless of the user. The products or services built on top of smart contracts are often referred to as ‘protocols’ by extension.

public blockchain: A globally open network wherein anyone can participate in transactions, participate in the consensus protocol to help determine which blocks get added to the chain, maintain and examine the contents of the chain.

Public goods: Public goods are things everyone can use for free, like parks or clean air, and using them doesn’t stop others from using them too. Governments often provide these because businesses usually won’t, since they can’t easily charge people for using them.

Public key: A public key is a set of characters that lets others send you digital currency securely, like an email address for money.

public key: Public blockchain networks are just that: public.  Their data is accessible and readable by anyone. In order to have any degree of usability when it comes to allowing users to do some things, like send transactions, but not others, like steal other peoples’ tokens, cryptographic technology is used. In particular, a design paradigm known as ‘public/private key pairs’ is employed to ensure users can interact with others on the network as they wish, while keeping their own account secure.These key pairs consist of two long strings of alphanumeric characters. A public key can be derived mathematically from its corresponding private key, but the inverse is not true: it is mathematically impossible to derive a private key from its corresponding public key. This allows, for example, users to have a public wallet address that anyone can use to send them tokens, with the peace of mind that as long as they properly keep the corresponding private key safe, those tokens cannot be stolen.  See also ‘private key’.

Re-entrancy attack: An attack that consists of an attacker contract calling a victim contract function in such a way that during execution the victim calls the attacker contract again, recursively. This can result, for example, in the theft of funds by skipping parts of the victim contract that update balances or count withdrawal amounts.

Receipt: Data returned by an Ethereum client to represent the result of a particular transaction, including a hash of the transaction, its block number, the amount of gas used, and, in case of deployment of a smart contract, the address of the contract.

Recursive Length Prefix (RLP): An encoding standard designed by the Ethereum developers to encode and serialize objects (data structures) of arbitrary complexity and length.

relayer: In the field of Decentralized Finance (DeFi), a relayer is any party or entity which hosts an off- chain orderbook. Relayers help traders discover counter-parties and cryptographically move orders between them. 0x is an example of a popular Ethereum relayer protocol.

Remote procedure call (RPC): RPC lets one computer request data or action from another over a network, like asking for info with a remote control.

Reward: An amount of ether awarded to validators that perform certain functions, including proposing a block or participating in a sync-committee, in each slot.

Rollups: A type of layer 2 scaling solution that batches multiple transactions and submits them to the Ethereum main chain in a single transaction. This allows for reductions in gas costs and increases in transaction throughput.  There are Optimistic and Zero-knowledge rollups which use different security methods to offer these scalability gains.

rollups: Rollups (pronounced “roll ups”) are one element in the set of tools and infrastructure being built as scaling solutions for the Ethereum network.  They consist, in general, of networks which prioritize their ability to compute transactions and smart contract functionality, and then ‘roll up’ those transactions to Ethereum Mainnet for secure verification of their validity. There are different ways of approaching this problem from a technical point of view, namely Zero Knowledge, or ZK, rollups, and Optimistic rollups. Arbitrum and Optimism are prominent examples. See the entries on both of these types of rollup for more.

RPC: The Remote Procedure Call is a technology that is used to transfer data between endpoints. You may often see it referred to as JSON-RPC, which is a specific usage; see ‘JSON-RPC’ for further details.

rug pull: Similar to the traditional financial scam of a pyramid scheme, a ‘rug pull’ is a cryptocurrency or crypto-token based scam in which the creators of the token create hype, through injecting liquidity into their token, airdropping, and other schemes, and once investors pile in and boost the price of the token up to a certain point, the creators liquidate their (generally majority) share of the tokens, leaving their investors with next to nothing.

Satoshi Nakamoto: A pseudonymous individual or entity who created the Bitcoin protocol, solving the digital currency issue of the “double spend.  ” Nakamoto first published their white paper describing the project in 2008, and the first Bitcoin software was released one year later.

scalability: A change in size or scale to handle a network’s demands. This word is used to refer to a blockchain project’s ability to handle network traffic, future growth, and capacity in its intended application.

Secure Hash Algorithm (SHA): A family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST).

Seed (phrase) / Secret Recovery Phrase: The seed phrase, mnemonic, or Secret Recovery Phrase is a crucial part of public blockchain technology, originally created for Bitcoin, and goes by many names. However, they all refer to a set of ordered words which correspond to determined values. These values never change, and therefore the same string of words in the same order will always produce the same number–this is the underlying functionality that allows seed phrases to back up wallets. This is also where the name ‘hierarchical deterministic wallets’ comes from, as all the accounts in a given wallet are deterministically created from the seed phrase, and they are hierarchically controlled by it. A Secret Recovery Phrase is exactly what it sounds like: something that is secret, and should be known only to the owner of the account. If the seed phrase is given to someone else, that person has complete control over the account; they can drain it of tokens and funds, execute transactions with it, etc.

Seed phrase/recovery phrase: A list of words given to you when you create a digital wallet. It acts like a password that can help you get back into your wallet if you lose access, making sure you don't lose your digital money or tokens.

self-executing: Functioning by itself, not controlled by any other party other than itself. Self-executing smart contracts cut costs and overhead by removing the need for an arbitrator and trust toward a third party. See also ‘protocol’.

Sequencer: A sequencer is a program responsible for ordering transactions in a blockchain network, particularly within Layer 2 scaling solutions.

Serenity: The Ethereum network is working on a series of technical upgrades that will allow massive increases in transaction throughput, amongst other things. The plan that outlined these changes was originally referred to as ‘Serenity’ , although that name has become less popular, in favor of specific descriptions of the upgrades themselves.

Serialization: The process of converting a data structure into a sequence of bytes.

serialization: The process of converting a data structure into a sequence of bytes. Ethereum internally uses an encoding format called recursive-length prefix encoding (RLP).

Shard / shard chain: Shard chains are discrete sections of the total blockchain that subsets of validators can be responsible for. This was originally intended to be the way that Ethereum scaled to millions of transactions per second, but it has now been superseded by the rapid development of scaling using rollups.

sharding: Sharding, in public blockchains, refers to splitting an entire network into multiple portions, called “shards.  ” Each shard would contain its own independent state, meaning a unique set of account balances and smart contracts. Sharding is currently being investigated and developed as one of the set of tools and solutions for scaling Ethereum.

Sidechain: A scaling solution that uses a separate chain with different, often faster, consensus rules. A bridge is needed to connect these sidechains to Mainnet. Rollups also use sidechains, but they operate in collaboration with Mainnet instead.

sidechains: A ‘sidechain’ refers to a chain that is connected to another (most often, to Ethereum) through a bridge, allowing assets to be transferred between them. In contrast to a Layer 2 network or a rollup, a sidechain is a full blockchain network in and of itself, and does not rely on Ethereum for consensus. It therefore must be evaluated independently in terms of its security, stability, and other features. See also “blockchain trilemma” , “modular blockchain” .Note: Bridges exist for good reason; sending tokens from a sidechain to Ethereum mainnet or vice versa would result in token loss.

Signing: Demonstrating cryptographically that a transaction was approved by the holder of a specific private key.

Singleton: A computer programming term that describes an object of which only a single instance can exist.

Slasher: A slasher is an entity that scans attestations searching for slashable offenses. Slashings are broadcast to the network, and the next block proposer adds the proof to the block. The block proposer then receives a reward for slashing the malicious validator.

slashing condition: Under a Proof of Stake (PoS) consensus mechanism, a slashing condition is one that causes the validator’s deposit to be destroyed when they trigger it. See also ‘Proof of Stake’.

Slot: A period of time (12 seconds) in which new blocks can be proposed by a validator in the proof-of-stake system. A slot may be empty. 32 slots make up an epoch.

slot: A slot, under Ethereum Proof of Stake consensus, is a 12-second period of time during which a new block may (or may not) be proposed. Every 32 slots comprise an epoch.  See also ‘epoch’.

Smart contract: A smart contract is a program that automatically executes agreements on a blockchain, like a self-enforcing digital contract. Introduction to smart contracts.

smart contracts: Smart contracts are programs that have been published on a public blockchain, and can be used by anyone. While they often contain agreements or sets of actions between parties that emulate a traditional legal contract, they are not, in and of themselves, legal documents.  Smart contracts are automated actions that can be coded and executed once a set of conditions is met, and are the dominant form of programming on the Ethereum Virtual Machine.

SNARK: Short for "succinct non-interactive argument of knowledge", a SNARK is a type of zero-knowledge proof.

soft fork: A change to the blockchain protocol resulting in only previously valid blocks and transactions being made invalid. Since old nodes will recognize the new blocks as valid, a soft fork is backward-compatible. However, this can result in a potential divide in the blockchain, as the old software generates blocks that read as invalid according to the new rules. Contrast with ‘hard fork’; for more basic information regarding forks, see ‘fork’.

Soft fork: A divergence in a blockchain that occurs when the consensus rules change. Contrary to a hard fork, a soft fork is backwards compatible; upgraded nodes can validate blocks created by non-upgraded nodes as long as they follow the new consensus rules.

Solidity inline assembly: EVM assembly language in a Solidity program. Solidity's support for inline assembly makes it easier to write certain operations.

Solidity: A procedural (imperative) programming language with syntax that is similar to JavaScript, C++, or Java. The most popular and most frequently used language for Ethereum smart contracts. Created by Dr. Gavin Wood.

Solidity: The programming language developers use to write smart contracts on the Ethereum network.  Try it out on Remix. See also ‘smart contract’.

stablecoin: A cryptocurrency whose value has been ‘pegged’ to that of something considered a ‘stable’ asset, like fiat currency or gold. It theoretically remains stable in price, as it is measured against a known amount of an asset which should be less subject to fluctuation.  Always spelled as one word.

Stablecoin: A stablecoin is a type of cryptocurrency designed to have a stable value, often pegged to a currency or commodity (like US dollar), to minimize price volatility.

Staking pool: The combined ETH of more than one Ethereum staker, used to reach the 32 ETH required to activate a set of validator keys. A node operator uses these keys to participate in consensus and the block rewards are split amongst contributing stakers. Staking pools or delegating staking are not native to the Ethereum protocol, but many solutions have been built by the community.

Staking: Depositing a quantity of ether (your stake) to become a validator and secure the network. A validator checks transactions and proposes blocks under a proof-of-stake consensus model. Staking gives you an economic incentive to act in the best interests of the network. You'll get rewards for carrying out your validator duties, but lose varying amounts of ETH if you don't.

staking: On the Ethereum Proof of Stake network, those wishing to participate in consensus must first lock up, or ‘stake’ , 32 ETH into a smart contract; this ETH may be ‘slashed’ (taken from them and ‘burned’ , put out of circulation) in the event that their validator behaves maliciously or does not meet performance requirements. Similar Proof of Stake mechanisms are in operation on other networks, as well.Although this is the canonical meaning of the word, similar actions taken at the level of a decentralized exchange (DEX) or another dapp are often called ‘staking’ , though it would probably be more accurate and descriptive to just call this ‘locking up tokens’.

STARK: Short for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof.

State channels: A layer 2 solution where a channel is set up between participants, where they can transact freely and cheaply. Only a transaction to set up the channel and close the channel is sent to Mainnet. This allows for very high transaction throughput, but does rely on knowing number of participants up front and locking up of funds.

state channels: State channels are part of the set of tools and platforms involved in scaling Ethereum. While a complex topic, state channels are essentially methods through which the current ‘state’ of the blockchain can be exported, and then based on that, any given number of transactions can take place off-chain, and then be moved back onto the main Ethereum chain.

State: A snapshot of all balances and data at a particular point in time on the blockchain, normally referring to the condition at a particular block.

state: The set of data that a blockchain network strictly needs to keep track of, and that represents data currently relevant to applications on the chain.

Supermajority: Supermajority is the term given for an amount exceeding 2/3 (66%) of the total staked ether securing Ethereum. A supermajority vote is required for blocks to be finalized on the Beacon Chain.

swap: As the number of different blockchain projects and tokens has proliferated, the system by which users exchange one token for another has come to be known as swa p pi n g, and the individual action, a swa p. Within MetaMask, users have access to a powerful aggregator showing them information about swaps across the ecosystem, this is MetaMask Swaps.

Sybil attack: Sybil attacks refer to individual humans tricking a system into thinking they are multiple people to increase their influence.

Sync committee: A sync committee is a randomly selected group of validators that refresh every ~27 hours. Their purpose is to add their signatures to valid block headers. Sync committees allow light clients to keep track of the head of the blockchain without needing to access the entire validator set.

Syncing: The process of downloading the entire latest version of a blockchain to a node.

szabo: A denomination of ETH. See also ‘ether (denominations)’.

Szabo: A denomination of ether. 1 szabo = 10^12 wei. 10^6 szabo = 1 ether.

Terminal total difficulty (TTD): The total difficulty is the sum of the Ethash mining difficulty for all blocks up to some specific point in the blockchain. The terminal total difficulty is a specific value for the total difficulty that was used as the trigger for execution clients to switch off their mining and block gossip functions enabling the network to transition to proof-of-stake. It is no longer relevant because Ethereum moved to proof-of-stake.

Testnet Kovan: An Ethereum testnet that uses Proof of Authority consensus, available through MetaMask.

Testnet Rinkeby: An Ethereum testnet that uses Proof of Authority consensus, available through MetaMask; faucet here. Following the transition to Proof of Stake, Rinkeby scheduled its deprecation for the end of 2023.

Testnet Ropsten: An Ethereum testnet that used Proof of Work, and, following the transition to Proof of Stake, was deprecated.

testnet: A testnet is a blockchain network that mirrors, as closely as possible, the current conditions of a corresponding ‘main’ network. Testnets are used by developers to verify that their smart contracts and other functionality work as intended, before permanently recording their code to a live blockchain network (and often spending significant gas fees in the process!).Tokens minted on testnets are n ot transferrable for their equivalent value on mainnets.

Testnet: Short for "test network," a network used to simulate the behavior of the main Ethereum network.

token: A token represents an asset issued on an existing blockchain; the transfer of tokens and the addresses that currently hold them are the subject of the network’s consensus activities.  There are many types of tokens; see also ‘ERC- 20’ and ‘ERC-721’ entries.

Token: A tradable virtual good defined in smart contracts on the Ethereum blockchain.

Total Value Locked (TVL): Total Value Locked, or TVL, is a common expression used in many contexts across the crypto ecosystem, so it’s important to pay attention to the specifics. In general, it refers to how much value, in tokens, has been deposited into something. Most often, it refers to a protocol, which is an application on the blockchain, or a set of protocols. For example, a decentralized token trading platform might have a series of liquidity pools, which are protocols enabling swaps between tokens, and the platform may quote the “TVL” for all the pools combined. Alternatively, if a network uses proof of stake for their consensus mechanism, they may represent the TVL of all the tokens staked into that consensus protocol.

transaction block: A collection of transactions on a blockchain network, gathered into a set or a block that can then be hashed and added to the blockchain.  See ‘hash’.

Transaction fee: A fee you need to pay whenever you use the Ethereum network. Examples include sending funds from your wallet or a dapp interaction, like swapping tokens or buying a collectable. You can think of this like a service charge. This fee will change based on how busy the network is.  This is because validators, the people responsible for processing your transaction, are likely to prioritize transactions with higher fees – so congestion forces the price up.  At a technical level, your transaction fee relates to how much gas your transaction requires.  Reducing transaction fees is a subject of intense interest right now. See Layer 2.

transaction fee: A small fee imposed on transactions sent across a blockchain network. These fees are used to pay network validators or miners for their participation in consensus, and thus ensure that a blockchain network is self- sustaining.

transaction pool: When a user submits a transaction to the Ethereum network–or many other networks based on Ethereum–the transaction goes into what’s known as a “transaction pool” , or “txpool” for short. This is essentially a queue of transactions that are waiting to be added to a block and recorded to the blockchain. There are mechanisms that determine which transactions are “picked up” and included in the next block, and there is currently a lot of research surrounding how this decision gets made (see “MEV”). In Bitcoin, the transaction pool was referred to as the “memory pool” , or “mempool” , and often these terms are used interchangeably.

Transaction: Data committed to the Ethereum Blockchain signed by an originating account, targeting a specific address. The transaction contains metadata such as the gas limit for that transaction.

Trust assumptions: Trust assumptions are basic beliefs about a system's safety and dependability, guiding what we trust for the system to function.

trustless: ‘Trustless’ is a term that gets used a lot in the decentralized web, and it deserves some explanation.Traditionally, to call something ‘trustless’ would sound like a negative thing. In the context of decentralized technology, it has a more technical meaning: since everyone has a copy of the ledger of all transactions ever executed, there is no need for a centralized entity that ‘must be trusted’ as the source of truth. With public blockchain networks, data isn’t kept on some centralized server somewhere that could be hacked or changed arbitrarily; anyone can verify the transactions themselves. This is why the term ‘trustless’ was coined: there is no need for trust, although, in a way, the rules and assurances built into the blockchain provide the basis for great er trust between people, because the system is guaranteed to work the same for everyone.

Trustlessness: The ability of a network to mediate transactions without any of the involved parties needing to trust a third party.

Turing complete: A concept named after English mathematician and computer scientist Alan Turing - a system of data-manipulation rules (such as a computer's instruction set, a programming language, or a cellular automaton) is said to be "Turing complete" or "computationally universal" if it can be used to simulate any Turing machine.

Turing-complete: Any machine that can calculate on a level equal to a programmable computer is Turing- complete, or computationally universal. The Ethereum Virtual Machine, which processes smart contracts and transactions, is Turing- complete, despite not existing on a single physical computer.

Validator lifecycle: The sequence of states that a validator can exist in. These include: deposited: At least 32 ETH has been deposited to the deposit contract by the validator pending: the validator is in the activation queue waiting to be voted into the network by existing validators active: currently attesting and proposing blocks slashing: the validator has misbehaved and is being slashed exiting: the validator has been flagged for exiting the network, either voluntarily or because they have been ejected.

Validator: A node in a proof-of-stake system responsible for storing data, processing transactions, and adding new blocks to the blockchain. To activate validator software, you need to be able to stake 32 ETH.

validator: A participant in Proof of Stake (PoS) consensus.  On Ethereum’s Proof of Stake network, validators need to stake 32 ETH in order to get included in the validator set. See also ‘staking’.

Validity proof: A security model for certain layer 2 solutions where, to increase speed, transactions are rolled up into batches and submitted to Ethereum in a single transaction. The transaction computation is done off-chain and then supplied to the main chain with a proof of their validity. This method increases the amount of transactions possible while maintaining security.  Some rollups use fraud proof.

validity proof: The proof submitted along with certain types of rollups to prove that the transactions are valid.  See also ‘rollups’.

Validium: An off-chain solution that uses validity proofs to improve transaction throughput. Unlike Zero-knowledge rollups, validium data isn't stored on layer 1 Mainnet.

Validium: One of the technologies developed for scaling of the Ethereum network.

Vyper: A high-level programming language with Python-like syntax. Intended to get closer to a pure functional language. Created by Vitalik Buterin.

Wallet: A wallet is a digital tool to store, send, and receive digital currency, like a virtual purse for your online money.

Wallet: In Ethereum-based blockchain technology, a ‘wallet’ is a something that allows you to manage private keys, your Secret Recovery Phrase, and the accounts generated from it.  This could be an internet-connected ‘hot wallet’ , like MetaMask, or an ‘airgapped’ hardware wallet. In more technical speak, you could say “the wallet is the client, not the keys.  ”It is very common for people to use the word ‘wallet’ to refer to their SRP itself, or the accounts generated from it, or even to one account.

Web 3.0: See Web3

web3: Web3 is a term used synonymously with “the decentralized web” and are often used to refer, broadly, to the blockchain and decentralized technology ecosystems and communities as a whole.

Web3: Web3 is the new internet with blockchain, where users control their data and transactions, not companies. No need to share any personal information.

Wei: The smallest denomination of ether. 10^18 wei = 1 ether.

Zero address: An Ethereum address, composed entirely of zeros, that is frequently used as an address to remove tokens from owned circulation. A distinction is drawn between tokens formally removed from a smart contract's index via The smallest denomination of ether. 1018 wei = 1 ether.  the burn() method and those sent to this address.

zero address: The Zero Address is an address on the Ethereum network that is the recipient of a special transaction used to register the creation of a new smart contract on the network.

Zero-knowledge proof: A zero-knowledge proof is a cryptographic method that allows an individual to prove that a statement is true without conveying any additional information.

Zero-knowledge rollup: A rollup of transactions that use validity proofs to offer increased layer 2 transaction throughput while using the security provided by Mainnet (layer 1). Although they can't handle complex transaction types, like optimistic rollups, they don't have latency issues because transactions are provably valid when submitted.

zk-SNARKs: Zero-Knowledge Succinct Non-interactive ARguments of Knowledge are an incredible technology, and vital to the scaling of blockchain technology and the decentralized web. They are mathematically complex and can be daunting; this explanation from the Ethereum Foundation is a good primer.

--


EIP (Ethereum Improvement Proposal): A design document providing information about new features, processes, or standards for Ethereum. There are three main types of EIPs: Standards Track: Proposals for changes that affect most or all Ethereum implementations, such as core protocol changes, network rules, or application standards (EIP-1).  Meta: Describes a process surrounding Ethereum, such as decision-making processes or guidelines (EIP-1.md).  Informational: Provides general information or guidelines for the Ethereum community without proposing new features (EIP-1)

FORK_BLKNUM: A parameter specifying the block number at which a particular fork, such as the Homestead Hard Fork, becomes active (EIP-2).

CALLDEPTH: A proposed opcode to return the remaining available call stack depth during contract execution, introduced in (EIP-3 EIP-3).

Consensus Layer: One of four layers of the Ethereum system standards. It ensures that a particular state and history are valid and provides settlement guarantees. It includes both soft forks and hard forks (EIP-4).

CREATE2: A new opcode introduced in EIP-86 that allows contract creation with a specific address based on a combination of sender, salt, and initialization code (EIP-86).

DELEGATECALL: A new opcode that is similar to CALLCODE, but it retains the sender and value from the parent scope to the child scope during execution (EIP-7).

SELFDESTRUCT: A renamed opcode from SUICIDE, introduced in EIP-6, to avoid negative connotations (EIP-6).

devp2p: A networking protocol for Ethereum. EIP-8 introduces forward compatibility requirements for devp2p implementations (EIP-8).

Uncle Rate: Refers to the rate of uncles (stale blocks) included in a block, considered in EIP-100's difficulty adjustment formula (EIP-100).

Serenity Currency and Crypto Abstraction: Introduces the concept of abstracting away the native Ether storage within accounts. Instead of Ether being stored directly, a contract at address 0 manages all Ether. Transactions no longer use msg.value, and a tx.gas opcode is added to access the original amount of gas. (EIP-101)

Safe Transaction Authorization via HTML Popup: Describes an authorization mechanism that allows web-based dApps to request transactions via eth_sendTransaction by opening an HTML popup for user approval without the need for CORS, enhancing security for user transactions. (EIP-107)

REVERT Instruction: Introduces the REVERT opcode (0xfd), which allows contracts to halt execution and revert state changes without consuming all remaining gas. This opcode can return a reason or error message to the caller. (EIP-140)

Designated Invalid EVM Instruction: Introduces an explicit INVALID opcode (0xfe), which functions as an abort or fail state for contract execution, distinct from other failure mechanisms. (EIP-141)

Bitwise Shifting Instructions: Adds efficient bitwise shift operations: SHL (shift left), SHR (logical shift right), and SAR (arithmetic shift right), improving processing efficiency by lowering gas costs compared to arithmetic-based shifting. (EIP-145)

Gas Cost Changes for IO-heavy Operations: Adjusts the gas costs for several operations (e.g., EXTCODESIZE, BALANCE, SLOAD, etc.) to address inefficiencies and DoS vulnerabilities due to underpricing of IO-heavy operations. (EIP-150)

BLAKE2 Compression Function Precompile: Adds a precompiled contract at address 0x09 for the BLAKE2b cryptographic function, enabling efficient hashing and improved interoperability with other blockchain networks like Zcash. (EIP-152)

Simple Replay Attack Protection: Introduces a method for protecting Ethereum from replay attacks by adding a chainid field to transaction signing, differentiating transactions across chains and preventing cross-chain replay. (EIP-155)

State Clearing: Proposes the deletion of empty accounts (accounts with zero balance, nonce, code, and storage) to reduce state size, simplify execution, and enhance client performance. (EIP-158)

EXP Cost Increase: Increases the gas cost of the EXP opcode to better reflect its computational intensity, preventing underpricing. (EIP-160)

State Trie Clearing: Introduces changes to prevent accounts from transitioning from non-existent to empty state and ensures that empty accounts are deleted after transactions. (EIP-161)

Contract Code Size Limit: Sets a hard limit on contract size at 0x6000 bytes, and if a contract exceeds this size during creation, it results in an out-of-gas error. (EIP-170)

Elliptic Curve Operations Precompile: Adds precompiled contracts for elliptic curve addition and scalar multiplication on alt_bn128, enabling efficient zkSNARK verification. (EIP-196)

Elliptic Curve Pairing Check Precompile: Introduces a precompiled contract for the optimal ate pairing function, useful for zkSNARK verification in Ethereum. (EIP-197)

Big Integer Modular Exponentiation Precompile: Adds a precompiled contract for modular exponentiation, allowing efficient RSA and other number-theory cryptographic operations. (EIP-198)

Blockhash Refactoring: Refactors the way blockhashes are stored in the state to simplify the protocol and enable more efficient light client synchronization. (EIP-210)

RETURNDATASIZE and RETURNDATACOPY Opcodes: Introduces two new opcodes, RETURNDATASIZE and RETURNDATACOPY, allowing efficient handling of variable-length return data in smart contracts. (EIP-211)

STATICCALL Opcode: Adds the STATICCALL opcode to allow non-state-changing calls to other contracts, improving security by preventing unintended state modifications. (EIP-214)

Clique Proof-of-Authority Consensus Protocol: Proposes a proof-of-authority consensus protocol designed for Ethereum testnets to address issues in low-hashrate PoW networks. (EIP-225)

Formal Process for Hard Forks: Establishes a formal process for planning and executing Ethereum hard forks, including guidelines for creating a Meta EIP to track the hard fork timeline and included proposals. (EIP-233)

BlockHash Filter Option: Adds a blockHash filter option to the JSON-RPC methods eth_newFilter and eth_getLogs, allowing logs to be fetched for a specific block, ensuring clients can retrieve logs from blocks in the current chain or previously reorged blocks. (EIP-234)

Homestead Hard Fork: Specifies changes for the Homestead hard fork, including the activation of the hard fork at certain block numbers and the inclusion of EIPs 2, 7, and 8. (EIP-606)

Spurious Dragon Hard Fork: Specifies changes for the Spurious Dragon hard fork, including replay attack protection, state trie clearing, and contract code size limits. (EIP-607)

Tangerine Whistle Hard Fork: Details the Tangerine Whistle hard fork, focused on addressing gas cost issues related to IO-heavy operations to mitigate DoS attacks. (EIP-608)

Byzantium Hard Fork: Specifies the Byzantium hard fork, part of the Metropolis upgrade, introducing features like the REVERT opcode, elliptic curve precompiles, and transaction status codes. (EIP-609)

Subroutines and Static Jumps: Proposes static jumps and subroutines for the EVM to replace dynamic jumps, enhancing performance, formal verification, and code security. (EIP-615)

SIMD Operations for the EVM: Suggests adding SIMD (Single Instruction Multiple Data) operations to the EVM, utilizing 256-bit stack items for parallel computation, boosting performance for certain cryptographic algorithms and vectorized operations. (EIP-616)

Whisper Specification: Defines the Whisper protocol's message format and packet structure used within the ÐΞVp2p Wire Protocol, ensuring compatibility across Whisper clients. (EIP-627)

Metropolis Difficulty Bomb Delay and Block Reward Reduction: Proposes delaying the Ethereum difficulty bomb (ice age) by 1.4 years and reducing block rewards to 3 ETH as part of the Byzantium hard fork. (EIP-649)

Transaction Status Code in Receipts: Replaces the intermediate state root in transaction receipts with a status code (1 for success, 0 for failure), allowing users to easily determine transaction outcomes. (EIP-658)

SWAPN, DUPN, and EXCHANGE Instructions: Introduces new instructions (SWAPN, DUPN, and EXCHANGE) to access and manipulate deeper stack items beyond the 16-item limit, improving stack management for complex functions and compiler optimizations. (EIP-663)

Ed25519 Signature Verification Precompile: Adds a precompiled contract for verifying Ed25519 signatures, improving the efficiency and gas cost of verifying these cryptographic signatures within smart contracts. (EIP-665)

Revert Creation on Address Collision: Reverts contract creation if the destination address already contains code or has a non-zero nonce, preventing code replacement attacks and maintaining contract immutability. (EIP-684)

Address Collision Halt: Proposes that contract creation fails if attempted at an address with existing code or a non-zero nonce, simplifying client implementations and ensuring consistency across clients. (EIP-689)

eth_chainId JSON-RPC Method: Introduces the eth_chainId JSON-RPC method to retrieve the chain ID used in replay-protected transactions, ensuring that users and applications are interacting with the correct blockchain. (EIP-695)

BLOCKREWARD Opcode: Adds a new opcode (0x46 BLOCKREWARD) to the EVM to return the block reward value, facilitating decentralized mining pools and merge-mined token systems. (EIP-698)

Snappy Compression for DEVp2p: Introduces Snappy compression to the DEVp2p networking protocol, reducing bandwidth usage by compressing message payloads, particularly benefiting initial sync processes. (EIP-706)

Typed Structured Data Hashing and Signing: Standardizes the process for signing typed structured data, allowing users to review human-readable messages before signing, improving security and usability in off-chain message signing. (EIP-712)

wallet_watchAsset RPC Method: Introduces the wallet_watchAsset RPC method to allow websites to suggest tokens for users' wallets to track, improving user experience by making it easier to manage assets. (EIP-747)

Completed Transaction Subscriptions and Filters: Proposes subscriptions and filters for completed transactions, allowing external callers to be notified of completed transactions and retrieve function return data when transactions are mined. (EIP-758)

Ethereum Node Records (ENR): Defines an open format for Ethereum node connectivity information, enabling the exchange of data such as IP addresses, ports, and public keys through various methods like node discovery, DNS, or ENS. (EIP-778)

DAO Fork: Describes an irregular state change at block 1,920,000, which transferred ether from the DAO and related accounts to a WithdrawDAO contract following the infamous DAO hack. (EIP-779)

Reduce Block Reward and Delay Difficulty Bomb: Proposes reducing the block reward to 1 ETH and delaying the difficulty bomb to mitigate energy consumption and control mining growth. (EIP-858)

Standardized Ethereum Recovery Proposals (ERPs): Suggests a standardized format for recovery proposals involving lost funds, aiming to streamline the process and ensure consistency in handling such cases. (EIP-867)

Node Discovery v4 ENR Extension: Extends Node Discovery Protocol v4 to support Ethereum Node Records (ENR), enabling authoritative retrieval of updated node records through existing discovery protocols. (EIP-868)

Reward Clients for a Sustainable Network: Proposes rewarding client developers with transaction fees and newly minted ETH to incentivize client development, aiming for a sustainable Ethereum network. (EIP-908)

Modifications to Ethash to Invalidate ASIC Hardware: Aims to modify the Ethash algorithm to break existing ASIC miners by changing certain FNV constants, enhancing resistance against hardware centralization. (EIP-969)

Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4: Proposes restoring the Parity Wallet's WalletLibrary contract, which was accidentally self-destructed, to unfreeze funds locked in multi-signature wallets. (EIP-999)

Ether Redistribution Between Two Addresses: Proposes transferring 100,000 ether from one address to another to improve balance uniformity, justified by decentralized ideals. (EIP-1010)

Hybrid Casper FFG: Specifies a hybrid consensus model combining Proof of Work (PoW) and Proof of Stake (PoS), known as Casper FFG, to provide finality and reduce energy consumption in Ethereum's transition to PoS. (EIP-1011)

Constantinople Hard Fork: Specifies the changes included in the Constantinople hard fork, such as bitwise shifting instructions, CREATE2, and reducing gas costs for certain operations. (EIP-1013)

Skinny CREATE2: Introduces the CREATE2 opcode, allowing contracts to be created at addresses that depend on a hash of the sender's address, a salt, and the contract's initialization code. (EIP-1014)

Configurable On-Chain Issuance: Proposes a system where block rewards are controlled by an on-chain governance contract, allowing for dynamic changes in issuance based on governance decisions. (EIP-1015)

Overflow Checking for the EVM: Adds overflow detection for arithmetic operations in the EVM, introducing two new opcodes (OFV and SOVF) to check and clear overflow flags. (EIP-1051)

EXTCODEHASH Opcode: Introduces the EXTCODEHASH opcode, which returns the keccak256 hash of a contract’s code, allowing contracts to verify code without needing the entire bytecode. (EIP-1052)

ProgPoW: A new Proof-of-Work algorithm designed to be ASIC-resistant by utilizing more parts of commodity GPUs, minimizing the efficiency gap between general-purpose hardware and specialized ASICs. (EIP-1057)

Net Gas Metering for SSTORE: Proposes changes to how gas is charged for SSTORE operations, introducing a system that charges based on net changes to storage, reducing gas costs for multiple updates in the same transaction. (EIP-1087)

Opt-in Account Exposure: Describes a protocol where dapps must request account access from the user, enhancing privacy and security by allowing users to approve or deny access to their Ethereum accounts. (EIP-1102)

Reduced Gas Costs for Elliptic Curve Precompiles: Lowers the gas costs for the ECADD, ECMUL, and pairing check operations on the alt_bn128 elliptic curve, making elliptic curve cryptography more efficient. (EIP-1108)

PRECOMPILEDCALL Opcode: Introduces a new opcode that allows direct calls to precompiled contracts without the overhead of the CALL opcode, reducing gas costs for these operations. (EIP-1109)

Transient Storage Opcodes: Introduces TLOAD and TSTORE opcodes, which behave similarly to storage but discard values after each transaction, allowing more gas-efficient inter-frame communication. (EIP-1153)

eth_getProof: Adds a new RPC method to return account and storage values along with Merkle proofs, allowing offline verification of account and storage data. (EIP-1186)

Ethereum Provider JavaScript API: Formalizes a JavaScript API for Ethereum providers to standardize how web applications interact with wallets and clients, enhancing consistency across implementations. (EIP-1193)

Defuse Difficulty Bomb and Reset Block Reward: Proposes permanently disabling the difficulty bomb and resetting the block reward to 5 ETH to give users more freedom over Ethereum's governance. (EIP-1227)

Constantinople Difficulty Bomb Delay and Block Reward Adjustment: Proposes delaying the difficulty bomb by 12 months and reducing block rewards to 2 ETH with the Constantinople fork to maintain system stability. (EIP-1234)

Remove Difficulty Bomb: Suggests removing the difficulty bomb and setting a fixed difficulty targeting 15-second block times, providing economic participants with more control over network upgrades. (EIP-1240)

Eliminate Difficulty Bomb and Adjust Block Reward: Proposes eliminating the difficulty bomb entirely and reducing block rewards to 2 ETH as part of the Constantinople fork to maintain network efficiency and reduce issuance. (EIP-1276)

Net Gas Metering for SSTORE: Proposes changes to gas metering for SSTORE operations, reducing gas costs for multiple updates to storage within the same transaction and enabling more efficient contract storage usage. (EIP-1283)

Increase Gcallstipend Gas in CALL Opcode: Proposes increasing the gas stipend for CALL operations from 2,300 to 3,500 gas units, allowing more complex fallback functions to be executed. (EIP-1285)

Modify Ethereum PoW Incentive Structure and Delay Difficulty Bomb: Proposes reducing uncle rewards, removing nephew rewards, and delaying the difficulty bomb while maintaining the current block reward of 3 ETH. (EIP-1295)

ChainID Opcode: Adds the CHAINID opcode to return the current chain’s EIP-155 unique identifier, enabling replay protection when handling signed messages in contracts. (EIP-1344)

Restricted Address Range for Precompiles/System Contracts: Reserves the address range from 0x0000000000000000000000000000000000000000 to 0x000000000000000000000000000000000000ffff for precompiles and system contracts. (EIP-1352)

Ethash 1a: Modifies the Ethash algorithm to hinder and delay ASIC-based mining by changing the hash function from fnv() to fnv1a(). (EIP-1355)

Reduced Gas Cost for Call to Self: Proposes reducing the gas cost for call instructions when the destination address equals the caller’s address, to encourage using CALL for internal function calls in smart contracts. (EIP-1380)

Blockchain Storage Rent Payment: Introduces rent payments for storage used by accounts, with rent deducted based on the quantity of storage each account uses. (EIP-1418)

Node Discovery via DNS: Proposes a scheme for authenticated, updateable Ethereum node lists retrievable via DNS, providing an alternative to hard-coded bootstrap node lists. (EIP-1459)

Smart Contract Weakness Classification (SWC): Introduces a classification scheme for security weaknesses in Ethereum smart contracts, aligned with the Common Weakness Enumeration (CWE) scheme. (EIP-1470)

Remote Procedure Call Specification: Defines a standard set of RPC methods that an Ethereum node should implement, ensuring consistency and predictability across different client implementations. (EIP-1474)

Define a Maximum Block Timestamp Drift: Specifies that block timestamps must be greater than the previous block’s timestamp and no more than 15 seconds ahead of system time. (EIP-1482)

TEthashV1: Modifies the Ethash PoW algorithm to obsolete current ASIC miners by replacing the deprecated FNV-0 hash with the FNV1A hash function. (EIP-1485)

Fee Market Change for ETH 1.0 Chain: Proposes a new transaction pricing mechanism with a base fee per gas, dynamically adjusting based on network congestion, and burned. Aims to reduce volatility, improve efficiency, and prevent miner manipulation of fees. (EIP-1559)

EthereumStratum/2.0.0: Defines a new standard for the Stratum protocol used by Ethereum miners to communicate with mining pool servers, providing an efficient two-way communication mechanism over a TCP connection. (EIP-1571)

Ethereum ProgPoW Hardfork: A meta-EIP specifying the changes included in the Ethereum ProgPoW hardfork, primarily introducing ProgPoW as the proof-of-work algorithm. (EIP-1588)

Istanbul Hardfork: A meta-EIP that specifies the changes included in the Istanbul hardfork, incorporating various EIPs aimed at improving performance, security, and cost-efficiency of Ethereum. (EIP-1679)

Temporal Replay Protection: Introduces a time-based replay protection mechanism for Ethereum transactions, allowing users to set a validity period for their transactions using a valid-until timestamp. (EIP-1681)

Storage Rent: Proposes a system where users must pay rent for storing data on the Ethereum blockchain, with accounts becoming inactive if they cannot pay. Inactive accounts can be restored by re-uploading their storage. (EIP-1682)

Generalized Account Versioning Scheme: Introduces a scheme for account versioning, allowing multiple versions of virtual machines to coexist, facilitating upgrades to Ethereum’s execution environments. (EIP-1702)

Disable SSTORE with Gas Left Below Stipend: Proposes disallowing the use of SSTORE when the remaining gas is lower than the call stipend of 2300 gas, mitigating potential reentrancy attacks. (EIP-1706)

Petersburg Hardfork: A meta-EIP specifying the removal of EIP-1283 from the Constantinople hardfork due to potential security risks, finalizing the changes in the Petersburg hardfork. (EIP-1716)

GraphQL Interface to Ethereum Node Data: Proposes a GraphQL schema for accessing Ethereum node data, replacing the current JSON-RPC interface to improve usability, efficiency, and future-proofing. (EIP-1767)

EXTBALANCE: Renames the BALANCE opcode to EXTBALANCE for clarity, aligning with other EXTCODE opcodes. (EIP-1803)

EC Linear Combination Precompile: Introduces a precompile to compute elliptic curve linear combinations for arbitrary curves. (EIP-1829)

Network Upgrade Windows: Defines four annual time windows for scheduling network upgrades (hard forks) to provide predictability. (EIP-1872)

SELFBALANCE: Introduces the SELFBALANCE opcode to fetch the current address balance efficiently, and reprices certain trie-size-dependent opcodes like SLOAD, BALANCE, and EXTCODEHASH. (EIP-1884)

DEVFUND_BLOCK_REWARD: Introduces a mechanism to capture a portion of block rewards for ecosystem funding, though initially set to zero. (EIP-1890)

MNT4 Curve Support: Adds precompiles for elliptic curve operations on the MNT4 curve, enabling recursive SNARKs for scalability. (EIP-1895)

blockHash Parameter: Allows JSON-RPC methods to query blockchain state using a block hash instead of just a block number. (EIP-1898)

rpc.discover: Adds OpenRPC service discovery to Ethereum’s JSON-RPC services, enabling machine-readable API specifications. (EIP-1901)

STRICTGASCALL: Proposes a strict gas semantic for CALL, DELEGATECALL, and STATICCALL, ensuring the specified gas is available or reverting otherwise. (EIP-1930)

VALID_CHAINID: Introduces the VALID_CHAINID opcode, allowing contracts to check if a chainID has been valid at any point in the chain’s history. (EIP-1959)

EC Arithmetic Precompile: Proposes a precompile for elliptic curve arithmetic and pairings with runtime-defined parameters for Weierstrass curves and pairings on various curve families. (EIP-1962)

VALID_CHAINID_BLOCK: A method to check if a specific chainID was valid at a specific block number, providing enhanced replay protection for minority-led forks. (EIP-1965)

EVM Parameter Limits: Introduces explicit value ranges for certain EVM parameters like gas limit, block number, and memory size to help create compatible client implementations. (EIP-1985)

EVMC Precompile Modules: Specifies the use of EVMC modules for implementing precompiled contracts, providing a flexible mechanism for precompiles through the EVMC interface. (EIP-2003)

Extended State Oracle (ESO): Proposes a precompile that allows contracts to query extended data sets, such as chain IDs and block hashes, using an extensible ABI-based interface. (EIP-2014)

wallet_updateEthereumChain: A wallet-namespaced RPC method that allows switching between EVM-compatible chains and registering new chains with wallets. (EIP-2015)

DEVFUND_BLOCK_REWARD: Proposes adding a temporary block reward of 0.0055 ETH per block for 18 months to fund Eth1.x development and repay a community loan. (EIP-2025)

State Rent Prepayment: Introduces a fixed one-time rent prepayment for creating or modifying accounts, used to fund future state rent and prevent account hoarding. (EIP-2026)

Net Contract Size Accounting: Begins tracking the net change in the number of storage slots used by contracts, preparing for future state rent and stateless client improvements. (EIP-2027)

Transaction Data Gas Cost Reduction: Reduces the gas cost for non-zero calldata from 68 to 16 gas per byte to improve on-chain scalability, especially for layer 2 solutions. (EIP-2028)

State Counters Contract: A contract deployed to store state counters (e.g., total transactions, accounts) to track state-related metrics for Ethereum. (EIP-2029)

Net Transaction Counter: Introduces a counter in the state counters contract that tracks the number of Ethereum transactions after the change is introduced. (EIP-2031)

Repricing SLOAD and SSTORE: Increases the gas cost of SLOAD and SSTORE operations to accommodate the additional bandwidth needed for stateless clients using block proofs. (EIP-2035)

Particle Gas Costs: Introduces a new unit of gas called "particles" (a fraction of gas) to reduce the cost of computational opcodes, enabling more efficient gas pricing. (EIP-2045)

Reduced STATICCALL Gas for Precompiles: Lowers the base gas cost for STATICCALL to precompiled contracts from 700 to 40 gas, improving efficiency. (EIP-2046)

YAML ABI: Recommends using YAML for ABI descriptions in EIPs and ERCs, allowing comments and improving readability compared to JSON. (EIP-2069)

Berlin Hardfork: Specifies the changes included in the Berlin hardfork. (EIP-2070)

Fork Identifier: Introduces a mechanism to summarize chain configurations using a FORK_HASH and FORK_NEXT for chain compatibility checks. (EIP-2124)

Common Prometheus Metrics: Standardizes names and formats for common metrics across Ethereum clients to ensure compatibility with Prometheus monitoring. (EIP-2159)

Net Gas Metering for SSTORE: Updates the gas cost for the SSTORE opcode based on the original, current, and new storage values, improving efficiency for contracts with frequent storage updates. (EIP-2200)

Ethereum Mainnet ID: Specifies that the Ethereum network with network ID 1 and chain ID 1 should be referred to as "Ethereum Mainnet" or just "Mainnet" when the context is clear. (EIP-2228)

Transaction Postdata: Introduces an optional postdata field in transactions for posting data on-chain, but not readable by the EVM, with a cost of 1 gas per byte. (EIP-2242)

wallet_getPermissions: Adds a JSON-RPC method for dApps to retrieve the permissions granted by a wallet for specific actions. (EIP-2255)

wallet_getOwnedAssets: Introduces a JSON-RPC method to retrieve a list of assets owned by an Ethereum address, as curated by the user's wallet. (EIP-2256)

Chain ID Bound: Establishes a safe and maximum range for the chain ID parameter to avoid overflow and compatibility issues, particularly for EIP-155 and EIP-712. (EIP-2294)

RJUMPSUB and RETURNSUB: Introduces two opcodes, RJUMPSUB and RETURNSUB, to implement simple subroutines in the EVM, allowing static and efficient control flow. (EIP-2315)

BEGINDATA: Introduces the BEGINDATA opcode to mark the start of data in contract bytecode, signaling that the remaining bytes are non-executable. (EIP-2327)

EXTSLOAD: Introduces the EXTSLOAD opcode, allowing contracts to directly read external contract storage data, reducing gas costs and improving efficiency. (EIP-2330)

eth/64 ForkID Handshake: Specifies an update to the Ethereum eth protocol (eth/64) to include the forkid in the handshake, enabling nodes to validate compatibility more efficiently. (EIP-2364)

EIPs Eligible for Inclusion: Tracks the status of EIPs that have been vetted by the core developers and marked as eligible for inclusion in future forks or upgrades. (EIP-2378)

Muir Glacier Difficulty Bomb Delay: Proposes delaying the Ethereum difficulty bomb by 4 million blocks (~611 days) to prevent increasing block times and network congestion. (EIP-2384)

Muir Glacier Hardfork: Specifies the Muir Glacier hardfork, which addresses the impending Ice Age by delaying the difficulty bomb. (EIP-2387)

Updates and Updated-by Header: Adds the updates and updated-by headers to track updates to active EIPs and indicate which EIPs modify other EIPs. (EIP-2458)

eth/65 Transaction Announcements: Introduces new message types in the eth protocol (NewPooledTransactionHashes, GetPooledTransactions, and PooledTransactions) to reduce bandwidth usage and improve transaction propagation efficiency. (EIP-2464)

Coinbase Calls: Allows the block coinbase (validator) to execute contracts directly without a transaction, where tx.origin = block.coinbase and gas.price = 0. (EIP-2474)

eth/66 Request Identifier: Adds a request ID to all request/response pairs in the eth protocol, improving efficiency and reducing the complexity of matching responses to requests. (EIP-2481)

Deprecate CALLCODE: Proposes deprecating the CALLCODE opcode by making it always return failure, as it has been replaced by DELEGATECALL. (EIP-2488)

Difficulty Freeze: Replaces the difficulty bomb with a difficulty freeze that begins at a specific block height, freezing difficulty and increasing it by 1% after that block. (EIP-2515)

BLS12-381 Precompile: Adds precompiles for BLS12-381 curve operations, allowing efficient cryptographic operations such as BLS signature verification and multiexponentiation. (EIP-2537)

BLS12-377 Precompile: Introduces precompiles for BLS12-377 curve operations, enabling efficient cryptographic operations and SNARK verification on the BLS12-377 curve. (EIP-2539)

TXGASLIMIT and CALLGASLIMIT: Introduces two new opcodes: TXGASLIMIT to push the transaction gas limit and CALLGASLIMIT to push the current execution frame's gas limit onto the stack. (EIP-2542)

ModExp Gas Cost: Reprices the ModExp precompile (0x05) to more accurately reflect its computational cost, improving efficiency for cryptographic operations. (EIP-2565)

Human Readable Parameters: Proposes a new Ethereum RPC method, eth_sendTransactionToContractFunction, allowing users to see human-readable contract function details when executing transactions. (EIP-2566)

Penalty for Account Trie Misses: Adds a gas penalty for trie accesses to non-existent accounts, reducing the discrepancy between normal and worst-case execution paths. (EIP-2583)

Trie Format Transition: Proposes a method to convert the Ethereum state trie from hexary to binary using overlay trees, enabling a phased transition. (EIP-2584)

Escalator Fee Market: Introduces the "escalator" fee model, allowing transactions to specify a start price, maximum price, and escalation over time for dynamic fee pricing. (EIP-2593)

Ephemeral Testnet Yolo: Specifies the Yolo ephemeral testnet, a short-lived network for testing infrastructure, not meant for dapp deployment or long-term use. (EIP-2657)

Precompile and KECCAK256 Repricing: Reprices the SHA256, RIPEMD, and KECCAK256 functions to better reflect their computational costs. (EIP-2666)

Limit Initcode Size: Proposes limiting the size of initcode to 49,152 bytes, enforcing a 16-bit addressable range for contract creation. (EIP-2677)

Limit Account Nonce: Limits the account nonce to a maximum value of 2^64-1, improving proof representation and optimizing client storage. (EIP-2681)

JavaScript request Method: Defines a standard request method on JavaScript Ethereum Providers to enable communication between the provider and Ethereum clients using JSON-RPC. (EIP-2696)

JavaScript Provider Event Emitter: Introduces standard event handling methods (on and removeListener) for JavaScript Ethereum Providers to notify clients about blockchain state changes. (EIP-2700)

Sponsored, Expiring, and Batch Transactions: Proposes a new transaction type that supports sponsored transactions (separate gas payer), batch transactions, and expiring transactions. (EIP-2711)

Typed Transaction Envelope: Defines a transaction envelope for supporting multiple transaction types, enabling easier addition of future transaction formats. (EIP-2718)

Transaction Package: Introduces a transaction type that allows a package of transactions to be executed serially, with information passed from one transaction to the next. (EIP-2733)

Reduce Intrinsic Transaction Gas: Proposes lowering the intrinsic gas cost of a transaction from 21,000 to 7,000 gas, making ETH transactions more affordable. (EIP-2780)

Ethereum Provider Connect/Disconnect Events: Specifies connect and disconnect events for JavaScript Ethereum Providers to notify clients when the provider connects or disconnects from the network. (EIP-2786)

Rich Transactions: Enables externally owned accounts (EOAs) to execute EVM bytecode directly, allowing EOAs to perform multiple atomic operations in a single transaction. (EIP-2803)

Transaction Replacement Message: Adds a new message type to the Ethereum Provider API for notifying clients when a transaction in the mempool is replaced or canceled. (EIP-2831)

DID Methods for JSON-RPC: Proposes new JSON-RPC methods (did_authenticate, did_createJWS, and did_decryptJWE) to enable wallets to interact with Decentralized Identifiers (DIDs) and support JOSE encryption. (EIP-2844)

Chunk-Based Code Merkleization: Splits contract code into fixed-size chunks and stores them in a Merkle tree, reducing witness sizes for stateless Ethereum clients. (EIP-2926)

Gas Cost Increases for State Access Opcodes: Increases the gas cost for SLOAD, *CALL, BALANCE, and EXT* opcodes on first access in a transaction, to address underpriced operations. (EIP-2929)

Optional Access Lists: Introduces a transaction type that includes an access list specifying addresses and storage keys the transaction plans to access, reducing gas costs for state access. (EIP-2930)

Serve Historical Block Hashes from State: Stores the last 8192 block hashes in a system contract, allowing stateless clients to access historical data without affecting the BLOCKHASH opcode. (EIP-2935)

EXTCLEAR Opcode: Introduces the EXTCLEAR opcode to clear storage for contracts that have been SELFDESTRUCTed, without clearing storage during SELFDESTRUCT. (EIP-2936)

SET_INDESTRUCTIBLE Opcode: Adds the SET_INDESTRUCTIBLE opcode, preventing a contract from being destroyed via SELFDESTRUCT. (EIP-2937)

Account Abstraction: Allows contracts to be the top-level accounts that pay fees and initiate transactions, enabling new wallet designs, signature schemes, and fee structures. (EIP-2938)

IS_STATIC Opcode: Introduces the IS_STATIC opcode, which indicates if the current context is static (i.e., part of a STATICCALL) to enhance account abstraction and security. (EIP-2970)

Wrapped Legacy Transactions: Defines two new transaction types that wrap legacy transactions with and without a chain ID, maintaining signature compatibility with older transactions. (EIP-2972)

Typed Transactions Over Gossip: Enables the transmission of typed transactions via devp2p, allowing clients to gossip new transaction types without upgrading the devp2p version. (EIP-2976)

Serenity Phase 0: The initial phase of Ethereum 2.0, introducing the beacon chain and proof-of-stake consensus without affecting Ethereum mainnet. It lays the foundation for future Ethereum upgrades, including sharding and validator mechanics. (EIP-2982)

IMPERSONATECALL: Introduces the IMPERSONATECALL opcode, allowing a contract to impersonate a sender derived from the real caller and a salt, enabling meta-transactions and native multi-user wallets. (EIP-2997)

eth_symbol: Adds the eth_symbol JSON-RPC method, which returns the symbol of the native coin of the connected network (e.g., "ETH" for Ethereum mainnet). (EIP-3014)

BW6-761 Curve Operations: Introduces precompiles for performing elliptic curve operations on the BW6-761 curve, enabling efficient verification of zkSNARK proofs. (EIP-3026)

BLS Remote Signer HTTP API: Defines an API for a BLS remote signer, allowing validator clients to sign block proposals and attestations using remote keys stored securely. (EIP-3030)

Add baseFee to eth_getBlockByHash: Adds a baseFee field to the eth_getBlockByHash JSON-RPC endpoint, returning the base fee for any block post-EIP-1559. (EIP-3041)

Add baseFee to eth_getBlockByNumber: Adds a baseFee field to the eth_getBlockByNumber JSON-RPC endpoint, returning the base fee for any block post-EIP-1559. (EIP-3044)

Add baseFee to eth_getUncleByBlockHashAndIndex: Adds a baseFee field to the eth_getUncleByBlockHashAndIndex JSON-RPC endpoint, returning the base fee for uncles post-EIP-1559. (EIP-3045)

Add baseFee to eth_getUncleByBlockNumberAndIndex: Adds a baseFee field to the eth_getUncleByBlockNumberAndIndex JSON-RPC endpoint, returning the base fee for uncles post-EIP-1559. (EIP-3046)

BN256 HashToCurve Algorithms: Introduces a precompile for the BN256 curve to enable efficient hash-to-curve operations, facilitating cheaper BLS signature verification. (EIP-3068)

AUTH and AUTHCALL: Introduces two opcodes, AUTH and AUTHCALL, allowing externally owned accounts (EOAs) to delegate control to a contract, enabling sponsored transactions and other flexible transaction schemes. (EIP-3074)

Slashing Protection Interchange Format: Defines a JSON format for proof-of-stake validator slashing protection data to enable secure migration between clients. (EIP-3076)

wallet_addEthereumChain: Adds an RPC method that allows dApps to suggest adding new EVM-compatible chains to wallets, improving multi-chain user experiences. (EIP-3085)

Block Explorer API Routes: Standardizes API routes for blockchain explorers, such as paths for transactions, blocks, accounts, and tokens, improving consistency across platforms. (EIP-3091)

Binary Trie Structure: Proposes a transition from a hexary to a binary trie structure for Ethereum’s account and storage tries, improving stateless Ethereum support and reducing proof sizes. (EIP-3102)

Increase Block Rewards to 5 ETH: Increases the block reward for proof-of-work mining from 2 ETH to 5 ETH to stabilize miner incentives during Ethereum’s transition to proof-of-stake. (EIP-3143)

EVM Trace Specification: Introduces a JSON format for tracing EVM execution during state tests, enabling consistent debugging and differential fuzzing across Ethereum clients. (EIP-3155)

BASEFEE Opcode: Adds the BASEFEE opcode, allowing smart contracts to access the block's base fee, useful for gas-related logic such as gas futures and bounties. (EIP-3198)

Crosschain Identifier Specification: Defines a self-verifying blockchain identifier, incorporating chain metadata to differentiate blockchains, including forks, for crosschain operations. (EIP-3220)

Difficulty Bomb Delay to Q2/2022: Delays the Ethereum difficulty bomb, pushing back the impact of increasing block times to allow Eth1 and Eth2 development to conclude the merge. (EIP-3238)

Giving Ethereum Fees to Future Salaries: Proposes transferring a portion of Ethereum mining and transfer fees to a Future Salaries contract, which funds common good producers, while also locking ETH to reduce circulating supply. (EIP-3267)

Removal of Refunds: Proposes removing gas refunds for SSTORE and SELFDESTRUCT operations, primarily to reduce block size variance and eliminate the use of GasToken. (EIP-3298)

Phase Out Refunds: Suggests gradually reducing gas refunds for SSTORE and SELFDESTRUCT operations over time to reduce block gas elasticity more smoothly than a sudden removal. (EIP-3300)

Account Gas Storage Opcodes: Introduces new opcodes (SELFGAS, USEGAS, STOREGAS) that allow contracts to store gas for later use, improving gas management without increasing state size. (EIP-3322)

wallet_switchEthereumChain: Adds an RPC method that allows dApps to request that the wallet switches its active Ethereum chain, improving multi-chain dApp interactions. (EIP-3326)

MEDGASPRICE Opcode: Introduces the MEDGASPRICE opcode, allowing contracts to access the median gas price of the parent block, useful for setting maximum gas prices and mitigating front-running attacks. (EIP-3332)

Paged Memory Allocation: Proposes changing the EVM’s memory model to use paged memory, improving flexibility for smart contract memory management while keeping gas costs manageable. (EIP-3336)

Frame Pointer Support: Adds four new opcodes (MLOADFP, MSTOREFP, GETFP, SETFP) to support memory operations relative to a frame pointer, improving memory management efficiency for smart contracts. (EIP-3337)

Limit Account Nonce to 2^52: Proposes limiting Ethereum account nonces to a maximum of 2^52 to simplify state witness handling and optimize transaction processing. (EIP-3338)

Increase Block Rewards to 3 ETH with 2-Year Decay: Increases block rewards to 3 ETH, followed by a gradual decrease over two years to 1 ETH, balancing short-term incentives for miners and long-term deflationary goals. (EIP-3368)

5 FNV Primes for Ethash: Modifies the Ethash algorithm by introducing five new FNV primes to replace the single FNV prime, aiming to disrupt existing ASIC miners and maintain Ethereum’s ASIC resistance. (EIP-3372)

Predictable Proof-of-Work Sunsetting: Sets block rewards to 3 ETH and gradually reduces them over one year to 1 ETH, aiming for a predictable phase-out of Proof-of-Work (PoW) mining. (EIP-3374)

Hardcoded Block Gas Limit: Hardcodes the block gas limit to 12.5 million gas, preventing miners from adjusting the gas limit and ensuring consistency across blocks. (EIP-3382)

Partial Removal of Refunds: Removes gas refunds for SELFDESTRUCT and restricts SSTORE refunds to a specific case, targeting the elimination of GasToken while preserving efficiency for certain use cases like anti-reentrancy locks. (EIP-3403)

Median Gas Premium: Proposes a transaction pricing mechanism where a fixed base fee is combined with a gas premium based on the median of included transactions, aiming to smooth gas price volatility. (EIP-3416)

Expanded Clique Block Choice Rule: Introduces a four-step block choice rule for the Clique consensus algorithm to reduce the occurrence of deadlocks in multi-validator environments. (EIP-3436)

SUDO Opcode: Adds the SUDO opcode, which allows calling from an arbitrary sender address, enabling recovery of assets from addresses with lost keys or bugs. (EIP-3455)

Transaction Data Opcodes: Introduces the opcodes ORIGINDATALOAD, ORIGINDATASIZE, and ORIGINDATACOPY to provide access to the original transaction’s data payload, improving efficiency for multi-contract systems. (EIP-3508)

Transaction Destination Opcode: Adds the ENTRYPOINT opcode, allowing contracts to access the original recipient of a transaction, facilitating introspection and new contract interaction patterns. (EIP-3520)

Reduce Access List Cost: Reduces the cost of declaring tx.to storage keys in access lists, making access lists more cost-effective for transactions involving storage access. (EIP-3521)

Reduction in Refunds: Reduces gas refunds for SSTORE and eliminates refunds for SELFDESTRUCT, limiting block gas refund to 20% of gas used to reduce block size variance and prevent GasToken exploits. (EIP-3529)

Restricted Chain Context Type Transactions: Introduces a new transaction type that restricts its validity based on block context conditions, such as block hash, miner, and block timestamp. (EIP-3534)

EOF (EVM Object Format): Introduces a versioned container format for EVM bytecode, enabling separation of code and data, with validation at contract creation time. (EIP-3540)

Reject 0xEF Byte: Disallows new contract code starting with the byte 0xEF, reserving it for the future use of EVM Object Format (EOF). (EIP-3541)

Difficulty Bomb Delay to December 2021: Delays the difficulty bomb, pushing its effects to December 2021 to align with the planned Ethereum upgrades. (EIP-3554)

Block Access List: Proposes building a block’s access_list by collating transaction access lists and including a fingerprint of this list in the block header, improving execution and validation efficiency. (EIP-3584)

Reject Transactions from Deployed Code Addresses: Disallows transactions from addresses that have deployed code, protecting against address collision attacks between contracts and externally owned accounts (EOAs). (EIP-3607)

Warm COINBASE: Starts the COINBASE address warm at the start of a transaction to reflect its actual cost and promote its use for payments. (EIP-3651)

EOF - Code Validation: Adds validation for EOF contracts at deployment time, ensuring correctness by rejecting bytecode with undefined instructions or truncated PUSH data. (EIP-3670)

Upgrade Consensus to Proof-of-Stake: Specifies the transition from Proof-of-Work (PoW) to Proof-of-Stake (PoS) on Ethereum Mainnet, deprecating PoW and upgrading the consensus mechanism to PoS. (EIP-3675)

EOF - JUMPDEST Table: Introduces a section in the EOF format to store the list of JUMPDEST instructions, removing the need for JUMPDEST-analysis at runtime and validating the table during contract creation. (EIP-3690)

Remove Support for Type 1 Transactions: Deprecates the use of TransactionType 1 by upgrading all transactions to TransactionType 2, enhancing gas fee functionality via EIP-1559. (EIP-3709)

Gas Limit Cap: Sets an in-protocol cap for the gas limit at 30,000,000, preventing block proposers from increasing the gas limit beyond this threshold. (EIP-3756)

Safer Control Flow for the EVM: Defines safety rules for EVM control flow, ensuring that contracts cannot halt due to invalid jumps or stack underflows. (EIP-3779)

Strict Enforcement of ChainID: Requires transactions to have an explicit chainId that matches the node's configuration, preventing cross-chain transaction replay attacks. (EIP-3788)

PUSH0 Instruction: Introduces the PUSH0 instruction, which pushes the constant value 0 onto the stack, reducing gas costs and bytecode size. (EIP-3855)

Limit and Meter Initcode: Sets a maximum size limit for initcode at 49,152 bytes and introduces a gas cost of 2 for every 32-byte chunk of initcode. (EIP-3860)

Gas Refunds on Reverts: Proposes refunds for reverted SSTORE, CREATE, SELFDESTRUCT, and LOGX operations, only charging for access costs but not modification costs. (EIP-3978)

Static Relative Jumps (RJUMP): Introduces new instructions (RJUMP, RJUMPI, and RJUMPV) that use relative offsets for static jumps, reducing execution costs and simplifying code analysis. (EIP-4200)

Difficulty Bomb Delay to June 2022: Delays the Ethereum difficulty bomb, making its effects noticeable by June 2022, to allow time for the Merge to Proof-of-Stake. (EIP-4345)

Time-Aware Base Fee Calculation: Proposes adjusting the block gas target based on block time to target stable throughput by time, helping to smooth base fee volatility under PoW and missed slots under PoS. (EIP-4396)

PREVRANDAO: Supplants the DIFFICULTY opcode with PREVRANDAO, which returns the latest beacon chain randomness in PoS blocks, replacing the former PoW-related difficulty value. (EIP-4399)

Bound Historical Data in Execution Clients: Clients must stop serving and may prune historical headers, bodies, and receipts older than one year, relying on weak subjectivity checkpoints for syncing. (EIP-4444)

Transaction Calldata Gas Cost Reduction: Reduces the gas cost for transaction calldata to 3 gas per byte and introduces a cap on the total calldata per block to mitigate the increased network strain. (EIP-4488)

Multi-byte Opcodes: Reserves 0xEB and 0xEC as prefixes to introduce extended multi-byte opcodes, allowing more opcodes to be defined in a larger opcode space. (EIP-4520)

Procedures for the EVM: Introduces ENTERPROC, LEAVEPROC, CALLPROC, and RETURNPROC instructions to define and manage EVM procedures with automatic memory stack management. (EIP-4573)

Consensus Layer Withdrawal Protection: Proposes additional protection for the BLSToExecutionChange operation to mitigate the risk of compromised consensus layer keys, providing a social consensus mechanism to favor legitimate holders. (EIP-4736)

Simplify EIP-161: Simplifies and retroactively deprecates unused aspects of EIP-161 related to state-clearing mechanisms, removing unnecessary edge cases that cannot occur on Ethereum Mainnet. (EIP-4747)

EOF - Functions: Introduces function isolation and CALLF and RETF instructions, allowing separate code sections for each function in EOF contracts and removing the need for dynamic jumps. (EIP-4750)

Deactivate SELFDESTRUCT: Renames the SELFDESTRUCT opcode to SENDALL, allowing contracts to transfer all ETH to a target without deleting code or storage, to prepare for future stateless Ethereum. (EIP-4758)

SELFDESTRUCT Bomb: Phases out the SELFDESTRUCT opcode by exponentially increasing its gas cost over time, eventually converting it to SENDALL, which transfers all ETH in the account but no longer deletes code or storage. (EIP-4760)

Statelessness Gas Cost Changes: Revises gas costs to reflect the cost of generating stateless witnesses, updating the gas schedule for access events and storage operations in preparation for Verkle trees. (EIP-4762)

Beacon Block Root in EVM: Introduces a system to store the hash of the beacon chain block root in the EVM, allowing proofs of beacon chain state for use cases like staking pools, bridges, and MEV mitigations. (EIP-4788)

Transaction Gas Limit Cap: Sets a maximum transaction gas limit of 2^63-1, ensuring that gas values are within a reasonable range. (EIP-4803)

Shard Blob Transactions: Introduces a new transaction type for blobs of data that improve Ethereum’s data availability, a key step toward full sharding, scaling Ethereum while maintaining backward compatibility. (EIP-4844)

Beacon Chain Push Withdrawals: Implements push-based validator withdrawals from the beacon chain to the EVM via a system-level operation, allowing for seamless withdrawals without user intervention. (EIP-4895)

Deposit Contract Snapshot Interface: Defines a format for transmitting the deposit contract Merkle tree in a compressed form, improving weak subjectivity sync times and reducing storage requirements for consensus clients. (EIP-4881)

eth/67 - Removal of GetNodeData: Removes the GetNodeData and NodeData messages from the Ethereum wire protocol, reflecting changes in how state data is accessed and promoting the use of the snap protocol. (EIP-4938)

MULDIV Instruction: Introduces the MULDIV instruction, which performs x * y / z in 512-bit precision, providing an efficient way to perform fixed-point arithmetic and cryptographic calculations in EVM. (EIP-5000)

AUTHUSURP: Introduces an opcode that deploys code to an authorized address, allowing externally owned accounts (EOAs) to migrate to contract accounts, effectively revoking the original ECDSA signature authority. (EIP-5003)

Increase SSTORE Price: Increases the gas cost of the SSTORE opcode from 20,000 to 40,000 when creating new storage (i.e., from zero to non-zero), reflecting the growing cost of adding state. (EIP-5022)

Remove Contract Code Size Limit: Removes the 24,576-byte limit on contract code size, allowing contracts to exceed this limit with additional gas costs applied based on the size of the contract. (EIP-5027)

AIRDROP Opcode: Introduces the AIRDROP opcode, which transfers ether to a destination address without handing over execution flow, preventing reentrancy risks during ether transfers. (EIP-5065)

EIP Editor Handbook: Outlines the responsibilities and processes of Ethereum Improvement Proposal (EIP) editors, including how decisions are made, the election of a Keeper of Consensus, and editor membership guidelines. (EIP-5069)

Expirable Transaction: Adds a transaction type with an expiration defined by a block number, allowing transactions to automatically expire after a certain block height. (EIP-5081)

Difficulty Bomb Delay to September 2022: Delays the Ethereum difficulty bomb by 11.4 million blocks, postponing its effects until mid-September 2022. (EIP-5133)

Semaphore for Reentrancy Protection: Introduces a precompiled contract at 0x0A to provide reentrancy protection by checking if an address is already present in the call stack, preventing reentrancy attacks without modifying storage. (EIP-5283)

Silent Signing Extension: Adds JSON-RPC methods to enable silent signing of transactions without user interaction for a specified period, improving user experience for high-transaction applications like gaming. (EIP-5345)

EOF - Stack Validation: Introduces deploy-time validation for EVM Object Format (EOF) functions, ensuring that stack underflows and overflows cannot occur during execution, reducing runtime checks. (EIP-5450)

CREATE2COPY: Introduces the CREATE2COPY opcode to reduce gas costs for creating contracts with identical code by referencing an existing contract’s code, avoiding redeployment gas expenses. (EIP-5478)

Restrict Ethereum Provider API Injection: Provides guidance for wallets to restrict the injection of Ethereum Provider APIs (like window.ethereum) to secure contexts, improving user privacy and security. (EIP-5593)

MCOPY: Adds the MCOPY opcode to efficiently copy memory within the EVM, reducing the gas cost of memory operations compared to using MLOAD and MSTORE. (EIP-5656)

window.evmproviders Object: Proposes replacing window.ethereum with window.evmproviders, allowing multiple wallets to be injected simultaneously, improving interoperability and user experience. (EIP-5749)

External Resource Approval Process: Defines the process for approving and managing external resources linked from EIPs, ensuring immutability, availability, and free access to resources. (EIP-5757)

Wallet Call API: Introduces new JSON-RPC methods for wallets to process batches of on-chain calls, enabling features like atomic execution of multiple transactions. (EIP-5792)

eth/68 - Add Transaction Type to Announcements: Extends the NewPooledTransactionHashes message to include transaction types and sizes, allowing nodes to optimize the fetching and propagation of transactions. (EIP-5793)

Delegate Transaction: Introduces a new transaction type allowing externally owned accounts (EOAs) to execute arbitrary code using a delegate call, expanding EOA capabilities without migrating to contract wallets. (EIP-5806)

PAY Opcode: Adds the PAY opcode to transfer ether to an address without executing any code on the recipient’s side, preventing reentrancy attacks and reducing gas costs for simple ether transfers. (EIP-5920)

Poseidon Hash Function Precompile: Adds a precompiled contract for the Poseidon cryptographic hash function, enabling efficient interoperability with ZK-rollups and zero-knowledge proofs on Ethereum. (EIP-5988)

DEACTIVATE: Replaces SELFDESTRUCT, keeping the account’s storage and marking the account as deactivated by setting its nonce to 2^64-1, while transferring the balance and leaving the option to reuse the account via CREATE2. (EIP-6046)

Deprecate SELFDESTRUCT: Officially deprecates the SELFDESTRUCT opcode by discouraging its use and signaling that its behavior might change in the future. (EIP-6049)

Private Key Encapsulation: Defines a method to securely transfer private keys using ECIES encryption, allowing private keys to be moved between applications without exposing the seed. (EIP-6051)

Supply Validator Deposits on Chain: Shifts the responsibility of validator deposit processing to the Execution Layer, removing deposit voting and simplifying the Consensus Layer. (EIP-6110)

Forkid Checks Based on Timestamps: Modifies the forkid checks to consider timestamps, aligning with the Proof-of-Stake fork scheduling mechanism that is based on time instead of block numbers. (EIP-6122)

Nonce Cap: Caps account nonce values at 2^64-2, reserving higher values for special contract functionality defined in other EIPs. (EIP-6188)

Alias Contracts: Introduces alias contracts, where a contract with nonce 2^64-1 forwards all calls to another contract, simplifying contract forwarding mechanisms. (EIP-6189)

Verkle-Compatible SELFDESTRUCT: Modifies SELFDESTRUCT to make it compatible with Verkle trees by setting the contract to an alias contract instead of deleting all its state. (EIP-6190)

JUMPF Instruction: Introduces the JUMPF opcode for EOF (EVM Object Format) contracts, enabling efficient tail-call optimizations without adding a return stack frame. (EIP-6206)

SSZ Transactions: Migrates transaction serialization from RLP to SSZ, aligning the transaction format with consensus and providing extensibility for future transaction features. (EIP-6404)

SSZ Withdrawals Root: Migrates the withdrawal Merkle-Patricia Trie (MPT) root to Simple Serialize (SSZ), aligning the withdrawals_root across consensus and execution layers. (EIP-6465)

SSZ Receipts: Migrates RLP receipts to SSZ, enabling efficient proofs for individual receipt components, simplifying gas calculations, and unifying receipt handling across transaction types. (EIP-6466)

SSZ Optional: Introduces the Optional[T] type in SSZ, allowing compact serialization for optional values without using workaround types like Union. (EIP-6475)

SSZ Transaction Signature Scheme: Defines a signature scheme for native SSZ transactions, reducing overhead by avoiding conversions from RLP and ensuring efficient hashing using SSZ. (EIP-6493)

EVMMAX Modular Arithmetic: Adds new EVM opcodes (ADDMODX, SUBMODX, MULMODX, etc.) for modular arithmetic operations, enabling efficient elliptic curve computations and cryptographic applications. (EIP-6690)

SELFDESTRUCT Only in Same Transaction: Limits SELFDESTRUCT to only fully delete contracts if called in the same transaction as contract creation; otherwise, it transfers ether but keeps the contract intact. (EIP-6780)

Rename Gas to Mana: Renames "gas" to "mana" across the Ethereum ecosystem to reflect the environmental friendliness of Proof-of-Stake and better represent the concept of resource use. (EIP-6789)

Unified Verkle Tree for State: Introduces a new Verkle tree for Ethereum's state, storing all changes in a Verkle structure while freezing the existing MPT. This is the first step towards Ethereum's transition to Verkle trees. (EIP-6800)

Ex Post Facto Cascading Revert: Introduces a transaction type that can revert a sender’s previous transactions, along with any subsequent dependent transactions, by cascading state reversion. (EIP-6810)

10-Minute Blocks: Increases Ethereum’s block time to 10 minutes to facilitate network synchronization over cosmic distances, enabling validators on the moon or other celestial bodies. (EIP-6811)

Preimage Retention: Requires execution layer (EL) clients to store the preimages of addresses and slot hashes produced between a fork preceding the verge and the verge itself, ensuring preimage availability for the transition to Verkle trees. (EIP-6873)

Math Checking in EVM: Adds checks for math underflows, overflows, and division by zero at the EVM level and introduces flags to signal errors. (EIP-6888)

SETCODE: Introduces the SETCODE opcode (0xfc) that allows contracts to replace their code in place, avoiding the need for SELFDESTRUCT and preserving internal state. (EIP-6913)

Reuse Withdrawn Validator Indices: Reuses fully withdrawn validator indices after a safe-to-reuse period to prevent unbounded growth of the beacon chain validator list. (EIP-6914)

Automatically Reset Testnet: Proposes a testnet that automatically resets to genesis at periodic intervals, preventing state bloat and providing a fresh environment for short-term testing. (EIP-6916)

Network Upgrade Activation Triggers: Lists and categorizes the various methods used to trigger network upgrades in Ethereum, including block numbers, total difficulty, and timestamps. (EIP-6953)

Multi Injected Provider Discovery: Proposes a new mechanism for discovering multiple wallet providers in a web page using window events, resolving conflicts caused by window.ethereum injection. (EIP-6963)

Contract Secured Revenue: Introduces Contract Secured Revenue (CSR) on EVM-based L2s, allowing smart contracts to claim a portion of transaction fees paid when users interact with them. (EIP-6968)

Elected Block Proposer Not Slashed: Ensures that a slashed validator cannot be elected as a block proposer, preventing missed proposals and maintaining network stability. (EIP-6988)

Execution Layer Triggerable Withdrawals: Allows validators with execution layer (0x01) withdrawal credentials to trigger exits and partial withdrawals directly from the execution layer, enhancing control over staked ETH. (EIP-7002)

Scheme-Handler Discovery Option (SHADOW): Proposes using custom protocol handlers to initiate connections between web pages and wallets via iframes and the postMessage API, enabling multiple wallets without content script permissions. (EIP-7039)

Perpetually Valid Signed Voluntary Exits: Locks the voluntary exit signature domain on Capella, allowing validator exits to be valid across future forks without needing to be re-signed. (EIP-7044)

Increase Max Attestation Inclusion Slot: Extends the maximum inclusion slot for attestations to the last slot of the next epoch (N+1), improving LMD-GHOST security and enabling faster confirmation rules. (EIP-7045)

Revamped CALL Instructions: Introduces EXTCALL, EXTDELEGATECALL, and EXTSTATICCALL with simplified gas semantics and clearer status codes, optimizing call operations in EOF contracts. (EIP-7069)

Linter Scope: Suggests a policy where EIP lint errors on unchanged lines should not block pull requests, improving the contribution process. (EIP-7199)

Increase the MAX_EFFECTIVE_BALANCE: Raises the maximum effective balance for validators while maintaining the minimum 32 ETH requirement, allowing for compounding rewards and validator consolidation. (EIP-7251)

Remove BLAKE2 Compression Precompile: Deprecates the blake2f (0x09) precompile by making calls to it result in an exceptional abort, as it has not seen significant use since its introduction. (EIP-7266)

ERC/EIP Repository Split: Proposes separating ERC specifications into a new repository, leaving the EIP repository focused on core protocol changes. (EIP-7329)

Migration Transaction: Introduces a transaction type allowing EOAs to migrate to smart contracts by deploying code at their own address and setting their storage, facilitating smart contract wallet adoption. (EIP-7377)

Time-Weighted Averaging for Base Fee: Proposes a modification to the base fee adjustment mechanism using a geometric moving average of past block sizes, reducing oscillations and disincentivizing bribes. (EIP-7378)

Whisk Proposer Election: Upgrades the block proposer election to the Whisk SSLE protocol, keeping block proposers secret until block publishing to prevent DoS attacks against known proposers. (EIP-7441)

EOF Data Access Instructions: Introduces DATALOAD, DATALOADN, DATASIZE, and DATACOPY instructions to enable contracts to access the data section of EOF containers. (EIP-7480)

SSZ StableContainer: Introduces StableContainer[N] to create flexible, forward-compatible containers with stable serialization and merkleization. It also introduces Profile[B] to support specialized subtypes of StableContainer. (EIP-7495)

Zero-Knowledge Wormholes: Proposes a minting function to re-mint Ethers that have been secretly burned, enabling privacy-preserving transfers using ZK proofs without smart contract interactions. (EIP-7503)

Max Epoch Churn Limit: Adds a maximum limit to the validator activation churn per epoch to slow validator growth and allow time for research into long-term solutions. (EIP-7514)

BLOBBASEFEE Instruction: Introduces the BLOBBASEFEE opcode to return the blob base fee of the current block, enabling contracts to account for blob data costs. (EIP-7516)

Atomic Storage Operations (SCREDIT, SDEBIT): Adds SCREDIT and SDEBIT opcodes to atomically increment and decrement storage values, preventing overflow and underflow. (EIP-7519)

Empty Accounts Deprecation: Prohibits empty accounts (with no code, zero nonce, and zero balance) on post-merge networks, eliminating legacy technical debt. (EIP-7523)

eth/70 - Available-Blocks-Extended Protocol: Introduces eth/70, which extends the Ethereum protocol with block range information and adds messages for requesting and sending block ranges. (EIP-7542)

EVM Decimal Math: Adds arbitrary precision decimal math opcodes (DECADD, DECNEG, DECMUL, DECINV, DECEXP, DECLN, DECSIN) for high-precision arithmetic and scientific calculations in the EVM. (EIP-7543)

Verkle Proof Verification Precompile: Adds a precompiled contract for verifying verkle proofs in a stateless Ethereum context, supporting multiple proof formats. (EIP-7545)

Inclusion Lists: Introduces a mechanism allowing proposers to specify transactions that must be included in subsequent blocks, improving censorship resistance. (EIP-7547)

Committee Index Outside Attestation: Moves the committee index outside the signed attestation message, allowing aggregation of equal consensus votes and improving Casper FFG efficiency. (EIP-7549)

Hardfork Meta Backfill: Aggregates specifications for Ethereum network upgrades between the Berlin and Shapella hardforks, listing the included EIPs. (EIP-7568)

Hardfork Meta - Dencun: Lists the EIPs included in the Deneb/Cancun network upgrade across both Ethereum's execution and consensus layers. (EIP-7569)

Versioning Scheme for EIPs: Introduces a semantic versioning scheme for EIPs, allowing clearer tracking of specification changes after they move to the "Review" status. (EIP-7577)

Reserve Precompile Address Range for RIPs: Reserves a precompile address range for the Rollup Improvement Proposal (RIP) process to avoid conflicts with Ethereum precompiles. (EIP-7587)

BLS Signed Transactions: Introduces a new transaction type signed with BLS signatures, allowing for the aggregation of signatures and reducing chain history growth. (EIP-7591)

PeerDAS - Peer Data Availability Sampling: Introduces a networking protocol that allows nodes to perform data availability sampling (DAS) to ensure that blob data is available without downloading all data. (EIP-7594)

Hardfork Meta - Pectra: Lists the EIPs included in the Prague/Electra network upgrade across both Ethereum's execution and consensus layers. (EIP-7600)

Hardfork Meta - Fusaka: Lists the EIPs included in the Fulu/Osaka Ethereum network upgrade. (EIP-7607)

Decrease Base Cost of TLOAD/TSTORE: Reduces the base gas cost for TLOAD and TSTORE and introduces a superlinear pricing model, improving the efficiency of transient storage. (EIP-7609)

Revert Creation in Case of Non-Empty Storage: Reverts contract creation if the target address has non-empty storage, ensuring that contracts cannot overwrite addresses with existing storage. (EIP-7610)

Verkle State Transition via Overlay Tree: Proposes switching from the Merkle Patricia Tree (MPT) to Verkle trees by overlaying the new structure onto the existing state, leaving the MPT untouched until later migration. (EIP-7612)

EOF Contract Creation: Introduces EOFCREATE and RETURNCONTRACT instructions to handle contract creation in the EOF format, replacing legacy CREATE and CREATE2. (EIP-7620)

Increase Calldata Cost: Increases the cost of calldata to reduce the maximum block size, making room for more blobs and improving network efficiency. (EIP-7623)

Extension of EIP-778 for Client ENR Entry: Adds a new entry to the Ethereum Node Records (ENR) to specify client information, such as client name and version, for network analysis and troubleshooting. (EIP-7636)

Optimize EOA EXTCODEHASH: Optimizes the output of EXTCODEHASH for EOAs by returning 0x when an address has no code but has a balance, improving gas efficiency. (EIP-7637)

Cease Serving History Before PoS: Execution layer clients will stop serving block data from before the Paris (PoS) upgrade over the p2p network, reducing the data burden. (EIP-7639)

Drop Pre-Merge Fields: Removes obsolete fields and messages from the eth protocol that became unnecessary after the Ethereum Merge. (EIP-7642)

Historical Hashes Accumulator: A structure committing to all pre-merge headers and their associated total difficulty, facilitating light client verification of historical block data. (EIP-7643)

Alias ORIGIN to SENDER: Aliases the ORIGIN opcode to the SENDER opcode, eliminating distinctions between the original transaction initiator and the immediate sender. (EIP-7645)

Prefetch Precompile: Introduces a precompile that allows contracts to add access lists programmatically, reducing gas costs for data access operations. (EIP-7650)

Sync Committee Slashings: Adds a slashing condition for malicious sync committee messages, deterring sync committee members from signing non-canonical beacon block roots. (EIP-7657)

Light Client Data Backfill: Defines a mechanism for syncing historical light client data between beacon nodes, facilitating backward synchronization of light client data. (EIP-7658)

Access Key Opcode: Introduces the ACCESS_KEY opcode to read access-list keys of the executing contract, ensuring reliable static input declaration. (EIP-7664)

Identity Precompile EVM-ification: Replaces the identity precompile with an equivalent piece of EVM code, reducing the number of precompiles in Ethereum. (EIP-7666)

Raise Hash Function Gas Costs: Increases gas costs for hash function opcodes and precompiles to match the computational demands of zero-knowledge proof (ZK-SNARK) systems. (EIP-7667)

Remove Bloom Filters: Eliminates bloom filters from the execution block and receipt objects, acknowledging their limited utility in practical dapp usage. (EIP-7668)

Retroactively Included EIPs: Lists EIPs introducing backward-compatible consensus changes that were activated independently of network upgrades, such as nonce limits and rejecting transactions from EOAs with deployed code. (EIP-7675)

Prepare for Address Space Extension: Modifies EOF operations to avoid trimming addresses during execution, preparing for future extensions to 256-bit addresses. (EIP-7676)

Return Deposits for Distinct Credentials: Automatically queues withdrawals for validator deposits where distinct execution withdrawal credentials exist, reducing potential front-running risks in staking. (EIP-7684)

General Purpose Execution Layer Requests: Introduces a framework for contract-triggered requests in the execution layer, exposing these requests to the consensus layer for processing. (EIP-7685)

Linear EVM Memory Limits: Adds a hard memory limit in EVM, ensuring that a transaction with N gas can use at most N bytes of memory. (EIP-7686)

Forward Compatible Consensus Data Structures: Transitions consensus SSZ data structures to StableContainer, enabling forward compatibility for verifiers and decentralized staking pools. (EIP-7688)

Blob Throughput Increase: Proposes an increase in the number of blobs per block, aiming to provide more scale to Ethereum's L2 solutions relying on L1 data capacity. (EIP-7691)

EOFv1 Meta: Lists the EIPs that belong to the EVM Object Format (EOFv1) proposal, also known as "Mega EOF", providing structured code and validation improvements. (EIP-7692)

EOF Creation Transaction: Enables the deployment of EOF contracts using creation transactions, allowing the use of initcontainers for deploying EOF contracts. (EIP-7698)

Native Account Abstraction with EOF: Proposes a variant of native account abstraction relying on EOF, separating validation and execution code sections for smart contract accounts. (EIP-7701)

Set EOA Account Code: Introduces a new transaction type that allows EOAs to set code during execution, enabling features like batching, sponsorship, and privilege de-escalation. (EIP-7702)

Increase Calldata Cost: Increases the gas cost for calldata to reduce the maximum possible block size and allow for a higher block gas limit. (EIP-7703)

NONREENTRANT and REENTRANT Opcodes: Introduces two new opcodes, NONREENTRANT and REENTRANT, to control a contract’s reentrancy status, preventing reentrancy attacks. (EIP-7705)

Separate Gas Type for Calldata: Creates a separate gas market for calldata, with its own base fee and gas limit, to better manage block size without making calldata more scarce. (EIP-7706)

Incentivize Access List Provisioning: Reduces the gas cost of access lists, encouraging their use and improving the data load efficiency for execution layer clients. (EIP-7707)

ETH Transfers Emit a Log: Automatically generates a log for every ETH transfer, including via transactions, CALL, and SELFDESTRUCT, enabling easier tracking of ETH movement. (EIP-7708)

Read BLOCKHASH from Storage: Modifies the BLOCKHASH opcode to retrieve the block hash from storage, adjusting its gas cost to reflect the storage access. (EIP-7709)

Box Type for EIP-712 Messages: Introduces a box type for EIP-712 messages, allowing parameters of arbitrary struct types while ensuring wallets can display the underlying data to users. (EIP-7713)

Anti-Correlation Attestation Penalties: Adjusts penalties for missed attestations based on their correlation with other missed attestations, encouraging validator diversification. (EIP-7716)

Network Upgrade Inclusion Stages: Formalizes the stages that Core EIPs go through before inclusion in network upgrades, providing better clarity on the upgrade process. (EIP-7723)

EVM Transaction Bundles: Introduces two new transaction types and an opcode, enabling EVM-native transaction bundles that delegate local sequencing rights to off-chain entities. (EIP-7727)

Enshrined Proposer-Builder Separation: Decouples the execution and consensus parts of an Ethereum block by allowing the proposer to delegate block construction to a builder, adding new validation mechanisms like Payload Timeliness Committees. (EIP-7732)

Leaf-Level State Expiry in Verkle Trees: Introduces state expiry at the leaf level in Verkle trees by adding an "update epoch" to extension nodes, allowing inactive data to be expired and reactivated via new transactions. (EIP-7736)

Uncouple Blob Count Between CL and EL: Separates blob count verification between the consensus and execution layers, allowing the consensus layer to verify blob targets while the execution layer dynamically receives the target from the consensus layer. (EIP-7742)

Two-Dimensional Log Filter Data Structure: Replaces per-block bloom filters with a two-dimensional log filter structure to improve the efficiency and precision of searching for log events, enabling light-client-friendly Merkle proofs. (EIP-7745)

State Conversion to Verkle Tree: Describes a procedure to gradually convert key-values from the Merkle Patricia Tree (MPT) to the Verkle Tree, allowing the migration of the Ethereum state in a manageable timeframe. (EIP-7748)

wallet_signIntendedValidatorData Method: Adds a new RPC method for signing data with an intended validator address using ERC-191 version 0x00, providing a simpler, more secure alternative to EIP-712 for smart contract accounts. (EIP-7749)

EOF/EVM Trace Specification: Updates the EIP-3155 JSON tracing specification to add support for EOF (EVM Object Format), enhancing the traceability of EOF contracts with new fields for sections and function depth. (EIP-7756)

HASCODE Opcode: Introduces the HASCODE opcode to discriminate between externally owned accounts (EOAs) and contract accounts, helping implement ERC-721 and ERC-1155 standards in EOF contracts. (EIP-7761)

Increase MIN_BASE_FEE_PER_BLOB_GAS: Proposes increasing the MIN_BASE_FEE_PER_BLOB_GAS to speed up price discovery on blob space, enhancing the Ethereum network’s efficiency during high demand. (EIP-7762)

Amsterdam Hardfork Meta: Lists the EIPs formally proposed, considered, and scheduled for inclusion in the Amsterdam network upgrade. (EIP-7773)

Prevent Block Gas Smuggling: Modifies gas accounting to exclude discounts and refunds from block gas calculations, ensuring block gas usage aligns with the actual workload. (EIP-7778)

Reduce Slot Time for Lower Peak Bandwidth: Proposes reducing Ethereum's slot time from 12 seconds to 8 seconds, increasing throughput by ~33% and improving bandwidth distribution. (EIP-7782)

Controlled Gas Limit Increase Strategy: Introduces a controlled gas limit increase mechanism, gradually raising the gas limit by a fixed rate to scale network capacity predictably. (EIP-7783)

GETCONTRACT: Introduces the GETCONTRACT opcode to return the address containing the bytecode by its hash, allowing contracts to identify and interact based on deterministic and tamper-proof bytecode identifiers. This opcode enhances security, auditability, and efficiency in the Ethereum ecosystem by enabling deterministic references to contract code, bypassing the mutability and opacity of contract addresses. (EIP-7784)

Dynamic target blob count: Adjusts the target blob count dynamically to maintain constant blob costs, aiming to optimize network resources and economic incentives related to blob space utilization, making L2 transactions costs predictable and stable. (EIP-7788)

Controlled Gas Limit Increase Guidelines: Provides specific parameters for a controlled and gradual increase in the Ethereum gas limit, aiming to ensure stable and predictable network scalability by outlining the start block, rate of increase, and gas cap. (EIP-7790)

Verifiable logs: Introduces a scheme to make the eth_getLogs response verifiable, enhancing the security and reliability of log information used by applications, by verifying log entries against accumulative commitments stored in a dedicated contract. (EIP-7792)