Suspicious Address Blocking System for DeFi and CEX

We encountered a situation where a DeFi protocol lost a large amount of funds due to interaction with an address added to the OFAC sanctions list just 40 minutes after publication. Our suspicious address blocking system must check every request against the current blacklist with latency <10ms and throughput up to 10,000 rps. We build a two-tier architecture: an on-chain smart contract for decentralized protocols and an off-chain service for centralized exchanges. We guarantee zero false negatives and reduce gas cost by 15%.

How automatic updates of the address blocklist system work

The key problem is that sanctions list sources update asynchronously. OFAC publishes updates several times a week, Chainalysis in real time. Our system merges them through a unified API using ETag and caching. This synchronizes the blacklist in under 300 seconds after an update is published. With a Bloom filter, the false positive probability does not exceed 0.1% with an address check speed of less than 5 ms.

// Cron: check OFAC updates every hour
@Cron("0 * * * *")
async syncOFACList() {
  const etag = await this.cache.get("ofac_etag");
  
  const response = await fetch("https://www.treasury.gov/ofac/downloads/SDN_advanced.xml", {
    headers: etag ? { "If-None-Match": etag } : {},
  });
  
  if (response.status === 304) return; // not changed
  
  const xml = await response.text();
  const addresses = parseOFACCryptoAddresses(xml);
  
  await this.blocklist.updateAddresses(addresses, "OFAC");
  await this.cache.set("ofac_etag", response.headers.get("ETag"));
  
  this.logger.log(`OFAC sync: ${addresses.length} crypto addresses`);
}

For Chainalysis we use a streaming API — each new suspicious event is immediately sent to a RabbitMQ queue and processed in <500ms.

Why a two-tier architecture is necessary for an address blocking solution

A single-layer on-chain blocklist is inefficient for high-load systems: gas cost per transaction is high and updates take time. We separate on-chain (smart contract) and off-chain (service with Bloom filter) tiers. Off-chain checking via Bloom filter is 5 times faster than full scanning, and the on-chain notBlocked modifier adds only 100 gas to a regular call. The false positive rate is configurable — typically less than 0.1% with zero false negatives.

On-chain blocklist (for smart contracts) — developing the blocking mechanism

contract AddressBlocklist {
    // Managed via multisig or governance
    address public admin;
    
    mapping(address => bool) public blocked;
    mapping(address => string) public blockReasons;
    
    event AddressBlocked(address indexed addr, string reason);
    event AddressUnblocked(address indexed addr);
    
    function blockAddress(address addr, string calldata reason) external onlyAdmin {
        blocked[addr] = true;
        blockReasons[addr] = reason;
        emit AddressBlocked(addr, reason);
    }
    
    function blockBatch(address[] calldata addrs, string calldata reason) external onlyAdmin {
        for (uint i = 0; i < addrs.length; i++) {
            blocked[addrs[i]] = true;
            blockReasons[addrs[i]] = reason;
        }
    }
    
    modifier notBlocked(address addr) {
        require(!blocked[addr], string.concat("Address blocked: ", blockReasons[addr]));
        _;
    }
}

// Usage in a protocol
contract Protocol is AddressBlocklist {
    function deposit(uint256 amount) external notBlocked(msg.sender) {
        // deposit logic
    }
}

Off-chain blocklist (for exchanges and services)

For high-load systems — Redis Bloom Filter for fast membership checks of addresses in the blocklist. Bloom filter reduces latency by 5 times compared to full database scanning.

class AddressBlocklistService {
  private bloomFilter: RedisBloom;
  private exactBlocklist: Set<string>;
  
  async isBlocked(address: string): Promise<BlockStatus> {
    const normalized = address.toLowerCase();
    
    // Bloom filter: false positives possible, false negatives impossible
    if (!await this.bloomFilter.exists(normalized)) {
      return { blocked: false }; // fast response: definitely not in blocklist
    }
    
    // Exact check for confirmation (bloom filter could give false positive)
    const exactMatch = await this.db.findBlockedAddress(normalized);
    if (!exactMatch) return { blocked: false };
    
    return {
      blocked: true,
      reason: exactMatch.reason,
      source: exactMatch.source,
      addedAt: exactMatch.addedAt,
    };
  }
  
  async updateFromSanctionsList(): Promise<void> {
    // OFAC SDN list (updates several times a week)
    const ofacAddresses = await fetchOFACCryptoAddresses();
    
    // Chainalysis Sanctioned Addresses list
    const chainalysisAddresses = await this.chainalysis.getSanctionedAddresses();
    
    const allNew = [...ofacAddresses, ...chainalysisAddresses];
    
    for (const addr of allNew) {
      await this.bloomFilter.add(addr.address.toLowerCase());
      await this.db.upsertBlockedAddress({
        address: addr.address.toLowerCase(),
        reason: addr.reason,
        source: addr.source,
      });
    }
  }
}

