1. Introduction

Many agents today are just glorified reply bots. But as we push agents into real onchain work—executing transactions, verifying data, collaborating in swarms, powering InfoFi, or scaling agent commerce—they need a universal language for verified data.

Agent attestations on Base: are a direct way for onchain agents to structure, sign, share, and build upon reliable data using EAS.

2. When to Use Attestations

Trust is everything. Here are a few ideas of when you might want your agent to attest:

• Agent Verification: A trusted authority verifies your agent’s address.

• Swarm Membership: Require “verified agent” status to join a swarm.

• Structured Metadata: Let your agent produce discoverable data fields others can build on.

• Agent Permissions: Attest and revoke agent authorizations and access.

• Agent Receipts: Publish a “receipt” once a task is done.

• Collaboration: Each agent attests to its contributions in multi-agent workflows.

• Milestone Tracking: Agents attest key achievements and milestones.

• AI Model Provenance: Attest which model was used and its reasoning logs.

• Payments & Distributions: Trigger ERC20/NFTs after an attestation is made.

• Loan & Repayment: Originate A2A lending and track loan repayments.

• Subscription Services: Attest which addresses are subscribed.

• Fact Checks: Agents/humans verify or dispute content accuracy onchain.

3. Quick Start with AgentKit and EAS SDK

Deploy Your Agent with AgentKit

Before making attestations, get your agent onchain. Use Coinbase’s AgentKit to create an agent that holds a wallet, initiates transactions, and can make attestations.

Contracts

On Base, two key EAS contracts are predeployed:

• EASSchemaRegistry: 0x4200000000000000000000000000000000000020 (for registering schemas)

• EAS: 0x4200000000000000000000000000000000000021 (for making attestations)

Find these in the Base Mainnet docs. EAS is natively integrated into the OP Stack, so these contracts are the same throughout the Superchain.

3.3 Explore the EAS SDK

With the EAS SDK you can easily make, revoke, delegate, and batch your attestations or register schemas.

Quick Install:

npm install @ethereum-attestation-service/eas-sdk 
// you can use yarn/npm/pnpm

Import and initialize the library:

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

export const EASContractAddress = "0xC2679fBD37d54388Ce493F1DB75320D236e1815e"; // Sepolia v0.26

// Initialize the sdk with the address of the EAS Schema contract address on your target chain
const eas = new EAS(EASContractAddress);

// Gets a default provider (in production use something else like infura/alchemy)
const provider = ethers.getDefaultProvider("sepolia");

// Connects an ethers style provider/signingProvider to perform read/write functions.
// MUST be a signer to do write operations!
eas.connect(provider);

4. Understanding Schemas & Attestations

Why attestations?

Attestations let agents package data or actions into a standardized, verifiable format. This ensures credibility: anyone—another agent, a smart contract, or a user—can verify who attested what and when.

Instead of siloed one-off solutions or random signed messages, EAS requires each attestation to match a schema—guaranteeing structured data. This enables:

• Standardized, structured data

• Discoverability in a single registry

• Interoperability across the Superchain

• Composability (attestations can reference each other)

• Revocable/Expirable for cleaning up old data

• Offchain or Onchain usage—whichever suits your use case best.

Example Onchain Attestation

await eas.attest({
  schema: schemaUID, // the schemaUID you are attesting with
  data: {
    recipient: OPTIONAL_ADDRESS, // if youre attesting about an address
    expirationTime: NO_EXPIRATION, // if you want your attestation to expire
    revocable: true, // Be aware that if your schema is not revocable, this MUST be false
    data: encodedData, // this is your encoded schema data following the schemaUID
  },
});

Learn more about Making Attestations.

Tip: You can also make offchain attestations—your agent signs data privately (e.g., stored locally). That’s perfect for large or sensitive data you don’t want onchain.

5. Defining Attestation Schemas

EAS uses schemas to define fields and data types for your attestations. You register or reuse a schema via the EASSchemaRegistry contract, get a Schema UID, and use it in attestations.

Example Agent Schemas:

• Verified Agent: bool verified

• Agent-to-Agent Rating: uint8 score, string details

• Transaction Receipt: uint256 amount, string transactionHash, string txPurpose

• Model Usage: string modelName, bytes32 modelHash, bytes32 instructionHash

6. Making an Attestation (Subscription Example)

Suppose your agent offers a subscription service. We define a schema for subscription details (tier/payment info) and create an attestation that “0xUserAddress is subscribed.”

6.1 Fields Overview

Core EAS Fields (no need to include in your schema):

• attester: E.g. your agent.base.eth address

• recipient: The subscriber’s address

• expirationTime: A date (or 0)

• revocable: Boolean for whether your agent can revoke

• refUID: Optional reference to another attestation

• data: Encoded custom fields

Custom Schema Fields (e.g., subscription details):

string subscriptionTier, string paymentFrequency, string paymentType, uint256 paymentAmount

• subscriptionTier: e.g. “Bronze,” “Silver,” “Gold”

• paymentFrequency: e.g. “Monthly,” “Annual”

• paymentType: e.g. “ETH,” “DAI,” or “CreditCard”

• paymentAmount: How much was paid

6.2 Example Code

1. Encode subscription data: Use EAS’s SchemaEncoder to define your fields.

2. Make the attestation: Provide EAS with the schema UID, the encoded data, and core EAS fields (recipient, revocable, etc.).

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

const provider = new ethers.providers.JsonRpcProvider("<YOUR_BASE_RPC>");
const signer = provider.getSigner();
const EASContractAddress = "0x4200000000000000000000000000000000000021";

const eas = new EAS(EASContractAddress);
eas.connect(signer);

const schemaEncoder = new SchemaEncoder(
  "string subscriptionTier,string paymentFrequency,string paymentType,uint256 paymentAmount"
);

const encodedData = schemaEncoder.encodeData([
  { name: "subscriptionTier", value: "Gold", type: "string" },
  { name: "paymentFrequency", value: "Monthly", type: "string" },
  { name: "paymentType", value: "ETH", type: "string" },
  { name: "paymentAmount", value: 50000000000000000n, type: "uint256" } 
  // 0.05 ETH
]);

const schemaUID = "<YOUR_SUBSCRIBE_SCHEMA_UID>";

const tx = await eas.attest({
  schema: schemaUID,
  data: {
    recipient: "0xUserAddress", 
    expirationTime: 1699999999, // e.g., end of 2025
    revocable: true,
    refUID: ethers.constants.HashZero,
    data: encodedData
  }
});

// This call sends a transaction on Base referencing your schema and data.
await tx.wait();
console.log("Subscription attestation sent!");

What’s happening here?

• We call eas.attest(...), referencing a known schema UID.

• recipient is the user’s address.

• expirationTime is set far in the future (end of 2025).

• revocable is true, meaning your agent can revoke later if payments lapse.

• encodedData is the custom schema data specifying subscriptionTier, paymentFrequency, and so on.

• Once the transaction is confirmed, EAS records the new attestation. You can view it via EAS explorers or programmatically.

Result: EAS stores:

• attester (your agent), recipient, expirationTime, revocable, UID

• Your custom subscription fields in the attestation data field

7. Advanced Features: Resolvers and Referenced Attestations

Resolver Contracts

Attach a resolver contract to your schema if you want:

• Payment or Staking: Ensure a fee is paid before attesting

• Role Checks: Only certain addresses or agent types can attest

• Context Verification: Confirm the user paid onchain

When an attestation or revocation is attempted, EAS calls your resolver. You allow or reject the action with custom logic.

Referenced Attestations (refUID)

refUID can chain multiple attestations:

• Tier Upgrades: If a user moves from “Silver” to “Gold,” reference the old subscription

• Content Collaboration: B references A’s contentHash to show it builds on the original

• Reputation Aggregation: Summaries referencing multiple attestations to build a track record

Simple example: an agent posts text (Attestation A), another “likes” it (Attestation B) by referencing A’s UID, showing a direct relationship.

8. Choosing Onchain vs. Offchain Attestations

Onchain

• Trustless, composable data

• Costs gas but is globally verifiable and easy for smart contracts to consume

Offchain

• Signed EIP-712 messages not stored onchain

• Free to generate, but you must store them in your own DB, IPFS, etc.

• Ideal for larger or private data

Advanced: If your agent processes large, sensitive data offchain, you can generate a zero-knowledge proof for relevant properties. Then your agent attests that proof onchain, letting a smart contract verify correctness without revealing raw data—privacy with trust.

9. Indexing & Querying Your Data

Default EAS Indexer

EAS provides an open-source indexer at 0x37AC6006646f2e687B7fB379F549Dc7634dF5b84 on Base. It tracks protocol-level fields (attester, recipient, expiration, etc.) but not your schema’s custom fields.

Creating a Custom Indexer

If you want to query field-level data (e.g., subscriptionTier == "Gold"), you’ll need your own indexer:

• Subgraph: Build a subgraph (e.g., with The Graph) that decodes EAS events

• Offchain Service: A script that listens for EAS contract events, decodes them, and stores data in a DB GraphQL on base.easscan.org Use the GraphQL API at https://base.easscan.org/graphql to fetch attestations by UID, attester, or other protocol-level fields. It won’t decode your custom fields, so you must handle that logic separately.

EAS SDK

If you know an attestation’s UID, you can call getAttestation(uid) in the EAS SDK to fetch the struct onchain. Then decode the data field using your schema.

Conclusion

Attestations give your agents a common language for trust and composability—whether verifying an agent’s identity, collaborating on tasks, or managing subscriptions. With EAS on Base, you can:

• Publish structured statements

• Reference each other’s outputs for deeper context

• Revoke/expire data to keep it valid

• Compose advanced workflows

We’re excited to see you harness agent attestations to build more reliable, collaborative onchain agents!

