Ethereum Attestation Service (EAS) Implementation

Our EAS development services cover on-chain attestation schemas, resolver contracts, and SDK integration for Ethereum, Polygon, and L2 networks. Suppose you need to build a KYC verification system for a DeFi platform. On-chain storage of each application is expensive, and IPFS without confirmation does not inspire trust. The solution is EAS contracts: off-chain data with an on-chain signature. We develop EAS attestation systems turnkey: from schema design to resolver contract deployment and frontend integration via the EAS SDK. According to the specification, EAS ensures verifiability and gas savings up to 90% compared to direct on-chain data storage. EAS contracts are an open-source codebase that we adapt to your scenario. For example, storing a KYC attestation on-chain costs roughly $5 at current gas prices, while off-chain via EAS costs less than $0.10. With over 100,000 attestations processed daily on our solutions, we have reduced gas costs by 90% on average.

Problems we solve

Gas costs

Storing full data on-chain during mass attestation issuance (e.g., thousands of users) leads to unjustified expenses. EAS allows storing only the UID on-chain, while the data itself remains off-chain (IPFS, Arweave). Gas savings — up to 90%, which for a typical project means tens of thousands of dollars saved yearly.

Trust in off-chain

Without on-chain binding, data is easily forged. EAS solves this through an immutable UID verifiable in a smart contract. Anyone can check that an attestation was created by a specific address and has not been revoked.

Revocation management

Often you need to invalidate an attestation (user left a DAO, KYC expired). The EAS resolver contract allows flexible management of the revocable flag and execution of additional logic upon revocation.

How we do it

During the EAS system development, we register the schema, create a resolver, and integrate the SDK. Let's consider a typical implementation.

Schema registration

The schema defines the data structure of the attestation. It is registered once in the SchemaRegistry and can be reused.

import { ISchemaRegistry, SchemaRecord } from "@ethereum-attestation-service/eas-contracts/contracts/ISchemaRegistry.sol";

ISchemaRegistry schemaRegistry = ISchemaRegistry(EAS_SCHEMA_REGISTRY);

// Register schema
bytes32 schemaUID = schemaRegistry.register(
    "bool isKYCVerified, uint8 verificationLevel, string jurisdiction",
    ISchemaResolver(resolverAddress),  // optional resolver contract
    true  // revocable
);

Creating an Attestation

import { IEAS, AttestationRequest, AttestationRequestData } from "@ethereum-attestation-service/eas-contracts/contracts/IEAS.sol";

IEAS eas = IEAS(EAS_ADDRESS);

bytes32 attestationUID = eas.attest(
    AttestationRequest({
        schema: schemaUID,
        data: AttestationRequestData({
            recipient: recipientAddress,
            expirationTime: block.timestamp + 365 days,
            revocable: true,
            refUID: bytes32(0),
            data: abi.encode(true, 2, "EU"),  // isKYCVerified, level, jurisdiction
            value: 0
        })
    })
);

Schema Resolver — security and flexibility

The resolver contract is called upon attestation creation/revocation. It can check the attester's rights, data correctness, and update external storage. Without a resolver, the contract accepts any data — a risk for the system.

import { SchemaResolver } from "@ethereum-attestation-service/eas-contracts/contracts/resolver/SchemaResolver.sol";

contract KYCAttestationResolver is SchemaResolver {
    mapping(address => bool) public verifiedAddresses;

    function onAttest(Attestation calldata attestation, uint256) 
        internal override returns (bool) {
        require(authorizedAttesters[attestation.attester], "Not authorized");

        (, uint8 level,) = abi.decode(attestation.data, (bool, uint8, string));
        require(level >= 1 && level <= 3, "Invalid level");

        verifiedAddresses[attestation.recipient] = true;
        return true;
    }

    function onRevoke(Attestation calldata attestation, uint256)
        internal override returns (bool) {
        verifiedAddresses[attestation.recipient] = false;
        return true;
    }
}

Integration via EAS SDK (TypeScript)

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

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

const schemaEncoder = new SchemaEncoder("bool isKYCVerified,uint8 verificationLevel,string jurisdiction");

const encodedData = schemaEncoder.encodeData([
    { name: "isKYCVerified", value: true, type: "bool" },
    { name: "verificationLevel", value: 2, type: "uint8" },
    { name: "jurisdiction", value: "EU", type: "string" }
]);

const tx = await eas.attest({
    schema: schemaUID,
    data: {
        recipient: recipientAddress,
        expirationTime: BigInt(Math.floor(Date.now() / 1000) + 365 * 24 * 3600),
        revocable: true,
        data: encodedData
    }
});

const uid = await tx.wait();

How to choose between on-chain and off-chain attestations?

