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
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: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: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 anattribution 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.