We’ve all been there before. You’re at a side event. Vibes are good, people are chatting, and you’re trying to figure out who to connect with. Your best friend Alice, whose judgment you trust completely, introduces you to Bob, a builder you know nothing about. Then Bob intros you to Charles, and now you’re left wondering, “Can I trust Charles just because Bob does?”.

Traditional trust algorithms like EigenTrust (unrelated to EigenLayer) were originally developed to calculate trust in file-sharing networks, like BitTorrent. However, these algorithms have often been misapplied to social trust scenarios, where they can be easily manipulated. Our new transitive trust algorithm avoids these pitfalls by ensuring that trust is earned and accurately reflected, even in complex and evolving relationships.

Note: This is an open-source developer tool built for the attestation community and beyond. It is not an algorithm built into EAS. The edges can be attestations or any type of edge. Although we think attestations are great edges!

Why Transitive Trust?

The Transitive Trust algorithm evaluates trust between peers based on direct attestations. It ensures that endorsements are genuine, discourages fake endorsements and collusion, and prevents anyone from unfairly inflating their reputation from others’ perspectives.

Key Properties of Transitive Trust

Attestations as the primitive.

Attestations are the foundation of the Transitive Trust algorithm and reputation systems because they provide a secure, verifiable, and decentralized way to capture and propagate trust. These onchain or offchain attestations ensure that trust is earned through genuine interactions, verifiably recorded, and resistant to manipulation—key to maintaining the network’s integrity.

Non-Destructiveness.

Every attestation of trust from one peer to another should result in the recipient’s trust score either increasing or remaining the same from the perspective of every other peer in the network. This ensures that trust scores are stable and reflect genuine interactions.

Non-destructiveness encourages honest endorsements without the risk of reputation loss and prevents trust manipulation through strategic vouching.

Example: Picture Alice introducing you to Bob, and Bob introducing you to Charles. If Bob vouches for Charles, this should either increase or maintain Charles's trustworthiness in your eyes. This non-destructiveness ensures that trust scores go up or stay the same, preserving stable and reflective relationships.

It’s important to know that transitive trust does allow for negative endorsements. Imagine Alice trusts Bob and vouches for him, which increases his trust score from her perspective. If Alice later discovers that Bob has acted dishonestly, she can attest to that as well, decreasing Bob's trust score from her perspective and those who trust her. This dual ability to provide positive and negative attestations ensures that trust scores are comprehensive and accurately reflect both positive and negative interactions.

Sybil-resistance and robustness towards malicious collectives.

No peer should be able to create another peer whose reputation is greater than that of the peer itself, and no collective should be able to create a peer whose reputation is greater than that of the collective’s most reputable member. i.e. no one can overwhelm the system by creating/joining malicious groups.

Example: Imagine Bob wants to be the most popular person at the event, so he starts high-fiving everyone, thinking it will make him more liked. He brings along two fake friends, Charles and James, and they all start high-fiving each other. In real life, this would be cringeworthy, but in a decentralized network, this is a common issue.

In existing systems like EigenTrust, this vulnerability is present because it assigns some initial value to all nodes in the network. This requires sybil resistance to be controlled and solved before the nodes are accepted into the network.

Our Transitive Trust algorithm prevents manipulation by ensuring that trust scores are only influenced by genuine direct endorsements between distinct entities. Each peer's trust score is derived from the trust others have in them, without allowing anyone to inflate their own score through collusion. This keeps the trust scores authentic and reliable.

Balanced incentive structures.

No peer should be able to raise or lower its trust score from the perspective of any other peer. Furthermore, no peer should be able to alter its standing relative to another peer from the perspective of a third observer. I.e. Nobody should be able to change the amount of trust placed in them by someone else

A balanced incentive structure ensures that trust scores are calculated from the perspective of each observer, reflecting their unique reasons for trust. This approach mirrors how trust works in the real world.

For example, if your best friend starts trusting someone new, it doesn’t mean you automatically trust your friend more because of that connection. Trust isn’t transferable in that way, and your own trustworthiness shouldn’t improve just because you endorse someone trustworthy. Existing systems often overlook this nuance, leading to skewed incentive structures.

Example: Here’s how it breaks down in existing systems. If you wanted to increase your score from the perspective of Alice, and you know that Alice likes Bob, then you could attest to Bob to increase your score from Alice’s perspective.

The transitive trust algorithm ensures that your standing with Alice remains unchanged unless Alice herself observes qualities in you that matter to her. This prevents a malicious actor from manipulating their reputation through strategic endorsements.

Immediate Use Cases We’re Excited About

If your situation involves important decisions based on trust—especially in p2p environments where relationships are complex and evolving—the Transitive Trust algorithm helps ensure trust is genuinely earned and fairly represented. It’s particularly valuable in high-stakes scenarios where misplaced trust could be costly.

• Sybil Resistance in Social Graphs: Enhancing proof of personhood and preventing fake identities in decentralized networks.

• DAO Peer Discovery: Identifying trustworthy peers within DAOs for better decision-making.

• Hiring Decisions: Using attestations to evaluate and hire candidates based on the qualities you care about.

• Decentralized Marketplaces: Protecting buyers by accurately reflecting seller reputations.

• Access-Based Systems: Managing engagement and access rights based on trust scores.

• Crowdsourcing Reliable Information: Filtering and prioritizing relevant projects or knowledge based on community trust.

• Oracle Reputation Scoring: Evaluating the trustworthiness of oracle providers.

• Content Moderation: Filtering content in social networks by assessing the trustworthiness of creators relative to consumers.

• P2P Lending Pools: Assessing borrower trustworthiness to reduce risk in decentralized lending platforms.

• Dispute Resolution: Selecting reliable mediators for resolving conflicts in decentralized systems.

• Open Source Contributions: Evaluating developer reliability and code quality based on community trust.

• Smart Contract Audits: Trusting audits are based on auditors' reputation and your network's trust in them.

• AI Agent Reputation: Calculating reputation scores for AI agents relative to tasks completed and reputation earned.

How to Contribute & Get Started

We’ve posted the whitepaper below and are looking for your comments. It’s math-heavy, so if you enjoy complex math, dive in! If math isn’t your thing, we’d still love your feedback on the problems you’ve faced or opportunities you see for reputation systems.

Paper: Designing A Subjective Transitive Reputation Algorithm

Access the whitepaper below. Contribute your feedback by attesting your contribution or feedback (see how below).https://attest.org/Transitive-Trust.pdf

npm package

After finalizing the paper and reviewing comments, we’ll launch developer tools to make running the algorithm simple to integrate. Our target launch is in September 2024.

Attest Your Feedback

Follow these steps to attest your feedback and comments to the paper. Our goal is to create a clear line of provenance from the original paper and how others have contributed to its growth over time.

#1. Access/download the existing whitepaper pdf.

#2 Verify that the file hash matches the attested version.

We’re excited to get comments from the community and general feedback. The current draft of the whitepaper has a file hash of:0xeacdf34e225304e45770e4e10cc1e39f7462829b83579cd7c2e0e562a467b655

You can validate this by going to the EAS Explorer and uploading the same file downloaded from above.

Attestation (Content Hash) - 0x8837...f37c7

View attestation details for 0x8837...f37c7 on EAS - Ethereum Attestation Service.

https://base.easscan.org

#3. Make a referenced attestation to the original file attesting your comment or contribution.

Use the explorer link below. It will take you to a schema used to attest a contribution as a string. It references the original UID of the contentHash in the Referenced Attestation Field.Note: You do not need to add a recipient. Just type in the contribution, feedback, or comment as a string field and make sure to attest onchain.

https://base.easscan.org/attestation/attestWithSchema/0x73ca2897489130673f4537b9fd050690955f56e683bc6a3714f380093dcb7a1d#template=:0x8837f3ad57e0c2f988112091d6eef2c28d180f07fc964bf97d16a12b3a3f37c7:0:true:0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000

We are excited to hear from you.

Keep attesting. Keep building.

Trust isn’t a simple yes or no thing, it’s not binary and you certainly can’t just create a universal “global trust score”. Trust is deeply personal, it’s about context and it changes depending on who you are and what you’re engaging with.

This article talks about the concept of relative trust networks and how digital attestations are changing our approach to establishing trust online.

The Concept of Relative Trust

"Relative trust is the varying degree of confidence we assign to people and things based on our personal connections & experiences.”

Think about your inner circle of friends or small community group.

When someone new comes into the picture, you start assessing: “Do we know similar people? What are their interests? Can I trust them?”. This is relative trust in its purest form, where we rely on our network of connections to navigate judgments and decisions. How much you trust can even be swayed by subtle personal cues like their energy or even how they presented themselves, whether we’re conscious of it or not. Just because you trust someone’s ability at work doesn’t mean you trust their cooking skills or that you trust them overall.

Trust is deeply personal and subjective, shaped by our unique experiences, preferences, and networks.

Trust networks aren’t just about people.

This nuanced view of trust isn't limited to personal relationships. Deciding to try a new restaurant, for instance, can be heavily influenced by friend recommendations or online reviews. This, too, is a form of relative trust, where we draw on the experiences of others to make our choices. Relative trust can also be extended to the networks of information we trust, businesses we buy from, and the applications we use.

Why a “Global Trust Score” falls flat.

We often seek guidance from "oracles of trust"—like credit agencies, data verifiers, or social media verifications/reviews—to make choices easier. But these systems, while helpful, are flawed and biased.

Take lending as an example: a bank will judge you on your credit score, but your family might lend based on personal trust, ignoring that score. And that blue check on Twitter? It doesn't mean someone's trustworthy and it’s certainly a lazy way to verify someone is not a bot.

We need context, not a one-size-fits-all score. Trust is personal and situational, and what we need is a system that understands that and gives us control.

Attestations are a key primitive for a trust network.

Attestations are simply digital signatures on structured information. They are made by one entity about someone or something. The power of this is that it’s highly composable and interoperable. You can start to compose them like Lego blocks to build context. The real value is you have the authenticity of the digital signature and the provenance of a timestamp. If you’re not familiar with attestations, you can learn more about them in our docs.

