Onchain Identity Attestation: The Reference We Wish Existed

An onchain identity attestation is a cryptographically signed claim, made by one party about a subject, that can be verified on a blockchain without trusting the party that stored it. That single sentence hides most of the arguments in the field. Who signs, what the claim asserts, where the signature lives, and how a verifier checks revocation are four separate decisions, and teams that collapse them into one usually ship something that breaks under audit. This pillar is the reference we wish existed when we started: it names the failure modes in onchain identity attestation up front, maps every question to the metric that proves or disproves it, and commits to a house position you can hold us to.

Key takeaways

• An onchain identity attestation separates four decisions: issuer, claim schema, storage location, and revocation path. Conflating them is the most common design error we see.
• The Ethereum Attestation Service runs on two contracts, is tokenless and free to use, and lets attestations reference other attestations by UID, which is why it has become the default substrate for onchain identity attestation.
• EIP-712, finalized on 12 September 2017 by Remco Bloemen, Leonid Logvinov and Jacob Evans, is the signing standard underneath most of this work. It binds a signature to a chain, a contract and a version, and it explicitly does not include replay protection.
• Regulation is arriving on a fixed clock: under Regulation (EU) 2024/1183, all 27 EU member states must issue a Digital Identity Wallet by December 2026, and obliged entities such as banks must accept it by December 2027.
• Our rule: put the claim offchain, anchor its hash onchain, and reserve fully onchain attestations for the small set of claims that a smart contract has to read during execution.

What an onchain identity attestation actually is

Start with the definition an answer engine can lift. An onchain identity attestation is a statement of the form issuer asserts predicate about subject, signed with the issuer's private key, structured against a published schema, and either written to a blockchain or hashed and anchored to one so any verifier can confirm it was not altered. The subject is usually an address or a decentralized identifier. The predicate is anything from passed KYC on this date to holds this credential to is a unique human.

The reason this matters is that identity on a public ledger is not a database row you own. It is a graph of claims that different parties make about the same subject, and the value of the graph depends entirely on who is willing to sign and who is willing to trust those signatures. A self-signed claim that you are accredited is worth nothing. The same claim signed by a regulated verifier, anchored so it cannot be backdated, and revocable when circumstances change, is worth a great deal. Every serious onchain identity attestation design is an argument about which signatures carry weight and how a verifier checks them cheaply.

The hub this pillar sits at answers one question for every entry beneath it: what is the smallest, most verifiable claim that solves the problem in front of you, and what does it cost to issue and to check? That is the charter. A wallet team asking whether to gate a feature, a compliance lead asking whether an attestation satisfies an auditor, a protocol asking whether to trust a reputation score, all reduce to that question. If you want the ground-level mechanics before the strategy, the identity walkthrough reference traces a single attestation from schema to verification.

The studio house position, and where we disagree with the field

Most published material on onchain identity attestation describes the surface and stops. The top search results agree that the topic matters and survey the primitives, but none of them commit to a dated benchmark, a named engagement, or a decision rule an operator could defend in a board meeting. That gap is the whole reason this hub exists. We would rather be specific and wrong than vague and safe, so here is the position.

Default to offchain attestations with onchain anchoring. The Ethereum Attestation Service supports both, and the offchain path costs no gas until you choose to anchor a hash. For the vast majority of identity claims, the verifier does not need the full claim sitting in contract storage; it needs proof the claim exists, was signed by the right issuer, and has not been revoked. Writing every attestation onchain is how teams turn a cheap system into an expensive one and leak subject data into a permanent public record at the same time.

Treat the schema as the product. An onchain identity attestation is only as portable as the schema it commits to. Teams that invent a bespoke schema for one integration create a claim no one else can consume, which defeats the point of putting it on a shared ledger. Reuse an existing schema before you register a new one. The attestation benchmarks entry publishes the numbers we hold ourselves to on schema reuse and verification latency.

Revocation is not optional and it is not free. A claim you cannot revoke is a liability the moment the underlying fact changes. The design cost of revocation, whether through a resolver contract, an expiry timestamp, or a revocation registry, belongs in the first architecture conversation, not the second launch. Where the field treats revocation as an advanced topic, we treat it as table stakes, and the identity anti-patterns reference catalogues what happens to teams that defer it.

The sub-topic map: the references under this hub

The hub decomposes onchain identity attestation into ten references across three tiers: topical entries that walk the mechanics, focal entries that decide one trade-off, and comparison entries that put two primitives side by side. Read them as a numbered playbook, not a glossary.

