Sanctions policy

DRAFT — pending counsel review.

How Plaza screens withdrawal addresses and counterparty wallets against sanctions lists. Posture, mechanism, escalation.

Posture

Plaza facilitates value movement and therefore screens. We do not treat sanctions screening as optional, and we do not treat it as solved. Two principles govern the policy:

1. Block before pay. Screening happens at withdrawal authorization time, before any on-chain transaction is broadcast. A blocked address cannot receive a payout.
2. Conservative defaults. When the screening provider returns ambiguous, Plaza treats the result as a hit and routes for human review. Customer-facing tone explains the delay; we do not falsely claim a problem with the address.

Mechanism

Plaza uses Chainalysis Free Sanctions Oracle as the primary screening source. The oracle is a free public on-chain contract on multiple chains (including Base) that returns sanctioned/clean for any given EVM address.

The integration:

• Every wallet address registered to a Plaza account is screened on registration.
• Every withdrawal destination is re-screened immediately before payout broadcast. The check is cheap (one RPC call) and freshness matters — sanctions designations change.
• Hits are stored against the wallet record with a timestamp and source. Stored hits expire after 24 hours and are re-screened on next use; this prevents stale negative caching from blocking a legitimate address whose listing changed.

A secondary screening source (TRM Labs or Elliptic) is on the procurement track for production. Until that is in place, Chainalysis is the only source. The architecture supports multiple sources with an OR aggregation — an address is blocked if any source flags it.

withdrawal request
  → ledger pre-flight (sufficient balance?)
  → sanctions screen (cached for 24h, re-screened if expired)
  → on hit: pause payout, open internal review case, notify counterparty
  → on clean: signer, broadcast, monitor

The screening call site is in crates/plaza-payout/src/screening.rs (available in v0.0.2). Today the placeholder always returns clean; the production toggle is PLAZA_SANCTIONS_SCREENING_ENABLED=1. The toggle defaults to off in development and on in production; CI fails if the production manifest sets it to off.

What is screened

• Withdrawal destinations (payout target addresses).
• Wallet registration on account creation.
• Funding source addresses on EIP-3009 buyer payments — passively screened, not blocked. A flagged funding source raises a review case but does not stop the order; the order’s funds are then quarantined until reviewed.

What is not screened:

• Email addresses, names, or off-chain identity. Plaza is not OFAC-licensed for non-on-chain screening at launch. Counsel review will determine the eventual scope.
• Sub-addresses of MPC custodians (Turnkey, Privy). The provider screens at their layer; Plaza relies on that.

Escalation ladder

When a screening hit fires, the case routes to the operations review queue. The ladder:

1. Tier 1 — operations review. A reviewer confirms the hit against the source list. False positives (typically a typo or a stale designation) are cleared and the address is whitelisted with an audit log entry.
2. Tier 2 — compliance lead. If the hit is real or ambiguous, the compliance lead decides whether to block permanently, hold pending more information, or refer to counsel. SLA: 24 business hours from hit.
3. Tier 3 — counsel. Real hits on sanctioned-list designations route to outside counsel. Plaza does not unilaterally release a blocked address. SLA: as advised by counsel.
4. Tier 4 — regulator notification. When required by counsel. Plaza does not disclose between Tier 3 and Tier 4 to the affected party.

The on-call engineer is not in this ladder. Sanctions hits are not pages. The review queue is monitored daily by the operations team.

Customer-facing tone

The user-visible message on a sanctions hit:

Withdrawal paused for review. Plaza screens withdrawal addresses against public sanctions lists. This typically clears within 24 hours; if there is a real issue we will contact you directly.

We do not name the screening provider in the user-facing message. We do not confirm or deny a specific list designation. The customer-facing copy is in frontend/copy/wallet.ts under screening.

If the hit is cleared (false positive), the customer sees the withdrawal proceed normally and a single audit log entry recording the screening review.

Audit log

Every screening event — registration check, withdrawal check, review action, override — is recorded in the audit log against the affected account. The log is queryable by the account owner via the GDPR export pipeline, with sanctions-specific entries redacted to avoid tipping off where the line is.

Reciprocity

Plaza screens its own withdrawal queue; it does not require pilot orgs to operate their own screening. Pilot orgs that do operate their own screening (because they are themselves regulated) can subscribe to webhook events on screening outcomes for their own audit needs. The webhook event types withdrawal.screening.cleared and withdrawal.screening.hit ship in v0.0.2.

Open questions for counsel

• The exact list of jurisdictions Plaza must screen against. OFAC SDN at minimum; UK / EU / UN lists likely; counsel to confirm the matrix.
• Recordkeeping retention period for screening events. Default is 7 years until counsel advises otherwise.
• Whether Plaza needs an MSB / money transmitter classification at launch volume, and how that affects the screening posture.
• Cross-border data handling — screening provider is US-based; some pilot org data flows through it.

These are tracked in BLOCKERS.md under the Legal section.