EAS is shaping up to be an early open-source onchain primitive for DID / Attestations
What is it?
EAS is an open-source Ethereum-based smart contract infrastructure for making attestations onchain or offchain. EAS can be accessed via onchain (via direct contract calls) or offchain (via indexers that power easscan.org)
It is comprised of three components:
Schema: The definition set of a data structure. It can be any type of data structure such as a number, string, address, etc. A simple example is a schema with a boolean (True/False) field for “AllowedToDrive”.
Attestation: The attestation by the issuer/attester’s ETH address to the recipient/user’s ETH address – an attestation must be based on a schema. An example is issuer is “government.eth”, recipient is “0x…”, data is “AllowedToDrive == True”, expiration date of 2 years is set after attestation is created. Each attestation has a unique ID.
Revocation: Issuer registers a revocation against a specific attestation. The attestation is deemed no longer valid. An example is “government.eth” revokes the attestation for “0x…”
EAS can support both onchain and offchain data structures.
On the onchain side – it’s a publicly verifiable data in a smart contract where the issuer and user are ETH addresses.
On the offchain side – offchain attestations can be generated as a signed piece of data (think conceptually like a json file) and exists offchain, though it may be posted publicly onchain or IPFS. Data can be shared privately thru use of merkle proofs, and potentially ZK.
What is an example in practice?
NewCo wants to attest “employee status” to a verified user’s wallet
NewCo is an issuer/attester (NewCo.eth), verified user is the recipient (ryan.eth) → NewCo.eth creates attestation on schema “IsEmployee” boolean with a value of "True" for ryan.eth
User is no longer employed or otherwise and now NewCo must revoke the attestation → NewCo.eth invokes revoke function on the original attestation, ryan.eth is no longer “IsEmployee==True” onchain
What’s novel vs existing solutions?
If we view EAS as a form of onchain identification, we might compare it to existing concepts such as NFTs and SBTs (soulbound tokens). They differ mainly in the ability to add expiration / revocation as well as composability:
NFTs – ERC standard that defines an object that is transferable (secondary markets) but not revocable – the closest concept being for a user to “burn” their NFT by sending to 0x…000 address
SBTs – modification of an NFT where the object is non-transferable (forever tied to address) and therefore if a wallet is compromised, it is difficult to clawback.
Both have limitations as well because standards would have to be modified to support more complex data schemas and required methods. The modifications would need to add other metadata like expiration / revocation – which would become a different standard beyond ERC721 / ERC1155.
What is the EAS value proposition?
EAS is purpose-built for attestations. Because attestations are immutable, non-transferrable, and can be expired/revoked – it achieves authenticity and provenance because we get a snapshot of the past, and present.
EAS is simple and flexible. Because it does not pre-assume any schema/data the issuer is attesting, issuers can “bring their own data.” For example, Gitcoin Passport transitioned from issuing and storing attestations on their own to then migrating to EAS on Optimism.
EAS is composable. Because there exists the concepts of “hooks” on attestations, a different smart contract can perform certain actions and subsequent workflows upon the attestation logic (ex. collecting payments or triggering other actions).
EAS is permissionless. The permissionless nature allows anybody to attest against anything and all the data can be shared among the ecosystem vs custom standards. As a result, the ecosystem avoids data fragmentation and proprietary data storage.
Who is adopting it?
See EAS Dune Dashboard for full traction
Optimism AttestationStation v1: Optimism has announced EAS as the attestation primitive. There is high community usage of the attestation infrastructure leading to the highest set of numbers. For example, Gitcoin Passport comprises almost ~90% of attestations
Arbitrum: Devfolio, a builder community / hackathon organizer, uses EAS as a way to build a voting system for their online hackathons, where attestations are used to vote on projects to win the prize pool and give kudos (tips) to fellow community members.
ETH Mainnet: Gas cost is prohibitive on mainnet and thus is likely why the # of attestations is low compared to others
Base: Launch just went live so numbers are new
What are the future use-cases / why should we care?
Macro DID Thesis: DID (“Decentralized Identity”) is basically “wallets/keys + data.” For example – Worldcoin is a smart contract wallet + retina data. Onchain-generated data will grow as web3 communities mature + decentralized social graphs are created. Also, more offchain-generated data will be mapped to wallets, EAS will be a key component of how it is represent onchain/smart contracts.
Ability to Import Data Silos: Given the flexibility and composability of EAS, we expect individual ecosystems to continue to converge. Similar to the Gitcoin Passport example mentioned above, web3 social graphs (Guild.XYZ, Farcaster, etc) may eventually be ported onchain to lower the cost of data verification, introduce new use-cases, and grow the data verification economy.
Strategic Adoption: As large players are entering web3, there will be a key question on how they bring existing data and map it to wallets. If they decide on an onchain / public approach, EAS will be the tool that a 1st-party issuer will explore. We may also see projects that have utilized SBTs transition to EAS eventually as they mature in community management.
Tie-in to ENS: The provenance of the issuer is important, and thus if the issuer can tie it back to their ENS name, it provides a powerful effect of combining primitives. Example is “DMV.eth” signing attestations. Also imagine a “blue check mark” added to your ENS if you have been attested on a specific EAS schema.