Anonymous but Verified: Using the Ethereum Attestation Service (EAS) to Build Dev Trust on Base

The Web3 space has always been a double-edged sword when it comes to privacy. On one hand, pseudonymity is a core ethos of the cypherpunk movement — after all, Bitcoin itself was created by the most famous anonymous developer in history, Satoshi Nakamoto. On the other hand, the modern DeFi and token ecosystem is plagued by a severe trust deficit.

The numbers are hard to ignore. Crypto fraud losses reached $9.3 billion in 2024, according to the FBI. In that same year, over 410 security incidents cost the industry $2.013 billion, with DeFi representing 82.68% of all breaches. Rug pull scammers have industrialised their craft to a disturbing degree — Pump.fun, a token launchpad on Solana, saw 98.6% of its more than 7 million tokens classified as potential scams. And by 2025, developers using anonymous identities were behind an estimated 92% of successful rug pulls.

This creates an intense dilemma for legitimate builders. How do you establish trust and prove your competence without handing over your government ID, exposing your physical location, or risking your personal safety? How can communities confidently invest in a project without knowing the real-world name of the person behind the keyboard?

The answer lies in Trustless Dev Doxxing — leveraging the Ethereum Attestation Service (EAS) deployed on Base to build a robust, cryptographically verifiable developer identity that proves your track record without ever revealing who you are in real life.

The Web3 Trust Crisis: Why Anonymous Devs Struggle

The Stigma of the "Anon Dev"

In the early days of crypto, being an anon dev was the standard. It protected developers from regulatory overreach and real-world security threats. But as the industry expanded into smart contracts and decentralised applications, the barrier to launching a token dropped to near zero.

This lack of friction created serial scammers. A malicious actor could launch a token, market it heavily, drain the liquidity pool, discard the wallet, and repeat the process the next day with a fresh address. The term "anon dev" has heavily depreciated as a result.

The scale is staggering. In early 2025, the number of reported rug pull incidents actually fell 66% compared to the same period in 2024 — yet total losses surged to nearly $6 billion, compared to just $90 million in the prior year. Scams are becoming fewer but far more devastating. The average amount stolen per rug pull in 2025 reached approximately $510,000, and over 7 million wallets have now experienced a rug pull at some point.

Meanwhile, NFT rug pull losses alone totalled $450 million in 2024, a 35% increase year-over-year. Soft rug pulls — where founders drain liquidity slowly over time rather than all at once — rose by 33% between 2024 and 2025. The threat is actively evolving.

The Flaws of Traditional Doxxing

To combat scams, the industry swung to the opposite extreme: traditional doxxing. Platforms and launchpads began requiring developers to undergo Know Your Customer (KYC) procedures, submitting passports and utility bills to centralised third parties.

But traditional doxxing introduces significant risks:

Centralised Honeypots. KYC providers become prime targets for hackers. A breach at a third-party verification service exposes the developer's real-world identity to the dark web — exactly the scenario that pseudonymity was designed to prevent.

Physical Security. A developer managing a treasury of millions of dollars becomes a target for extortion or kidnapping the moment their physical identity and location are known.

Regulatory Uncertainty. In many jurisdictions, the legal framework for token creation is murky at best. Developers may wish to remain anonymous to avoid unwarranted legal harassment while still operating ethically and shipping working products.

What the Market Actually Demands

What investors and communities actually need is not a developer's legal name, but evidence of their competence and integrity. They want to know whether the developer writes secure Solidity, whether they have a history of locking liquidity, and whether their previous projects succeeded. This is the concept of a verifiable dev track record — and it can now be built cryptographically, without sacrificing privacy.

What Is the Ethereum Attestation Service (EAS)?

EAS is an open-source, permissionless, token-free public good infrastructure for making attestations on-chain or off-chain. An attestation is simply a digitally signed claim made by one entity about another entity, or about a specific piece of data.

Think of it as a digital notary stamp. In the real world, a university attests to your degree, a government attests to your driving ability, and a bank attests to your credit score. EAS brings that same dynamic to the blockchain — allowing anyone to attest to anything. The protocol is neutral, open, and deliberately minimal: it does not presuppose how it will be used or what schemas are appropriate for any given use case.