1. Identity walkthrough. The operator's read on how a single onchain identity attestation is issued, stored and verified end to end. Start here if you have never shipped one.
2. Attestation benchmarks. The dated numbers most teams miss: verification gas, issuance latency, and schema reuse rates across live deployments.
3. Consumer field report. What real users do when an identity flow asks them to sign, and where they abandon.
4. Identity scheme decision framework. Maps a starting condition to a primitive so the choice stops being a matter of taste.
5. Regulator due diligence on identity. How a supervised entity should document an onchain identity attestation so it survives an examination, covered in the regulator due diligence on identity reference.
6. Soulbound versus DID side by side. The comparison that decides which primitive proves what, primitive by primitive.
7. KYC attestation case study. A worked case study read from a real regulated engagement.
8. Broken attestation postmortem. Traces one live failure to its root cause, block by block.
9. Identity anti-patterns. The recurring mistakes that turn a clean design into an audit finding.
10. Identity infrastructure cost breakdown. Puts a number on every part of the stack, line by line.

The tiers exist so you can enter at your depth. A founder scoping a feature reads the framework and the cost breakdown. An engineer mid-build reads the walkthrough and the benchmarks. A compliance lead reads the regulator due diligence entry and the KYC case study.

Soulbound tokens, DIDs and attestations: which primitive proves what

The field offers three primitives for onchain identity attestation, and they are not interchangeable. A decentralized identifier (DID), standardized by the World Wide Web Consortium, is a subject-controlled identifier that resolves to a document describing how to verify claims about it; DID version 1.0 became a W3C Recommendation in 2022 and version 1.1 invited implementations in 2026 with a comment deadline of 5 April 2026. A verifiable credential is a claim signed by an issuer that a holder presents to a verifier, forming the issuer, holder, verifier trust triangle documented in the 2024 IEEE survey on the subject. A soulbound token (SBT) is a non-transferable, NFT-like token bound permanently to one address, which lacks a finalized standard and encodes the claim as token ownership rather than a signed statement.

The practical decision is rarely SBT versus DID in the abstract. It is which primitive gives the verifier the cheapest honest answer to the question being asked.

Our read: an EAS attestation is the most composable substrate because attestations can reference other attestations by UID, so a KYC claim can point at the identity claim it depends on. A DID is the right anchor when the subject must carry identity across contexts they do not control. A soulbound token is defensible only when the claim is genuinely public and non-transferable membership, and never for anything a subject might reasonably want to keep private, because token ownership on a public chain is visible to everyone. The soulbound versus DID side-by-side reference runs this trade-off to its conclusion with the numbers attached.

What an onchain identity attestation costs, in numbers

The economics decide the architecture, so put numbers on them before you commit. A base value transfer on an EVM chain costs 21,000 gas. Verifying a single EIP-712 signature adds roughly 3,000 gas, about 14% on top of that base, which is why signature checks are effectively free and storage is where the cost hides. Writing one attestation into contract storage can cost 20,000 gas or more per stored word, so storing a five-field claim onchain can cost over 400% more gas than the base transfer that carries it, an order of magnitude more expensive to store than to verify. The offchain path avoids more than 90% of that storage gas until you decide to anchor a hash, and anchoring one 32-byte hash costs the same whether the underlying claim carries three fields or thirty.

The market context confirms the direction. The decentralized identity market reached $7.4 billion in 2026, and the regulatory clock is fixed: 27 EU member states must issue a wallet by December 2026, and obliged entities have a 36-month window closing in December 2027 to accept it. Content that ships proper structured schema has roughly a 2.5x higher chance of being cited by AI answer engines, which is why every reference entry under this hub publishes its data in tables rather than prose. The cost of an onchain identity attestation is therefore two numbers, not one: the gas to issue and verify, and the compliance cost of getting the schema wrong.

1. Verification. About 3,000 gas per EIP-712 signature check, independent of claim size.
2. Onchain storage. From 20,000 gas per 32-byte word written, scaling with every field stored.
3. Offchain issuance. 0 gas to sign; the cost appears only when you anchor.
4. Anchoring. One hash, roughly 21,000 to 26,000 gas, constant regardless of claim size.
5. Revocation. A registry write or resolver call, budgeted at issuance, never deferred.

The identity infrastructure cost breakdown puts current figures against each line. The headline holds: for a system issuing thousands of claims, the gap between an offchain-anchored design and a fully onchain one is the gap between a rounding error and a budget line.