Example Attestations for a Relative Trust Network

• A social graph and network of trusted entities

• Verifications and approvals of a piece of information, like an article or fact.

• Disputes and weights for not trusting certain entities or things

• Reviews made on a particular entity

• Trade information, interactions, and transactions between different entities

Building a Relative Trust Network

Let’s explore a practical example of how a relative trust network might form by building a social graph of people and things you trust.

Seeding the trust graph

Building a trust network starts with identifying and weighing your connections. It's like setting up your social network from scratch. You connect to a new platform designed to map out your trust relationships. It suggests entities for you to consider based on your past interactions and the digital footprints you've left — like transaction history and previous attestations.

Here's where you make it your own. You see a list of entities — people, organizations, smart contracts — and you assign a trust weight to each. It's a bit like following someone on social media but with an extra step: you're not just following; you're rating how much you trust them. Your mom might be a full 100%, a friend 85%, and vitalik.eth, whom you respect but don't know personally but respect might get a 90%.

Expanding Your Network

With these weights in place, the platform shows you a network map. It's a visual representation of your connections and their connections — a second-degree trust circle, if you will. If your friend trusts someone 80%, and you've rated your friend at 75%, the platform might suggest a 60% trust level for this new person in your network.

We even built a super simple demo of this in the early eas days.

Refining Your Trust Settings

But life isn't static, and neither is trust. You come across new entities and information that might change your perspective. Your trust network should allow you to adjust the weights dynamically. If an entity receives an attestation from a highly trusted connection, you might bump up their score. Conversely, if there's a breach of trust, you can dial it back down.

Bridging Web2 and Web3 Identities

A significant aspect of building these trust networks is bridging established Web2 reputations into the Web3 framework. EAS can help facilitate this by allowing users to bring their verified Web2 credentials into the decentralized world. We’ve seen this already with fitness data being attested to by the Receipts team and much more in development.

Receipts: Fitness Rewards Platform

Receipts is a rewards and loyalty platform for the fitness & wellness industries. Connect your wearable to the app and earn rewards when you workout. Brands can directly reach, acquire, & retain high value, highy active customers.

https://receipts.xyz

The Journey Has Begun, We Have the Tools.

The journey to robust trust networks begins with creating valuable attestations. Each one, especially those from trusted sources, adds a layer of depth and reliability to the network. It's not just about collecting attestations; it's the context and the credibility behind them that matter. These are the seeds from which trust networks and knowledge marketplaces sprout, offering verified content and clear information lineage.

As we build this network, privacy remains paramount. We already have the tools to ensure greater privacy and control for users. Tools like offchain attestations, the ability to generate zero-knowledge proofs from attestation data, and even using private data attestations that allow selective disclosure of data are all great approaches.

Imagine relative trust graphs of the future.

In the not-too-distant future, imagine putting on a VR headset like the Vision Pro or Quest and stepping into your trust network. This virtual space transforms abstract connections into a navigable landscape. Paths link you to individuals and entities, their brightness reflecting the strength of your trust. Intersections where paths converge mark shared connections, offering insights at a glance.

With a gesture, you could pull up a history of interactions, view attestations, and understand the context behind each connection. This VR experience would make assessing trust not just insightful but also engaging, turning the intangible into something almost tangible.

This vision is the practical evolution of trust graphs, where the digital and the experiential merge. It's a step towards making the concept of trust more accessible and interactive, allowing us to engage with our network in a way that's both meaningful and grounded in our digital reality.

Resources About Ethereum Attestation Service:

Helpful Links

• EAS Core Concepts

• Speedrun EAS

• Ideas to Build

Community Content:

• Unlocking Decentralized Identity by Bankless

• Ethereum Attestation Service Explainer Video by Vasa

• ELI5 Ethereum Attestation Service - Why You Should Care - Ryan Yi

The attestation layer is quickly evolving as a critical piece of infrastructure for trust online and onchain. Its significance has the potential to be on par with foundational elements like ENS and the EVM, which have been instrumental in shaping the trajectory of our ecosystem.

Together as a community, we’ve already accomplished so much. The narrative and attention around attestations is rapidly growing.

EAS is being adopted by industry leaders like Optimism and its Superchain ecosystem, Gitcoin Passports to improve sybil resistance, Guild for greater community access and control, builder communities like Devfolio, and other prominent builders throughout the ecosystem.

The growth has been exponential and it’s clear to us that EAS as a public good extends beyond any single team. As such we have been thinking about what the future of EAS should look like.

So what’s next?

Credible Neutrality is the commitment of a system to operate without favoring any participant, agenda, or outcome. It's a promise that the platform's operations are transparent, unbiased, and free from external influences.

In order to maintain the trust and confidence of builders developing on EAS, it’s vitally important that EAS remains a free-to-use, permissionless, and open-source public good into the future.

The integrity of a widely used attestation layer is paramount, and this is why we are announcing our plans to make sure that EAS continues to be a community-driven, credibly neutral protocol layer.

Why Credibly Neutral?

Imagine a future where a foundational attestation layer serves as the bedrock for our critical systems and daily interactions. It's a world where governments use it to issue digital IDs, where the origins of intellectual property are safeguarded, where financial status is validated, and where knowledge and trust networks continuously evolve. This layer empowers decentralized social networks, and onchain voting, simplifies loan processes and manages title transfers, and enables boundless possibilities resulting in millions of attestations made regularly.

If such an attestation layer was not credibly neutral, the governance system that controlled it could start attaching fees to the core protocol, find ways to disenfranchise applications that may have been built on top of it over time, or favor some applications over others and put them at an unfair advantage. We further believe that token-based governance models for this layer would be inappropriate as a safeguard for credible neutrality.

The token model does not solve the scenario where a well-funded entity or monopoly could buy a majority of the tokens and capture the governance of the protocol. Thus undermining the very essence of decentralization and trust in the attestation layer.

Credible neutrality isn't just a nice to have; it is essential for the success of this layer.

Our next steps

In the coming days and weeks, we'll be engaging with core contributors and thought leaders in the community to lay out our plans regarding credible neutrality, and ensure that the integrity of EAS is safeguarded far into the future.

If you resonate with our vision of a credibly neutral, open-source attestation layer, we want to hear from you. Your insights, expertise, and passion will shape the future of EAS.

The EAS team.

Get In Touch With Us

• Telegram:

  https://t.me/+EcynOr0iFu03MTYx

• Twitter: https://twitter.com/eas_eth

• Read more: EAS’s Purpose

We’re on the right path with EIP-4337.

Initially, Ethereum utilized Externally Owned Accounts (EOAs), offering simplicity and familiarity. But EOAs came with constraints.

EIP-4337 introduced account abstraction, unlocking capabilities like transaction batching, account recovery, and sponsored gas fees. However, this expansion brought its set of challenges, such as the need for AA to exist on Layer 2 (L2) solutions, standardization requirements, and wallet integrations.

Beyond these, there's another crucial aspect to address: trustfulness and contextual depth in our transactions.

However, our transactions lack trustfulness.

Attestations have the power to provide rich, context-aware information within transactions. For instance, consider a DAO project requiring multi-signature approval for fund disbursement. You could use a multisig or even a smart contract wallet, but both lack context as to why the transaction is occurring.

What if we used attestations to improve the authorization logic? In this scenario, an attestation signifies a project manager's approval for a project ID, and another denotes a treasury manager's consent to allocate funds for that project. Once these attestations are available, the funds can be disbursed. This not only adds layers of approval but gives transactions a richer narrative.

As builders, it's time to turn this possibility into a reality. Picture the transformation—where attestations provide not just an approval, but a rich story behind each transaction.

But what does this look like in practice?

With attestations, we can supercharge account abstraction in ways not previously imagined. Here are some practical applications:

1. Role-Based Authorizations: Attestations can demand transactions to have approvals from key DAO or community members, heightening security.

2. Enhanced Security: Attestations can require specific roles or identities to approve, reducing unauthorized transactions.

3. Consent Verification: For Dapps needing user consent before processing actions, attestations can ensure these consents have been provided.

4. Regulatory Compliance: Attestations can certify that transactions comply with necessary regulatory conditions.

5. Contextual Understanding: Attestations can embed transactions with rich, structured data.

6. Flexible Authorization Logic: Beyond a binary yes/no, attestations enable a variety of approval types.

7. Dynamic Access Control: Attestations can grant and revoke permissions as roles within a project evolve.

8. Off-Chain to On-Chain Verification: Attestations can bridge off-chain data with on-chain transactions.

9. Conditional Execution: Attestations can enable conditional transactions, facilitating actions like collateral checks within DeFi smart contracts.

10. Automated Governance Voting: DAOs can utilize attestations for efficient, off-chain voting mechanisms, reducing gas costs and improving governance participation.

Let’s break down a funding request example.

This flow is an example funding request that shows an address requesting a payment to be authorized, then the following attestations show additional approvals for the payment. Once provided, the funds could be deployed to the appropriate party.

Initiating the “Funding Request”.

