Summary: Next.ID is best understood not as a generic DID brand, but as an offchain identity-graph control plane that splits identity binding, user-signed profile data, graph indexing, and downstream profile APIs into separate layers. Its core mechanism is the Avatar: a keypair-controlled identity root that can prove ownership of web2 and web3 accounts, append signed metadata, and then be queried through relation and profile services. That makes Next.ID a useful comparison class for BYOF, ComposeDB, Ethereum Follow Protocol, OpenRank, and Human Passport: those systems foreground follow-list portability, data models, rankings, or sybil scoring, while Next.ID foregrounds the lower-layer problem of how heterogeneous account claims get bound, stored, indexed, and served back to applications.
What it does:
Lets users create an Avatar identity and bind web2/web3 accounts such as Twitter/X, Discord, GitHub, Ethereum, Solana, ENS, DNS, ActivityPub, and others to it through signed proofs
Records account-binding history as a signed ProofChain, where each proof references the previous link and is published publicly rather than remaining only in a hosted database
Uploads proof records to Arweave so third parties can verify bindings without fully trusting Next.ID’s hosted APIs
Exposes a KV Service that stores arbitrary JSON metadata in avatar-linked namespaces, with writes authorized by avatar signatures and patches following RFC 7396 merge semantics
Runs a RelationService that aggregates inter-identity and cross-platform graph data for search, discovery, and ranking; the project explicitly describes this layer as a search engine for identities and mentions a PageRank-like soul rank
Ships downstream developer products such as Web3.bio and the Universal Profile API so apps can resolve one identity into richer cross-platform profiles
Key claims:
The most important design move is the split between proof creation, signed metadata storage, relation indexing, and profile delivery. That decomposition is more analytically useful than filing Next.ID as just another DID product.
The ProofService docs are explicit that each persona has a public proof chain where every modification is signed and chained to the prior one. That means the durable primitive is not merely an API result but a user-controlled history of account-binding claims.
The public-verifiability story is real but partial. Next.ID pushes proof records to Arweave and makes them queryable, yet practical usage still depends on hosted proof, relation, and profile services. The governance question is therefore not just who owns the keys, but who decides supported proof methods, platform adapters, indexing scope, and API behavior.
The KV Service is a revealing second layer because it turns identity roots into portable metadata containers. Apps are encouraged to write under their own namespaces, which means application-specific presentation and social context can travel with the user instead of staying trapped inside one frontend.
RelationService is where a large share of hidden power can accumulate. The repository and docs frame it as identity-relationship aggregation plus search and even soul rank, which means query ranking, graph weighting, imported datasets, and indexing policy may matter as much as the underlying proofs.
Web3.bio and the Universal Profile API show how identity infrastructure becomes productized: the graph is not just for verification, but for search, profile synthesis, analytics, and app onboarding.
Next.ID belongs in the active corpus because it sharpens a useful distinction inside crypto identity: verifiable account binding, portable signed metadata, graph indexing, ranking, and profile rendering are separable layers even when one project presents them as one stack.
Whitepaper: No canonical standalone Next.ID whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official site, docs for ProofService and KV Service, roadmap notes, Web3.bio API docs, and the official GitHub repositories; see ../whitepapers/next-id-primary-sources-2026-05-10.md.