Skip to main content

What is an ASP

The Association Set Provider is a third-party service that gates which deposits are spendable through normal flows. The protocol delegates compliance and lineage screening to this service. The contracts only verify that the ASP attested to a specific label.

What an ASP does​

  • Watches the chain for new deposits.
  • Applies its compliance policy to each one, such as sanctions screening, blocklist checks, and AML rules.
  • Generates a Merkle root over the labels it approves.
  • Publishes that root to ASPRegistry via a POSTMAN_ROLE holder calling updateASPRoot.
  • Serves a snapshot API for fast client-side discovery.

What an ASP does not do​

  • It never holds user keys.
  • It cannot decrypt transfer note payloads, which are encrypted to recipient viewing keys.
  • It does not custody funds.
  • It does not move funds.
  • It does not sign transactions on behalf of users.

The one thing it does receive is each deposit's opening, encrypted to its own key, which is what it screens.

Compliance-without-decryption design​

The ASP works with depositor identity (visible on-chain at deposit time) and the deposit's claimed metadata (also public). Once a deposit's label is attested, any descendant transfer of that value remains private: the ASP does not see who received the value, the amounts involved, or the recipient address.

Trust scope​

  • Liveness: if the ASP stops attesting, new deposits can't move through normal flows. Users can ragequit to recover.
  • Honesty: a malicious ASP could approve illegitimate deposits. The protocol can't detect this, so what matters is the operator's compliance posture.
  • Censorship: the ASP could refuse to attest specific deposits. Users affected by this can ragequit publicly, and the funds aren't lost.

Current ASP​

0xbow operates the canonical ASP at api-dev.0xbow.io (Sepolia). Other ASPs could be deployed against the same pool by extending POSTMAN_ROLE, but currently each pool's deployment runs a single ASP.