How to verify an onchain identity attestation without trusting a server

Verification is where an onchain identity attestation earns its name. The reason to anchor a claim to a blockchain is that a verifier no longer has to trust the issuer's server to be online or honest at check time. The verifier needs four inputs: the claim, the issuer's signature, the schema it was signed against, and a revocation status. Three of those travel with the claim; the fourth is why revocation design is not optional.

The check itself is mechanical. Recompute the EIP-712 digest from the typed claim and the domain separator, run one ecrecover to recover the signing address, and confirm it matches the issuer you expect. That call costs about 3,000 gas and returns a yes or no with no external dependency. If the claim was anchored, hash it and compare against the onchain record; a match proves the claim existed and was not altered after anchoring. If the issuer attached a resolver contract, the same call can enforce onchain rules, for example that the attester sits on an allowlist or that a fee was paid. This is the property that makes an onchain identity attestation composable: one attestation can point at another by UID, so a verifier walks a chain of claims rather than trusting a single opaque assertion.

Revocation is the step teams skip and later regret. A verifier that checks the signature but never checks revocation will accept a claim that turned false months ago. The three defensible patterns are an expiry timestamp baked into the claim, a revocation registry the verifier reads, and a resolver that refuses to validate revoked UIDs. Budget one of them at issuance, not after launch. The consumer field report shows what real users do when a verification prompt asks them to sign, and where a badly designed check loses them.

How onchain identity attestation goes wrong: five failure modes

We named the failure modes up front because they are where the field quietly loses. Each one maps to a metric you can measure before launch.

1. Signing an opaque blob. Before EIP-712, wallets asked users to sign 32-byte hex strings they could not read, and phishing followed. EIP-712 exists to fix exactly this. In the authors' own words, it is a standard for hashing and signing of typed structured data as opposed to just bytestrings, and critically it does not include replay protection. The metric: can a user read what they are authorizing before they sign? If not, the design is broken.
2. No replay protection. Because EIP-712 leaves replay out, the signer must bind each signature to a chain, a contract, a version and a nonce through the domain separator. Teams that skip the nonce ship attestations that can be replayed on a fork or a sibling chain. The metric: is every signature bound to a chainId and a nonce?
3. Onchain storage of private claims. Writing a KYC result to contract storage makes 100% of that field publicly readable, forever, to every observer. The metric: what fraction of attested data is publicly readable that should not be? The correct answer is 0%, achieved by anchoring a hash and keeping the claim offchain.
4. Unrevocable claims. A claim with no revocation path becomes false the moment the fact changes and stays onchain asserting the opposite. The metric: mean time to revoke, measured in blocks. If it is unbounded, you have a liability, not an attestation.
5. Schema lock-in. A bespoke schema no other verifier consumes turns a shared-ledger claim into a private one with extra steps. The metric: how many independent verifiers can parse the claim without custom code? The broken attestation postmortem walks one real instance of failure mode four from symptom to root cause.

Three engagements where the attestation playbook was load-bearing

The playbook is not theory. Three anonymized engagements show where an onchain identity attestation decided the outcome. Names and identifying details are withheld; the technical shape is exact.

A regulated stablecoin issuer, KYC gating on a payment rail, delivered in nine weeks. The team had planned to write each verified user's KYC status directly to a permissioned contract. We moved the claim offchain, signed it with EIP-712 against a reused schema, and anchored only the hash, so the subject's compliance status never became public. Verification stayed a single signature check. Result: no personal data onchain, and the auditor accepted the anchored hash as tamper-evidence.

A consumer identity wallet, onboarding abandonment cut by design, delivered in six weeks. Users were dropping at a signing screen that showed raw hex. We rebuilt the flow on EIP-712 typed data so the wallet displayed a human-readable claim, and bound every signature to a nonce and chainId to close the replay gap. The engagement turned an unreadable prompt into a claim a user could understand before approving it.

A DAO tooling team, composable reputation without a token, delivered in five weeks. The team wanted transferable reputation as a token, which is the anti-pattern: reputation you can sell is not reputation. We implemented non-transferable EAS attestations that reference each other by UID, so a contribution claim can point at the identity claim it rests on. The KYC attestation case study documents the compliance variant of this pattern in full.

The throughline across all three: clients kept ownership of everything built, because the sovereignty thesis this studio was founded on refuses vendor lock-in. An onchain identity attestation you cannot migrate off one provider is not sovereign, and defeats the reason to put it on a public chain in the first place.