Two Core Smart Contracts

EAS operates through two elegant, composable smart contracts:

The Schema Registry Contract defines the structure of any claim. A schema might include a bool for SmartContractAudited, an address for TokenDeployed, and a uint256 for PeakMarketCapReached. Anyone can register a new schema for any use case, and those schemas are publicly available for the entire ecosystem to build on.

The Attestation Contract is where claims are actually issued. It records the attester's identity, the recipient's address, optional expiration, revocation status, and the underlying structured data defined by the schema.

There is also an optional Resolver Contract — a piece of custom logic that runs before or after an attestation is created. This opens the door to powerful, trust-enforced financial mechanics (more on this later).

On-Chain vs. Off-Chain Attestations

EAS supports both modes, giving developers flexibility depending on their privacy and cost requirements.

On-chain attestations are stored directly on the blockchain. They require gas but deliver the highest level of public verifiability and immutability. Smart contracts can programmatically read these attestations — for instance, a launchpad contract that only allows token launches from wallets holding a verified "Trusted Dev" attestation.

Off-chain attestations use the same EAS schemas but are not posted to the blockchain. They are signed using EIP-712 signatures and can be shared via a URL, QR code, or API. They cost zero gas and are highly privacy-preserving, while still being fully cryptographically verifiable by anyone who receives the data.

The Transitive Trust SDK

One of EAS's most significant recent milestones is the release of the Transitive Trust SDK, shipped as part of the project's ongoing development milestones tracked through Karma GAP. The SDK allows developers to programmatically traverse chains of trust — enabling a system where trust is not just a single attestation from one entity, but a composable web of verified relationships. If Entity A trusts Entity B, and Entity B attests to Entity C, the SDK provides tools to calculate and express the resulting trust score transitively. This moves EAS from a simple credentialling tool into a primitive for building sophisticated reputation graphs.

The Perfect Match: EAS on Base

While EAS is deployed on Ethereum Mainnet and several other Layer-2 networks — including Optimism and Arbitrum — building your developer identity on Base offers distinct advantages.

Cost-Effective Reputation Building

A comprehensive verifiable track record requires many attestations over time. Doing this on Ethereum Mainnet would quickly become prohibitively expensive. Because Base is an Optimistic Rollup settling on Ethereum, transaction fees are fractions of a cent, making it practical to build a highly granular, continuously updated on-chain reputation without significant financial friction.

Coinbase's Institutional Endorsement

Base has a unique relationship with Coinbase, one of the most regulated and trusted institutions in crypto. Coinbase was the first major institutional third party to deploy on-chain attestations via EAS on Base — a product called Coinbase Verifications. The service, launched in November 2023, allows users to attest their Coinbase account and country of residence on-chain.

Coinbase Verifications uses a dedicated schema (0xf8b05c79f090979bf4a80270aba232dff11a10d9ca55c4f88de95317970f0de9 on Base), and all Coinbase attestations are issued from a single, verified attester address, making provenance trivially verifiable. Over 77,000 verified Coinbase users had participated in on-chain verification as of early 2024, with the number growing as more Base-native applications integrate attestation-gated features.

Critically, EAS on Base is a predeploy — it ships as part of the Base network itself (at 0x4200000000000000000000000000000000000021 for the attestation contract and 0x4200000000000000000000000000000000000020 for the schema registry). This means the infrastructure is native to the chain, not an afterthought.

Basenames and Onchain Identity

In mid-2024, Base launched Basenames — human-readable .base.eth ENS-compatible identifiers for wallet addresses. Crucially, Basenames natively integrated EAS attestation keys into their text records. Discount eligibility during the Basename launch was partially determined by verifying on-chain EAS attestations including Coinbase Verification status and NFT ownership. This signals that EAS is becoming foundational infrastructure for user identity on Base, not just a peripheral feature.

Deep DApp Ecosystem

Base has rapidly emerged as a hub for DeFi activity, consumer applications, and meme tokens. Having your attestation data native to Base means it can be synchronously read by the exchanges, lending protocols, and launchpads operating on the same network — no cross-chain bridging of trust data required.

How Trustless Dev Doxxing Works in Practice