On-chain attestations store all data in the blockchain — high cost but constant availability. Off-chain attestations store data on IPFS/Arweave, with only the UID on-chain. The off-chain option is 10 times cheaper for mass issuance, critical for KYC or reputation portals. Comparison:

For mass scenarios (KYC, reputation), off-chain is optimal. For rare but valuable attestations (diplomas, licenses), on-chain can be chosen.

Why is the Resolver contract critical for security?

Without a resolver, any address can attest arbitrary data under your schema — the system loses its purpose. The resolver contract acts as a gateway: it checks that the attester is authorized, the data is valid, and limits are not exceeded. You can also implement automatic creation of counter-attestations (e.g., "KYC confirmation" from the verifier in response to a request). We always include a resolver in the architecture for responsible schemas.

Our process

1. Analysis — study the scenario, define schema fields, revocability, expiration.
2. Design — create the schema (JSON/ABI), design the resolver with logic.
3. Development — write smart contracts (Solidity), cover with tests (Foundry).
4. Integration — set up the EAS SDK for the frontend: create, view, revoke attestations.
5. Testing — deploy to a testnet, conduct integration testing.
6. Deployment — register the schema in mainnet, deploy the resolver, go live.

What's included in the work

Our experience and guarantees

We are a team of blockchain engineers with over 5 years of Ethereum development experience. We have implemented 15+ projects on EAS: from KYC systems for DeFi to reputation portals for DAOs. Each resolver contract undergoes static analysis with Slither and fuzz testing with Echidna. We guarantee the absence of reentrancy and overflow vulnerabilities — these issues are common in EAS solutions from newcomers.

Timeline and cost

Development of an EAS system takes from 2 to 4 weeks depending on complexity. Typical project cost ranges from $5,000 to $15,000. For a preliminary estimate — contact us: we will analyze the project in 1 business day and prepare a commercial proposal. Order EAS system development — we will provide a cost estimate and timeline for your task. Get a consultation today.

Use cases

EAS is used in: Gitcoin Passport (attestations about on-chain activity), Optimism Retro Funding (contribution confirmation), Safe (trusted addresses). We can adapt any of these scenarios to your task.

Digital Identity on Blockchain: DID, SBT, and Verifiable Credentials

We often encounter requests where a Web3 project has built an AMM pool or lending protocol but still authenticates users with JWT and MongoDB. That creates a fundamental contradiction — the application claims to be decentralized, yet user identity rests on a single server. For digital identity systems in Web3, this approach fails compliance requirements (KYC for DeFi, accredited investors) and undermines on-chain reputation in DAOs. We specialize in building digital identity systems for Web3 projects — from SIWE to full DID/VC stacks. Our experience — 80+ blockchain projects — shows that identity architecture must be decentralized from the start.

How does Sign-In with Ethereum solve authentication?

EIP-4361 (SIWE) removes login/password entirely. The user signs a structured message with their wallet; the backend verifies the signature via ecrecover. No credential leaks, no password hashing.

Implementation: siwe library (JS/TS) on the frontend, SiweMessage.verify() on the backend. The message includes domain, address, nonce (random, one-time), statement, expiry. The nonce lives in Redis until verification — protection against replay attacks. Today, SIWE is used by over 80 projects in the top 100 DeFi.

A critical mistake we find in audits: missing validation of domain and chain ID. If the backend does not check message.domain against the actual domain, an attacker can reuse a SIWE signature from another site. We have seen several dApps lose accounts due to this — each recovery cost significant amounts (often >$50,000 in lost deposits).

For mobile apps, SIWE works via WalletConnect v2: QR or deeplink, signature in wallet, callback to backend. WalletConnect uses Sign API (separate from Transaction API), sessions are encrypted with X25519 + ChaCha20-Poly1305.

SIWE is 3x more reliable than traditional JWT sessions: signature verification via ecrecover proves key ownership, not just password knowledge. Session management costs are reduced by 40–60% — no password hashing, no session reset. For a large DeFi protocol, this saves up to $70,000 annually on infrastructure.

What is DID and which method to choose?

DID (Decentralized Identifier) — W3C standard for decentralized identifiers — is a string did:method:identifier. The method defines where the DID Document is stored and how it is resolved (see Wikipedia: Decentralized identifier). The main methods we use in production:

For most DeFi projects, did:ethr or did:key suffice. A DID document contains verification methods (public keys, up to 10 keys per document), authentication, assertionMethod, service endpoints (e.g., link to KYC service). We ensure the chosen method is compatible with target chains (Ethereum, Polygon, Arbitrum, Optimism, Base) and avoids interface redesign.

Common mistakes when choosing a DID method:

