Launching a Social Graph with On-Chain Attestations

A social graph is a map of the relationships between entities, such as users, organizations, or smart contracts. In Web3, traditional centralized social graphs controlled by platforms like Facebook or X are replaced with decentralized, user-owned alternatives. On-chain attestations provide the foundational data layer for this shift. An attestation is a cryptographically signed piece of data that makes a claim about a subject, such as "Alice is a member of DAO XYZ" or "Bob completed a coding course." These claims are stored on-chain or on decentralized networks like Ethereum Attestation Service (EAS) or Ethereum's Verifiable Credentials (VCs), making them portable, composable, and resistant to censorship.

The core components for building this graph are the Schema, Attester, and Recipient. A Schema defines the structure of the attestation data (e.g., fields for recipient, issuer, credentialType). The Attester (or Issuer) is the entity that creates and signs the attestation, which could be a DAO, an institution, or even another smart contract. The Recipient is the subject of the claim, typically a user's Ethereum address. By linking these signed attestations together, you can construct a graph where nodes are addresses and edges are verifiable relationships or attributes. This enables use cases like reputation systems, Sybil resistance, and credential-based access control without relying on a central authority.

To implement this, you typically interact with an attestation registry like Ethereum Attestation Service (EAS). First, you register a schema that defines your data format. Then, you or your application's backend will make an on-chain transaction to create an attestation, linking the recipient to the attested data. For example, a DAO might attest to a member's contribution score after a governance round. Developers can then query these attestations to build applications—a DeFi protocol could grant a loan based on a verified credit score attestation, or a governance system could weight votes based on proven expertise.

Key technical considerations include data storage costs and privacy. Storing all data fully on-chain (on Ethereum mainnet) is expensive. Solutions include storing only a cryptographic hash on-chain with the full data on IPFS or using optimistic rollups or L2s like Arbitrum or Optimism for cheaper attestations. For privacy, you can use zero-knowledge proofs (ZKPs) via systems like Semaphore or Sismo to allow users to prove they hold a valid attestation (e.g., "is over 18") without revealing the underlying data or their identity, a concept known as selective disclosure.

The social graph built from attestations becomes a public good infrastructure for Web3. It allows any application to read and verify user relationships and credentials, breaking down data silos. Unlike Web2 social graphs, users own their connections and can take their verifiable reputation across different dApps. This interoperability is powered by open standards and shared registry contracts, enabling a new paradigm of trust-minimized, composable social identity that forms the backbone of decentralized communities, professional networks, and credential markets.

You'll need a working knowledge of Ethereum development and smart contracts. Familiarity with Solidity, the Ethereum Virtual Machine (EVM), and a development framework like Hardhat or Foundry is essential. Ensure you have Node.js (v18 or later) and npm/yarn installed. For wallet interaction and signing, you should understand Ethereum JSON-RPC and have experience with libraries like ethers.js (v6) or viem.

The core of this system is an attestation schema registry. You can use an existing standard like EAS (Ethereum Attestation Service) or build a custom registry. EAS provides a robust, gas-efficient base for creating, updating, and revoking attestations on-chain. You'll need to decide whether to deploy your own instance or use a public one like eas.eth on Ethereum Mainnet or its deployments on Optimism, Arbitrum, or Base.

To store the graph data, you need a method for indexing and querying attestations. While you can query the blockchain directly, for performance you'll likely use a graph indexer. The Graph Protocol allows you to create a subgraph that indexes attestation events and makes them queryable via GraphQL. Alternatively, you can use a custom indexer or an RPC provider with enhanced APIs like Alchemy's Enhanced APIs or QuickNode's GraphQL endpoints.

User interactions will require a frontend library for wallet connection and transaction signing. Wagmi (built on viem) or RainbowKit are popular choices that simplify connecting to wallets like MetaMask, Coinbase Wallet, or WalletConnect. Your dApp will use these to request signatures for creating attestations, which are verifiable statements linking one Ethereum address to another with metadata (e.g., "follows", "endorses").

