How to Design a Social Graph for Professional Networks in Web3

A Web3 professional social graph is a decentralized data structure that maps relationships like employment history, skills, endorsements, and project collaborations. Unlike centralized platforms like LinkedIn, which silo user data, a Web3 graph is built on open protocols, allowing users to own and port their professional identity across applications. Core components include a decentralized identifier (DID) as the root node, verifiable credentials (VCs) for attested claims (e.g., a degree), and graph edges that define relationships between entities. This architecture shifts control from a corporate database to user-controlled wallets and interoperable smart contracts.

Designing this system requires selecting foundational protocols. For identity, use the W3C DID standard with implementations like did:ethr or did:key. Attestations are best modeled as Verifiable Credentials, issued by trusted entities and stored in a user's wallet or decentralized storage like IPFS or Arweave. The graph data itself—the connections between DIDs—can be stored on-chain for global consensus (e.g., using a registry smart contract) or off-chain in a decentralized social protocol like Lens Protocol or Farcaster Frames. The choice depends on the required data permanence, cost, and update frequency.

A critical technical challenge is balancing data availability with privacy. Sensitive details, like a salary verification VC, should be stored off-chain with only its cryptographic hash committed on-chain. The EIP-712 standard is essential for signing structured, human-readable attestations. For example, an endorsement from a colleague would be a signed EIP-712 message containing the endorser's DID, the recipient's DID, a skill tag, and a timestamp. This signed payload becomes a portable, verifiable edge in the graph that any application can trust without contacting a central server.

Here is a simplified smart contract example for an on-chain professional graph registry, written in Solidity. It allows users to create connections and store the hash of a verifiable credential for auditability.

solidityCopy
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
contract ProfessionalGraph {
    struct Connection {
        address from;
        address to; // DIDs can be represented as addresses initially
        bytes32 credentialHash; // IPFS hash of the signed EIP-712 VC
        uint256 timestamp;
        string connectionType; // e.g., "ENDORSED", "COLLEAGUE_AT"
    }
    mapping(address => mapping(address => Connection)) public connections;
    event ConnectionCreated(address indexed from, address indexed to, bytes32 credentialHash);
    function createConnection(address to, bytes32 credentialHash, string calldata connectionType) external {
        connections[msg.sender][to] = Connection(msg.sender, to, credentialHash, block.timestamp, connectionType);
        emit ConnectionCreated(msg.sender, to, credentialHash);
    }
}

To query and utilize this graph, developers need indexers. For on-chain data, you can listen to the ConnectionCreated event using The Graph subgraph. For off-chain data stored on protocols like Ceramic or Lens, you would use their native GraphQL APIs. The user experience is anchored in a crypto wallet; a dApp requests signatures for connections or credential issuance via WalletConnect or a similar protocol. The end goal is an interoperable professional profile: a user's DID resolves to a collection of verifiable claims and connections that can be seamlessly used in hiring platforms, DAO contributor systems, and credential-gated professional communities.

A Web3 social graph is a decentralized data structure that maps relationships and interactions between users. Unlike centralized platforms like LinkedIn, where the platform owns and controls this graph, a Web3 social graph is typically built on public infrastructure like blockchains or decentralized storage. This shift enables user sovereignty—individuals own their social connections and can port them across different applications. Core to this design is the use of decentralized identifiers (DIDs), which provide a persistent, verifiable identity not reliant on a central issuer.

The technical stack for a professional network involves several key layers. The identity layer is built on DIDs and Verifiable Credentials (VCs), which allow for attestations like "worked at Company X" to be cryptographically signed and verified. The data layer often uses IPFS or Arweave for storing profile data and credentials in a censorship-resistant way, with content identifiers (CIDs) anchored on-chain. The smart contract layer, typically on Ethereum, Polygon, or other EVM chains, manages the graph's logic—recording connections (follows, endorsements) as on-chain events or storing pointer hashes to off-chain data.

For the graph structure itself, you must choose between on-chain and hybrid models. A fully on-chain graph, using smart contracts to store each connection, offers maximum transparency and composability but can be expensive. A hybrid approach, where only the root hash of a graph dataset is stored on-chain (e.g., using Merkle trees), is more common for cost efficiency. Libraries like Graph Protocol for indexing or Ceramic Network for mutable stream-based data are essential tools for querying and managing this decentralized data efficiently.

When designing relationship types, think in terms of smart contract events. An Endorsement event could log the endorser, recipient, skill, and a link to the Verifiable Credential. A Connection event could establish a bidirectional link. These on-chain footprints create a transparent and programmable history of professional interactions. It's crucial to design your data schema with composability in mind, allowing other dApps to easily read and build upon your graph's connections.

Finally, consider the user experience and key infrastructure. Users need a crypto wallet (like MetaMask) to interact with the network as their identity anchor. You'll need to integrate a sign-in with Ethereum (SIWE) flow for authentication. For developers, interacting with the graph will involve using ethers.js or viem to read contract events and IPFS gateways or Ceramic clients to fetch associated profile data. This stack forms the prerequisite foundation for building a professional network that is user-owned, interoperable, and verifiable.

