How Cloak screens for sanctioned addresses before its privacy layer applies

Cloak is private financial infrastructure on Solana, built on zero-knowledge proofs. Its protocol enables transfers of USDC, USDT and SOL while breaking the public link between sender and receiver. The transactions themselves remain visible onchain, but an outside observer sees one wallet deposit into Cloak's shield pool, and another receive funds from it, rather than seeing that wallet X paid wallet Y.

The same property that makes a transfer private also removes the transaction details that compliance tooling would otherwise inspect.

The team, based in São Paulo, addressed that before moving from testnet to mainnet. Cloak's stated requirement was to comply with OFAC requirements and to reduce abuse by malicious users. They integrated Range's Risk API before its program went under audit, which put the screening inside the audited surface rather than alongside it.

So far in private beta, Cloak has processed over $500k USD in total payment volume on Solana, with the public launch slated for this month.

Why the control has to sit at the perimeter

Most compliance tooling in crypto assumes the transaction graph is readable. That means teams can screen the counterparty, trace the funds, flag the pattern.

A privacy protocol removes that assumption by design. The deposit into the shield pool and the eventual payment out remain visible onchain, but the public record does not show which depositor funded which recipient. Once funds enter the privacy layer, the sender-to-receiver relationship that conventional screening relies on is no longer publicly available.

That leaves two decision points, both at the perimeter of the pool. On the way in, Cloak assesses the address and the transfer before funds enter, and decides whether to allow it. On the way out, sends submitted through the relay are screened against the authenticated sender, so a spend is checked even though the public record does not tie it back to a deposit. What cannot be done is reconstructing the counterparty relationship after the fact from the public transaction graph, so the check has to happen at the moment of entry or send, not later.

Auditors ask about this, as do the exchanges, custodians and payment partners on the other side of every eventual withdrawal. The question a privacy protocol has to answer is what prevents a sanctioned address from entering before the transaction becomes confidential.

What Cloak uses

Cloak integrated Range's Risk API to screen addresses at the perimeter of the privacy product. Two capabilities do the work:

• Sanctions and blacklist screening against lists from OFAC, the UN, EU and UK sanctions lists, PEP lists and stablecoin issuer blacklists, run before the privacy layer applies
• Payment risk assessment across the transfer, which extends the check beyond binary list membership to the behavior and counterparty history attached to the addresses involved

Range returns the risk assessment and the evidence behind it. Cloak owns the policy decision and determines what happens to a flagged address.

Screening at the entrance is one half of Cloak's compliance model. The other half runs in the opposite direction: its site describes viewing keys that let a user disclose a transaction selectively to an auditor or a compliance officer, keeping transactions private by default while remaining auditable when required. That is disclosure after the fact, at the user's choice. Perimeter screening is what applies before anything enters. That sequencing matters because once privacy applies, the transaction can no longer be screened in the same way. Screening controls who can enter, while viewing keys preserve an audit path after the transaction is private.

Why the sequencing mattered

Cloak wired Range in before its program went for audit. When the audit ran, the screening path was part of the code under review, and the program that shipped to mainnet carried the compliance control with it.

A screening path added after an audit is not part of that audit. The protocol then carries a compliance explanation that does not match the reviewed code until the next review closes the gap. Cloak brought the control into the reviewed program while the architecture could still incorporate it, so the compliance story and the audited code were the same thing on the day it shipped.

Cloak is live on mainnet for private beta, with full public access opening soon. With Range, compliance and risk screening were in place before the first shielded transaction, not added once the product had users to protect.

Build screening into the audited surface

Cloak is an early version of a problem that is becoming ordinary. Private transfers are entering mainstream stablecoin infrastructure, and every product that adopts them inherits the same constraint: the closer the privacy guarantee is to the user, the more of the compliance burden shifts to the edge of the system.

Any team holding an audit date and a confidential transfer feature is already making this decision, whether or not it is on the agenda. The cost and complexity increase once the audit begins.

“Privacy should break the link between counterparties without removing controls over who can enter the system. With Range, we screen transactions before they enter Cloak’s privacy layer. We built that control in before audit, so it was part of the protocol from the start.” Arthur Bretas, co-founder of Cloak

Range's Risk API provides the most comprehensive screening for Solana wallets and tokens. Our onchain compliance solution is also used by other privacy-focused Solana apps, including Umbra and Vanish.

Range is the platform for companies operating across stablecoins and fiat. If you are building a product where the compliance control has to sit at the perimeter, get in touch.