A shrinking association set does affect the real strength of compliance proofs, but the reason credibility may drop is not what you might think.
A smaller association set shrinks your hiding place
The core logic of privacy pool withdrawal proofs is: a user creates a zero-knowledge proof showing "my deposit belongs to a compliant association set," and at the same time "I really know the secret information behind this deposit."
The association set is maintained by an association set provider (ASP). It is basically a list of compliant deposits. When generating a proof, the user selects a subset from that list and proves the deposited funds are inside that set.
The smaller the association set, the smaller the anonymity set you can hide in. If an outside observer knows a withdrawal comes from a compliant set of only a few dozen addresses, the chance of linking that withdrawal to a specific user is much higher than if the set contains thousands of addresses. Related model documents also note that a very small anonymity set greatly weakens privacy protection.
Why credibility may drop? The key is dilution of the "compliance signal"
The credibility of a compliance proof depends on two things: first, the cryptographic validity of the proof itself; second, how much trust outside observers place in it.
As the association set keeps shrinking, two problems can appear:
First, the set you choose may look more and more "suspicious." If a compliant set shrinks from "all KYC-passed addresses" to "VIP users of a specific exchange," then even if the proof is still valid, outside observers will know the withdrawer comes from a very specific group. That itself can leak information.
Second, the more addresses are excluded, the more your proof may look like "avoiding something." If the compliant set keeps shrinking, observers may suspect that illegal funds in the pool are increasing, or that the ASP is tightening screening. This suspicion can directly affect how the market accepts the proof. Even if the proof is mathematically sound, others may start doubting the "compliance" label.
Core issue: a valid proof and an accepted proof are different
Technically, the association set update mechanism is dynamic: the ASP can remove deposits that are later judged illegal from the compliant set. If your deposit remains in the compliant set, the generated proof is still cryptographically valid. The system also keeps a history of recent association set tree roots to prevent proofs from failing due to slight delays.
But "the proof is valid" and "external entities such as exchanges or regulators accept the proof" are different things. If the association set shrinks too much, the commercial value of the compliance proof falls, because external entities may no longer see the set as neutral or broad enough.
What you can do
If the association set keeps shrinking, the simplest response is to choose a compliant set that still has a large enough anonymity set for generating your proof. The privacy pool design allows users to choose different association sets, so you have the chance to choose a less strict set.
Also, a healthy compliance privacy system should have multiple competing ASPs for users to choose from. If the current ASP's association set shrinks to the point of hurting privacy, switching ASPs may be a more fundamental solution.
How to check
When generating a proof, you can check the size of the selected association set in the pool's frontend or a block explorer, such as how many deposit addresses it contains. If that number clearly decreases, or is much smaller than other available sets, be cautious. It may no longer provide enough anonymity to protect privacy.