Finally, consider the data structure of your attestations. Each attestation in EAS, for example, contains a recipient (the subject), an attester (the issuer), a schema (the data format), and data (the encoded content). You must design your schema—whether it's a simple boolean isFollowing or a complex struct with a score and comment—and encode it using a tool like the EAS Schema SDK. Plan for how you will handle schema evolution and attestation revocation in your application logic.

An on-chain attestation is a cryptographically signed statement stored on a blockchain or a verifiable data layer like Ethereum Attestation Service (EAS) or Verax. Unlike a standard transaction, an attestation is a structured piece of data that makes a claim about a subject, such as "Wallet 0x123... is a verified member of DAO XYZ" or "This account holds a Gitcoin Passport score of 25." The signature from an attester (a user, a smart contract, or an oracle) provides verifiable provenance, while the on-chain or decentralized storage ensures immutability and public verifiability. This primitive is the foundational data unit for constructing rich, user-owned social graphs.

A decentralized social graph is a network of relationships and reputational data built from these attestations, owned by users rather than a central platform. Traditional Web2 social graphs are locked inside corporate databases. In Web3, a social graph can be composed by querying attestations linked to a user's primary identifier, typically their wallet address. Connections like follows, memberships, skills endorsements, and event attendance become portable, verifiable assets. Protocols like Lens Protocol and Farcaster implement their own graph structures, but attestation standards like EAS schemas enable interoperable, composable graphs that any application can read and contribute to.

To launch a basic social graph, you first define the types of relationships or traits you want to represent using schema definitions. In EAS, a schema is registered to the blockchain with a unique UID and a structure defined in a string format like bytes32 userId, bytes32 communityId, bool isActive. Your application's smart contract or a permitted off-chain service then creates attestations that conform to this schema. For example, to attest that a user joined a community, you would call attest on the EAS contract with the schema UID and the encoded data (userWallet, communityId, true). This creates a permanent, verifiable link in the graph.

Here is a simplified example of creating a "follow" attestation using a hypothetical EAS schema in a smart contract:

solidityCopy
// Pseudocode for attestation creation
bytes32 followSchemaUID = 0x123...;

function attestFollow(address follower, address followee) public {
    bytes memory encodedData = abi.encode(follower, followee, block.timestamp);
    eas.attest({
        schema: followSchemaUID,
        data: {
            recipient: followee, // Subject of the attestation
            expirationTime: 0, // No expiration
            revocable: true,
            refUID: bytes32(0), // Not referencing another attestation
            data: encodedData,
            value: 0
        }
    });
}

This code mints a verifiable follow link. The graph is built by indexing and querying all attestations with this schema UID.

Applications read the social graph by querying attestation data from the blockchain or indexed services like The Graph or direct from EAS's GraphQL API. A profile page might fetch all attestations where a user's address is the recipient, displaying their memberships, skills, and followers from various sources. The key advantage is permissionless composability: a new app can instantly leverage the existing graph of attestations without needing API keys or platform approval. However, designers must consider data freshness, revocation logic, and spam resistance, often implemented through attester permissions and schema design that includes timestamps or stake-based mechanisms.

Effective social graph design involves strategic schema planning. Instead of one monolithic schema, use specific schemas for different relationship types: one for forum badges, another for DAO roles, and another for skill endorsements. This allows for efficient querying and clear data semantics. Furthermore, leveraging off-chain attestations via EAS's off-chain service can reduce gas costs for high-volume social data while maintaining cryptographic verifiability. The end goal is a user-centric identity layer where reputation and connections are as portable and secure as the assets in a user's wallet, enabling a new generation of decentralized social media, reputation-based governance, and trust-minimized credentialing.