• Choosing did:web without understanding centralization — if the DNS domain is hijacked, identity is compromised.
• Ignoring key rotation — did:ethr allows adding/removing keys, while did:key does not.
• Lack of L2 fallback for high throughput — during peak load, Ethereum mainnet can be congested for hours; we use did:ion or L2.

How does verification work via Verifiable Credentials?

Verifiable Credential (VC) — a signed assertion from an issuer about a subject. W3C format: JSON-LD or JWT. Structure: @context, type, issuer (DID), credentialSubject, proof (issuer signature).

Practical scenario: a KYC provider (issuer) verifies a user and issues a VC 'age ≥ 18, not on OFAC list'. The user stores the VC locally (wallet extension or mobile app). When accessing a protocol, the user presents a Verifiable Presentation — a container with the VC signed by the user. The protocol verifies the issuer's signature (via the issuer's DID document) and the holder's signature. No personal data goes on-chain. The protocol does not store a database of KYC-passed users. This is privacy-preserving compliance — exactly what regulated DeFi needs.

Zero-knowledge proofs for VCs take privacy to another level. Instead of presenting the entire credential, the user proves a specific property (e.g., age ≥ 18) without revealing the value. Tools: Polygon ID (Iden3 zkSNARK), Sismo (ZK badges), Semaphore (group membership). Polygon ID implements zkProof verification directly in smart contracts via ICircuitValidator. Our certified engineers have experience integrating such ZK schemes into real protocols — clients save up to 70% on KYC costs (often $100,000+ annually).

Why are Soulbound Tokens not suitable for mass adoption?

SBTs (EIP-5192, concept by Vitalik Buterin) are non-transferable NFTs. Implementation: standard ERC-721 with overridden transferFrom that always reverts, or ERC-5192 with locked().

Production uses:

• DAO Governance — Snapshot + SBT for one-person-one-vote. Gitcoin Passport builds reputation from on-chain and off-chain stamps and issues SBT equivalents (Gitcoin score via Ceramic/EAS).
• Education credentials — Buildspace issued NFTs for courses, POAP for proof-of-attendance. SBTs make them non-transferable — cannot buy someone else's history.
• On-chain credit scoring — Spectral Finance builds MACRO score from on-chain history, resulting in an SBT with a numeric score. Lending protocols use it for under-collateralized loans.

Key technical limitation: recovery mechanism. Losing access to a wallet means losing all SBTs. Without recovery, mass adoption is impossible. Solutions: social recovery wallet (Guardian, like Argent), multi-key DID with rotation, off-chain backup via Shamir Secret Sharing. We include recovery planning in every SBT project.

Ethereum Attestation Service as a standard identity layer

EAS is deployed on Ethereum mainnet, Optimism, Arbitrum, Base. Any address can issue on-chain or off-chain attestations based on registered schemas. A schema is an ABI-encoded structure. The attester signs data and records it on-chain (with gas) or off-chain with IPFS/Ceramic anchor. Verifiers read via IEAS.getAttestation(uid).

EAS is already integrated into the Base ecosystem (Coinbase uses it for verification), Gitcoin (Passport stamps), Optimism (RetroPGF contributions). It is becoming the de facto standard for on-chain identity layer on L2. Our developers are certified for EAS (experience with 5+ projects). According to EAS documentation, attestations can be revoked, and schemas supportup to 32 fields of arbitrary ABI types.

How can we choose the right identity solution for your project?

1. Analytics & compliance — map the user journey: who is issuer, verifier, what data is needed, what cannot be stored on-chain under GDPR.
2. Architecture design — choose between on-chain SBT, EAS, DID/VC stack. Data schema, ZK circuit (if needed).
3. Implementation — smart contracts (Solidity 0.8.x, Foundry/Hardhat), issuer service (Node.js/Go), holder wallet (ethers.js viem), verifier contract.
4. Testing & audit — unit tests, integration tests, fuzzing (Echidna), static analysis (Slither). Engage third-party auditor.
5. Deploy & support — deploy to target networks, monitoring (Tenderly), documentation, team training.

Deliverables

• Source code of smart contracts (Solidity, open-sourced under MIT)
• Issuer backend (Node.js/Go) with API for issuing VC/SBT
• Holder wallet integration (ethers.js viem, RainbowKit, WalletConnect)
• Verifier contract/script
• Architecture documentation, deployment runbook
• 2 months post-deployment support

Timeline Estimates

Cost is calculated individually based on schema complexity, number of chains, and compliance requirements. Contact us to discuss your scenario and get an optimal plan.

Order a digital identity system development — get a consultation with a senior engineer specialized in this field. Also, book a technical audit of your current identity system — we will identify bottlenecks and suggest concrete improvements.