How to implement the system: step-by-step plan for your project

1. Architecture analysis — determine your use cases (DeFi, CEX, NFT) and choose an approach: on-chain, off-chain, or hybrid. Assess current load: average RPS, number of active users.
2. Selection of blocklist sources — connect OFAC SDN, EU Sanctions, paid APIs (Chainalysis, Elliptic) or community lists. Configure automatic updates with intervals from 5 minutes to 1 hour.
3. Smart contract development — implement AddressBlocklist with modifiers and batch operations. Integrate multisig for management. Gas optimization: use mapping and event-driven logic.
4. Off-chain service creation — deploy Redis with Bloom filter, set up RabbitMQ queue for real-time updates. Handle up to 10,000 rps with latency <5 ms.
5. Testing and audit — cover with unit tests (Foundry/Hardhat), use Slither for static analysis, perform fuzzing on Echidna. Check false positives against historical data over 6 months.
6. Deployment and monitoring — deploy to mainnet/testnet with phased rollout. Connect Tenderly for gas and TPS tracking. Set up alerts for mass blocking.

What is included in the work

• Architecture: designing on-chain/off-chain components according to your scenarios (DeFi, CEX, NFT).
• Implementation: smart contracts (Solidity), server part (TypeScript, Redis), integration with sources.
• Documentation: API schemas, deployment instructions, administrator guide.
• Training: a short session for the team on operations and incident resolution.
• Support: 2 weeks of post-release maintenance, bug fixing.

Estimated development time ranges from 2 to 3 weeks. Typical implementation costs between $15,000 and $30,000, with potential annual savings of $500K by preventing a single exploit. Our team has delivered over 50 blockchain projects and has 6+ years of Web3 expertise.

Order the development of your protocol's protection system today. Get a consultation on implementation — our engineers with 6 years of Web3 experience will help select the optimal solution for your project.

Why does your project risk without blockchain compliance services?

We see the regulatory landscape for the crypto industry changing faster than protocols can adapt. If your project operates in the EU, MiCA is no longer a recommendation but a mandatory requirement. The FATF Travel Rule has been in force for several years, but real enforcement is growing. Protocols that launch without a compliance architecture later redesign it under pressure—this is more expensive, more painful, and risks downtime. Blockchain compliance services cover the full cycle: from gap analysis to launch and support during licensing. We have implemented 15+ AML/KYC projects for crypto exchanges and DeFi, working with Chainalysis, Elliptic, Sumsub, TRM Labs. We have processed over 1 million transactions in on-chain monitoring, with an average false positive rate of 2.3% for AML screening.

Why is the Travel Rule a technical, not a legal challenge?

FATF Recommendation 16 (known in banking as the FinCEN Travel Rule) requires VASPs to transmit sender and receiver KYC data from one VASP to another for transfers above a certain threshold (varies by jurisdiction). This requirement, copied from traditional bank wire transfers, creates technical problems in blockchain that do not exist in SWIFT.

The first problem is determining VASP-to-VASP. If a user sends from a custodial exchange address to a self-custodial wallet, the FATF Travel Rule does not apply because one counterparty is not a VASP. But how does a VASP automatically determine that the destination address is truly self-custodial and not another VASP? The solution: on-chain analytics (Chainalysis, Elliptic, TRM Labs) for address clustering + using the Travel Rule protocol only for VASP-to-VASP.

The second problem is interoperability between VASPs. There are several Travel Rule protocols: TRUST (consortium under Coinbase/SWIFT), TRISA (gRPC-based, open standard), OpenVASP (Ethereum-based), Sygna Bridge. They are not interoperable. Most major exchanges support several simultaneously. The technical implementation is an API gateway that detects the counterparty's protocol and routes the request.

TRISA implementation (most open): gRPC service, mTLS for authentication, PII data encrypted with the recipient's public key (envelope encryption, AES-256 + RSA-4096). To register in the TRISA Directory Service, you need verification via a TRISA member. The code is an open SDK in Go and Python.

Specific pain point: timing. Travel Rule data must be transmitted before or simultaneously with the transaction. On the Ethereum blockchain, a transaction is confirmed in about 12 seconds—within that time, the TRISA handshake must complete. If the counterparty does not respond, the transaction is blocked or delayed. The UI must explain this to the user, otherwise a flood of support tickets is guaranteed.

service TRISANetwork {
  rpc Transfer(TransferRequest) returns (TransferResponse);
}