So how does a developer actually achieve trustless doxxing — proving they are the architect of a successful past project without linking their old and new wallets on-chain?

The Core Problem: Compartmentalisation Without Opacity

Imagine a developer — call them ShadowDev. Two years ago, ShadowDev used Wallet A to deploy a highly successful DeFi protocol that peaked at a $50M market cap. Wallet A is now cold. ShadowDev wants to launch a new project using a fresh identity, Wallet B, for operational security.

If ShadowDev simply claims to be the original developer, no one will believe them. If they send a transaction from Wallet A to Wallet B to prove ownership, blockchain analytics firms will permanently and publicly link the two wallets — destroying the compartmentalisation they were trying to maintain.

The EAS Solution: Third-Party Attestation

Here is how EAS solves this elegantly:

The Trusted Auditor. ShadowDev approaches a reputable third-party auditing firm or a trusted community multisig that uses EAS.
The Private Proof. Through a secure, encrypted off-chain channel, ShadowDev provides the auditor with a cryptographic signature generated by the private keys of Wallet A. This proves — beyond any doubt — that they control the wallet that deployed the original protocol.
The Attestation. The auditor verifies the signature privately. They then issue an on-chain EAS attestation to Wallet B, using a schema designed for this purpose. The attestation does not mention Wallet A. It states only what matters: that the operator of Wallet B has successfully launched a protocol that exceeded a $50M market cap.
The Result. Wallet B now holds an immutable, cryptographically verified attestation from a reputable auditing firm. Investors can independently verify the auditor's signature on the attestation. Trust is established. ShadowDev's real identity remains unknown, and the on-chain link between Wallet A and Wallet B remains broken to the public.

Advanced Privacy: Merkle Trees and Private Data Attestations

EAS also supports Private Data Attestations, which use Merkle trees for even more granular privacy control.

A developer can take hundreds of data points — lines of code contributed, bugs patched, previous multisig participations, TVL managed — hash them into a Merkle tree, and post only the Merkle root hash on-chain as an EAS attestation. Later, if they need to prove a specific credential to a grant committee or launchpad, they provide a Merkle proof off-chain. The committee verifies that the specific credential hashes up to the public root stored on EAS — proving the credential is valid without exposing any of the other underlying data. Crucially, this is not theoretical: EAS's on-chain attestations encoded using Merkle trees are a documented, actively used feature.

Step-by-Step Guide: Building Your Verifiable Dev Track Record

Step 1: Define Your Reputation Vectors

Before writing a single line of code, decide what makes you trustworthy. Are you a Solidity security specialist? A frontend engineer who has shipped production DApps? A DAO operator who has managed a treasury? Identify the specific, measurable metrics that prove your competence in your domain.

Step 2: Use Existing Schemas or Register New Ones

Visit the EAS Explorer for Base — base.easscan.org — and search the schema registry. The community has already registered schemas for common developer credentials. If your specific credential does not have a schema, registering one is straightforward. For example:

bool noCriticalVulnerabilities, uint256 tvlSecured, string protocolName

Schema registration is a one-time on-chain transaction and permanently available to the entire ecosystem.

Step 3: Accumulate Attestations from Trusted Sources

An attestation is only as valuable as the entity issuing it. Self-attestations are meaningless for trust-building. You need third-party endorsements:

Smart Contract Auditors — Firms like CertiK, OpenZeppelin, or Code4rena should issue an EAS attestation alongside their PDF report. This makes the audit result composable and on-chain readable.
Grant Programs — If you deliver on a grant from Arbitrum DAO, Optimism RetroPGF, or similar ecosystems, request that the committee attest to your milestone completion via Karma GAP (the Grantee Accountability Protocol). Karma GAP is already trusted by Arbitrum, Gitcoin, Optimism, Octant, Celo, Scroll, and Lisk, and it stores all milestone and progress data as EAS attestations on-chain. In early 2025, Karma GAP also integrated with Giveth, allowing donors to see verified grantee progress data before committing funds.
Bug Bounties — When you claim a bug bounty on a platform like Immunefi, request an on-chain attestation of the severity level and successful patch.
Previous Collaborators — Past multisig co-signers, protocol governance participants, and client teams who can vouch for your work history.