Begin by creating a new project directory and initializing a Node.js environment. Install the core dependencies: eas-sdk for interacting with the attestation protocol, viem for Ethereum interactions, and dotenv for managing private keys. Use a package manager like npm or yarn. For example: npm init -y && npm install eas-sdk viem dotenv. This setup provides the essential tooling to create, sign, and manage on-chain attestations, which are the fundamental data units of your social graph.

Next, configure the EAS SDK with your target blockchain. The EAS protocol is deployed on multiple networks including Ethereum mainnet, Optimism, Arbitrum, and Base. Import and instantiate the EAS class from the SDK, providing the correct contract address for your chosen network. You must also configure a signer using viem's wallet client, connecting via a provider like Alchemy or Infura. Store your RPC URL and wallet private key securely in a .env file, never committing it to version control.

The core concept is the Schema. A schema defines the structure of your attestations—the fields and data types for each connection in your graph. Before creating attestations, you must register a unique schema on-chain using the EAS instance. For a social follow, a schema might include fields like address follower (address), address followed (address), and uint256 timestamp. Registering a schema returns a UID, which you will reference for all subsequent attestations of that type. This ensures data consistency across your application.

With the schema registered, you can construct and send attestations. An attestation is an on-chain record that attests to a piece of data. To create a "follow" attestation, you would encode the follower's address, the followed address, and a timestamp into the schema's format. Call eas.attest() with the schema UID and the encoded data, which your configured signer will submit as a transaction. This transaction, once confirmed, immutably stores the social connection on the blockchain, forming a verifiable edge in your graph.

Implementing a resolver contract is an advanced but powerful pattern for dynamic data. While simple attestations are static, a resolver is a smart contract that can be referenced in your schema. It executes logic at attestation time (e.g., checking if a user holds a specific NFT to grant a "verified" badge) or revocation time. This allows your social graph logic to be programmable and context-aware. The EAS documentation provides templates for writing custom resolvers in Solidity.

Finally, structure your project for scalability. Organize your code into modules: one for configuration and EAS initialization, another for schema management, and a third for core attestation operations. Use environment variables for network configuration. This modular approach makes it easier to test, extend, and deploy your social graph application to different environments, from testnets to production mainnet deployments.

An attestation schema is a blueprint that defines the structure of your on-chain data. It specifies the fields, their data types, and their purpose. For a social graph, common schema fields include recipient (the user being attested about), relationshipType (e.g., follows, endorses, is_teammate), confidenceScore, and expirationTime. Using a standardized schema like those from the Ethereum Attestation Service (EAS) ensures your data is interoperable and can be easily queried and understood by other applications. Think of it as creating a database table schema before you insert any rows.

You create a schema by registering it on-chain. This is a one-time transaction that permanently records your schema's unique identifier (schemaUID) on the blockchain. For example, using EAS on the Optimism network, you would call the register function on the EAS contract with your schema string. A schema string looks like bytes32 recipient, bytes32 relationshipType, uint8 confidenceScore, uint64 expirationTime. Each field type (like uint8 or bytes32) must be a valid Solidity type. Once registered, this schemaUID becomes the reference point for all attestations made using that structure.

Designing your schema requires careful consideration of your application's needs and future scalability. Key decisions include: whether data is immutable (stored directly on-chain) or encrypted/off-chain (with only a reference hash stored on-chain), if attestations should expire, and how to structure fields for efficient indexing. For a follower graph, a simple address follower, address followed schema might suffice. For a professional reputation system, you may need nested structures or multiple related schemas. Always optimize for the queries your dApp will need to perform.

Here is a practical example of registering a schema using the EAS SDK in a Node.js script. This code defines a 'Follow' schema and registers it on the Sepolia testnet.

javascriptCopy
import { EAS, SchemaRegistry } from "@ethereum-attestation-service/eas-sdk";
import { ethers } from "ethers";

const provider = new ethers.providers.JsonRpcProvider(YOUR_RPC_URL);
const signer = new ethers.Wallet(YOUR_PRIVATE_KEY, provider);

