Wallet Intelligence

The problem

Every AML vendor scores Ethereum mainnet well. Almost none of them understand the corridors where African fraud actually moves: TRON-based USDT, regional exchanges with thin compliance teams, and OTC desks that exist only in Telegram groups. Local exchanges and fintechs were buying expensive Western screening tools that returned "no data" for the addresses that mattered most to them.

41Swara had something those vendors didn't: years of incident-response engagements that produced a proprietary database of malicious addresses, scam clusters, and mule patterns specific to East African flows. Wallet Intelligence turns that database into a product.

Constraints

• Evidence quality over coverage. A false "high risk" flag on an innocent customer is a regulatory and reputational event for our clients. Every label in the database carries provenance — which engagement, what evidence class, what confidence — and scores expose that provenance instead of hiding it behind a number.
• TRON is different plumbing. Resource model, address format, token semantics — TRON support couldn't be an EVM adapter with the serial numbers filed off. It got its own ingestion path.
• Client data never leaves the engagement. The malicious-address database is built from consulting work under strict confidentiality. The pipeline anonymizes at ingestion: behavioral fingerprints and addresses survive; client identity and case detail never enter the product boundary.

Architecture

• Ingestion workers (Go) stream blocks from EVM chains and TRON into a normalized transfer model, with chain-specific decoders kept thin and isolated.
• A wallet graph built on the transfer stream: nodes are addresses, edges are value flows with temporal weighting. Cluster expansion runs as scheduled jobs, not at query time, so lookups stay fast.
• Risk scoring combines three signals — direct database hits, graph proximity to labeled clusters, and behavioral heuristics (peel chains, fan-out structuring, dormancy-then-burst). The API returns the score and the path: which hops, through which entities, with what confidence.
• Sub-200ms lookups because scoring is precomputed and the query path only ever touches the serving store. Screening sits in our clients' transaction hot path; latency is a feature.

My role

I own the technical direction: the graph model, the scoring design, and the anonymization boundary between consulting work and product. I wrote the TRON ingestion path personally and review every heuristic before it can affect a production score.

Outcomes

• In production with regional exchanges screening deposits and withdrawals against corridors no incumbent vendor covers.
• The provenance-first scoring design survived its first regulatory audit without findings — the auditors could trace every flag to evidence.
• The malicious-address database now grows from both directions: consulting engagements feed the product, and product detections open new engagements.