Which reference to read first, by starting condition

Decision criteria beat a table of contents. Match your starting condition to the entry that answers your next question.

• You have never shipped an attestation. Read the identity walkthrough, then the identity scheme decision framework. You need the mechanics and the map before the numbers.
• You are choosing a primitive. Read the soulbound versus DID comparison and the identity scheme decision framework. The choice is a trade-off, not a preference.
• You are under regulatory supervision. Read the regulator due diligence on identity reference and the KYC attestation case study. Your metric is examinability, not elegance.
• You are debugging a live system. Read the broken attestation postmortem and the identity anti-patterns catalogue. Someone has already made your mistake and written it down.
• You are budgeting. Read the identity infrastructure cost breakdown and the attestation benchmarks. Every part of the stack has a number attached.

The decision framework itself lives in the identity scheme decision framework reference, which turns starting condition into a recommended primitive with the reasoning shown.

What is changing in onchain identity attestation this year

The forces reshaping onchain identity attestation are regulatory and standards-driven, and both are on a clock. Under Regulation (EU) 2024/1183, all 27 EU member states must provide a European Digital Identity Wallet by December 2026, and obliged entities including banks and very large online platforms, defined as those with more than 45 million monthly active users in the EU, must accept it by December 2027. The wallet integrates W3C Verifiable Credentials and the ISO/IEC 18013-5 standard, and introduces Qualified Electronic Attestations of Attributes carrying the same legal weight as an identity document. For any team building identity, this converts verifiable credentials from an optional pattern into a compliance requirement for 100% of obliged entities, on a deadline.

The practical consequence is that an onchain identity attestation designed today is designed against a moving target with a known destination. A system that emits claims in a proprietary shape will interoperate with nothing when the regulated wallet arrives, and the cost of retrofitting a schema after launch is far higher than choosing a standards-aligned one at the start. This is the strongest argument for the schema-as-product discipline stated earlier: the schema you pick now is the schema an examiner, a partner and a regulated wallet will all read in 2027. Teams that treat the schema as an afterthought are buying a rebuild.

The standards layer is moving in step. W3C Decentralized Identifiers version 1.1 opened for implementation in 2026, tightening the data model that DID-based identity depends on. The decentralized identity market reached 7.4 billion US dollars in 2026, and adoption signals followed: Microsoft added DIDs to Entra Verified ID in 2022, and issuers such as Dock and Vouched build on the same primitives. The direction is unambiguous. Regulated, standards-compliant credentials are becoming the default, and purely speculative token-as-identity designs are being left behind. Our forward read: teams that anchor to W3C and eIDAS-aligned schemas now will not need to rebuild in 2027, and teams that invent proprietary schemes will.

Where this hub sits in the blockchain and crypto payment rails family

Onchain identity attestation does not stand alone. It is one hub in the blockchain and crypto payment rails family, which covers smart contracts, stablecoin rails, wallet user experience, custody, and the engineering trade-offs between layer 1, layer 2 and offchain settlement. Identity is the layer that makes the others accountable: a stablecoin rail needs KYC attestations to satisfy AML obligations, a custody design needs identity claims to authorize withdrawals, and wallet UX is where a user meets an attestation and decides whether to sign. Read this pillar alongside the family's work on KYC and AML rails and on wallet UX, because an identity decision made in isolation from the payment flow it serves is a decision made blind.

The dependency runs in one direction. Payment rails inherit their trust assumptions from the identity layer, so a weak onchain identity attestation upstream becomes a compliance gap downstream at the moment of settlement. A stablecoin issuer that anchors KYC claims correctly can prove, on demand and without a central database, that every sender cleared a check; an issuer that stored those claims as public token ownership has leaked its entire customer list and still cannot revoke a single one cleanly. The same primitive that gates a payment also authorizes a custody withdrawal and unlocks a governance vote, which is why we treat identity as the load-bearing layer of the family rather than a feature bolted onto each product. Design the attestation once, correctly, and the rails, the custody model and the governance surface all inherit a claim they can verify. Design it wrong, and every downstream system inherits the same unrevocable liability.

FAQ: onchain identity attestation

What is an onchain identity attestation in one sentence?

It is a cryptographically signed claim by an issuer about a subject, structured against a published schema and either written to a blockchain or anchored to one by its hash, so any verifier can confirm the claim was signed by the stated issuer and has not been altered.

How much does an onchain identity attestation cost to issue?

