Available Groups (Attester Data)
A group is said to be available for an attester when the attester has access to on-chain data in the specific format that it requires. This enables the attester to validate user claims.
Most attesters require a third party to post on-chain data (e.g merkle roots), though some just read from the EVM directly. Each available group in the context of an attester has a group identifier.
Standard User Request (Attester Input)
A user request targets a specific attester and specific groups of that attester. It has two components:
a set of claims: "I have an account with value >3 in the available group #5 of the attester, and an account with the value 0 in the available group #10 of the attester"
a destination: "I want to receive the attestation on this destination"
Arbitrary data required by the attester to validate the request "Here is proof for my claims and proof that I own the destination"
Attester: verifyRequest (Attester internal function)
Each attester has its own way to verify user requests.
Some attesters simply check on-chain states (e.g NFT.balanceOf(sourceAccount) > 0)
Some others verify Merkle Proofs from a group root made available to them
ZK Attesters verify Zero Knowledge Proofs (ZKP)
Attester: buildAttestations (Attester internal function)
Once an attester has verified a user's request, it constructs one or multiple attestations. Each attester has its own logic to construct attestations from verified user requests.
Example: Alice claims to be part of the 'ENS DAO Voters' group with 5 votes, and wants the attestation on 0x2.
Attester 1 logic: User will receive an attestation from the collection #132 which regroups all ENS DAO Voters.
Attester 2 logic: User will receive an attestation from the collection #99 which regroups all voters of public good DAOs.
Attestation Recording (Attester Output)
All generated attestations are stored in the Attestations Registry, a contract that keeps all user attestations in collections.