// Initialize SchemaRegistry contract
const schemaRegistryContractAddress = "0x0a7E2Ff54e76B8E6659aedc9103FB21c038050D0"; // Sepolia
const schemaRegistry = new SchemaRegistry(schemaRegistryContractAddress);
schemaRegistry.connect(signer);

// Define your schema
const schema = "address follower, address followed, bool isActive";
const resolverAddress = "0x0000000000000000000000000000000000000000"; // No custom resolver
const revocable = true; // Allow attestations to be revoked

// Register the schema
const transaction = await schemaRegistry.register({
  schema,
  resolverAddress,
  revocable,
});

await transaction.wait();
console.log("Schema registered!");

After running this, you will receive a transaction hash and, upon confirmation, a unique schemaUID for your 'Follow' schema.

With your schema registered and its schemaUID in hand, you have established the foundational data model for your social graph. This schema acts as a contract between your application and the blockchain, ensuring all subsequent attestations are consistent and verifiable. The next step is to use this schema to issue actual attestations—populating your graph with data by having users or your dApp create on-chain proofs of their social connections.

An attestation is a signed piece of data recorded on-chain that makes a verifiable claim. In the context of a professional social graph, the two most common types are skill attestations (self-attested claims like "I know Solidity") and endorsement attestations (third-party validations like "I confirm Alice knows Solidity"). These are created as EAS schemas, which define the structure of the data, such as skillName (string), proficiencyLevel (uint8), and experienceYears (uint8). Each attestation is cryptographically signed by the attester's wallet, creating a permanent, tamper-proof record on an L2 like Optimism or Base to minimize gas costs.

To create an attestation, you first need to define or reference a schema. For a skill, you might use a simple schema with a skill string field. For a more detailed endorsement, you might include skill, rating, and comment. You can find existing schemas on the EAS Schema Explorer or create your own. The core action is calling the attest function on the EAS contract, passing the schema's unique identifier (schemaUID), the attestation data, and signing it with your private key. This transaction mints a new attestation with a unique attestationUID.

Here is a basic example using the EAS SDK to make a self-attestation for a skill:

javascriptCopy
import { EAS, Offchain, SchemaEncoder } from "@ethereum-attestation-service/eas-sdk";
const eas = new EAS(EASContractAddress);
eas.connect(signer);

// Encode the data for the schema "string skill"
const schemaEncoder = new SchemaEncoder("string skill");
const encodedData = schemaEncoder.encodeData([
  { name: "skill", value: "Solidity", type: "string" },
]);

const tx = await eas.attest({
  schema: schemaUID,
  data: {
    recipient: "0x0", // Use zero address for self-attestations
    expirationTime: 0n, // No expiration
    revocable: true,
    data: encodedData,
  },
});
const newAttestationUID = await tx.wait();

This code creates an on-chain record attesting to the skill "Solidity".

For endorsements, the process is similar but the recipient field is set to the Ethereum address of the person being endorsed. This creates a verifiable link from the endorser to the recipient within the graph. A robust social graph application will index these attestations—using a subgraph on The Graph or directly querying EAS's GraphQL API—to build profiles, calculate reputation scores, and visualize connections. The revocable flag is crucial; it allows an attester to invalidate a claim later if needed, which is essential for maintaining data integrity and trust.

When designing your attestation strategy, consider data freshness and sybil resistance. A simple self-claimed skill has lower trust weight than one with multiple endorsements from reputable identities. You can implement systems where endorsements themselves can be attested to (e.g., endorsing the quality of an endorsement) to create a web of trust. Furthermore, linking attestations to verifiable credentials or proof-of-personhood protocols like World ID can significantly increase the graph's resistance to spam and fake profiles, making the social data far more valuable.

