Technical Glossary

This technical glossary is aimed to provide a broad overview of Sismo Attesters and Attestations.
For a more concrete view of Sismo protocol, head to the examples section which goes over both simple and advanced use cases in more detail.
Groups
Term
Description
Account
An account is a pair of an account identifier (e.g an Ethereum address, github username or twitter username) and a particular value (e.g number of votes submitted to the ENS DAO or number of twitter followers).
Group of Accounts
A group bundles accounts that share reputation or historical characteristics. The group can either exist on-chain (e.g current owners of an ERC20 token) or off-chain (e.g ENS DAO Voters, generated off-chain on June 10th, 2022).

Group examples:
ENS DAO voters. Account values = number of votes
Early Ethereum users. Account values = number of transactions made before 2018
Ethereum Clients Github Contributors. Account values = number of commits
Accounts with high DeFi reputation. Account values = DegenScore score
Sismo followers on Lens. Account values = Date of follow
User Claim
A user claim targets a specific group. It consists of:
A targeted group identifier 
"I own an account that's part of the 'ENS DAO voters' group"
"I own a Lens profile that's part of the 'Sismo followers' group"
A claimed value 
"I voted more than 3 times in the ENS DAO"
"I followed Sismo on Lens before June 15th, 2022"
ExtraData: optional additional data that might be required and verified by an attester
"generationTimestamp of the group is June 10th, 2022"
Attesters
Term
Description
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"
Proof (Attester Input)
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.
Attestations Registry
Term
Description
Attestation
An attestation is a certificate that proves a fact. Attestations are bundled in collections. An attestation consists of: 
An owner (address)
A value (number/uint256)
A recorder (address of the issuer)
Timestamp (date of the underlying certification - can differ from date of recording)
ExtraData (arbitrary data field that can be used by attesters)
Attestations Collection
The Attestations Registry is divided into attestation collections. A collection bundles owners that share some historical or reputation characteristics. 
Authorized Issuers
Multiple types of issuers can be authorized to write in the attestation registry (attesters, bridges, front contracts etc..). Issuers must be authorized/unauthorized by Sismo's governance.
Badges
Term
Description
Badge
A badge is a Token representation of an attestation. It is a stateless ERC1155 contract that reads balances from the attestation value
Example: the balance of a user for badge #1535 is its value for the attestation collection #1535 If the user does not have an attestation in the collection #1535, its balance will be null

Term	Description
Account	An account is a pair of an account identifier (e.g an Ethereum address, github username or twitter username) and a particular value (e.g number of votes submitted to the ENS DAO or number of twitter followers).
Group of Accounts	A group bundles accounts that share reputation or historical characteristics. The group can either exist on-chain (e.g current owners of an ERC20 token) or off-chain (e.g ENS DAO Voters, generated off-chain on June 10th, 2022). Group examples: ENS DAO voters. Account values = number of votes Early Ethereum users. Account values = number of transactions made before 2018 Ethereum Clients Github Contributors. Account values = number of commits Accounts with high DeFi reputation. Account values = DegenScore score Sismo followers on Lens. Account values = Date of follow
User Claim	A user claim targets a specific group. It consists of: A targeted group identifier "I own an account that's part of the 'ENS DAO voters' group" "I own a Lens profile that's part of the 'Sismo followers' group" A claimed value "I voted more than 3 times in the ENS DAO" "I followed Sismo on Lens before June 15th, 2022" ExtraData: optional additional data that might be required and verified by an attester "generationTimestamp of the group is June 10th, 2022"

Term	Description
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"
Proof (Attester Input)	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.

Term	Description
Attestation	An attestation is a certificate that proves a fact. Attestations are bundled in collections. An attestation consists of: An owner (address) A value (number/uint256) A recorder (address of the issuer) Timestamp (date of the underlying certification - can differ from date of recording) ExtraData (arbitrary data field that can be used by attesters)
Attestations Collection	The Attestations Registry is divided into attestation collections. A collection bundles owners that share some historical or reputation characteristics.
Authorized Issuers	Multiple types of issuers can be authorized to write in the attestation registry (attesters, bridges, front contracts etc..). Issuers must be authorized/unauthorized by Sismo's governance.

Term	Description
Badge	A badge is a Token representation of an attestation. It is a stateless ERC1155 contract that reads balances from the attestation value Example: the balance of a user for badge #1535 is its value for the attestation collection #1535 If the user does not have an attestation in the collection #1535, its balance will be null

Badges

Attesters Examples

Last modified 3mo ago