What is an ASP?

An Association Set Provider (ASP) is an off-chain service that:

1. Maintains a list of addresses (or identity commitments) meeting specific compliance criteria
2. Organizes them in a Poseidon-hashed Merkle tree
3. Publishes the Merkle root on-chain (to the AttestationHub)
4. Allows users to generate ZK membership proofs against the published root

Users prove they are in the tree — without revealing which address they are.

The ASP Workflow

The Merkle Tree

The ASP's approved list is stored as a LeanIMT (Lean Incremental Merkle Tree):

• Leaves: Poseidon(address) — identity commitments, not raw addresses
• Internal nodes: Poseidon(left, right)
• Root: Published on-chain in the AttestationHub

The Poseidon hash is ZK-friendly (designed for efficient circuit computation). The tree supports incremental updates — adding a new member requires recomputing only $O(\log n)$ nodes.

Identity Commitments

Rather than storing raw addresses, ASPs store identity commitments:

const identityCommitment = Poseidon(address)

This allows the ASP to work with any identity system — Ethereum addresses, zkPass credentials, WorldID commitments, Semaphore groups — by plugging in a different IHashFunction or IAttestationVerifier.

ZK Membership Proof

When a user wants to prove membership, they generate a ZK proof that:

• They know an address a such that Poseidon(a) is a leaf in the tree
• The tree has the published root r
• They are the owner of a (via signature)

The verifier learns: "someone in the approved set made this claim." Nothing more.

Root History

On-chain, the AttestationHub stores a rolling history of recent roots (not just the latest). This allows:

• Transactions submitted slightly after a root update to still use the previous root
• Resilience against timing attacks (users don't need to rush proof generation)

Each root has a TTL (time-to-live). Proofs generated against expired roots are rejected.

Multiple ASPs for Multiple Use Cases