Querying the social graph requires interacting with the smart contract or indexer where your attestations are stored. For Ethereum Attestation Service (EAS) schemas, you can use the official EAS GraphQL API or a subgraph. A typical query fetches attestations for a specific schema ID and filters by the attester or recipient address. For example, to get all 'Follow' attestations a user has made, you would query for attestations where attester equals the user's wallet address and schemaId matches your 'Follow' schema. This returns a list of connection data, including the recipient's address and any optional metadata stored in the attestation.

For efficient and complex queries, especially when displaying a network, consider using a dedicated indexer. Tools like The Graph allow you to create a subgraph that ingests attestation events and structures the data into entities like User and Connection. This enables powerful queries, such as "get all mutual follows" or "find the shortest path between two users." Processing this data on a backend server or using a service like Goldsky for hosted subgraphs can significantly improve your application's performance and user experience compared to direct contract calls.

Displaying the graph effectively is crucial. Frontend libraries like React Flow or Vis.js are excellent for rendering interactive network diagrams. Nodes typically represent user addresses (often truncated or linked to an ENS name), and edges represent the attestations between them. You can style edges based on attestation data—for instance, coloring a 'Trust' connection differently from a 'Collaborated With' connection. Implementing search, filters for connection types, and zoom/pan controls makes the graph explorable. Always link nodes to on-chain explorers like Etherscan for transparency.

To make addresses user-friendly, integrate ENS resolution. Displaying alice.eth is more meaningful than 0x1234.... Services like the ENS Public Resolver or libraries such as ethers-ens can resolve addresses to names and vice versa. Furthermore, you can enrich profiles by fetching avatar images from NFT profile picture (PFP) contracts or other on-chain metadata. Remember to handle the asynchronous nature of these lookups and provide appropriate loading states in your UI to ensure a smooth experience.

Finally, consider the privacy and performance implications of your implementation. While attestation data is public on-chain, your UI controls what is displayed. Implement pagination or virtual scrolling for large graphs to prevent browser slowdowns. Cache resolved ENS names and other metadata locally to reduce redundant RPC calls. For a complete reference, review the EAS Explorer source code or the Graph Protocol documentation for advanced query patterns specific to attestation data.

The architecture you've built demonstrates a powerful pattern for creating verifiable, portable social data. The Ethereum Attestation Service (EAS) provides the trust layer, allowing you to create attestations—like follows, likes, or skills—that are cryptographically signed and stored on-chain or off-chain. The Graph indexes this data into a queryable subgraph, making it efficiently accessible for your application's frontend. This decouples the trust layer from the data availability and query layers, a common best practice in Web3 development.

To extend this project, consider implementing more complex relationship types. For instance, you could create attestation schemas for community membership, skill endorsements, or content curation. Each new schema would require updating your subgraph's schema.graphql to define the new entity and its relationships, then regenerating and deploying the subgraph. Explore using EAS's off-chain attestations via the eas-offchain SDK for high-volume, low-cost interactions, reserving on-chain attestations for high-value actions.

Next, integrate this graph data into a frontend application. Use GraphQL clients like Apollo or URQL to query your subgraph from a React or Next.js app. Display user profiles, connection graphs, or feed algorithms based on attested relationships. For wallet connection and attestation creation, leverage wagmi and viem alongside the EAS SDK. Remember to handle network switching, as your subgraph and contracts are deployed to specific chains like Sepolia or Optimism.

Further development should focus on data composability and privacy. Investigate how your attestations can be used by other applications through schema alignment. For privacy-sensitive data, explore zero-knowledge proofs (ZKPs) with EAS, using tools like Sismo or Semaphore to create attestations that verify a claim without revealing the underlying data. This allows for reputation systems where users can prove membership or achievements privately.

Finally, consider the long-term sustainability of your graph. Plan for subgraph upgrades and schema evolution as your application grows. Monitor query performance on The Graph's hosted service or explore decentralized indexing options. Engage with the communities around EAS and The Graph on their respective Discord servers and forums to stay updated on new features and best practices for building robust, decentralized social infrastructure.