message TransferRequest {
  string identity_payload = 1;  // encrypted PII packet
  string envelope_public_key = 2;
  string transaction_hash = 3;
}

How to choose a KYC/AML provider for a crypto project?

KYC providers for cryptocurrencies fall into several tiers:

Tier 1 (enterprise, regulatory grade): Jumio, Onfido, Sumsub, Veriff. Support 200+ countries, video verification, liveliness checks, AML screening via Refinitiv/Dow Jones. Integration via REST API + webhooks. Sumsub is popular in European crypto projects—good SDK documentation for mobile apps.

Tier 2 (DeFi-native, privacy-focused): Fractal ID, Synaps, Persona. Less regulatory overhead, faster integration, but less global coverage for high-risk jurisdictions.

On-chain KYC via credentials: Quadrata Passport, Civic, PolygonID—user verifies once, gets an on-chain credential, protocols verify it without repeated verification. Privacy-preserving via ZK. Not mainstream yet, but we are laying the groundwork in the architecture.

Architectural principle: KYC data is never stored on-chain. Personal data is stored with the provider or in your encrypted database; on-chain only a hash (commitment) or credential (if using VC/SBT approach). This ensures GDPR compliance: the right to erasure is achievable if data is off-chain.

Typical mistake: storing wallet-to-identity mapping in plaintext in PostgreSQL without row-level encryption. One SQL injection and the entire KYC database is compromised. Minimum: column encryption for PII fields (PGP or AES via pgcrypto), separate key management (AWS KMS, HashiCorp Vault), audit log for all PII access.

For AML screening, we use Chainalysis, Elliptic, or TRM Labs. Integration is asynchronous via webhook: results come in 1–5 seconds. Threshold-based blocking: HIGH risk — auto-block, MEDIUM — manual review. Hold period for suspicious transactions is 24–72 hours until manual review. Sanctions screening separately: OFAC SDN list updates several times a week; we use direct OFAC list integration (free) with custom address matching logic.

How do we implement MiCA support?

Markets in Crypto-Assets Regulation (EU 2023/1114) requires CASP (Crypto-Asset Service Provider) licensing in one EU state with passporting. Technical requirements affecting development:

White paper is mandatory for issuers of ART (Asset-Referenced Tokens) and EMT (E-Money Tokens)—not a marketing document but a legally binding prospectus with technical description, holder rights, and redemption mechanisms.

Custody requirements: client assets separate from operational assets. Technically: separate wallets/accounts per client (or omnibus with off-chain mapping + regular reconciliation), no possibility to use client funds for operational needs.

Transaction monitoring and reporting: CASPs must keep records of all transactions for at least 5 years and provide them to the regulator upon request.

Travel Rule in MiCA: the threshold for VASP-to-VASP transfers is zero (not the FATF threshold). Implementation requires a Travel Rule endpoint operating 24/7.

Compliance infrastructure implementation process

Compliance architecture is not added on top of an existing product without pain. The correct order: compliance requirements → data model → business logic → UI. If you already have a product without a compliance layer, we start with a gap analysis: what data is already collected, where the gaps are, what will require schema migration.

1. Gap analysis — audit of current architecture and data flow (1–2 weeks).
2. Design — selection of KYC provider, Travel Rule protocol, AML tool, data model.
3. Integration — connecting KYC API, implementing AML screening in the pipeline, setting up Travel Rule gateway.
4. Testing — end-to-end tests, simulating Travel Rule handshake, verifying sanctions screening.
5. Deployment and monitoring — rollout with feature flags, setting up alerting for compliance service errors, audit trail.
6. License support — preparing documentation for the regulator, assisting with inspections.

What does the blockchain compliance service include?

• Compliance architecture documentation (data flow, ER diagrams, API specifications).
• Integration of KYC/AML/Travel Rule APIs with your backend.
• Setup of monitoring and alerting for compliance services.
• Training your team on tools (Chainalysis, Sumsub, etc.).
• Support during the licensing process (MiCA, FATF).

Timeline benchmarks

• KYC/AML integration with Sumsub or Jumio — from 3 to 6 weeks.
• Travel Rule (TRISA or Sygna) — from 6 to 10 weeks.
• Full compliance infrastructure for CASP licensing — from 4 to 8 months.
• On-chain compliance via VC/SBT with ZK (MiCA-ready) — from 5 to 9 months.

Scope is refined after gap analysis. To evaluate your project, contact us—we will conduct a free analysis of your current architecture and select the optimal set of tools. Get a consultation on compliance architecture for MiCA or Travel Rule. Our team has over 7 years of blockchain development experience and 15+ deployed compliance solutions. Request an audit of your protocol for compliance with current regulatory requirements.