A Web3 professional graph moves beyond simple follower counts. Its core entities are self-sovereign identities (like Ethereum addresses or decentralized identifiers/DIDs) linked by verifiable connections. Unlike Web2 platforms, the user owns this graph. The primary data model must define the structure for these connections and the attestations—such as skill endorsements or employment verification—that give them professional meaning. This model is typically implemented as a set of smart contract structs and mappings.

Consider a minimal on-chain schema. A Profile struct could store a user's display name and a URI pointing to off-chain metadata (like a resume stored on IPFS). A Connection struct would link two addresses with a status (e.g., PENDING, CONFIRMED). Most importantly, an Attestation struct is needed. This would include fields for the attester (issuer), recipient, a schema identifier (e.g., "SkillEndorsement"), and the attestation data (often a hash of the claim). The Ethereum Attestation Service (EAS) schema registry is a practical reference for this pattern.

The relationships between these entities are critical. A single identity can have multiple profiles (for different contexts), many bidirectional connections, and a stream of incoming/outgoing attestations. Your contract design must efficiently query these relationships. Use nested mappings like mapping(address => mapping(address => Connection)) public connections to check connection status between two users. For scalable attestation retrieval, consider emitting indexed events or using a The Graph subgraph instead of expensive on-chain enumeration.

A key decision is the granularity of on-chain data. Storing only essential linkage and proof on-chain (using hashes) while keeping detailed data off-chain (on IPFS or Ceramic) is the standard pattern for cost and flexibility. For example, the attestation data field would be a hash of a JSON object containing the skill name and level. The corresponding JSON file is stored decentralized, and its integrity is verified by the on-chain hash. This hybrid approach balances transparency with rich data storage.

Finally, design for composability from the start. Use open standards like ERC-725 for identity or EIP-712 for typed attestation signatures. This allows other protocols—like a decentralized hiring dApp or a credential verifier—to seamlessly interpret and build upon the graph data. Your core model isn't just for your application; it's a public utility for the ecosystem.

A verifiable attestation is a cryptographically signed statement issued by one identity about another, stored on a public blockchain or decentralized storage. In a professional network, these act as immutable, portable credentials for skills, job history, project contributions, and peer endorsements. Unlike traditional LinkedIn profiles, attestations are self-sovereign—users control their data and can present proofs without relying on a central platform for verification. This shifts trust from a single corporation to the underlying cryptographic proofs and the reputation of the issuers.

To design the attestation system, you must define the core schema—the data structure of each credential. Common schemas for professional networks include SkillAttestation, EmploymentAttestation, and EndorsementAttestation. Each schema specifies required fields (e.g., skillName, proficiencyLevel, issuer, recipient, expirationDate) and optional metadata. Using a standard like Verifiable Credentials Data Model or EIP-712 for typed structured signing ensures interoperability across applications. Smart contracts or off-chain signers then mint these schemas into attestations.

The technical implementation involves two main components: an issuer and a verifier. The issuer (e.g., a former employer or a project lead) signs the attestation data with their private key, creating a digital signature. This signed payload, along with the original data, is either recorded on-chain (e.g., using the EAS - Ethereum Attestation Service) or stored off-chain in a system like Ceramic Network or IPFS with a pointer on-chain. The verifier (e.g., a hiring platform) can then cryptographically verify the signature against the issuer's public address to confirm the attestation's authenticity without contacting the issuer directly.

For developers, implementing a basic skill attestation on Ethereum using EIP-712 involves structuring the data, signing it, and potentially registering it in a registry contract. Here's a simplified Solidity and JavaScript example:

solidityCopy
// Example attestation struct
struct SkillAttestation {
    string skillName;
    uint8 proficiency; // 1-5 scale
    address recipient;
    uint256 validUntil;
}

javascriptCopy
// Signing the attestation with ethers.js
const domain = { name: "ProfGraph", version: "1", chainId: 1 };
const types = { SkillAttestation: [
    { name: "skillName", type: "string" },
    { name: "proficiency", type: "uint8" },
    { name: "recipient", type: "address" },
    { name: "validUntil", type: "uint256" }
]};
const attestation = { skillName: "Solidity", proficiency: 5, recipient: "0x...", validUntil: 1893456000 };
const signature = await signer._signTypedData(domain, types, attestation);
// Store `attestation` and `signature` on-chain or in decentralized storage

Key design considerations include revocation mechanisms, privacy, and graph traversal. Attestations may need to be revoked if information changes; this can be managed via a revocation registry or expiry timestamps. For privacy, consider zero-knowledge proofs (ZKPs) to allow users to prove they hold a credential without revealing its contents. Finally, to build the social graph, your application needs to index these attestations—querying events from the blockchain or a decentralized graph database like The Graph—to map connections between identities based on issued and received credentials, enabling features like reputation scoring and talent discovery.

For on-chain storage, smart contracts on networks like Ethereum or Polygon are the canonical source of truth for relationships and core attributes. A common pattern uses a registry contract to map user addresses to a unique, incrementing profileId (an ERC-721 token). Relationship edges—such as follows, endorses, or collaborates_with—are then stored as mappings from one profileId to another, often with additional metadata like a timestamp or skill tag stored in a struct. This approach ensures verifiability and censorship resistance, as all connections are publicly recorded on the ledger.

