Summary: Ethereum Follow Protocol is best understood not as a social app, but as a portable registry for following, tagging, muting, and blocking Ethereum accounts through NFT-addressed lists. Its core mechanism is the separation between list ownership, list management, intended user identity, and list storage location. That makes it a useful comparison class for ENS, SIWE, delegate registries, and attestation systems, because it shows how a reusable account-relationship graph can be standardized independently of any one interface or feed algorithm.
What it does:
Lets users mint an EFP List NFT and use it to create an onchain list of followed Ethereum accounts
Stores list entries as versioned List Records and supports tags such as block, mute, and top8, plus arbitrary custom tags
Separates each list into Owner, Manager, and User roles so custody, editing, and represented identity can be split across addresses
Allows the List NFT to point at a List Storage Location on Ethereum L1, Ethereum L2, and potentially CCIP-read-based offchain storage in the future
Uses Account Metadata to mark a Primary List, with the union of all Primary Lists forming the social graph used for follower counts
Exposes app, docs, contracts, and API repos so other clients can integrate, inspect, and reuse the protocol
Key claims:
The intro docs make the design choice explicit: the primitive is the list, not the interface. A user mints a list NFT, sets a storage location, and populates records that other apps can interpret.
The Owner / Manager / User split is the most important analytic feature. It reveals that the real control plane is not merely “who follows whom,” but who holds the NFT, who can edit records, and which Ethereum account the list is meant to represent.
The roles docs emphasize that the Owner role is the most important because it controls the List Storage Location. That means secure custody of the NFT is upstream of every downstream social experience built on the list.
The List Records docs are valuable because they keep the base data structure deliberately minimal: version + record type + data bytes, with only address records enabled at launch. This gives EFP a narrow initial primitive while leaving room for future record types such as ENS names, DIDs, NFT references, encrypted records, and URLs.
The docs also warn that managers can upload arbitrary record data and clients must validate version, type, and data length. That is an important reminder that “open protocol” shifts responsibility onto client interpretation and validation policy.
EFP’s follower-count logic is more opinionated than a casual “follow protocol” label suggests. Only Primary Lists count toward the social graph, and block / mute-tagged accounts are excluded from followers and following counts.
EFP belongs in the corpus because it provides a clean example of unbundling a social product into portable ownership, list-editing authority, metadata, and downstream interpretation.
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official app site, official docs on introduction / roles / list records / list metadata, and the official GitHub organization and repos; see ../whitepapers/ethereum-follow-protocol-primary-sources-2026-05-10.md.