Skip to main content

ASP attestation

The Association Set Provider (ASP) is operated by 0xbow and attests which deposit lineages are approved after screening. Without attestation, a note can't be spent and therefore cannot benefit from the privacy affordances of the shielded pool.

What the ASP attests to​

  • Deposit labels. A label is a Poseidon hash binding a depositor's intent at deposit time, and the ASP reviews deposits and includes the approved labels in a Merkle root.
  • Not transfers. Once a deposit's label is approved, all descendant notes (created via transact spends) inherit that approval.
  • Not values. The deposit's opening (value, tokenId, noteAddressHash, depositSecret) is encrypted to the ASP's public key so it can screen the deposit, and deposit values are public on-chain anyway; what the ASP can never decrypt are the recipient-encrypted transfer note payloads.

How attestation flows​

  1. The user makes a deposit, and the resulting note enters PENDING.
  2. The ASP service consumes the deposit's LabelRegistered event, decrypts the encrypted opening with its own key, and applies its policy.
  3. The ASP generates a new Merkle root that includes the approved labels.
  4. An account with POSTMAN_ROLE calls ASPRegistry.updateASPRoot(root, ipfsCID) to publish the new root.
  5. The SDK's next discoverNotes() sees the new root and transitions the note from PENDING to ACTIVE.

What if attestation fails​

  • A note that isn't attested stays PENDING while it is still under review, or moves to REJECTED on an explicit refusal.
  • REJECTED notes are recoverable via ragequit, a public exit by the current note owner in which the note's label is published on-chain so the deposit can be linked to the recovery.
  • The ASP cannot freeze your funds, because the protocol guarantees this recovery path independently of the ASP's cooperation.

See query the attestation snapshot and check a note's status for the operational workflows.