How the ASP works

The association set provider (ASP) is the party that curates the list of approved origins. It is the one role in Murk with any discretionary power at all, so it's worth being exact about what that power is.

What it does

1. Watches the chain. Every deposit publishes its origin, and every cross-source combine publishes its lineage encrypted to the ASP's key. The ASP reads both straight from Solana — the chain is the source of truth, so a total loss of the ASP's database is repaired by rescanning.
2. Decides which origins stay approved. By default, every deposited origin is approved. An origin leaves the list only by being revoked (see Revocation).
3. Publishes the list. The full approved set is served publicly, so anyone can read it and rebuild the Merkle root from it independently.
4. Posts the root on-chain. A single on-chain instruction records the root with a timestamp. The program keeps the last 64 roots and treats one as valid for 3 hours after it is posted. Your wallet fetches the list, rebuilds the tree locally, and derives its own membership proof — it does not ask the ASP for permission to spend.

That last point is the important one. The ASP is not in the transaction path. It never sees your spend, never signs it, and cannot decline it. Its only lever is what it chooses to put in the next published list.

What it can do

It can censor future private spends of a lineage. If the ASP stops including an origin, notes descending from that deposit can no longer produce a valid membership proof, so they stop being privately spendable from that point on.

It can be unavailable. If the ASP stops posting roots entirely, the last root expires after 3 hours and private spending pauses pool-wide until a root is posted again.

It learns which origins were combined. A cross-source combine reveals merged origin ← {input origins} to the ASP alone, in a form anyone can verify exists but only the ASP can read. That is a lineage relationship between labels — not amounts, not owners, not your balance, not who you paid.

What it cannot do

• It cannot take your funds. There is no instruction that lets any authority move value out of the pool. Withdrawals pay out exactly the amount bound inside a proof you generated.
• It cannot freeze your funds. Revocation removes private spendability, not ownership. The emergency exit works regardless of what any list says, and requires no cooperation from the ASP.
• It cannot redirect a payment. Destination, amount and fee are fixed inside the verified proof.
• It cannot read your funds. Note contents decrypt only under their owner's viewing key. The ASP holds no key that reveals a balance, an amount or a counterparty.
• It cannot deanonymise you. It sees labels and a public deposit ledger that everyone else can see too. Your spends do not reference their origin on-chain.
• It cannot mint value. Conservation is enforced inside every proof and again by the on-chain program.

In short: the ASP can decline to vouch for a lineage. That is the whole of its power.

Governance and where it's heading

The on-chain program will only accept a root from one configured authority key, and that key can be a threshold multisig — the program does not care which, so this can be hardened without any code change.

You can check which key holds the authority on the deployment you're using, on-chain, at any time.

Transparency commitment. Every revocation should be published with a citable reason — an OFAC listing, a public hack attribution. Nothing in the protocol enforces that; it is an operational commitment, and it is what makes over-blocking contestable rather than invisible.

Related

→ Association sets · Revocation · Emergency exit · Security model