# Compliance

> How Senddy prevents illicit deposits and supports privacy-preserving regulatory compliance.

Source: https://www.senddy.com/docs/technical/compliance
Last modified: 2026-08-01T23:49:54.000Z

---

## Overview

Senddy takes a layered approach to compliance — blocking sanctioned deposits at the contract level while giving legitimate users the tools to prove their funds are clean without sacrificing privacy.

| Layer | Mechanism | Type | Purpose |
|---|---|---|---|
| **Deposit screening** | Chainalysis sanctions oracle | Automatic, enforced | Blocks OFAC-sanctioned addresses from depositing |
| **Association proofs** | ZK association circuit | Voluntary, privacy-preserving | Users prove funds trace back to approved deposits |
| **View key sharing** | Cryptographic key separation | Voluntary | Users grant read-only access to auditors |

## Deposit Screening

### How it works

Every deposit into the Senddy pool is screened against the [Chainalysis sanctions oracle](https://go.chainalysis.com/chainalysis-oracle-docs.html) — a smart contract maintained by Chainalysis that tracks wallet addresses included in sanctions designation lists from the US (OFAC), EU, and UN.

When a user calls `depositWithPermit2Sig`, the pool contract checks the depositor's address against the oracle before accepting funds. If the address is flagged, the transaction reverts with a `SanctionedAddress` error.

### Key properties

- **On-chain enforcement** — The check happens in the pool contract itself. There is no way to bypass it.
- **No off-chain dependency for blocking** — The oracle is an on-chain smart contract, not an API. It works even if Senddy's services are down.
- **Admin-configurable** — The pool owner can update the oracle address or disable screening if needed (e.g., to migrate to a new oracle version).
- **Minimal gas overhead** — The oracle check is a simple storage read on the Chainalysis contract.

### Chainalysis oracle

The Chainalysis sanctions oracle is deployed across multiple EVM chains. Senddy uses the Base deployment:

| Network | Oracle Address |
|---|---|
| Base | `0x3A91A31cB3dC49b4db9Ce721F50a9D076c8D739B` |

The oracle is maintained by Chainalysis, updated regularly to reflect the latest sanctions designations, and is free to use without a customer relationship.

## Association Proofs

### The problem

Deposit screening prevents sanctioned addresses from entering the pool. But what about the other direction — how can a user *prove* their funds are clean after they've been in the private pool?

Traditional approaches break privacy: you'd have to reveal your full transaction history. Senddy solves this with **association proofs** — a zero-knowledge proof that your funds trace back to approved deposit sources, without revealing which specific deposits funded you.

### How it works

1. **Association Set Providers (ASPs)** maintain Merkle trees of approved deposits. An ASP might be a compliance service, a regulated entity, or a jurisdiction-specific operator.
2. When a user wants to prove compliance, they generate a ZK proof showing:
   - Their note's nullifier is correctly derived
   - The source deposit exists in the ASP's approved set (Merkle membership proof)
   - There is a valid chain of custody from the deposit to their current note
3. The proof reveals **nothing** about which specific deposit was used — only that it was in the approved set.

### Use cases

- **Institutional compliance** — Funds, DAOs, or businesses using Senddy can prove their treasury is clean for auditors
- **Regulatory requests** — Users can respond to compliance inquiries without exposing their full transaction graph
- **Cross-protocol trust** — Other DeFi protocols can require association proofs before accepting Senddy withdrawals
- **Jurisdictional flexibility** — Different ASPs can maintain different compliance standards (US OFAC, EU sanctions, etc.)

### Key properties

- **Voluntary** — Association proofs are never required for basic usage
- **Privacy-preserving** — The proof reveals nothing about your transaction history, balance, or which deposit funded you
- **Multi-ASP support** — Users can prove compliance against multiple providers simultaneously
- **No retroactive enforcement** — Users who don't need compliance proofs are unaffected

## View Key Sharing

For situations where full transparency is needed (tax reporting, institutional audits), Senddy's key architecture supports **voluntary disclosure**:

- The **spend key** controls funds and never leaves the user's device
- The **view key** can decrypt transaction history but cannot move funds
- Users can share their view key with auditors, accountants, or regulators to provide full read access without giving up control

This provides a spectrum of compliance options — from proving a single claim (association proof) to full transparency (view key sharing) — all without compromising the privacy of other users.