1. Summary
This post proposes a new public-good security primitive for Arbitrum: an Open Theft Signal (OTS) a victim-activated risk signal for wallet addresses.
The idea is not to censor any address on-chain, but to create a shared infrastructure where theft victims can submit evidence, and the ecosystem (wallets, dapps, exchanges, bridges, risk tools) can consume a standardized risk signal in near real time.
2. Personal context (why I care)
Recently, my own MetaMask wallet was drained.
I did not interact with any obvious scam site or approve a “max” transaction that I remember. The funds were just gone, sent to a fresh, unknown address.
As a DAO governance researcher, this incident forced me to think in structural terms:
we have strong tools for screening addresses, but almost no shared way for victims to broadcast “this address is stealing funds” in a structured, machine-readable way that the rest of the ecosystem can actually use.
3. Current state: strong screening, weak victim signal
Today, the crypto ecosystem already uses:
-
Wallet screening and risk scoring tools that analyze addresses, assign risk scores, and detect sanctions or known scam exposure.
-
Sanctions and blacklist enforcement stablecoin issuers and exchanges can freeze or review funds when addresses are linked to sanctions or known illicit clusters.ofac.
-
Security tooling and risk data networks Web3 security products and risk networks already offer APIs to warn users about malicious contracts, drainers, and scam domains.alchemy+2
However, there is a missing piece:
We do not have a universal, open, victim-initiated “proof-of-theft” signal that can quickly mark an address as “under theft investigation” with a clear confidence score and evidence trail.
Most victims today only have social media, DMs, or ad hoc Discord messages. That is not infrastructure.
4. Concept: Open Theft Signal (OTS)
Objective:
Create an open, neutral signal layer where any user who gets hacked can submit a structured report, which is then turned into a risk signal for addresses that other services on Arbitrum can consume.
High-level flow:
-
Complaint / report
-
Victim submits a report with:
-
Their address
-
Suspected thief / destination address
-
Transaction hashes and timestamps
-
Basic context (for example, interacted with website X, signed transaction type Y)
-
-
-
Evidence & scoring
-
Backend / oracle checks:
-
On-chain flows (source → victim → thief → mixers / bridges / CEX)
-
Known drainer / phishing patterns
-
Other reports against the same address or clusterelliptic+2
-
-
Generates a risk score and a confidence level, instead of a binary “good / bad” label.scorechain+1
-
-
Signal output
-
Address gets labelled as, for example:
-
“Theft-reported: under review”
-
“High confidence theft address”
-
-
This label + score is exposed through an open API or oracle feed.
-
-
Ecosystem reaction (opt-in)
-
Wallets / dapps on Arbitrum can:
-
Show warnings when users try to send funds to such addresses
-
Require extra confirmation (“I understand this address is under theft investigation”)
-
-
Centralized exchanges / KYC services (where legally possible) can:
-
Flag deposits
-
Apply enhanced review / monitoring on suspicious flowschainalysis+3
-
-
This does not change Ethereum / Arbitrum consensus.
It adds an information layer on top that makes theft harder to hide and easier to react to.
5. Why Arbitrum is a good place to discuss this
Arbitrum has:
-
A large DeFi footprint where user fund safety is critical.
-
Strong builders in wallet security, risk data, and compliance tooling.webacy+1
-
A governance and public goods culture that supports open infrastructure work.
If we design OTS as an open standard, Arbitrum can be an early adopter and key stakeholder, without centralizing power in a single vendor.
6. Important design and governance questions
To keep this short, I will list the main open questions instead of full answers:
-
Who reviews and escalates reports?
- Options: security alliance, multi-DAO council, risk service consortium, or hybrid.
-
How to prevent abuse / fake reports?
-
Confidence scoring
-
Reputation for reporters
-
Clearly separated labels like “1 report, low confidence” vs “clustered, high confidence”
-
-
Appeals and expiry
-
Should labels decay over time if no new evidence appears?
-
How can wrongly reported addresses request re-evaluation?
-
-
Funding model
-
Public goods funding (DAO grants, OP-style impact funding, etc.)
-
Hybrid model with open core + paid enterprise integration.
-
Personally, I see this as a public-good coordination layer, closer to “shared data infra” than to “one more private SaaS tool.”
7. What I am asking the Arbitrum community
Right now, this is an RFC / concept discussion, not a formal proposal.
I would like feedback on:
-
Does the Arbitrum community agree that a victim-activated theft signal is a missing piece in our security stack?
-
If yes, should we explore:
-
A research working group or small task force to map existing tools and gaps?
-
An RFP / grant for a neutral OTS prototype focused on Arbitrum flows?
-
-
Which existing projects (wallets, risk data networks, security DAOs, compliance tools) should be in the room from day one?
I am happy to contribute from the governance and risk design side as MconnectDAO (research, analysis, and requirements), and collaborate with technical teams who can handle implementation.
8. Closing
My own wallet hack was a small event compared to the billions lost in large exploits every year. But on an architectural level, it highlighted a simple truth for me
We have good tools for analyzing bad addresses,
but almost no shared way for victims to signal them in time.
If Arbitrum wants to be a safe home for the next wave of users and protocols, I believe it is worth exploring an Open Theft Signal as part of our broader security and governance toolkit.
Looking forward to your thoughts, questions, and criticism.
Manoj Kumar Desai
DAO Governance Researcher, MconnectDAO