Compliance

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.

Deposit Screening

How it works

Every deposit into the Senddy pool is screened against the Chainalysis sanctions oracle — 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:

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.