Introduction
A social graph is a map of relationships.
In traditional internet platforms, that usually means who follows whom, who messages whom, or who belongs to which group. In web3, the idea becomes much broader. A social graph can connect wallets, decentralized identifiers, communities, governance activity, attestations, and reputation signals across multiple apps and networks.
That matters now because crypto is moving beyond simple wallet balances. More products need ways to understand who an address represents, how that entity is connected to others, and whether those connections can be trusted. This affects digital identity, self-sovereign identity, proof of humanity, on-chain reputation, and DAO governance.
In this guide, you’ll learn what a social graph is, how it works, where it fits in the Identity & Governance ecosystem, its benefits and limitations, and how to think about security and privacy before relying on it.
What is social graph?
A social graph is a structured representation of relationships between people, organizations, wallets, devices, or applications.
Beginner-friendly definition
Think of it as a network map:
- each node is a person, wallet, DID, organization, or app
- each edge is a relationship, such as follows, membership, delegation, trust, credential issuance, or past interaction
In crypto, a social graph may include:
- wallet-to-wallet interactions
- DAO membership
- governance forum participation
- delegated voting relationships
- signed attestations
- verifiable credentials
- links between a person’s identity wallet and their public profiles
Technical definition
Technically, a social graph is a graph data model made of vertices and edges. The edges may be:
- directed or undirected
- weighted by strength or importance
- typed by relationship class
- time-based, expiring or changing over time
- verifiable using digital signatures
In web3 systems, graph data can be built from on-chain events, off-chain databases, decentralized storage, or a hybrid model. Trust often comes from cryptographic primitives such as digital signatures, hashing, key management, and sometimes zero-knowledge proofs for selective disclosure.
Why it matters in Identity & Governance
A wallet address alone says very little. It can hold tokens, sign transactions, or vote, but it does not automatically tell you:
- whether it belongs to a unique human
- whether it is linked to a known contributor
- whether it has long-term community history
- whether it has been vouched for by a trusted credential issuer
- whether it is part of a Sybil cluster or governance attack
A social graph adds context.
In the broader Identity & Governance ecosystem, it helps connect:
- digital identity and self-sovereign identity (SSI)
- decentralized identifiers (DIDs)
- verifiable credentials
- attestations and signed attestations
- proof of humanity or proof of personhood network designs
- on-chain reputation
- governance systems such as off-chain voting, on-chain voting, and delegated voting
How social graph Works
At a high level, a social graph works by collecting relationship data, verifying it where possible, and making it usable for applications.
Step-by-step explanation
1. Entities get identifiers
The graph starts with entities such as:
- wallets
- users
- DAOs
- credential issuers
- applications
- DIDs
A person may use one wallet, several wallets, one DID, or multiple DIDs depending on privacy and use case.
2. Relationship signals are created
These signals can come from many places, including:
- following or subscribing
- sending and receiving assets
- participating in a governance forum
- submitting or commenting during a proposal lifecycle
- off-chain voting on a Snapshot-style system
- on-chain voting through a governance module
- receiving a membership credential
- obtaining proof of attendance or contribution
- being delegated votes by other members
- locking tokens in a voting escrow or veToken system
Each of these can become an edge in the graph.
3. Claims are signed or recorded
Some relationships are just observed behavior. Others are explicit claims.
For example:
- a credential issuer can sign a verifiable credential
- a DAO can issue a signed attestation
- a governance contract can emit on-chain voting events
- an identity wallet can present a proof tied to a DID
Digital signatures matter here. They allow others to verify that a claim came from the expected issuer and was not modified after issuance.
4. Data is stored and indexed
Not all graph data belongs on-chain.
- On-chain data is transparent and easier to verify, but expensive and permanent.
- Off-chain data is cheaper and more flexible, but requires stronger integrity and availability design.
- Hybrid systems often store the full credential off-chain while anchoring a hash, status pointer, or revocation reference on-chain.
5. Applications apply rules
Apps then interpret the graph for specific purposes, such as:
- granting access to a private community
- ranking contributors
- filtering bots
- calculating reputation
- enabling delegated voting suggestions
- setting governance permissions
- checking whether quorum threshold rules should treat certain participants differently
This step is where design choices matter most. The graph itself is neutral. The application logic is not.
6. Relationships change over time
A good social graph is not static.
Credentials can expire. Attestations can be disputed. A credential issuer can revoke a claim. Delegations can be removed. Governance status can change after a proposal passes or fails.
That is why credential revocation and update mechanisms are a core part of any serious identity system.
Simple example
Imagine Alice joins a DAO.
- She creates a wallet and an identity wallet tied to a DID.
- She completes identity proofing with a provider or community process.
- She receives a verifiable credential showing she is an approved community member.
- She contributes to discussions in the governance forum.
- Another member delegates votes to her.
- The DAO issues an attestation for completing a working group task.
- A governance app reads those signals and recognizes Alice as a legitimate contributor.
Now the DAO can use that graph to:
- let Alice access contributor-only tools
- reduce spam in governance
- show her reputation history
- help others decide whether to delegate to her
Technical workflow
A more technical implementation may look like this:
- a DID document points to public verification methods
- a credential issuer signs a verifiable credential with its private key
- the user stores it in an identity wallet
- the app verifies issuer signatures using public keys
- a revocation registry is checked
- selective disclosure or zero-knowledge proofs reveal only needed facts
- a smart contract or off-chain policy engine applies governance rules
For example, the rule might be: “allow proposal creation only if the wallet can prove membership credential validity and prior contribution attestation, without revealing legal name.”
Key Features of social graph
A useful social graph usually has several important features.
Relationship-centered design
It focuses on connections, not just isolated identities. This is what makes it useful for trust, reputation, and governance.
Multi-source identity signals
A strong graph can combine:
- DIDs
- wallet activity
- verifiable credentials
- attestations
- governance participation
- community endorsements
No single signal is enough for every use case.
Cryptographic verification
Where possible, claims should be backed by digital signatures. This improves integrity and reduces tampering risk.
Portability
In better-designed systems, a user can carry parts of their reputation or identity from one app to another instead of starting from zero every time.
Revocability and expiry
Identity claims should not last forever by default. Real systems need expiry dates, status checks, and credential revocation support.
Privacy options
A modern social graph does not have to expose every relationship publicly. Selective disclosure, encryption, and zero-knowledge proofs can reduce unnecessary exposure.
Governance utility
A social graph can support:
- delegated voting
- contributor discovery
- proposal review workflows
- governance forum permissions
- risk signals against governance attacks
Composability
Different protocols, wallets, and applications can build on the same underlying identity and attestation layers if standards are compatible.
Types / Variants / Related Concepts
The term social graph overlaps with several adjacent concepts. These are related, but not identical.
Social graph vs digital identity
Digital identity is the broader idea of how an entity is represented online. It can include usernames, wallet addresses, DIDs, credentials, and account history.
A social graph is narrower: it focuses on the relationships between identities.
Self-sovereign identity (SSI)
SSI is an approach where users control their identity data rather than relying entirely on centralized platforms. In practice, SSI often uses:
- DIDs
- identity wallets
- verifiable credentials
- selective disclosure
A social graph can be built on top of SSI, but SSI is the identity model, not the graph itself.
Decentralized identifier (DID)
A DID is an identifier format designed for decentralized systems. It helps resolve keys and verification methods without depending on one central database.
A DID can be a node in a social graph. It is not the graph.
Verifiable credential and credential issuer
A verifiable credential is a signed claim about a subject. A credential issuer is the entity that signs it.
Examples of claims:
- “This wallet belongs to an approved member”
- “This user completed identity proofing”
- “This person attended an event”
- “This developer contributed to project X”
These become powerful graph inputs when combined with relationships and reputation.
Attestation and signed attestation
An attestation is a statement made by one party about another. A signed attestation is cryptographically signed so others can verify who issued it.
Not every attestation is a full verifiable credential. Some are simpler, more app-specific signals.
On-chain reputation
On-chain reputation is reputation derived from blockchain-visible behavior, such as voting history, staking behavior, contribution records, or transaction patterns.
It can feed into a social graph, but it does not capture the full picture. Many important identity and trust signals remain off-chain.
Proof of humanity and proof of personhood network
These systems aim to show that one account corresponds to one real human, or at least one distinct person, without necessarily exposing full personal identity.
They can be used to strengthen a social graph for anti-Sybil purposes, but they do not replace the graph. They only answer one question: uniqueness.
Governance process connections
A DAO’s governance process naturally creates graph data:
- governance forum discussion
- proposal lifecycle activity
- off-chain voting
- on-chain voting
- delegated voting relationships
- vote locking through voting escrow
- veToken participation
- governance module permissions
This is why social graphs matter beyond social apps. They are also governance infrastructure.
Benefits and Advantages
A well-designed social graph can create value for different groups.
For users
- portable reputation across apps
- less repeated onboarding
- stronger pseudonymous credibility
- better discovery of communities and collaborators
For developers
- reusable identity and attestation layers
- more nuanced access control
- improved bot and Sybil filtering
- richer recommendation and matching systems
For DAOs and communities
- better contributor recognition
- smarter delegated voting flows
- stronger resistance to low-effort governance spam
- more context around voter participation
For businesses and enterprises
- flexible partner and member access systems
- verifiable claims without exposing all underlying data
- lower dependence on a single identity platform
- clearer governance and permissioning models
For markets and ecosystems
The biggest advantage is not speculation. It is coordination.
A social graph helps protocols understand who is interacting, which relationships matter, and how trust can be transferred or verified across systems.
Risks, Challenges, or Limitations
Social graphs are useful, but they are not neutral or risk-free.
Privacy and deanonymization risk
Combining wallets, DIDs, credentials, and behavioral data can make users easier to track. Even if each data point seems harmless, the combined graph may reveal more than intended.
Bad or misleading data
If an issuer is careless, compromised, or dishonest, the graph becomes less trustworthy. A signed attestation is only as useful as the trust in the signer.
Centralization around major issuers
SSI and decentralized identity do not automatically eliminate power concentration. If a small number of credential issuers become dominant, they can shape who gets access and who does not.
Sybil and governance attacks
Attackers can try to farm credentials, buy old accounts, simulate interactions, or exploit delegated voting networks. A social graph can reduce some abuse, but it can also become a target.
Bias and exclusion
Graph-based scoring can favor early users, highly connected insiders, or people from certain communities. New users may face a cold-start problem.
Revocation and dispute complexity
What happens if a credential is revoked by mistake? What is the appeals process? How do downstream apps update their decisions? These are governance questions, not just technical ones.
On-chain permanence
Data placed directly on a blockchain is hard to remove. Sensitive identity information should generally not be stored in plaintext on-chain.
Fragmentation
Different protocols may use different DID methods, attestation formats, or revocation systems. Interoperability remains a practical challenge.
Key management risk
If a user loses keys to an identity wallet, they may lose access to credentials or reputation history unless recovery mechanisms exist.
Compliance uncertainty
Identity, privacy, and data-handling requirements differ by jurisdiction. For legal or regulatory questions, verify with current source.
Real-World Use Cases
Here are practical ways a social graph can be used in crypto and digital identity systems.
1. Portable web3 profiles
A user can carry follows, memberships, attestations, and verified roles across multiple apps instead of rebuilding a profile from scratch.
2. DAO membership and contributor tiers
DAOs can map who joined, who contributed, who reviewed proposals, and who received community-issued attestations. This can support role-based access and contributor recognition.
3. Governance delegation maps
Delegated voting creates a relationship graph. This can help members see who delegates to whom, where influence is concentrated, and how governance power flows.
4. Sybil-resistant community rewards
Projects may use identity proofing, proof of humanity, attestations, and interaction graphs to make community rewards, allowlists, or grants harder to game. This should be treated as risk reduction, not perfect prevention.
5. Reputation-aware governance
A governance module may combine token ownership with contribution history, prior voting behavior, or verified membership to shape who can propose, comment, or moderate.
6. Marketplace trust
Freelancers, creators, auditors, and service providers can use a graph of past work, endorsements, and signed credentials to show credibility without relying only on centralized platform ratings.
7. Identity-gated communication channels
Communities can use credentials and graph rules to control access to discussion spaces, voting channels, or governance forum privileges.
8. Enterprise partner onboarding
Businesses can exchange verifiable credentials for employee roles, certifications, or partner status. A social graph then maps relationships between organizations, teams, and permissions.
9. Developer ecosystems
Open-source communities can connect code contributions, issue triage, bounty completion, and governance participation into a reputation graph for maintainers and contributors.
10. Selective disclosure access control
A user might prove “I am a verified member” or “I hold a valid credential from an approved issuer” without revealing unrelated personal data.
social graph vs Similar Terms
| Term | What it means | Main focus | How it differs from a social graph |
|---|---|---|---|
| Digital identity | The overall online representation of a person, entity, or device | Identity itself | A social graph maps relationships between identities |
| Self-sovereign identity (SSI) | A user-controlled identity model using wallets, DIDs, and credentials | User control and portability | SSI can support a social graph, but it is not the graph |
| Decentralized identifier (DID) | A decentralized identifier linked to verification methods | Identification and key resolution | A DID is one node or reference point inside a graph |
| On-chain reputation | Reputation inferred from blockchain-visible actions | Behavioral history on-chain | A social graph can include on-chain reputation plus off-chain relationships |
| Proof of personhood network | A system meant to show uniqueness of participants | Sybil resistance and uniqueness | It answers “is this a distinct person?” not the full relationship map |
Best Practices / Security Considerations
If you build with social graphs, a few principles matter a lot.
Minimize data collection
Only collect the identity and relationship data you actually need. More data does not automatically mean better trust.
Avoid storing sensitive personal data on-chain
If data must be referenced on-chain, use careful design:
- anchor hashes, not raw documents
- keep encrypted data off-chain where appropriate
- remember that hashing is not the same as encryption
Verify issuers and check revocation status
Do not trust any credential just because it is signed. Verify:
- who issued it
- whether the issuer is trusted for that claim
- whether the credential has expired
- whether it has been revoked
Use selective disclosure where possible
A user often does not need to reveal full identity. Zero-knowledge proofs or minimal-claim presentations can reduce privacy leakage.
Separate identities when needed
Users may want different wallets or DIDs for different contexts. Full linkability can become a privacy problem.
Treat graph scores as inputs, not truth
A reputation score or trust score can be useful, but it should not be treated as objective reality. Provide explanation and appeal paths where decisions matter.
Design governance carefully
A social graph should complement, not replace, a sound governance framework. Good governance still needs:
- a clear governance process
- transparent proposal lifecycle rules
- anti-bribery and anti-capture thinking
- sensible quorum threshold design
- monitoring for governance attacks
Audit governance modules and identity logic
If smart contracts enforce graph-based permissions, they should be reviewed carefully. Edge weighting, delegation logic, and credential checks can all create unintended attack surfaces.
Secure the identity wallet
Identity wallets hold keys, credentials, and permissions. Basic wallet security still applies:
- protect seed phrases and private keys
- use hardware security where appropriate
- understand recovery flows
- beware phishing and malicious signature requests
Common Mistakes and Misconceptions
“A social graph is just a follower list.”
Not in web3. It can include attestations, credentials, governance actions, delegation, reputation, and access relationships.
“A DID proves who someone is.”
A DID identifies an entity and helps verify keys. It does not automatically prove legal identity, uniqueness, or trustworthiness.
“If it’s signed, it must be true.”
Digital signatures prove who signed a claim, not whether the claim is correct.
“More connections mean more trust.”
An account with many edges may still be low quality, bought, automated, or manipulated.
“Putting identity data on-chain makes it decentralized and better.”
It may make it more transparent and harder to delete, but not necessarily safer or more private.
“A social graph solves governance.”
It helps, but governance quality still depends on incentives, process design, enforcement, culture, and participation.
“Off-chain voting is not real governance data.”
It often is. Snapshot voting, forum discussion, and informal signaling can be central parts of a governance process even if final execution happens on-chain.
Who Should Care About social graph?
Beginners
If you are new to crypto, understanding social graphs helps you make sense of web3 social apps, identity wallets, community roles, and DAO participation.
Developers
If you build wallets, social apps, DAOs, marketplaces, or authentication layers, social graph design affects trust, privacy, and user experience.
Businesses and enterprises
If you need partner onboarding, role verification, or portable identity across systems, social graph architecture can reduce duplication and improve control.
Investors
If you evaluate protocols, this concept helps you analyze user retention, governance health, issuer trust assumptions, and resistance to Sybil behavior. It is more useful for assessing infrastructure quality than for predicting price.
Security and governance professionals
If you assess protocol risk, social graphs matter for access control, identity verification, vote concentration, governance attack surfaces, and reputation manipulation.
Future Trends and Outlook
Several trends are likely to shape how social graphs evolve in web3.
More portable identity and reputation
Expect stronger links between DIDs, identity wallets, verifiable credentials, and app-level profiles so users can carry trust signals more easily.
Better privacy-preserving proofs
Selective disclosure and zero-knowledge systems are likely to become more important as users demand proof without oversharing.
Stronger issuer and revocation infrastructure
As credential use grows, issuer reputation, credential status registries, and revocation design will matter more.
Governance-native identity layers
More DAOs may connect forum identity, delegated voting, on-chain voting, and reputation into a single governance experience rather than keeping them siloed.
Ongoing tension between privacy and compliance
Identity systems will continue balancing user control, anti-fraud needs, and jurisdiction-specific requirements. For regulatory implications, verify with current source.
Less focus on raw follower counts, more on verifiable relationships
The industry is gradually moving from vanity metrics to more meaningful signals such as contribution history, validated membership, and context-aware trust.
Conclusion
A social graph is not just a map of followers. In web3, it is a relationship layer that can connect wallets, DIDs, verifiable credentials, attestations, governance activity, and reputation into something applications can actually use.
That makes it powerful, but also sensitive. A good social graph improves coordination, access control, and governance quality. A bad one creates privacy leaks, exclusion, and false confidence.
If you are evaluating or building around this concept, start with three questions:
- What relationships actually matter?
- How are those relationships verified?
- How will privacy, revocation, and governance disputes be handled?
Get those right, and a social graph becomes useful infrastructure rather than just another buzzword.
FAQ Section
1. What is a social graph in simple terms?
A social graph is a network map showing how people, wallets, organizations, or apps are connected to each other.
2. Is a social graph only for social media?
No. In web3, it can include governance activity, DAO membership, attestations, verifiable credentials, and on-chain reputation.
3. How is a social graph used in crypto?
It is used for digital identity, access control, reputation, delegated voting, anti-Sybil defenses, community rewards, and governance design.
4. Is a social graph the same as digital identity?
No. Digital identity describes an entity itself. A social graph describes relationships between entities.
5. How do DIDs fit into a social graph?
A DID can act as a node or reference point in the graph, helping verify keys and identity-related claims.
6. What is the role of verifiable credentials?
Verifiable credentials add signed claims to the graph, such as membership, role, uniqueness, or completed identity proofing.
7. Are social graphs always on-chain?
No. Many are hybrid. Some data is on-chain for transparency, while other data stays off-chain for privacy, cost, or flexibility.
8. Can a social graph prevent governance attacks?
It can help reduce some attacks, especially Sybil-style manipulation, but it is not a complete defense on its own.
9. What happens if a credential is revoked?
Applications should check revocation status and update permissions or trust decisions accordingly. Good systems include expiry and revocation handling.
10. Why do DAOs care about social graphs?
Because governance is relational. Delegation, forum participation, proposal history, contributor trust, and voter behavior all create useful governance signals.
Key Takeaways
- A social graph is a map of relationships between users, wallets, DIDs, organizations, and apps.
- In web3, it often combines social activity, identity claims, attestations, governance behavior, and reputation.
- DIDs, verifiable credentials, and identity wallets can feed a social graph, but they are not the same thing.
- Social graphs can improve access control, coordination, and DAO governance, especially when paired with proof of personhood or anti-Sybil measures.
- Signed data proves who made a claim, not whether the claim is accurate.
- Privacy, issuer trust, credential revocation, and key management are core design concerns.
- A social graph should support governance, not replace a sound governance framework.
- The best systems use minimal disclosure, clear revocation logic, and transparent decision rules.