ECIP 1119: Treasury Sanctions Compliance Oracle
| Author | Cody Burns |
|---|---|
| Discussions-To | https://github.com/orgs/ethereumclassic/discussions/530 |
| Status | Draft |
| Type | Standards Track |
| Category | ECBP |
| Created | 2026-03-17 |
| Requires | 1112 |
Simple Summary
This ECIP introduces a multi-oracle sanctions compliance layer for Ethereum Classic treasury governance, ensuring that all disbursements from the Olympia Treasury (ECIP-1112) are screened against international sanctions lists before execution. Competitive oracle providers deliver screening services on-chain, withdrawals are conditional on passing compliance checks, and funds atomically return to the treasury if recipients are sanctioned. Privacy is preserved through zero-knowledge proofs during market participation, with compliance verified only at withdrawal.
Motivation
This proposal introduces a multi-oracle sanctions turnstile integrated with the futarchy governance system established in ECIPs 1117/1118. Rather than relying on a single centralized compliance provider, the system creates a competitive marketplace where oracle service providers bid for DAO funding to deliver sanctions screening data on-chain. The architecture implements pessimistic withdrawal checking—every fund release requires positive clearance from a stake-weighted oracle consensus before execution.
Three foundational principles guide the design. First, atomic fund protection: if any oracle flags a recipient as sanctioned, the withdrawal transaction reverts and funds remain in the vault without requiring separate recovery logic. Second, privacy preservation: market participants can trade on prediction markets without identity disclosure, with compliance verification occurring only at withdrawal through zero-knowledge proofs of non-sanctioned status. Third, competitive accountability: oracle providers must stake collateral, meet service-level agreements, and face slashing for stale or incorrect data, with the DAO retaining authority to rotate underperforming providers.
The sanctions data landscape
OFAC’s Specially Designated Nationals (SDN) list serves as the primary U.S. sanctions enforcement mechanism, containing individuals, entities, vessels, and since November 2018, cryptocurrency wallet addresses. The list is available in multiple formats—XML, CSV, and fixed-width files—through Treasury’s download portal at treasury.gov/ofac/downloads/sdn.xml. treasury Critically, OFAC provides no real-time API; institutions must implement scheduled downloads and determine their own update frequency based on risk assessment.
The EU maintains a parallel consolidated sanctions list through the European Commission, available via the Sanctions Map portal at sanctionsmap.eu. A significant compliance risk exists because transposition delays of over 20 days have been documented between Official Journal publication and consolidated list updates. UN Security Council sanctions, currently covering 30 regimes including 252 individuals and 89 entities on the ISIL/Al-Qaida list, serve as the foundation for most national lists.
Traditional financial institutions achieve near-real-time compliance through commercial providers like SWIFT Transaction Screening, which maintains a library of 70+ sanctions lists updated every 15-60 minutes. This creates the benchmark ECIP-1119 must approximate: sub-hourly list synchronization with comprehensive multi-jurisdictional coverage.
Tornado Cash precedent reshapes protocol compliance
The Fifth Circuit’s November 2024 ruling in Van Loon v. Department of Treasury fundamentally altered the sanctions landscape for blockchain protocols. The court held that immutable smart contracts cannot constitute “property” under IEEPA because they lack the essential characteristics of ownership—no party can exclude others from using them, and they remained accessible even after OFAC designation. Treasury subsequently delisted Tornado Cash in March 2025, Cointelegraph acknowledging “novel legal and policy issues.”
However, this ruling creates a critical distinction: mutable smart contracts remain potentially sanctionable. For ECIP-1119’s upgradeable compliance modules, this means the proxy architecture must be carefully designed. More importantly, the criminal prosecutions of Tornado Cash developers Roman Storm and Alexey Pertsev demonstrate that individual liability persists regardless of protocol-level exemptions. DAO participants governing compliance parameters face potential exposure under the CFTC v. Ooki DAO precedent, where token holders were treated as general partners with joint liability.
OFAC’s October 2021 guidance makes the compliance framework clear: virtual currency participants must implement risk-based sanctions programs including management commitment, risk assessment, internal controls, testing, geolocation tools, and blockchain analytics. a16zcrypto Global Legal Insights Smart contract automation alone does not satisfy these obligations—human oversight remains mandatory.
On-chain screening infrastructure today
The Chainalysis Sanctions Oracle represents the only production on-chain compliance solution, deployed at address 0x40C57923924B5c5c5455c48D93317139ADDaC8fb across Ethereum, Polygon, Arbitrum, Optimism, and other EVM chains. The oracle exposes a simple interface:
interface SanctionsList {
function isSanctioned(address addr) external view returns (bool);
}
This service is free and requires no customer relationship, making it an attractive baseline layer. However, independent analysis by ChainArgos revealed update latencies of 66-92 days between OFAC designation and oracle synchronization—a critical gap for compliance-critical applications.
TRM Labs offers a complementary API-based approach with cross-chain coverage spanning 25-28 blockchains. Their free tier permits 100 queries daily (1,000 per day with API key), returning simple boolean responses. The enterprise offering includes behavioral detection for structuring, mixing, and bridge usage patterns. Elliptic provides similar capabilities with coverage across 50+ blockchains and 250+ cross-chain bridges, Elliptic Elliptic though neither offers direct on-chain oracle infrastructure.
The recommended hybrid architecture layers these solutions: Chainalysis Oracle for instant on-chain baseline checks, TRM Labs API via Chainlink Functions for enhanced screening and cross-chain coverage, and a DAO-controlled override mechanism for appeals and edge cases.
Chainlink infrastructure for compliance oracles
Chainlink’s recently announced Automated Compliance Engine (ACE) provides purpose-built infrastructure for sanctions compliance, featuring pre-transaction eligibility checks, allowlist/denylist policy enforcement, and hold policies for sanctioned wallets. Chainalysis The platform integrates with Chainalysis KYT for automated sanctions screening (launching Q2 2026) Crypto Briefing and GLEIF’s verifiable Legal Entity Identifier system for wallet-to-entity mapping. Identity Week
For custom sanctions data delivery, Chainlink Functions enables serverless computation that queries external APIs (including premium sanctions databases) using threshold-encrypted API keys. Chainlink Chainlink A typical sanctions check costs approximately 0.24 LINK per request (roughly $2-4 USD) including gas overhead of ~185,000 gas for FunctionsRouter coordination plus callback execution. Chainlink L2 deployments on Arbitrum or Optimism reduce costs by 90%+.
The Decentralized Oracle Network (DON) security model provides defense-in-depth through multiple independent Sybil-resistant nodes Chainlink (including Deutsche Telekom, Swisscom, and Vodafone), Off-Chain Reporting (OCR) consensus with median aggregation, and cryptographic signatures on all data points. Cyfrin Updraft Chainlink’s Staking v0.2 adds cryptoeconomic security with 45 million LINK staked, chain Chainlink 700 LINK slashing per node for valid downtime alerts, chain and a 28-day unbonding period. Chainlink chain
Circuit breaker and conditional withdrawal architecture
The core withdrawal mechanism implements a checks-effects-interactions pattern where sanctions verification occurs before any state changes:
function conditionalWithdraw(uint256 amount) external nonReentrant {
// CHECKS: Multi-oracle sanctions consensus
require(!aggregateSanctionStatus(msg.sender), "SANCTIONED");
require(balances[msg.sender] >= amount, "INSUFFICIENT");
// EFFECTS: Update state before external call
balances[msg.sender] -= amount;
// INTERACTIONS: Transfer last
(bool success,) = msg.sender.call{value: amount}("");
require(success, "TRANSFER_FAILED");
}
Multi-oracle consensus prevents single-point-of-failure manipulation. The recommended pattern collects responses from N registered oracle providers, applies stake-weighted voting where each provider’s vote counts proportionally to their bonded collateral, removes statistical outliers, and requires M-of-N agreement (typically 2/3 majority). Cyfrin Updraft Chainlink Blog If any threshold condition fails, the entire transaction reverts atomically—funds never leave the vault for sanctioned addresses.
Emergency override mechanisms address oracle network failures through tiered circuit breakers. Cyfrin Updraft Chainterms Tier 1 automatically pauses high-risk functions when oracle staleness exceeds thresholds. Tier 2 enables complete protocol freeze via multi-signature authority. Tier 3 activates emergency shutdown with time-locked fund withdrawal capability bypassing normal sanctions checks after extended delay periods (e.g., 14 days).
Gas efficiency for per-transfer sanctions checking runs approximately 2,500 gas for simple on-chain lookups (Chainalysis Oracle), 15,000-30,000 gas for multi-oracle consensus with three providers, and 40-60% savings through batch processing of multiple withdrawal requests where base transaction costs amortize across the batch.
Privacy-preserving compliance through zero-knowledge proofs
The fundamental tension between prediction market privacy and sanctions compliance resolves through zero-knowledge proofs of non-sanctioned status. Users can mathematically demonstrate they are NOT on a sanctions list without revealing their identity. The mechanism operates as follows: a KYC provider issues cryptographically-signed credentials containing identity information; the user generates a ZK proof that their identity hash does not match any sanctions list entry; the on-chain verifier confirms proof validity without learning actual identity.
Production-ready implementations include Polygon ID (zk-SNARKs with BBS+ signatures for selective disclosure), zkPass (zkTLS protocol proving attributes from Web2 sources without API access), and Galactica Network (zkKYC tokens with government decryption capability for fraud investigation). The W3C Verifiable Credentials Data Model v2.0 (May 2025 recommendation) provides the standardized framework for selective disclosure—holders reveal only specific claims needed (e.g., “not sanctioned”) without exposing full identity.
Privacy Pools, launched April 2025 on Ethereum following Vitalik Buterin’s seminal 2023 paper, represent the cutting edge of compliant privacy. Users deposit into a privacy pool and on withdrawal generate ZK proofs that their deposit belongs to a “good” association set excluding known illicit deposits. This creates a separating equilibrium where honest users demonstrate compliance while bad actors cannot produce valid proofs.
For ECIP-1119’s integration with Nightmarket-style prediction markets, a tiered model applies: anonymous trading below thresholds with address-only screening, zkKYC attestation for medium-value participation, and enhanced due diligence at fiat off-ramps with selective de-anonymization capability for legal process.
Competitive oracle market design
The oracle marketplace operates through DAO-governed RFP (Request for Proposal) cycles following established patterns from ENS, Compound, and dYdX DAOs. Providers submit proposals specifying technical capabilities, data sources, SLA commitments, and pricing. A working group evaluates applications based on:
-
Technical requirements: Data freshness (within 24 hours of OFAC updates), query response latency, multi-chain coverage
-
Performance metrics: 99.9% uptime (max 43.8 minutes monthly downtime), false positive rate commitments
-
Bond requirements: Minimum stake (e.g., 10,000 tokens) with maximum caps to prevent concentration
-
Term structure: 6-12 month service periods with competitive re-bidding at renewal
Provider reputation accumulates through on-chain performance tracking across dimensions including task-level accuracy, completion time, historical performance, and uptime. Gemini Frontiers A sliding window mechanism weights recent performance more heavily, while threshold-based adjustment prevents single-provider dominance. The BLOR (Bayesian Learning Oracle Reputation) model from academic research achieves 94%+ accuracy in identifying optimal nodes through dynamic reputation adjustment using reinforcement learning. Frontiers
Economic incentives align through multiple revenue streams: base fees (fixed periodic payment for maintaining service), per-query fees (variable based on usage), performance bonuses (rewards for exceeding SLA metrics), and staking rewards (returns on bonded collateral). Medium DEV Community Slashing conditions include 5-25% of bond for data staleness exceeding thresholds, providing false sanctions data verified through fraud proofs, and extended downtime beyond SLA parameters. Chainlink Blog
Technical integration with ECIP-1117/1118 prediction markets
The sanctions compliance layer integrates with futarchy governance through modifications to the prediction market settlement flow. When markets resolve and winning positions become withdrawable:
-
Position claim: User submits withdrawal request for resolved market position
-
Sanctions query: Settlement contract calls multi-oracle aggregator with recipient address
-
Consensus computation: Aggregator collects stake-weighted responses, applies 2/3 majority threshold
-
Conditional release: If consensus returns “not sanctioned,” funds transfer; otherwise, transaction reverts
-
Return to vault: Blocked funds remain in treasury, logged with sanctions reason code
Edge cases require specific handling. Sanctioned mid-market: Positions opened before sanctions designation but withdrawn after must be blocked at withdrawal; the prediction market itself operates permissionlessly while the treasury gate enforces compliance. Appeals process: Users can initiate governance-controlled appeals through timelock-protected override votes; during appeal periods, funds remain locked but not permanently confiscated. Delisting scenarios: If an address is removed from sanctions lists (as occurred with Tornado Cash), the governance override mechanism enables fund release following verification.
Upgrade paths accommodate evolving sanctions requirements through modular architecture. The sanctions checker interface permits swapping implementations via DAO governance vote with timelock protection:
interface ISanctionsChecker {
function isSanctioned(address account) external view returns (bool);
function batchCheck(address[] calldata accounts) external view returns (bool[] memory);
}
The Diamond Pattern (EIP-2535) enables independent upgradeability of compliance facets—sanctions, jurisdiction, KYC—without modifying core treasury logic. Beacon proxies permit synchronized upgrades across multiple vault deployments through single-transaction implementation changes.
Implementation architecture summary
┌─────────────────────────────────────────────────────────────────┐
│ DAO GOVERNANCE LAYER │
│ • Issues oracle service RFPs │
│ • Sets SLA requirements and evaluation criteria │
│ • Manages provider rotation and appeals │
└────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────┐
│ ORACLE SELECTION CONTRACT │
│ • Provider registry with stake tracking │
│ • Reputation scoring (accuracy, uptime, latency) │
│ • Automatic rotation based on performance │
└────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────┐
│ MULTI-ORACLE AGGREGATOR │
│ • Collects responses from N providers │
│ • Stake-weighted voting with outlier removal │
│ • 2/3 consensus threshold for sanctions determination │
│ • Fallback to Chainalysis Oracle if consensus fails │
└────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────┐
│ WITHDRAWAL TURNSTILE (Upgradeable Proxy) │
│ • CEI pattern: check sanctions before any transfer │
│ • Atomic reversion: funds never leave for sanctioned addresses │
│ • Circuit breakers: tiered pause mechanisms │
│ • Emergency override: extended timelock bypass for failures │
└────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────┐
│ PRIVACY COMPLIANCE LAYER │
│ • zkKYC verification via Polygon ID or zkPass │
│ • Privacy Pools integration for source-of-funds attestation │
│ • Selective de-anonymization escrow for legal process │
└─────────────────────────────────────────────────────────────────┘
Recommended parameters and deployment strategy
| Parameter | Recommended Value | Rationale |
|———–|——————|———–|
| Minimum oracle providers | 3 | Redundancy without excessive coordination costs |
| Consensus threshold | 2/3 (67%) | Byzantine fault tolerance standard |
| Minimum provider bond | 10,000 ETC | Meaningful stake for accountability |
| Data staleness threshold | 24 hours | Balance freshness with update latency |
| Emergency timelock | 14 days | Extended period for oracle failure recovery |
| Slashing rate (staleness) | 5% of bond | Proportionate penalty for minor violations |
| Slashing rate (false data) | 25% of bond | Severe penalty for compliance failures |
| Provider term length | 12 months | Stability with competitive pressure |
| Appeals window | 7 days | Sufficient time for governance review |
Deployment phases: Phase 1 integrates Chainalysis Oracle as single-provider baseline with DAO override capability. Phase 2 adds Chainlink Functions for TRM Labs API queries and multi-oracle aggregation. Phase 3 implements zkKYC attestation and Privacy Pools integration. Phase 4 launches competitive oracle marketplace with full RFP framework.
Conclusion
ECIP-1119 establishes a sanctions compliance architecture that threads the needle between regulatory necessity and decentralization principles. By creating a competitive oracle marketplace rather than hardcoding a single provider, the system maintains censorship resistance while satisfying compliance obligations. The multi-oracle consensus mechanism prevents any single entity from blocking legitimate withdrawals, while atomic fund protection ensures sanctioned addresses never receive treasury funds.
The privacy-preserving compliance layer through zkKYC and Privacy Pools represents the current frontier of regulatory-compatible privacy, enabling prediction market participants to trade without identity disclosure while producing verifiable compliance attestations at withdrawal. This positions ETC’s futarchy governance as potentially the first prediction market system with protocol-native sanctions compliance—a necessary evolution as regulatory scrutiny of DeFi intensifies following the Tornado Cash precedent.
The proposal’s most significant innovation is treating sanctions oracle services as a competitive market rather than infrastructure dependency. Oracle providers compete on data freshness, accuracy, and price, with underperformers facing slashing and rotation. This creates aligned incentives: providers profit from reliable service while the DAO retains sovereignty over compliance parameters. The result is a compliance layer that strengthens rather than compromises decentralization.