Step 4: Implement Resolver Contracts for Automated Trust Enforcement

EAS Resolver Contracts allow trust to be woven directly into financial logic. Rather than asking investors to trust your claims, you can make trust a mathematically enforced condition.

A developer building a token presale contract could implement a resolver that checks: "Investors can only deposit funds into this presale if the developer's wallet holds an active EAS attestation from a recognised auditing firm confirming no malicious code." Trust is no longer a narrative — it is a programmatic requirement.

Step 5: Display Your Trust Profile

Query the EAS GraphQL API or the Base EAS indexer to pull your wallet's attestation history. Display a Trust Profile directly on your project's website or DApp interface, with direct links to base.easscan.org so users can independently verify every cryptographic signature. Coinbase's OnchainKit provides a getAttestations function that makes querying EAS attestations from a wallet on Base a straightforward, single-function call — making integration into any frontend trivial.

Real-World Use Cases: The Broader Ecosystem Impact

Attestation-Based Grant Tracking and Portable Reputation

Major DAOs distribute millions of dollars in grants, but tracking accountability for pseudonymous teams has historically been difficult. Karma GAP addresses this directly. When a team receives a grant, all project milestones and progress updates are stored as EAS attestations. This data is permanently verifiable on-chain and — critically — portable. A pseudonymous team that successfully delivers for the Arbitrum DAO can point to their EAS-backed GAP profile when applying for a subsequent grant on Base or Optimism. The cold-start trust problem for anonymous developers dissolves.

Decentralised Hiring and Freelancing

The Web3 gig economy is massive, but hiring pseudonymous smart contract developers carries enormous risk. With an EAS-based developer identity, a freelancer can present a portfolio of attestations from previous clients confirming their reliability, code quality, and delivery track record — creating a meritocratic, identity-blind professional economy.

Sybil Resistance in Airdrops

Airdrop farming — spinning up thousands of wallets to extract value — has drained billions from genuine communities. Projects can filter Sybil attackers by requiring users to hold specific EAS attestations (such as "Active Contributor" or "Humanity Verified") before claiming. Combining multiple attestation types into a holistic trust score ensures value flows to legitimate participants rather than bot farms.

Continuous, Living Reputation

Traditional trust evaluation is a one-time event — you read an audit report before a launch and form a judgment. Because EAS attestations can be issued, updated, and revoked at any time, trust becomes a continuously updated metric. If a developer acts maliciously, an attesting body can revoke their "Trusted Dev" attestation, immediately signalling to the entire ecosystem that the individual's reputation has been compromised. Trust earned is also trust that can be lost — which is precisely the kind of accountability the market has been asking for.

The Road Ahead

The rise of Decentralised Identity (DID) systems is expected to curb anonymous scam launches by approximately 30% by 2026, according to industry analysis. EAS is one of the most production-ready implementations of this infrastructure available today — a public good with no token, no rent-seeking, and no central controller.

The EAS team continues active development. Alongside the Transitive Trust SDK, active work is underway on expanded schema developer tooling and greater awareness among builders. The protocol is deployed and live on Ethereum Mainnet, Base, Optimism, Arbitrum, Polygon, and testnets including Sepolia — and is already embedded in the institutional fabric of Base via the Coinbase Verifications predeploy.

Conclusion

The era of blind trust in anon devs is over, but the necessity for developer privacy remains. We have entered a new paradigm where privacy and accountability are no longer mutually exclusive.

Through Trustless Dev Doxxing, enabled by the Ethereum Attestation Service on Base, developers can step out from the shadow of suspicion without sacrificing personal security. A verifiable dev track record, woven together from cryptographically signed attestations issued by auditors, grant committees, clients, and ecosystem participants, is the most powerful resume in the Web3 world.

It does not ask your community to believe you. It proves — mathematically, immutably, and anonymously — that you have already delivered.

Further reading and developer resources:

EAS Documentation: docs.attest.org
Base EAS Explorer: base.easscan.org
Coinbase Verifications on GitHub: github.com/coinbase/verifications
Karma GAP: gap.karmahq.xyz
EAS Transitive Trust SDK: github.com/ethereum-attestation-service/transitive-trust-sdk