Thinking about Attestations

Thinking about attestations

Based on a lot of conversations with Albert Ni, Barry Whitehat, Personae, ZKonduit, Axiom, and more. I mostly mean to put put forward my own tentative and incomplete framework for unifying some common themes we’ve been seeing.

I expect our answers to questions like “What are attestations” and “Why are attestations important” to evolve rapidly over time; here’s just my own very very rough first pass.

Attestations will be increasingly important infrastructure for the next generation of Internet communication, enabled by new cryptographic primitives like ZK proofs.

Attestations are self-evident claims that are portable and interpretable across platforms, networks, computing environments, or permissions systems, that can be produced and consumed permissionlessly (or as permissionlessly as possible). They are the closest thing we have to “theorems” about real-world data and entities.

  • Self-evident claims: I’m shifting slightly from my previous language of “credible” claims (, in favor of “self-evident” claims. Self-evident claims are claims whose validity requires no* context to assess (i.e. determining the validity of such a claim does not require us to go through a third party with permissioned auxiliary information, such as Facebook/Google/the government/etc). Oftentimes, this is achieved by coupling a claim with a cryptographic proof (see below).
    • *Of course there is always some implicit context, but ideally it is minimal. In the best case, self-evident claims should be verifiable given only access to a library of pure cryptographic functions, as well as possibly publicly-accessible DNS records and/or Ethereum blockhashes.
  • Permissionless production and consumption: Ideally, attestations of arbitrary complexity can be generated and interpreted by anyone, with minimal reliance on third parties.
    • Attestations about blockchain activity have effectively no third-party reliance.
    • Attestations about activity on Reddit rely on Reddit to publish a signed Merkle root, and make private account data available to each user; but from here, attestations of arbitrarily complexity can be requested by any third party or generated by any client.

Attestations have two components:

  • Claim: The statement itself. Like “I have at least 1500 karma on the r/cryptocurrency subreddit,” “I own a Dark Forest planet,” “I possess a fingerprint signed and timestamped by a trusted camera manufacturer that hashes to H,” “I hold at least $20,000 of cryptocurrency on Coinbase, and Binance, and in my own wallets, combined.”
  • Proof: A cryptographic artifact (signature from a trusted authority that serves as a root of trust, a ZK proof, Merkle proof of inclusion in a block header) that verifies the claim.
    • Note that the proof can actually be a proof of a stronger claim. For example, a light client proof proving that I own a particular NFT in a collection is still a proof that I own some NFT in that collection.

Basically, attestations are pieces of data that “speak for themselves.”

Base vs. Composed Attestations

In my model I have found it useful to distinguish between “base” attestations vs. “composed” attestations.

  • Base attestations are rigid, signed claims: a signed transaction or commit, a JSON of account activity or metadata signed by Reddit, a light client proof of an account balance as of a certain blockhash, etc. Generally, these are signatures of specific data, or proofs of inclusion in a publicly-accessible cryptographic accumulator root that we come to consensus on.
  • Composed attestations are built from base attestations. For example, an attestation to a JSON of my karma across many different subreddits can be turned into an attestation that I have at least 1500 karma on some specific subreddit, using a ZK proof. Or, a proof that I have some specific reputation score based on a formula taking into account multiple different data sources, would be a composed attestation. Generally, these kinds of attestations either require you to present a bunch of base attestations all at once (which you probably won’t want to do because base attestations may contain extra unnecessary data), or else combine these base attestations with a ZK proof.

Attestation Lifecycles

To understand possible attestation lifecycles, I propose to think about five questions.

What will we produce attestations about?

Activity on various digital platforms. Here are a few that might be especially good to start with:

  • Activity on social platforms, communication platforms
    • Web2/permissioned, like Twitter or Reddit - attestations must be rooted in Twitter/Reddit as a trust root
    • Web3-native, like Farcaster or Skiff - this platforms host cryptographically-signed data, so we don’t need to rely on a centralized root of trust
    • Anywhere where we have cryptographically-secured data - for example, Github commits are signed by (usually) RSA keys that are publicly accessible. Emails are signed by mailservers.
  • Financial service providers or custodians
    • Coinbase or crypto custodians
    • Banks
  • Blockchains, like Ethereum
    • On-chain or historical data
    • Proof-of-consensus attestations also allow chain accumulators to be accepted in environments that can’t “query” for blockhashes in the same way that humans and servers can—for example, in smart contracts on other chains
  • Eventually - attestations that are simply generated according to some neutral protocol that is not tied to a platform
    • For example, ETHDos asks you to produce attestations that conform to a certain protocol (signing a message that says something like, “0xabcd is my friend”)

Who will produce attestations?

For activity on permissioned platforms, these platforms must produce the “base” attestations.

For activity on permissionless or cryptographic platforms, users can produce their own “base” attestations.

Once a user has base attestations, they can create their own “composed” attestations.

Where will attestations be stored?

The easiest but dumbest way in the case of permissioned attestations is for the permissioning platform to store the attestations. For example, I could query a signed Twitter API to get some attestation about my account data or some other account data.

But we would like to put storage and control of attestations (or attestation data) in the hands of users. In the short-medium term, this may look like a wallet or password manager browser extension. In the long term, this hopefully looks like browser standards, secure enclaves on phones, etc.

I think that ZKeeper or some future wallet-like browser extension like “EthPassport” would be critical infrastructure here. The ZKeeper presentation from Devcon is excellent as a demonstration for what may be possible.

How do we compose (compute on) base attestation to build more complex attestations?

Another question is in what execution environment base attestations will be composed or computed on, and what kinds of computations we’ll be able to use to compose base attestations. Here are some examples of ZK primitives that can be used:

  • Merkle proofs / inclusion proofs allow us to go from a piece of data “I am a specific person with property X” to “I am some secret person with property X”
  • Recursive proof composition or certain flavors of MPC (a la ETHDos, Blind Find, collaborative SNARKs, etc.) allows us to compute proofs on multiple secrets owned by multiple people—useful for generating attestations for social facts.
    • Recursive proof composition also allows a single user to combine multiple predicates together from base attestations - for example, “EITHER I have a ZKP attestation from Coinbase that I hold 100ETH, OR I have a ZKP attestation to blockchain data proving that I have a wallet with 100ETH”
  • ZKML circuits allows us to prove that we have data that classifies to some class (”I have a picture of a bird in my database,” “I have just taken a selfie that matches a passport photo for some non-sanctioned person”)
    • Note that there are still a lot of open questions here - for example, how to deal with adversarial attacks on models, when model weights are public.

Who will consume attestations?

The whole point of attestations is to enable third-party application developers to permissionlessly tap into the rich and complex datasets of digital activity and identity. A network of open attestation infrastructure is the next step beyond a network of open APIs.

In the short term, here are a few possible consumers:

  • Permissioned base attestation producers may consume their own attestations, adopting a modular authorization infrastructure internally.
  • Publishing and messaging platforms like Twitter, Mirror, Substack, Signal, etc.
  • Smart contracts that gate certain functionality depending on being able to produce an attestation (of identity, of reputation, etc.)
  • Services that care about rate-limiting and anti-sybil mechanisms (Gitcoin or anything that requires soft guarantees around accounts that vote on stuff, faucets, etc.)
    • Autonomous Worlds and crypto-native games are a really interesting category here!

Meta: how will standards emerge around the interpretation of attestations?

This is a hard and important open question! What standards will emerge around what attestations are meaningful?

It’s especially important to prevent “capture” of these standards layers by entities that aren’t fully aligned with building the most open / interoperable ecosystems.


Hey, thanks for the writeup and the deep analysis over the topic. It was a really interesting read. This sounded to me really similar to the concept of claims which appears in DID’s specs. They’re tied to your identity and you can form trees with them. Showing the opening to a claim which proves things similar to the ones mentioned in your examples.

Have you seen these? If so, Do you also see the similarities? Otherwise, are they indeed close to what you have in mind?

On another side, attestations from others about you are also a really important topic. How to deal with fake claims? How to make the ones that matter to you more relevant? Maybe a reputation system which is also private could be a requirement for that. Would be nice to know your thoughts.


Oh cool, thanks for sharing this, I hadn’t seen this spec before. Here are some of my initial thoughts (based on a quick skim, might send more thoughts later if I get a chance to do a deeper and more proper read):

  • Yes, there are definitely some very strong similarities here, and I think the end goals are roughly similar!
  • However there are some serious limitations to this signature-based DID model that I think these newer cryptographic tools (succinct proofs, ZK proofs) make significant progress in addressing.
  • For one thing, it seems very difficult to keep anything meaningful private in a VC. Consider “I own this specific NFT in the Dark Forest NFT collection,” versus “I own some NFT in the Dark Forest NFT collection.” It doesn’t look like the latter is directly possible right now with VCs (you can get an attestation to the latter, but you can’t just get the latter permissionlessly, which is a big difference).
    • This has some pretty important consequences. There’s the ideological and political stuff for sure, having the freedom not to reveal anything more than is necessary to authenticate etc. But also, information asymmetry is just important mechanically in order for many systems to function. For example, in any ID system where you are meant to custody some secret (private key, hash pre-image password, biometric, etc.), you need to prove you know a secret with some property without revealing everything about it. This has big implications for (the lack of) composability and permissionlessness; it also means that credential issuers have a loooot of power.
  • Succinct proofs are important because some credentials or more complex attestations are likely to involve significant computation. Take the example of a credential that you can use to represent that you have some creditworthiness score, according to the execution of some public model or formula on some private data. A succinct proof of this fact is much less unwieldy than a massive JSON containing VCs of every major financial action you’ve taken in the last N years.
    • Some credentials/presentations (in their language) that we will probably care about in the future will rely on the ingestion of lots of data. It would be really annoying to have to pass around VCs that are megabytes long…

That’s a good point!!! I did not consider that. And it’s a totally fair concern.

Theoretically you could have a tree of proofs and publish the root of it linked to your ID. With that, you can always proof that you hold a proof that proves the validity of an attestation. So I think it is indeed possible to keep the privacy. But of course changing the underlying attestation as a proof stored in a tree for which the root is published linked to your ENS for example.

I do agree. I do have to say I’m not suggesting to just use the claim concept as is directly defined. But, I think the whole DID spec is something where we could pick ideas and stuff for sure.
I know that Snarks are definitely needed for Attestation applications. And indeed I think it won’t make sense to not use them. I just linked claims as something we can look at to get ideas or at least, things that we would like to be different.

I think my main concern is the fact that, as you mention, the permissioned-attestation expeditors will hold too much power. And can create false attestations.
But I’m positive this might change in the future. We see more and more decentralized applications. Mastodon is an example maybe. Where an attestation would be able to be validated by anyone.

Anyway, thanks for sharing your thoughts on this. I think, the first thing that would be important is to see if some kind of exploratory work can be made on the area. And, specially that goes in the direction of having private attestations always. Such as the idea of the merkle tree of proofs of correct attestations for example.

1 Like