Cowrie Research

ethereum-follow-protocol

3 min read

Ethereum Follow Protocol

  • Name: Ethereum Follow Protocol
  • URL: https://efp.app/
  • Category: onchain social graph protocol / identity-stack primitive / portable account-list registry
  • Tags: ethereum-ecosystem
  • Summary: Ethereum Follow Protocol is a portable account-list registry, not a social app. It standardizes following, muting, blocking, and tagging Ethereum accounts through NFT-addressed lists whose ownership, management, represented user, and storage location can all diverge. The useful point is that EFP turns account-relationship data into a reusable object other clients can read instead of leaving the graph trapped inside one interface.
  • 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.
  • Sources:

Internal linkages

  • App-facing packaging layer that turns EFP data into default profile and follow UI for developers: ethereum-identity-kit

  • Fatter onchain social-graph branch that keeps more identity and social product surface inside one protocol family: lens-protocol

  • Adjacent session/auth primitive for apps that want Ethereum-account sign-in around the same identity surface: eip-4361

  • Last reviewed: 2026-06-06 UTC

Graph View

Backlinks