However, storing and indexing complex graph data directly on-chain for querying is inefficient and costly. This is where The Graph protocol becomes essential. You create a subgraph that indexes events emitted by your smart contracts (e.g., ConnectionCreated, EndorsementAdded). The subgraph's mapping functions process these events and populate a queryable GraphQL API with normalized entities like User, Connection, and Endorsement. For example, you can instantly query "all users who endorsed Alice for 'Solidity' skill" without scanning the entire blockchain.

For richer, off-chain profile data (bio, profile picture, detailed work history), decentralized storage solutions like IPFS or Arweave are used. The on-chain profile record typically stores a content identifier (CID) pointer to this metadata. Your subgraph can fetch and incorporate this off-chain data into its entities, providing a complete view. A hybrid architecture is standard: immutable relationships on-chain, indexed via The Graph, with supplementary data on decentralized storage.

When designing queries, consider the core use cases of a professional network. You'll need efficient lookups for: a user's 1st-degree connections, the shortest path between two users (for measuring network proximity), and aggregated reputation scores based on endorsement weight and connection density. The Graph's GraphQL interface allows for nested queries, such as fetching a user along with their connections' profiles in a single request, which is far more efficient for building client applications than multiple RPC calls.

To optimize performance and cost, implement pagination in your queries to handle large connection lists, and consider derived fields in your subgraph. For instance, you can calculate a user's total endorsement count per skill or their PageRank-like influence score within the mapping functions, storing these computed values in the indexed entities. This moves computation from the client to the indexer, speeding up query response times. Always test your subgraph queries with tools like the GraphQL Playground provided by the hosted service.

The core of discoverability is a queryable social graph. Unlike a simple follower list, this graph should model multi-dimensional relationships. A user node can have edges representing colleagues, collaborators, endorsers, or project contributors, each with on-chain or signed attestations as proof. Using a graph database like The Graph for indexing or a Ceramic stream for composable data allows you to build complex queries, such as "find all developers who contributed to at least two of the same DAOs as me" or "show me the strongest connection paths to a specific hiring manager."

Reputation must be portable and verifiable, not a platform-specific score. Implement a system of verifiable credentials (VCs) or attestations using frameworks like Ethereum Attestation Service (EAS) or Verax. These allow third parties—like former employers, project DAOs, or credential issuers—to issue tamper-proof claims about a user's skills, employment history, or project completion. These attestations become edges in the social graph with a verifiable issuer, timestamp, and optional revocation status, creating a cryptographically-backed professional profile.

To make this data actionable, you need reputation aggregation logic. This is an off-chain or on-chain algorithm that interprets the graph data. For example, a smart contract could calculate a composite skill score for "Solidity" by weighting self-claims low, peer endorsements medium, and verified project deployments high. Another algorithm might measure trust decay, where an attestation from five years ago carries less weight than one from last month. Lens Protocol's use of open and customizable OpenGraph metadata for profiles is a practical reference for composable reputation data.

Finally, design the discovery features that leverage this infrastructure. This includes search filters that use graph traits (e.g., "skills verified by 3+ colleagues"), recommendation engines that suggest connections based on shared verifiable project history, and visual trust indicators on profiles showing the source and volume of attestations. The goal is to move beyond keyword-based profiles to a system where a user's professional standing is a function of their verifiable, networked proof-of-work.

Interoperability is the cornerstone of a functional Web3 professional network. Unlike siloed Web2 platforms, your graph should allow users to port their social data—connections, endorsements, and credentials—across different applications. This requires adopting established decentralized identity (DID) and verifiable credential (VC) standards from the W3C, such as did:ethr or did:key. By using these standards, you ensure that a user's professional identity and graph are not locked into your single application, fostering a more open ecosystem.

For on-chain integration, leverage graph query standards like The Graph Protocol's subgraphs or Ceramic's ComposeDB. These allow other dApps to read and, with proper permissions, write to your social graph in a standardized way. For example, a DeFi protocol could query your subgraph to check a user's trustScore—derived from their professional endorsements—as part of a underwriting process. Design your smart contracts and data models with these external queries in mind, exposing clear public interfaces.

Bridging to Web2 is equally critical for adoption. Implement OAuth-compatible sign-in flows that mint a decentralized identifier (DID) for the user upon their first Web3 login, pulling relevant profile data from LinkedIn or Twitter. Use oracles like Chainlink to bring verifiable off-chain data (e.g., GitHub commit history, professional certifications) on-chain as verifiable credentials. This hybrid approach lowers the barrier to entry while building a richer, verified graph.

Finally, plan for cross-chain social graphs. As professional activity spans Ethereum, Solana, and Layer 2s, your architecture should not be chain-specific. Utilize interoperability protocols like LayerZero or Axelar for cross-chain messaging. This allows a connection made on Polygon to be recognized and utilized by an app on Arbitrum. The goal is a unified social layer that operates across the multi-chain landscape, making the professional network truly chain-agnostic.