Offchain attestations cost nothing to sign, because the signature is created and stored offchain until someone chooses to anchor it. Onchain attestations cost gas to write, plus roughly 3,000 gas for the single ecrecover call a verifier uses to check an EIP-712 signature. The cost lever is deciding what genuinely needs to live in contract storage.

Do I need EIP-712 for onchain identity attestation?

In practice, yes. EIP-712 is the standard that lets a wallet show a human-readable claim and bind the signature to a specific chain, contract and version. The Ethereum Attestation Service and most credential systems build on it. Remember that it does not provide replay protection, so you must add a nonce yourself.

Should I use a soulbound token or a verifiable credential?

Use a verifiable credential when the subject needs selective disclosure and privacy, because a credential is presented on demand rather than published. Use a soulbound token only when the claim is genuinely public, non-transferable membership. A soulbound token published on a public chain is visible to everyone, which rules it out for anything sensitive.

Does the EU Digital Identity Wallet affect onchain designs?

Yes. Regulation (EU) 2024/1183 requires all 27 member states to issue a wallet by December 2026 and obliged entities to accept it by December 2027. It standardizes on W3C Verifiable Credentials, so identity systems that align to that standard now will interoperate with the regulated wallet, and proprietary schemes will not.

Where should a compliance team start?

Start with the regulator due diligence on identity reference and the KYC attestation case study. Both are written around examinability: documenting an onchain identity attestation so it survives a supervisory review, rather than optimizing for elegance.

How La Boétie builds onchain identity attestation systems

La Boétie is a venture studio, digital agency and technical consultancy that builds onchain identity attestation systems clients fully own. Most teams arrive after a do-it-yourself attempt with AI tools produced an insecure prototype: exposed keys, unprotected routes, claims written to the wrong place. We rebuild them properly, in a fraction of the time, on three fronts.

Architecture and scheme selection. We decide, with you, whether a claim wants a DID, a verifiable credential, a soulbound token or an EAS attestation, and where each claim should live. A flexible team of five to six engineers, multilingual and across time zones, means the architecture conversation happens fast and the answer is specific to your constraints, not a template.

Implementation and integration. We build the attestation layer: EIP-712 typed-data signing so users can read what they authorize, resolver contracts for onchain verification and revocation, and offchain anchoring so private claims never hit public storage. We reuse existing schemas before registering new ones, because a portable claim is worth more than a bespoke one.

Fractional technical leadership. When you need an externalised CTO to own the roadmap rather than a one-off build, we operate as one, in the opinionated spirit the studio was founded on: you asked for X, and we build what you actually need instead. The throughline, drawn from Étienne de La Boétie's 1548 argument against voluntary servitude, is that technology must belong to the client. No vendor lock-in, ever.

If you are choosing a primitive, scoping a build, or repairing a live attestation system, book a studio intro call and bring the specific claim you need to prove. We will map it to the cheapest honest design in the first conversation.

Conclusion

Onchain identity attestation rewards teams that keep four decisions separate: who issues the claim, what schema it commits to, where it is stored, and how it is revoked. The field describes the surface; this hub defends a position. Put the claim offchain, anchor its hash, sign with EIP-712 and a nonce, reuse the schema, and build the revocation path first. Do that and an onchain identity attestation becomes what it should be, a cheap and honest answer to a verifier's question, rather than an expensive public record of data you never meant to expose. Start with the reference that matches your condition, and hold us to the metric on every one.

À lire également :

• Identity walkthrough reference
• Attestation benchmarks reference
• Soulbound versus DID side-by-side reference
• Identity scheme decision framework reference
• Regulator due diligence on identity reference
• KYC attestation case study reference
• Broken attestation postmortem reference
• Identity anti-patterns reference
• Identity infrastructure cost breakdown reference

Sources :

• EIP-712: Typed structured data hashing and signing : Ethereum Improvement Proposals, 2017
• Welcome to EAS, Ethereum Attestation Service documentation : Ethereum Attestation Service, 2024
• Decentralized Identifiers (DIDs) v1.1 : World Wide Web Consortium, 2026
• Regulation (EU) 2024/1183 and the EU Digital Identity Wallet : European Union, 2024
• What Is Ethereum Attestation Service and How to Use It : QuickNode, 2024
• Decentralized Identity and Verifiable Credentials: The Enterprise Playbook : Security Boulevard, 2026
• ERC-725 and ERC-735 identity and claim standards : ERC725 Alliance, 2017
• A Survey on Decentralized Identifiers and Verifiable Credentials : IEEE, 2024