A member initiates the request, providing key details like the amount, currency type, and request category. Each detail is captured in a structured format, known as the schema (#165) of the attestation. When made, every attestation generates a unique identifier (UID), which is a hash of the attestation data, enabling future references.

While this attestation has a field to represent the category of the payment, it could also have a referenced attestation that refers to the Project ID that is being approved or why the funds were being requested.

Authorizing the Funding Request.

Post the initiation, the request needs approval. Here's where the beauty of attestations shines. For instance, the treasury manager can review the request and provide their attestation, either approving or denying it, referencing the original UID.

It's not just a single layer of approval. Multiple authorizations from various addresses can be integrated into this workflow, providing a robust, secure approval process. Once all necessary attestations are collected and validated, the payment is automatically processed to the appropriate party.

This example illuminates each attestation and builds a narrative around a transaction, layer by layer, ensuring thoroughness and secure authorizations. The multi-level approval process enhances security and makes it robust. Once all attestations are in place, the payment flows seamlessly.

What we witness here is more than just a payment process - it's the potential of Ethereum transactions to become more contextual and secure. These attestations are not just mere approvals; they are the bridges linking intent, action, and verification.

Pioneering The Path Ahead

Attestations are expanding what’s possible in Ethereum while infusing transactions with trust and transparency. Ethereum isn't just becoming more efficient and flexible—it's evolving to be more adaptable to a wider range of applications, fostering a more inclusive, vibrant, and trustful ecosystem.

However, building a dynamic and adaptable ecosystem with attestations isn’t without challenges. Developers must understand how to implement attestations effectively within existing structures and navigate potential complexities. For product people, translating these advancements into industry-specific applications could be the key to unlocking novel opportunities.

To get started, explore the Ethereum Attestation Service and delve into the world of attestations. Together, we can shape the Ethereum of the future, creating a more trustful, dynamic, and inclusive ecosystem for all. It's more than just an upgrade. It's the next evolution in the Ethereum journey.

Your expertise, your ideas, and your actions can drive this change.

Are you ready to be a part of it?

About Ethereum Attestation Service

EAS is an infrastructure public good for making attestations onchain or offchain. Attestations are simply digital signatures on structured data. To learn more about EAS, explore the following resources:

• Website: https://attest.sh

• Docs: https://docs.attest.sh

• Github: https://github.com/ethereum-attestation-service

• SDK: https://docs.attest.sh/docs/getting--started/javascript

• GraphQL API: https://sepolia.easscan.org/graphql -- change the subdomain for your chain

• Twitter: https://twitter.com/eas_eth

• Learn about attestations: https://optimism-goerli.easscan.org/learn

• Make your first schema: https://sepolia.easscan.org/schema/create

Explorer Sites (Etherscan for Attestations):

• Sepolia: https://sepolia.easscan.org

• Base: https://base-goerli.easscan.org

• Optimism-Goerli: https://optimism-goerli.easscan.org

• Arbitrum: https://optimism-goerli.easscan.org

• Mainnet: https://easscan.org

Further Reading

• Alchemy’s Account Abstraction Overview: https://docs.alchemy.com/docs/account-abstraction-overview

• EIP 4337: https://eips.ethereum.org/EIPS/eip-4337

• Metamask’s Account Abstraction: Past, Present, Future: https://metamask.io/news/latest/account-abstraction-past-present-future/

• Ethereum.org Account Abstraction: https://ethereum.org/en/roadmap/account-abstraction/

Meet Sybil: A Persistent Identity Problem

Sybil attacks exploit weak identity mechanisms, thriving wherever there's money to be made or value to be extracted. In a Sybil attack, a malicious user creates multiple identities to manipulate a system or network, like voting systems and airdrops. Poor Sybil resistance can jeopardize a protocol or community.

The recent Arbitrum Airdrop is a prime example: one address used 866 addresses to receive 1.4M ($1.9M) $ARB. Coindesk further reported that nearly 48% of all tokens were distributed to users who controlled multiple addresses.

Despite efforts to detect and prevent such attacks, bad actors continue to find ways to exploit the system. The key to overcoming this issue lies in adopting an offensive approach to Sybil resistance, which focuses on strengthening eligible users rather than just detecting malicious ones or patterns.

These aren’t sophisticated schemes either; the attackers anticipate eligibility criteria and generate hundreds of quality accounts that may be eligible based on on-chain behavior. At the root of all these attacks is an undefined single exploiter.

“Did you know? The name "Sybil" comes from a famous case of dissociative identity disorder (DID) in the 1970s, where a woman named Shirley Ardell Mason had an alter personality named "Sybil".

Attestations: Building Sybil-Resistant Identities

At its core, a digital identity is a collection of attestations made by various entities over time, representing different facets of an individual's life. Your first identity is when your mother names you. She attested to who you are. Then over time different entities and individuals attest to various facets of your life - if they trust you, your grades at school, the government attesting to your passport, and more.

Attestations are digital records signed by an individual or entity that can be about any type of information. By using attestations and privacy-preserving technologies like ZK, we can create more Sybil-resistant digital identities, significantly increasing the protection of projects from identity exploits.

Ethereum Attestation Service (EAS) can be used to make attestations and build an aggregated representation of a wallet address's digital identity.

Taking Steps Towards 100% Sybil Resistance

Achieving 100% Sybil resistance may seem out of reach and it is, but with a progressive approach and the use of attestations, projects can continue making massive improvements toward this goal. By starting with simple verifications and gradually building more comprehensive identities, we can develop a more Sybil-resistant future.

Start with Simple Verifications

We can begin building more comprehensive identities and require attestations for eligibility with simple identity verifications, such as:

• Phone verification attestations

• Social account verifications like Twitter

• Email verifications

• ENS ownership verification

• Employment verifications

• Attesting to people and things you trust

These simple verifications alone are not enough to prove someone's personhood. Just look at how well the verified checkmark is working for Twitter.

Build Upon Behaviors and Achievements

To create a more complete digital identity, we can attest to one's behaviors and achievements, such as:

• Attendance at community events or hackathons

• Proof of contributions in a DAO

• Community roles

• Academic credentials

• Proof of skill

• Proof of residency

Bringing Off-Chain Identities On-Chain

Ultimately, as more partners integrate attestation technology, we'll be able to attest to digital identities and provide better proof of personhood and Sybil resistance with:

• Identity services verifying one's driver's license or passport

• Government attestations to one's citizenship

• KYC providers attesting to an address passing their compliance check

• Banks attesting to one's financial stability

• And more

It’s important to recognize that these types of attestations would be made with privacy-preserving technologies such as zero-knowledge attestations and private data attestations using merkle tree proofs.

Not all identity data needs to live on chain. For example, a government could attest to a simple hash of the passport number and its current status.

https://easscan.org/offchain/url/#attestation=eNqdkUuuHDEIRfdS41LEx2AY9q82Eb0BtmEBT4mU5cfd2UGYMIHLvYefB%2FwgPU48D%2FhzQ4J%2B8f0eRO1F0ydPfUpcyk%2FIgWL0SLF%2BvIeZQbLhoq4K1MhHNZwWpphphdgcF7Zck4eYa8tuvRs1kE6e8hFRG5XhCNQpJ6OQ8XTzUpKpRSadJ9BKXGXilKvAKrNQAwfDcZK9dTJTLV6PvLebpxeTRdPJfgks47oBsc%2Fn9TmaujiWDw%2FtjsFCyANYMmLsLCPKqgGETynqtodlCPdIECvr7SNSrQr3%2BgStZgw1h1TH3SJI5%2FYokzB68SYRZBm8jUgk0diQ%2FsXnG8JYgvhKhoR273J5F3I2Xu3h%2FSFj9oX7P2qom5PZCXvzOH99%2F863BMFylQjWGQ1HKPflCzh8rCLKjW1ylaO5R5s11gBptX3nBy%2F8Z2lWAtt2Al9%2FAQr%2BlMU%3D

Following this approach, we can create a compelling, comprehensive view of an individual's identity, making it increasingly difficult for Sybil attacks to succeed.

Building on Existing Efforts

Many projects are already working on Sybil-resistant mechanisms that can benefit from the interoperability of attestations made on EAS.

The Ethereum community must coordinate to develop a more sybil resistant future. Trying to solve sybil resistance alone will be a fragmented and never-ending uphill battle. By working together, we can begin attesting to many different facets of one’s identity and allow greater composability and interoperability in determining the eligibility of addresses in a more secure and customizable way.

This interoperability of attestations will enable projects to selectively choose which attestations matter most to them for sybil resistance and authorizations. Some examples in the future may require:

• Gitcoin Stamp attestations

• POAPs and proof of attendance at certain community events

• Sismo ZK badges

• Worldcoin Orb attestations

• Proof of Humanity attestations

• Disco Data Backpacks

• Lens Profile Information

• And more

Greater adoption of attestations will be propelled by Layer 2 ecosystems like Optimism, incentivizing and coordinating builders to experiment and create more secure, robust digital identities for Sybil resistance.

These types of attestations could be aggregated into a single attestation. For example, you may attest “isHuman” to addresses that are eligible if they have X, Y, & Z attestations.

A Future of Relative Trust

We envision a future where relative trust is the norm, just like in the physical world. In doing so we can purge any big brother scoring system that exists today.

In this world, all identity platforms and online communities are attesting to different aspects of one's digital identity, and individuals can also attest to the relative trust they have with one another.

This allows individuals and entities to generate their own relative reputations and risk scores for a subject address, enabling projects to calculate their Sybil-resistant rules and determine which attestations are required.

Moving Forward Together

As a community, we need to work together to develop a more Sybil-resistant future. By collaborating, we can create a diverse range of attestations, enabling better composability and interoperability in determining the eligibility of addresses in a more secure and customizable way.

Get started by creating your first attestation, attesting to someone who is your friend. This simple attestation allows one address to attest a "bool" isFriend to their friend's ENS address.

Try it on:

• Sepolia

• Mainnet, or

• Arbitrum

• Optimism coming soon!

Get In Touch With Us

Twitter: https://twitter.com/eas_eth

Learn More About EAS

• Ethereum Attestation Service Website

• EAS Documentation

• EAS Scan

• EAS on Github

Additional Resources

• Arbitrum Foundation Sybil Detection on Github

• 

  Lookonchain

  @lookonchain

  

  We found 2 super airdrop hunters of $ARB.
  
  0xe1e2 received 1.4M $ARB($1.92M) via 866 addresses and added all 1.4M $ARB to #Uniswap to provide liquidity.
  arbiscan.io/token/0x912ce5…
  
  0xbd4e received 933,375 $ARB($1.28M) via 630 addresses.
  arbiscan.io/token/0x912ce5…

  

  724

  2:21 AM • Mar 24, 2023

• Coindesk Article on Crypto Airdrop Sybil Attacks

• Gitcoin Community Sybil Resistance Community Roadmap

Mastering Merkle Trees 🌳

Merkle Trees play a vital role in situations where it's essential to maintain privacy while ensuring the accuracy and reliability of the information.

They are cryptographic data structures designed for secure and efficient data verification. Imagine a tree built from the ground up, with individual pieces of data called leaves at the base. Each leaf is put through a cryptographic process called hashing. Next, pairs of these hashed leaves are combined and hashed again, creating a new level of parent nodes in the tree. This process repeats itself until there's only one hash left at the top, known as the Merkle Root.

What makes Merkle Trees special is their ability to prove that specific data is part of the tree without disclosing the entire dataset. This is done using a Merkle proof, which includes a data element's hash and a series of related hashes. By checking the Merkle proof against the Merkle Root, anyone can confirm the authenticity and inclusion of that data element without accessing the complete dataset.

Merkle Trees are integral to privacy-focused technologies like zero-knowledge proofs and secure data sharing, striking a balance between data integrity and privacy.

The Art of Concealing and Revealing 🤫

Private Data Attestations take advantage of Merkle Trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy.

Attestors can now selectively disclose parts of their attestations without revealing the entire attestation data. This allows for greater control over the information being shared, while still providing the necessary proof or verification for specific use cases. It is beneficial for use cases that require sensitive information to be withheld while still verifying crucial aspects of an individual's credentials or reputation.

A quick example of how it works:

1. The user or entity submits data for selective disclosure.

2. Data is encoded, generating a Merkle root hash.

3. Creator's address attests to the Merkle root hash on or off-chain.

4. The user produces proofs for specific data fields to disclose.

5. Verifier checks proofs against the Merkle root.

Note: EAS utilizes OpenZeppelin's Merkle-tree library and ethers.js for Merkle Tree operations.

Alice’s Proof of Funds Example.

Alice is eager to make a cash offer on a new home, but first, she must prove that she has sufficient Proof of Funds to pay for it.

1. Bob's Regional Bank (0xeee...) initiates a private data attestation for Alice's known wallet address (0x1e3de...), including details such as her current cash balance, whether she has over $100k, and her credit score.

2. Bob’s Regional Bank then attests to the private data, which gets encoded and generates a Merkle tree root hash of all the fields.

The created attestation only contains the "Private Data" bytes32 value representing the Merkle tree root. This "Private Data" is accessible exclusively to the original attestor address or those who have received and verified any proof of the data.

Once the attestation is made, Bob’s Bank can provide Alice with the entire data from the tree which will allow her to generate proofs from it.

3. Alice can now selectively disclose specific parts of her encoded data by generating a proof/leaf for the desired data field.

In this case, Alice wants to share her legal name and confirm that her balance is over $100k. By clicking 'Generate Proof,' she obtains the 'Proof Result.'

4. The provided proof can be verified against the attested Merkle tree root hash, ensuring secure confirmation of the disclosed data without exposing the entire dataset.

See how this works! Grab the proof value below and go to this attestation on Sepolia.

{"leaves":[{"type":"string","name":"legalName","value":"Alice Jane","salt":"0x57fcfaba9f561d63633eea87b3b7ec966458ae8fc9d5eb97f7ac9720e0081ec7"},{"type":"bool","name":"over100k","value":true,"salt":"0x1e484bb1b34642c7ab9503a0f168c1a0a484b84d9d67125b43ab4bc6345d6f80"}],"proof":["0x5c748363cb92f90d75fb865d93d9fa4394f8bbc8af543f225de23ba791c21819","0xa29bc29fec293e03b8f4a933de34a71fbb0a6eec96ec13b3aff9fa397645ca06"],"proofFlags":[false,false,true]}

Attestation (Private Data) - 0x7be3...0dc3e

View attestation details for 0x7be3...0dc3e on EAS - Ethereum Attestation Service.

https://sepolia.easscan.org

Key Benefits of Private Data Attestations with Merkle Tree Proofs:

1. Enhanced Privacy: Preserve sensitive information by retaining only the Merkle tree root hash in the attestation, effectively restricting unauthorized access to the entire dataset.

2. Selective Disclosure: Reveal specific data fields by generating a proof/leaf for the desired data, enabling a tailored approach to information sharing.

3. Secure Verification: Validate the disclosed data against the attested Merkle tree root hash, guaranteeing data integrity and authenticity.

4. Versatile Use Cases: Applicable to a wide range of scenarios where privacy and selective data disclosure are essential, such as identity verification, access control, academic records, healthcare records, and beyond.

Example Use Cases ✨

1. Identity Verification: Leverage private data attestations for selective disclosure of identity attributes, ensuring privacy while maintaining necessary verification.

2. Access Control: Apply attestations for managing access to restricted resources, enabling proof of eligibility without revealing personal information.

3. Employment History & References: Share specific employment details and references while keeping sensitive information confidential.

4. Academic Records & Certifications: Selectively disclose academic achievements to institutions or employers without revealing the entire background.

5. Financial Transactions: Use attestations to prove necessary financial information without disclosing sensitive data or full transaction history.

6. KYC & AML Compliance: Fulfill KYC and AML requirements by verifying specific information without revealing unnecessary personal data.

7. Voting & Elections: Ensure a confidential and secure voting process by proving voter eligibility without disclosing personal information.

8. Supply Chain Traceability: Verify product origin and authenticity without revealing sensitive supplier or proprietary process information.

9. Intellectual Property Rights: Prove ownership of intellectual property without disclosing content or trade secrets.

10. Medical & Healthcare Data: Selectively disclose medical records or patient data for privacy and secure sharing of sensitive health information.

Getting Started: Integration & Developer Resources

To begin integrating private data attestations into your projects, check out the available resources and guides. The best way to get started is to try generating sample private data attestations, generating proofs, and verifying them on Sepolia or the chain of your choice.

Official documentation for a comprehensive understanding of the feature and its implementation will be added to our docs shortly.

If you need any support or have questions, DM us on Twitter @eas_eth and we’ll set up a private chat group together.

Future Developments and Roadmap

Ethereum Attestation Service will continue improving and expanding privacy-focused features, including enhancing private data attestations, integrating zero-knowledge proofs, and further collaboration with the rest of the Ethereum community.

Keep an eye on project updates and announcements to stay informed about the latest advancements and opportunities for involvement.

Wrapping Up

Private data attestations bring a new level of privacy and selective disclosure to the Ethereum Attestation Service ecosystem. This feature empowers users to maintain control over their data while ensuring data integrity and secure verification. We encourage developers to explore and experiment with this innovative solution, unlocking the potential to create groundbreaking applications and services across various industries. Together, we can build a more secure and privacy-conscious future for the Ethereum ecosystem and beyond.

Stay In Touch

• Website: https://attest.sh

• Docs: https://docs.attest.sh

• Explorer: https://easscan.com

• Twitter: @eas_eth

We are thrilled to announce the launch of Ethereum Attestation Service (EAS), a public good for making attestations on or off-chain.

As builders, you understand the critical role trust plays in decentralized applications, and with the ecosystem evolving, a robust and accessible trust layer is more important than ever. However, the lack of a standardized and open way to make attestations on or off-chain is limiting the trust in decentralized applications.

EAS provides a solution to this problem and we’re ready to deploy it across multiple EVMs. We are live on Arbitrum and will be deploying on Mainnet in the coming days, then shortly after we’ll deploy on Optimism and the other chains that the community prioritizes.

With EAS, making attestations becomes easier, more reliable, and cost-effective, making trust a standard for every project in the Ethereum ecosystem.

Introducing Ethereum Attestation Service 👋

Ethereum Attestation Service (EAS)

Ethereum Attestation Service (EAS) is a public good for making attestations on or off-chain.

EAS aims to be the base layer for all attestations creating greater portability, interoperability, and composability. We strongly believe that the base layer for attestations and trust cannot be controlled by a centralized team or tokenized. These types of incentives and controls at the base layer can thwart innovation, create fragmentation, and shift the focus to extracting value versus creating it.

EAS is open-source, permissionless, tokenless, composable, and serves as a free public good.

Why We’re A Public Good

EAS is a public good, which means it is free, open, and accessible to all. EAS will be openly shared and available for anyone to use and build upon, encouraging the development of new and innovative applications and use cases for attestations. It is built by the public for the public, with a focus on creating and coordinating value rather than extracting it. This open access will benefit the Ethereum community by fostering creativity and innovation.

EAS will also contribute to the community by providing educational resources and documentation to help developers and users understand and effectively use the service. This will help to build a strong and knowledgeable community around EAS. By providing a shared infrastructure, open access, and educational resources, EAS will create a public good that benefits the entire Ethereum community.

The Importance of Attestations to Ethereum

In order to decentralize more than money and assets there needs to be a generic ledger for making statements on Ethereum. This ledger will help build more trust across our online interactions. Anytime you need to prove or verify something, attestations will play a critical role.

Attestations play a critical role in building trust and transparency on the Ethereum network. They are a way to make statements about any topic and verify their authenticity. By providing a standardized way to create and manage attestations, EAS makes it easier to build decentralized applications that require trust.

EAS enables developers to easily create schemas and attest with them, without the need for complex, limited, or fragmented solutions. This creates greater accessibility, portability, and interoperability across the EVM ecosystem. EAS will help unlock the potential of the Ethereum ecosystem, allowing builders and consumers to create innovative projects and new forms of intellectual, social, and economic opportunities.

We're excited to launch EAS and look forward to seeing the amazing things that builders will create with it.

How EAS Works

EAS is a powerful yet elegantly simple solution. We've refined our contracts through community feedback and iterative improvements, and we're thrilled to make them available to everyone.

EAS operates through two straightforward smart contracts: one for creating schemas, and the other for making attestations with them. By using our optional resolver contract, you can unlock additional capabilities when making attestations, such as attaching payments or selecting specific addresses that can use the schema.

EAS supports on-chain and off-chain attestations, depending on your needs. To learn more about how to use EAS, check out our documentation.

The Power of Attestations ✨

Attestations are simply statements or pieces of evidence about anything, made by anyone on the Ethereum network. They're digital records signed by an individual, company, or organization to verify information about another person, entity, or thing.

Attestations play a critical role in establishing trust and credibility online. With face-to-face interactions becoming less common, it can be challenging to determine the accuracy or reliability of information digitally. Attestations provide a means of third-party validation and cryptographically signed confirmation, making it easier for others to trust and depend on that information.

Attestations Go Beyond Digital Identity & Credentialing

While attestations are often associated with digital identity and verifiable credentials, their potential goes far beyond that. Attestations have a wide range of use cases that can be used to prove and build more trust in various scenarios, including:

• Voting systems, ensuring the integrity and transparency of the voting process

• Proof of X, anytime you need to provide evidence to prove the state of something (attendance, funds, compliance, etc)

• Content authenticity, preventing misinformation online

• Reputation systems, establishing credibility and trustworthiness within online communities

• Supply-chain provenance, verifying the authenticity and origin of goods and products

• Prediction markets and oracles, providing a means of reliable information for decision-making

Attestations can be applied in any context where trust needs to be established, making them a versatile tool for a wide range of industries and applications.

Deploying EAS Across Multiple EVMs 🚀

We're excited to launch EAS across multiple EVMs with a strong focus on developer engagement and community feedback.

Our primary goal is to provide developers with a smooth onboarding experience and a simple way to start building. We've designed our deployment strategy to be easy to use, so that ecosystem builders can join us in growing the EAS contracts. As we collect feedback from the community, we plan to release future versions of EAS to meet the evolving needs of developers.

We’re not launching naked.

We're thrilled to announce that we're launching EAS with a strong focus on the experience and education for the community. As part of this focus, we've created several resources to help innovators build with EAS:

• An attestation explorer for anyone to verify attestations

• A no-code schema builder for easily creating schemas

• A no-code attestation maker to easily make attestations

• An SDK for increasing the speed for devs to experiment & integrate EAS

• The ability to make verifiable off-chain attestations.

• Developer documentation to get started for all levels of technicality

• Educational resources to understand EAS

Each deployment of EAS on mainnet and the L2’s will have its own version of the EAS Scanner, similar to how Etherscan works, and how ENS has deployed across chains.

EAS Explorer

Our attestation explorer allows you to easily browse and verify any attestation that has been made using EAS.

Ethereum Attestation Service - Explorer

EAS enables anyone to create and validate onchain and offchain attestations on Ethereum. Explore attestations, schemas, and transform online trust.

https://easscan.org

Schema Builder

The Schema Builder makes it simple to create a schema about any topic and attest to it.

Ethereum Attestation Service - Explorer

EAS enables anyone to create and validate onchain and offchain attestations on Ethereum. Explore attestations, schemas, and transform online trust.

https://easscan.org

Attestation Maker

The Attestation Maker allows you to make an attestation without writing any code. Just navigate to a schema and click ‘Attest with Schema’.

EAS SDK

An easy-to-use javascript/typescript SDK for integrating EAS into your projects.

GitHub - ethereum-attestation-service/eas-sdk: Ethereum Attestation Service - TypeScript/JavaScript SDK

Ethereum Attestation Service - TypeScript/JavaScript SDK - ethereum-attestation-service/eas-sdk

https://github.com

Off-Chain Attestations

EAS allows you to easily make off-chain attestations. Off-chain attestations still carry the entire attestation data and authenticity from the signature and provide more privacy than on-chain attestations.

EAS allows you to easily timestamp off-chain attestations on-chain as well as revoke them on-chain, which gives off-chain attestations a verifiable timestamp and similar versatility as on-chain attestations.

Launch Plan 🧑‍💻

EAS does not presuppose where builders will use EAS and we want to empower builders across the entire EVM. We have developers already building on Arbitrum and we will plan to launch quickly on Mainnet, Optimism, and other chains in the near term. Here’s an overview of our now, next, later roadmap:

Now

• Increasing awareness & adoption of EAS

• Deploying on Mainnet

• Continuing to improve the developer onboarding & activation experiences

• Furthering the community infrastructure & engagement

Next

• Deploying on Optimism

• Building “powered by EAS” services to increase adoption

• Increasing developer participation across the EVM

• Continue to educate and improve EAS based on feedback

Later

• Hosting and participating in ETH-based hackathons

• Continue to improve the EAS contracts based on adoption & feedback

• Continue partnerships within Web3 & Web2 for trust-based applications powered on Ethereum

Join the EAS Community 🤗

We believe that a strong community is essential for the success of EAS. We have already seen positive engagement and feedback from early adopters, and we look forward to building a vibrant and inclusive community of builders, users, and evangelists.

If you have any questions, feedback, or suggestions for EAS, reach out to us on Twitter. We’ll also be launching the community Discord in the coming days.

Thank you for your support, and we look forward to working with you to create a more accessible, reliable, and trustworthy Ethereum ecosystem.

Learn more about EAS

• Website: https://attest.sh

• GitHub: https://github.com/ethereum-attestation-service

• Docs: https://docs.attest.sh

Join us on Alice's journey through a mock DAO as we explore the power of attestations in action.

Breaking Free 🔓

Communities should not be shackled to the centralized platforms they choose to assemble on. They must seek decentralization and independence. When a community and its members are truly decentralized, it empowers individuals and collective innovation that transcends existing boundaries and systems.

By breaking free from centralized platforms and embracing decentralization, communities can take ownership of their governance and generate more honest and transparent opportunities. Through the use of attestations, the community can govern itself in a manner that is fair, secure, and free from the influence of centralized entities.

The Problem with Centralized Platforms

Centralized platforms pose significant challenges to the achievement of true decentralization for communities. While user-friendly platforms like Discord are popular, they don't provide the necessary flexibility and portability for decentralized community management.

Let's take a look at a common authorization journey in Discord:

1. User buys or receives the membership NFT (ERC721).

2. Collab.Land or other software authenticates access.

3. The user agrees to server community rules.

4. The user selects reaction roles for further access in the Discord.

5. The member ultimately leaves but membership is not revoked.

There are several issues with this process:

1. Anyone can buy, sell, or transfer the authorization token.

2. Centralized platforms control user data.

3. Community roles aren't easily extensible or portable to other systems.

4. Bad actors and spam can easily join and disrupt community progress.

5. Memberships are often lifetime and not based on engagement or contribution.

6. Reputation systems, if any, are centralized in the platform.

7. Voting systems are also disparate and not accessible to all members.

To truly embrace decentralized community management, it's essential to acknowledge the limitations of current centralized platforms and move towards more open, interoperable systems that prioritize portability and user autonomy. When a community is more portable, it opens up new possibilities for growth and collaboration with other communities and their partners.

Attestations Will Help Us Decentralize.

Attestations are digital statements about anything that are signed by a wallet. Attestations have provable authenticity, the data they hold cannot be altered, they are composable, and they can be revoked by the attestor.

Ethereum Attestation Service (EAS) is a public good for easily making Ethereum-based attestations about any topic on or off-chain. Each attestation made with EAS has these critical features:

1. UUID - the autogenerated unique universal identifier that’s a hash of the attestation

2. Timestamp - when it was created

3. Attester - who made the attestation

4. Recipient - the address the attestation was about (if relevant)

5. Attestation data - the information of the attestation

6. Reference UUID - the UUID of the related attestation (if any)

7. Expiration time (optional) - the time the attestation expires

8. Revocation time (optional) - the status and date if attestation was revoked

9. Resolver - an optional contract that can be triggered from the schema once the attestation is made

You can customize the schema of the attestation data to be anything you want to fit your specific use case, as long as it follows Ethereum ABI types. Different people may find certain fields more valuable or effective, depending on their specific needs.

The value of an attestation comes from the credibility and trustworthiness of the person making the attestation, not from the schema itself.

Attestations can be used for much more than just community roles and authorizations. They can help us achieve new possibilities in digital identity, reputation systems, voting systems, supply chain provenance, prediction markets, moving important records on-chain, digital signatures, notaries, and more.

Alice’s Attestation Journey in a mock DAO

Let's explore the benefits of using attestations for better-decentralized community management. We’ll follow Alice on her journey from joining the mock DAO, gaining authorizations, voting, and ultimately leaving.

For the following Alice examples let’s assume:

• Alice’s Wallet Address: 0xe7E05f1ea1Bed40e17a4E81D299bcCdfE908dB03

• DAO Wallet Address: 0x3A10bd511Ee30e04B75F97529383d4C97C5bc7d1

Please Note - The schemas used in these examples are not meant to be the optimal types and fields for every use case. We have opted for simple string types in most use cases to allow for easy reading.

Depending on your use case, you may find certain fields more or less important, or may want to add or modify fields as necessary. You have complete flexibility to customize your own schemas according to your unique requirements using EAS.

[1] Granting Alice Access to the Community

Alice is a solidity engineer who wants to join the DAO. When Alice joins, the DAO creates an immutable but revocable attestation that permits Alice into the community. This attestation includes Alice's assigned "roleID" and the "teams" she is a part of.

[2] Assigning Additional Authorizations

Alice wants to contribute more to the community and earns a "Senior Developer" role after passing a coding challenge. The DAO attests to this additional role which authorizes Alice to review code commits from junior developers.

[3] Attesting to Member Engagement

Alice continues to contribute significantly to the DAO. She regularly engages in community events, contributes to core projects, manages channels, and more. To recognize her efforts, the DAO attests to her contributions to a recent project.

[4] Using Attestations for Membership Voting

The DAO can create a schema for voting on specific issues. Once a DAO member has the authorization to vote, the DAO can collect votes using attestations made by its members.

Note* - This is a one address one vote example, however, you could set up your voting strategy and fields any way you’d want. This vote was done off-chain and published to IPFS. *

[5] Time-based memberships & subscriptions

The DAO can issue time-based memberships, like subscriptions to members. For example, they might give Alice a VIP community pass that grants her access to a specific section of the community for a set period of time. These passes can be made using attestations and then expire over a period of time.

[6] Revoking Access & Authorizations

Over time, Alice becomes less active in the DAO and finds another community she's more passionate about. The DAO revokes certain authorizations, such as her being a core developer, until her activity improves again.

Notice that this does NOT delete the record that she was a core developer, but adds a revocation status to it. This way Alice & the DAO can still prove her contributions.

By using attestations for community management, DAOs like the Mock DAO can build stronger and more efficient decentralized organizations.

Advantages of Attestations for Decentralized Communities

By using attestations for community management, DAOs like the mock DAO can build stronger and more efficient decentralized organizations. And more importantly, we can move decentralized communities towards:

1. Enhanced Flexibility: Attestations allow for greater flexibility in defining community roles and responsibilities. With attestation-based management, community members can be authorized to perform specific tasks based on their unique skills, experience, and reputation within the community.

2. Extensibility and composability: Community roles and authorizations in centralized platforms are often not easily extensible or portable to other systems. In contrast, attestations can be customized to fit specific use cases and can be easily shared across different systems.

3. Composability: Attestations can be combined to form a comprehensive view of a member or community, creating a "lego-like" structure of trust. Attestations from outside the community can also be incorporated to enhance trust and reputation.

4. Decentralized trust: Attestations promote transparency and accountability in decentralized communities, allowing members to self-manage without the need for centralized authorities or intermediaries, while also reducing fraud and fostering trust.

5. Increased community engagement: Attestations can increase community engagement by enabling members to earn rewards and recognition for their contributions to the community. This can help to incentivize participation and increase collaboration, creativity, and innovation within the community.

Limitations with Attestations

While attestations offer significant advantages in decentralizing community management, there are limitations to consider. Not everyone in a community may have access to a wallet or be familiar with Ethereum, and not all community roles can be easily attested to, making centralized platforms or other methods necessary in some cases.

Attestations may not always be the most effective or cost-efficient solution depending on the DAO's smart contract implementation and use cases. If a DAO only needs to control voting on proposals, using smart contracts may be sufficient. However, if greater portability and extensibility of activities are required, or the DAO wants customization to permit specific attestations over time to vote, attestations are valuable.

The use of attestations requires technical expertise, and may not be accessible to everyone. However, as the technology develops and becomes more user-friendly, we can expect greater adoption of attestations and other decentralized tools for community governance.

Getting Started With Your Own Attestations

If you're interested in using attestations to decentralize your own community management, there are a few steps you can take to get started.

1. Define your schema: First, you'll need to define the schema for your attestations. This will involve determining the data fields you want to include.

2. Use an attestation service: EAS offers an SDK for developers as well as a friendly UI for those not-as technical enabling people to easily make schemas and make attestations on or off-chain.

3. Test your schema: Before you start creating actual attestations, it's a good idea to test your schema. This will allow you to identify any issues or errors in your schema before you start creating attestations that will be used by real users.

4. Start creating attestations: Once you've defined your schema and tested it, you can start creating actual attestations for your community. This may involve using smart contracts to automate the attestation process, or manually creating attestations and adding them to the blockchain.

Learn more at Ethereum Attestation Service

Ethereum Attestation Service (EAS) is a public good for making attestations on and off-chain about any topic. As a public good, EAS is completely open-source, permissionless, tokenless, and free to use.

Developers can get started with EAS using the SDK, while non-technical users can create schemas and attestations through EAS's intuitive no-code UI. With EAS, it's easy to establish trust in your community and create more equitable governance structures.

Ethereum Attestation Service

Open-source public good for making attestations on or off-chain.

https://attest.org

Conclusion

Decentralizing community memberships and authorizations is a key step toward creating more equitable and transparent community governance systems. By using attestations on Ethereum, communities can achieve greater decentralization, while also improving security and reducing the risk of bias and censorship. While there are some limitations to consider, the benefits of using attestations for community governance are significant, and will likely continue to be a focus of development and innovation in the blockchain space.

Stay in touch with us.

Twitter: @eas_eth

Ethereum Attestation Service

Open-source public good for making attestations on or off-chain.

https://attest.org

Ethereum Attestation Service - Explorer

EAS enables anyone to create and validate onchain and offchain attestations on Ethereum. Explore attestations, schemas, and transform online trust.

https://easscan.org

Ethereum Attestation Service

Make attestations about anything onchain or offchain. - Ethereum Attestation Service

https://github.com

The article introduces another solution for verifiable credentials using Ethereum-based attestations and explores the trade-offs and limitations of ERC721 (NFTs) and Soulbound Tokens (SBTs).

ERC-721 (NFTs): The Current Standard & Limitations

NFTs have created a sensation in the industry, particularly for digital art and collectibles, leading to the wider adoption of NFTs for various purposes such as membership badges, proof of attendance, skill showcasing, and more. This surge in popularity has made ERC-721s the go-to choice for creating different types of verifiable credentials (VCs).

The Limitations of ERC-721 Verifiable Credentials

While NFTs can serve as VCs, they come with several limitations that can limit their effectiveness in certain use cases, especially as it pertains to one's identity, authorizations, and reputation.

Transferability:

ERC-721 tokens are like hot potatoes, they can easily be passed on to someone else. This can pose challenges for VCs. For example, a certificate NFT could end up in the hands of someone who doesn't possess the same level of knowledge or expertise, potentially leading to misuse and misrepresentation of the credential.

Irrevocability:

Once an ERC-721 token is handed over, it cannot be taken back. This creates potential risks in identity and reputation systems. For instance, if a credential is provided to a member who later becomes a bad actor or if the credential needs to expire after a certain time, it can't be revoked. Creative solutions like "seasons" or multiple tokens have been introduced as a workaround but are not ideal.

Lack of standardization:

ERC-721 tokens are like snowflakes, each one is unique with its own custom contract and metadata which makes it difficult to ensure compatibility and interoperability between different use cases.

Soulbound Tokens (SBTs): The Upgrade

Soulbound Tokens (SBTs) are a significant upgrade to the limitations of traditional NFTs as verifiable credentials. SBTs are unique digital assets that presumably cannot be transferred to other accounts or addresses. Once they are assigned to a specific account, they remain bound to it, hence the name "soulbound".

SBTs can be used to represent a user's identity and accomplishments, attendance, and more creating an on-chain identity and resume of behavior. This opens up new possibilities for DAOs, contributors, and governance designs, including improved sybil resistance and better community organization.

There are several amazing projects that are starting to integrate and explore SBTs as a verifiable credential alternative and the concept of soulbound tokens is promising, but it's building upon existing technology and still has its limitations.

Existing Limitations of Soulbound Tokens as Verifiable Credentials

SBTs are making a splash in the world of VCs with their improved security and utility compared to traditional NFTs. But, even with all their awesomeness, they still have a few quirks.

Transferability Risk

Despite being more secure than traditional standards like ERC-721, SBTs are not completely soulbound and can still be transferred. This can happen through private key sharing, multi-sigs, smart contract exploitation, or threshold ECDSA.

Examples:

1. The SBT is sent to my account A, but I just give you my private key, thus transferring (or at least sharing the ownership) together with you.

2. The SBT is sent to account A, but its private key is actually distributed between multiple parties via a threshold ECDSA DKG and signing scheme.

3. The SBT is sent to account A, but it's actually a smart contract that has an "owner" and a method to "change the owner". This is similar to how a team exploited EthCC conference tickets, by creating lots of contracts that can change who is eligible to use the tickets under the hood.

4. The SBT is sent to account A, but it's actually a multi-sig (similar to 3, but more conventional)

"When EthCC offered another batch of 300 tickets in March, the group devised a method to make the non-transferable NFTs transferable."

https://www.cryptotimes.io/ethcc-nft-ticket-scalpers-protest-receiving-half-of-the-refund/

Limited Off-chain and Scalable Privacy Capabilities

Being restricted to the on-chain world, SBTs don't offer much privacy protection unless combined with zero-knowledge proofs. And while there are solutions to move SBTs to Layer 2 networks to reduce costs, not all use cases require on-chain storage. This can limit SBTs' effectiveness in certain applications.

Lack of Common Registry and Specification

Unfortunately, there is no central registry or specification for SBTs, which can lead to fragmentation in the market. Different protocols and builders have their own ideas about how SBTs should be used, causing confusion and hindering interoperability between systems and protocols.

Despite these limitations, SBTs are a promising technology with exciting potential, especially for communities and organizations looking for better identity, authorizations, and reputation systems compared to traditional ERC-721 tokens.

Attestations: An alternative path forward

“In order to decentralize more than just money and assets, the world needs a decentralized protocol/ledger for arbitrary attestations about anything.” - Steve Dakh, Co-Founder @ Ethereum Attestation Service

Attestations are simply statements or pieces of evidence about anything, made by anyone. They're digital records signed by an individual, company, or organization to verify information about another person, entity, or thing. They have a variety of uses, like identity verification, reputation building, proof of X, content authenticity, and even beyond VCs, like supply-chain tracking and compliance assurance, voting systems, ticketing, oracles, and more.

Think of attestations as a digital reference. Just like you trust your friends' opinions, you trust attestations from reliable sources. But if the "attester" isn't trustworthy, the attestation loses its value. The value of an attestation depends on the reliability of the entity making the statement. For example, a certificate of completion from a reputable university holds more credibility than one from an unknown online course provider or your friend.

Attestations play a crucial role in establishing trust in the digital world. In the absence of physical interaction or presence, it can be difficult to verify the information. Attestations provide third-party validation and secure confirmation of the authenticity of the information, making it easier for others to trust and rely on it.

The key features of an attestation

Authenticity: Because the attestation is signed by the attester using their wallet, the attestation record can be verified as authentic.

Non-transferable: Attestations are tied to a specific wallet address and cannot be transferred to another address.

Revocable: Attestations can be designed to include the option of revocability, allowing the attester to revoke the attestation if necessary.

Expireable: Attestations can have a predetermined expiration date, making them ideal for time-based credentials or membership subscriptions.

Immutable: Once an attestation is made, it cannot be altered or deleted, ensuring the attestation remains trustworthy and verifiable.

Transparent: On-chain attestations are easily verifiable and transparent, as anyone can verify the authenticity of the attestation. Off-chain attestations retain the attestation data and authenticity but offer greater privacy.

Composable: Multiple attestations can be combined and linked to create a larger picture of the information being attested to. Think of attestations as lego blocks for trust.

Versatile: Attestations can be used in a wide range of use cases, from supply-chain provenance to ticketing systems and voting systems, oracles, and beyond.

Interoperable: Attestations are interoperable between different platforms and systems, making it easier for organizations and individuals to share their verified credentials and reputations across ecosystems.

Batchable: Attestations can be made in batches, allowing for multiple attestations to be made at once, reducing the administrative overhead involved in the verification process.

Badgeless: With attestations, you do not need custom art or graphics like most NFT or SBT solutions. However, you can easily use the attestation data and build a pretty UI if you want.

On or off-chain: Attestations can be made on-chain, recorded on a blockchain, or off-chain. The choice between on-chain and off-chain depends on the level of transparency and privacy required for the particular use case.

Using attestations as verifiable credentials

Attestations have several use cases and are a great alternative or complementary solution for VCs. For example, you might authenticate access to your DAO with an NFT and then control roles and memberships with attestations instead of additional NFTs or SBTs.

Attestation Use Cases

Self-sovereign identity: Individuals attest to and control specific attributes of their identity, social accounts, and more. This can be done on or off-chain.

Reputation systems: Community members can make attestations to vouch for others in their network, including information such as trustworthiness, reliability, and behaviors.

Social graphs: Users can make attestations to create a verified network of people they know and interact with, allowing them to build their circle of influence.

Authentication into a DAO or community group: DAOs can make attestations to grant access to a specific address, allowing them to join a community instead of minting and distributing NFTs.

Community roles & authorizations: Community managers can use attestations to assign roles and permissions to users within the community. This can include information such as the user's level of access, responsibilities, and allowed actions.

Voting systems on or off-chain: Builders can use attestations to verify member eligibilities and identity to ensure that only authorized people are able to participate in the voting process. Further, attestations can be used to cast votes and provide a more transparent and suitable record of the voting results on or off-chain.

Employment statuses & verifications: Employers can use attestations to verify the work history of employees or DAO members, providing a trusted and verifiable record of their employment.

Credentials, certifications, and licenses: Schools, dapps, certification boards, and other organizations can use attestations to verify the credentials, licenses, and certifications of individuals. These attestations can have expiration dates and can be revoked if necessary.

Quests & badges: Dapps can use attestations to confirm the completion of quests, courses, or other achievements by a user's wallet.

Content authenticity & accuracy: Both users and third-party organizations can use attestations to verify the authenticity and accuracy of content online, providing a trusted source of information for others.

Proof of X: Proof of anything. E.g. An event organizer attesting to the attendance of someone or a financial institution attesting to the proof of funds of an individual and more.

Example of a DAO attesting to the role of a specific user:

A DAO can utilize attestations to assign roles and permissions to community members. This testnet example is showing a mock DAO is shown making an attestation to a User, recognizing their role in a guild.

The attestation specifies the DAO as the "From" address, the User as the "To" address, and includes details such as the guild name and role ID. It is further validated by the DAO's signature and includes a timestamp for when the role was granted, providing a verifiable and transparent record.

If the User changes their role or departs from the community, the DAO can revoke the attestation with ease which would have its own unique timestamp, leaving a clear and verifiable record of the change.

Going beyond VC use cases with attestations.

Attestations have the potential to revolutionize many industries and create new solutions to age-old problems. Beyond identity-based solutions, attestations can be applied to a wide range of use cases, including:

1. Supply Chain Provenance: Attestations can verify the origin and authenticity of products, promoting transparency and security in the supply chain. This can help prevent fraud and counterfeiting, and increase consumer trust in the products they purchase.

2. Political Transparency: Attestations can be used to verify and track political campaign donations and spending, promoting transparency and accountability in political campaigns. This can increase public trust in the political process and reduce the risk of corruption.

3. Content Authenticity: Creators can use attestations to prove the authenticity of their work, from digital art to blog posts, research reports, and more. Attestations by 3rd parties can also verify the accuracy of the information, increasing credibility for the creator and trust for consumers.

4. Voting Systems: Attestations can be used to conduct secure, transparent, and tamper-proof voting processes. This can increase voter confidence and ensure that election results are accurate and fair.

5. Ticketing: Attestations can be used for ticket verification, ensuring that only authorized individuals have access to events. This can reduce the risk of ticket fraud and scalping, and increase the efficiency of ticket management.

6. Proof of X: Attestations can be made by various third-party entities to provide verifications and proof of anything, such as proof of funds, attendance, skills, personhood, nationality, authenticity, and more. This can streamline many processes and increase the accuracy and efficiency of data verification.

7. Off-chain oracles: Attestations can be used to provide off-chain data for smart contracts, increasing the functionality and versatility of decentralized applications.

8. Prediction markets: Attestations can be used to provide reliable data for prediction markets, increasing the accuracy and fairness of market outcomes.

9. Land Registries and Title Documents: Attestations can be used to verify land ownership and title documents, simplifying the transfer of property ownership and reducing the risk of fraud.

10. Health Records: Attestations can be used to store and verify health records, ensuring the privacy and security of sensitive information and increasing interoperability between healthcare providers, access to care, speed for claims, and more.

These are just a few of the many exciting use cases of attestations. As the technology continues to evolve and mature, it's likely that new and innovative solutions will emerge, further demonstrating the versatility and power of attestations.

A future outlook on verifiable credentials and decentralized identity

As blockchain adoption continues, VCs and decentralized identity are set to play a big role in the secure exchange of information and safeguarding your digital reputation.

1. Take more control of your data: One of the key benefits of VCs and decentralized identity is the potential to give individuals greater control over their personal information. With VCs, individuals can selectively share only the necessary information and have the assurance that their data is being stored securely. This shift towards user-owned data will allow individuals to have more control over their personal information and reduce the risk of data breaches and unauthorized access.

2. Abstraction of your identity: The use of VCs also has the potential to change the way we think about our digital identity. Currently, individuals often use a single digital identity across multiple platforms, but in the future, the abstraction of identity could allow individuals to use different VCs for different roles they play in life. For example, a person may use one verifiable credential for work purposes, and another for personal purposes. This shift will enable individuals to maintain their privacy and security while still being able to participate in various aspects of their digital lives.

3. Better UX with your digital identity: As the technology evolves, the user experience of accessing, managing, and sharing VCs is expected to become more intuitive and user-friendly. This will increase the overall adoption and use of the technology.

4. Expect further integrations with existing platforms: VCs and decentralized identity are likely to become more integrated with existing systems (web2 & web3) and platforms, making it easier for individuals and organizations to utilize the technology within their existing infrastructure.

5. Security and decentralization will be favored: As technology advances, VCs and decentralized identity systems will enhance security, protecting sensitive information and reducing the risk of breaches and fraud. The shift towards decentralization will also reduce dependence on centralized identity providers and further leverage attestations to enhance identity.

How to get started with Attestations

Getting started with attestations is easier than ever, with new technologies like the Ethereum Attestation Service and L2s starting to explore this market.

The first step is to identify where greater trust and authenticity can improve your projects. This could be around the users in your system, but can also extend beyond user authenticity to any type of verification process or area where trust is needed. Take some time to consider what information needs to be attested to and how it can benefit your project. From there, you can start exploring the various attestation services and technologies available, and choose the one that best fits your needs and requirements.

Ethereum Attestation Service

EAS is the recommended way to start your attestation journey. The contracts are elegantly simple and full of utility.

EAS is a public good for making attestations about any topic, on-chain or off-chain. It is engineered to serve as the base layer for attestations enabling a more interoperable and composable attestation future.

It’s completely open-source, permissionless, tokenless, and free to use. EAS comes with an attestation explorer (similar to Etherscan) and you can even make attestations and build your own schemas using a no-code solution on the explorer site.

Ethereum Attestation Service

Open-source public good for making attestations on or off-chain.

https://attest.org

Ethereum Attestation Service - Explorer

EAS enables anyone to create and validate onchain and offchain attestations on Ethereum. Explore attestations, schemas, and transform online trust.

https://easscan.org

Ethereum Attestation Service

Make attestations about anything onchain or offchain. - Ethereum Attestation Service

https://github.com

Attestation Station on Optimism

The Attestation Station is a smart contract for attestations that operates on Optimism. Its main objective is to provide an open and easily accessible platform for developers creating applications based on reputation. By allowing anyone to make attestations about addresses, it builds a vast library of both qualitative and quantitative data, which can be utilized across the OP ecosystem.

https://community.optimism.io/docs/governance/attestation-station/#

Conclusion

As the world becomes increasingly reliant on digital solutions, verifiable credentials and attestations are playing a crucial role in building trust and ensuring the accuracy of information.

It's important to remember that ERC-721, SBTs, and Attestations are not necessarily competitive solutions, but rather complimentary or compatible depending on the use case.

Attestations are still in their early days and there is a lot of room for growth and innovation. The opportunities are limitless, and we encourage everyone to start exploring and experimenting with attestations to see what new solutions they can create. Whether you're a builder, a user, or simply curious, now is the time to start discovering the potential of this exciting technology.

Stay in touch

Twitter: https://twitter.com/eas_eth