Protocol papers
Oracles, data and agents.
A number on a chain is only as good as the committee or the sensor that signed it. An agent that can pay needs a stop.
How to read this shelf
Each card opens a study. The study is a reading of a public paper, not the paper and not a description of today's network. Status is a design paper unless the record says historical or failure case.
How to read this page
Research status is named on the page. Primary sources are linked. This is a mechanism and operating note, not investment suitability, legal advice, a security guarantee or an implementation certificate.
Chainlink · 2017 · Design paper
Chainlink: A Decentralized Oracle Network
The 2017 Chainlink paper: a network of independent nodes that fetch off-chain data, aggregate it, and deliver a signed result on-chain, with a reputation and penalty story around the nodes. It is the reference design for 'the contract needs a fact from outside'.
The Graph · 2020 · Design paper
The Graph: a decentralised query protocol for blockchains
The Graph's protocol paper for indexing chain data. Indexers stake on serving a subgraph. Curators signal which subgraphs matter. Consumers pay for queries. The problem is read access, not consensus.
Augur · 2018 · Design paper
Augur: a Decentralized Oracle and Prediction Market Platform
The Augur paper: prediction markets whose outcomes are reported by token holders, with a dispute ladder that can escalate a contested result. It is both a market design and an oracle design. The historic library already holds Gnosis. Augur is the other canonical public prediction-market paper and was not in that set.
Ocean · 2019 · Design paper
Ocean Protocol: A Decentralized Substrate for AI Data and Services
Ocean's technical paper for publishing, pricing and consuming data services with on-chain access control and off-chain storage. The data does not sit inside the chain. The permission and the payment do.
Bittensor · 2021 · Design paper
Bittensor: A Peer-to-Peer Intelligence Market
Rao's paper for a market in which machine-learning models score each other. Peers rank neighbours, ranks accumulate on a ledger, and an incentive mechanism is specified to resist a naive cartel of mutual high scores. It is a design for pricing intelligence as a commodity, not a benchmark of any particular model.
SingularityNET · 2017 · Design paper
SingularityNET: A Decentralized, Open Market and Network for AIs
Goertzel's 2017 proposal for a marketplace where AI services discover, call and pay each other. The paper is broad on purpose: discovery, reputation, inter-agent calls and a tokenised payment rail, sketched as one network.
ERC-4337 · 2021 · Design paper
Account Abstraction Using Alt Mempool
Smart-contract accounts that propose UserOperations, bundled by a separate mempool, without a change to Ethereum's consensus. Paymasters can sponsor gas. The validation rule lives in the account, which is the point and the risk.
UMA · 2020 · Design paper
UMA Data Verification Mechanism: Adding Economic Guarantees to Blockchain Oracles
An oracle that does not answer every question in real time. It prices the cost of bribing the token holders who would resolve a dispute, and it asks contract designers to keep the profit of a lie below that cost. The draft is an economic argument, not a feed you can read as truth.
Bitcoin as a beacon · 2015 · Design paper
On Bitcoin as a Public Randomness Source
The paper asks when a proof-of-work block hash is a safe public beacon, and how a miner can bias it by withholding or grinding.
Decentralized identifiers · 2022 · Design paper
Decentralized Identifiers (DIDs) v1.0
A DID is an identifier whose document, including keys, can be resolved by a method. The method says where the document lives. The standard does not pick one blockchain.
Verifiable credentials · 2025 · Design paper
Verifiable Credentials Data Model v2.0
An issuer signs a set of claims about a subject. A holder later presents those claims, or a derivation, to a verifier. The verifier checks the issuer's signature, not a central account.
EIP-7702 · 2024 · Design paper
Set Code for EOAs
A transaction can temporarily, for the transaction's authority, delegate an externally owned account's code to a contract. The key still signs. The code that runs can batch, sponsor, or limit what the key may do.
BIP 22 · 2012 · Design paper
getblocktemplate - Fundamentals
BIP 22, getblocktemplate - Fundamentals. A new JSON-RPC method for "smart" Bitcoin miners and proxies.
BIP 23 · 2012 · Design paper
getblocktemplate - Pooled Mining
BIP 23, getblocktemplate - Pooled Mining. Extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.
BIP 43 · 2014 · Design paper
Purpose Field for Deterministic Wallets
BIP 43, Purpose Field for Deterministic Wallets. A "Purpose Field" for use in deterministic wallets based on algorithm described in BIP-0032 (BIP32 from now on).
BIP 48 · 2020 · Design paper
Multi-Script Hierarchy for Multi-Sig Wallets
BIP 48, Multi-Script Hierarchy for Multi-Sig Wallets. A logical hierarchy for deterministic multi-sig wallets based on an algorithm described in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on).
BIP 49 · 2016 · Design paper
Derivation scheme for P2WPKH-nested-in-P2SH based accounts
BIP 49, Derivation scheme for P2WPKH-nested-in-P2SH based accounts. The derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki|BIP 141]]) serialization format for segregated witness transactions.
BIP 71 · 2013 · Design paper
Payment Protocol MIME types
BIP 71, Payment Protocol MIME types. A MIME (RFC 2046) Media Type for Bitcoin payment request messages.
BIP 72 · 2013 · Design paper
bitcoin: uri extensions for Payment Protocol
BIP 72, bitcoin: uri extensions for Payment Protocol. An extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70).
BIP 73 · 2013 · Design paper
Use "Accept" header for response type negotiation with Payment Request URLs
BIP 73, Use "Accept" header for response type negotiation with Payment Request URLs. An enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]]) that addresses the need for short URLs when scanning from QR codes.
BIP 84 · 2017 · Design paper
Derivation scheme for P2WPKH based accounts
BIP 84, Derivation scheme for P2WPKH based accounts. The derivation scheme for HD wallets using the P2WPKH ([[bip-0173.mediawiki|BIP 173]]) serialization format for segregated witness transactions.
BIP 88 · 2020 · Design paper
Hierarchical Deterministic Path Templates
BIP 88, Hierarchical Deterministic Path Templates. This document describes a format for the representation of the templates that specify the constraints that can be imposed on BIP32 derivation paths.
BIP 127 · 2019 · Design paper
Simple Proof-of-Reserves Transactions
BIP 127, Simple Proof-of-Reserves Transactions. A simple way to construct proof-of-reserves transactions.
BIP 145 · 2016 · Design paper
getblocktemplate Updates for Segregated Witness
BIP 145, getblocktemplate Updates for Segregated Witness. Modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]].
BIP 173 · 2017 · Design paper
Base32 address format for native v0-16 witness outputs
BIP 173, Base32 address format for native v0-16 witness outputs. We first describe the general checksummed base32 '''Why use base32 at all?''' The lack of mixed case makes it more efficient to read out loud or to put into QR codes.
BIP 176 · 2017 · Design paper
Bits Denomination
BIP 176, Bits Denomination. Bits is presented here as the standard term for 100 (one hundred) satoshis or 1/1,000,000 (one one-millionth) of a bitcoin.
BIP 179 · 2019 · Design paper
Name for payment recipient identifiers
BIP 179, Name for payment recipient identifiers. A new term for 'address' Bitcoin addresses are intended to be only used '''once''' and you should generate a new one for every new incoming payment.
BIP 321 · 2024 · Design paper
URI Scheme
BIP 321, URI Scheme. A URI scheme for describing Bitcoin payment instructions.
BIP 350 · 2020 · Design paper
Bech32m format for v1+ witness addresses
BIP 350, Bech32m format for v1+ witness addresses. We first specify the new checksum algorithm, and then document how it should be used for future Bitcoin addresses.
BIP 353 · 2024 · Design paper
DNS Payment Instructions
BIP 353, DNS Payment Instructions. A standard format for encoding [[bip-0021.mediawiki|BIP 21]] URI schemes in DNS TXT records.
BIP 385 · 2021 · Design paper
raw() and addr() Output Script Descriptors
BIP 385, raw() and addr() Output Script Descriptors. This document specifies raw() and addr() output script descriptors.
EIP 234 · 2017 · Design paper
Add `blockHash` to JSON-RPC filter options.
EIP 234, Add `blockHash` to JSON-RPC filter options.. Add an option to JSON-RPC filter options (used by eth_newFilter and eth_getLogs) that allows specifying the block hash that should be included in the results.
EIP 695 · 2017 · Design paper
Create `eth_chainId` method for JSON-RPC
EIP 695, Create `eth_chainId` method for JSON-RPC. Include eth_chainId method in eth_-namespaced JSON-RPC methods.
EIP 1898 · 2019 · Design paper
Add `blockHash` to defaultBlock methods
EIP 1898, Add `blockHash` to defaultBlock methods. For JSON-RPC methods which currently accept a default block parameter, additionally allow the parameter to be a block hash.
EIP 2159 · 2019 · Design paper
Common Prometheus Metrics Names for Clients
EIP 2159, Common Prometheus Metrics Names for Clients. Standardized names of common metrics for Ethereum clients to use with Prometheus, a widely used monitoring and alerting solution.
EIP 2228 · 2019 · Design paper
Canonicalize the name of network ID 1 and chain ID 1
EIP 2228, Canonicalize the name of network ID 1 and chain ID 1. The Ethereum network with network ID 1 and chain ID 1 is named Ethereum Mainnet.
EIP 2681 · 2020 · Design paper
Limit account nonce to 2^64-1
EIP 2681, Limit account nonce to 2^64-1. Account nonces are currently specified to be arbitrarily long unsigned integers.
EIP 2718 · 2020 · Design paper
Typed Transaction Envelope
EIP 2718, Typed Transaction Envelope. TransactionType || TransactionPayload is a valid transaction and TransactionType || ReceiptPayload is a valid transaction receipt where TransactionType identifies the format of the transaction and Payload is the transaction/receipt contents, which are defined in future EIPs.
EIP 3855 · 2021 · Design paper
PUSH0 instruction
EIP 3855, PUSH0 instruction. Introduce the PUSH0 (0x5f) instruction, which pushes the constant value 0 onto the stack.
EIP 4938 · 2022 · Design paper
eth/67 - Removal of GetNodeData
EIP 4938, eth/67 - Removal of GetNodeData. The Ethereum Wire Protocol defines request and response messages for exchanging data between clients.
EIP 5792 · 2022 · Design paper
Wallet Call API
EIP 5792, Wallet Call API. Defines new JSON-RPC methods which enable apps to ask a wallet to process a batch of onchain write calls and to check on the status of those calls.
EIP 7935 · 2025 · Design paper
Set default gas limit to 60M
EIP 7935, Set default gas limit to 60M. This should be significantly increased to 60M by the time Fusaka is released by execution layer clients updating their default configurations.
ERC 162 · 2016 · Design paper
Initial ENS Hash Registrar
ERC 162, Initial ENS Hash Registrar. The implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the Ethereum Name Service (ENS).
ERC 173 · 2018 · Design paper
Contract Ownership Standard
ERC 173, Contract Ownership Standard. This specification defines standard functions for owning or controlling a contract.
ERC 820 · 2018 · Design paper
Pseudo-introspection Registry Contract
ERC 820, Pseudo-introspection Registry Contract. This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.
ERC 1820 · 2019 · Design paper
Pseudo-introspection Registry Contract
ERC 1820, Pseudo-introspection Registry Contract. This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.
ERC 2535 · 2020 · Design paper
Diamonds, Multi-Facet Proxy
ERC 2535, Diamonds, Multi-Facet Proxy. This proposal standardizes diamonds, which are modular smart contract systems that can be upgraded/extended after deployment, and have virtually no size limit.
ERC 3668 · 2020 · Design paper
CCIP Read—Secure offchain data retrieval
ERC 3668, CCIP Read—Secure offchain data retrieval. Contracts wishing to support lookup of data from external sources may, instead of returning the data directly, revert using OffchainLookup(address sender, string[] urls, bytes callData, bytes4 callbackFunction, bytes extraData).
ERC 7201 · 2023 · Design paper
Namespaced Storage Layout
ERC 7201, Namespaced Storage Layout. We define the NatSpec annotation @custom:storage-location to document storage namespaces and their location in storage in Solidity or Vyper source code.
ERC 7820 · 2024 · Design paper
Access Control Registry
ERC 7820, Access Control Registry. The Access Control Registry (ACR) standard defines a universal interface for managing role-based access control across multiple smart contracts.
ERC 7950 · 2025 · Design paper
Encode chain id with transaction hash
ERC 7950, Encode chain id with transaction hash. This standard proposes a way to encode the combination of a chain ID and a transaction hash into one string.
ERC 8042 · 2025 · Design paper
Diamond Storage
ERC 8042, Diamond Storage. This standard formalizes the diamond storage pattern originally introduced by ERC-2535 Diamonds and widely adopted across smart contracts.
BIP 93 · 2023 · Design paper
codex32: Checksummed SSSS-aware BIP32 seeds
BIP 93, codex32: Checksummed SSSS-aware BIP32 seeds. We first describe the general checksummed base32 '''Why use base32 at all?''' The lack of mixed case makes it more efficient to read out loud, write, type or to put into QR codes.
BIP 122 · 2015 · Design paper
URI scheme for Blockchain references / exploration
BIP 122, URI scheme for Blockchain references / exploration. A URI scheme for looking up blocks, transactions and addresses on a Blockchain explorer, or in general to make proper Blockchain references.
BIP 126 · 2016 · Design paper
Best Practices for Heterogeneous Input Script Transactions
BIP 126, Best Practices for Heterogeneous Input Script Transactions. When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner.
BIP 128 · 2026 · Design paper
Timelock-Recovery Storage Format
BIP 128, Timelock-Recovery Storage Format. This document proposes a standard format for saving timelock-recovery plans, to allow different wallets to generate them, and different services to monitor/execute them.
BIP 136 · 2017 · Design paper
Bech32 Encoded Tx Position References
BIP 136, Bech32 Encoded Tx Position References. A '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally, an outpoint index within the transaction.
BIP 172 · 2025 · Design paper
Define Bitcoin Subunits as Satoshis
BIP 172, Define Bitcoin Subunits as Satoshis. To formally define and standardize Bitcoin's smallest indivisible unit (1/100,000,000 of a bitcoin) as "satoshi" (singular) or "satoshis" (plural), with "sats" as the standard abbreviated form.
BIP 323 · 2026 · Design paper
24 nVersion bits for general purpose use
BIP 323, 24 nVersion bits for general purpose use. 24 bits are reserved in the nVersion field as extra nonce space for miners, providing for additional hashrate with header-only mining without relying on rolling nTime more often than once per second.
BIP 376 · 2026 · Design paper
Spending Silent Payment outputs with PSBTs
BIP 376, Spending Silent Payment outputs with PSBTs. We use the following functions and conventions: ser 32 (i): serializes a 32-bit unsigned integer ''i'' as a 4-byte sequence, most significant byte first.
EIP 2780 · 2020 · Design paper
Resource-based intrinsic transaction gas
EIP 2780, Resource-based intrinsic transaction gas. This EIP decomposes the flat 21,000 intrinsic transaction cost into explicit primitives, each priced to match the resources a transaction actually consumes.
EIP 7834 · 2024 · Design paper
Separate Metadata Section for EOF
EIP 7834, Separate Metadata Section for EOF. Introduce a new separate metadata section to the Ethereum Object Format (EOF) that is unreachable by the code, and any changes to which does not affect the code.
EIP 7954 · 2025 · Design paper
Increase Maximum Contract Size
EIP 7954, Increase Maximum Contract Size. To raise the maximum allowed size for contract code deployed on Ethereum from 24,576 bytes to 65,536 bytes, and to raise the initcode size limit from 49,152 bytes to 131,072 bytes.