Skip to main content
Privacy protocols on Solana - mixers, privacy pools, confidential transfer programs - face a unique challenge: they need to prevent sanctioned or stolen funds from entering the protocol while preserving user privacy for legitimate users. If tainted funds flow through your protocol, it taints the entire pool and exposes your project to regulatory risk. Range’s Address Risk Score provides a straightforward solution: screen the depositor’s wallet before accepting funds. Block high-risk wallets at the door - before they can contaminate the pool.
Prerequisites: You need a Risk API key and familiarity with the Address Risk Score endpoint. For onchain enforcement, see the Onchain Risk Verifier guide.

Why Screen Deposits?

Privacy and compliance are not mutually exclusive. Screening depositors (not tracking what happens inside the pool) lets you maintain privacy guarantees for legitimate users while blocking bad actors.

Architecture

Address Risk Score already includes sanctions and blacklist screening. You do not need a separate sanctions check - OFAC-flagged and stablecoin-blacklisted addresses are factored into the risk score.

Step 1: Screen the Depositor

Before accepting a deposit, check the wallet’s risk score. This single API call covers malicious proximity, ML-based behavioral analysis, sanctions, and blacklist screening.

Example Response - Flagged Wallet

This wallet is 1 hop from known hack funds - it should be rejected.

Step 2: Make a Deposit Decision


Step 3: Integrate into Your Deposit Flow

Off-Chain (Backend / Frontend)

Screen wallets in your dApp frontend or backend before constructing the deposit transaction:

Onchain (Solana Program)

For protocol-level enforcement that can’t be bypassed by calling the program directly, use the Onchain Risk Verifier. This verifies risk scores inside your Solana program using Switchboard oracles:
Onchain enforcement is stronger than off-chain screening alone. Users can bypass your frontend, but they can’t bypass your program’s instruction logic. For maximum protection, use both: off-chain screening for UX (show the user why they’re blocked) and onchain verification as the enforcement layer.
Alternative: Signed message attestation. Instead of using Switchboard oracles, you can implement a lighter-weight pattern where your backend signs an attestation message containing the screened wallet address and a timestamp. The Solana program then uses Ed25519 signature verification (via the Ed25519 precompile) and instruction introspection to confirm: (1) the message was signed by your trusted attestation key, (2) the depositor matches the approved address in the message, and (3) the timestamp is fresh. This approach trades the decentralized oracle model for a simpler trusted-backend pattern.

Choosing Your Risk Threshold

The right threshold depends on your protocol’s risk tolerance and regulatory posture:
Setting the threshold too low (e.g., ≥ 3) will reject a significant number of legitimate users. Many clean addresses are naturally within 4–5 hops of flagged addresses through shared exchange or program interactions. Start with ≥ 7 and adjust based on your data.

Handling Edge Cases

What If the Risk Check Fails?

Network errors or API timeouts shouldn’t block legitimate deposits indefinitely. Implement a fallback policy:

Known System Addresses

Some addresses that interact with your protocol will be system programs, token programs, or exchange hot wallets. These will have an attribution field in the response - use it to fast-path known entities:

Rate Limits

If you’re processing high deposit volume, see Rate Limits & Plans for scaling options. For onchain enforcement via Switchboard oracles, rate limits apply to the oracle quote requests, not the onchain verification.

Compliance Considerations

Screening deposits demonstrates that your protocol has taken reasonable steps to prevent misuse. Document your screening policy and keep records:
  • Policy document - Define your risk threshold and what happens when a deposit is rejected
  • Audit log - Store the risk score, reasoning, and decision for each screened deposit
  • Threshold rationale - Document why you chose your threshold and any adjustments over time
  • False positive handling - Have a process for users to contest rejections

What’s Next

Address Risk Score

Full endpoint reference with scoring logic and examples.

Onchain Risk Verifier

Enforce risk checks directly in your Solana program.

Compliance Pipeline

Build a full compliance screening workflow.

Supported Chains

See which networks are supported for address risk scoring.
Last modified on June 17, 2026