Open Theft Signal for Arbitrum: Victim-Activated Wallet Risk Layer

Early Idea Discussion
1

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:

  1. 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)

  2. 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

  3. 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.

  4. 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:

  1. Does the Arbitrum community agree that a victim-activated theft signal is a missing piece in our security stack?

  2. 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?

  3. 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

2

The gap identified here is real. Before OTS moves toward an RFP or prototype, one architectural correction is essential:

The system must not treat an address as the primary unit of truth. It must treat an incident-bound evidence graph as the primary unit of truth.

A destination address is an observation, not an attribution.

The first recipient of stolen funds may be an attacker-controlled wallet, but it may also be a relay, a router, a bridge endpoint, a pooled exchange deposit address, a smart contract, a compromised intermediary, or an unrelated address deliberately inserted into the path. If OTS attaches a global “thief” label directly to an address, one incorrect or malicious report can contaminate every downstream consumer of the signal.

This is not a minor implementation detail. It determines whether OTS becomes reliable security infrastructure or a scalable false-positive amplifier.

1. Separate the claim, the evidence, the attribution, and the response

These are four different layers and should never be collapsed into one score.

Claim

A reporter asserts that a specific incident occurred.

Evidence

The system records independently verifiable facts: transactions, logs, approvals, call traces, token movements, bridge messages, contract interactions, block positions, and cryptographically committed supporting material.

Attribution

An analytical process determines the role of each address or contract within that particular incident.

Response

Each consuming wallet, dApp, bridge, exchange, or monitoring system decides what operational action is appropriate.

OTS should transport evidence and attribution. It should not silently convert a victim report into a universal enforcement decision.

A report can therefore be validly submitted without the alleged attribution already being accepted as true.

2. Bind every signal to a specific incident

The core object should be an immutable incident record containing, at minimum:

  • incident identifier;
  • chain ID;
  • claimant address or account;
  • affected address or account;
  • transaction hashes;
  • block numbers and ordering;
  • affected assets and amounts;
  • relevant approval or signature events;
  • observed destination addresses;
  • report creation time;
  • evidence-bundle hash;
  • signature domain;
  • nonce;
  • schema version.

The claimant can sign a typed report. Contract accounts and multisigs must also be supported, rather than assuming that every claimant is an EOA.

That signature establishes that a defined account authorized the report at a defined time. It does not, by itself, prove that the transfer was unauthorized or that the first recipient controlled the theft.

This distinction is especially important when the original wallet may already be compromised. An attacker who controls the key may also be capable of signing reports or counter-reports.

3. Assign incident-specific roles instead of permanent address labels

Each node in the incident graph should receive a role based on the available evidence, for example:

  • victim account;
  • direct recipient;
  • suspected operator-controlled account;
  • relay;
  • consolidation point;
  • dispersal point;
  • bridge entry;
  • bridge exit;
  • exchange deposit endpoint;
  • mixer exposure;
  • beneficiary;
  • smart-contract infrastructure;
  • unrelated infrastructure;
  • unresolved role.

An address may occupy different roles in different incidents. A bridge contract is not a thief because stolen funds passed through it. A pooled exchange address is not attacker-controlled merely because it received a deposit. A compromised wallet can be a victim in one incident and an intermediary in another.

The signal must therefore be:

  • incident-scoped;
  • role-aware;
  • directional;
  • time-bounded;
  • evidence-linked.

A global address label should be produced only when repeated, independent evidence supports a persistent control attribution.

4. Do not reduce confidence to an opaque number

A single score such as 87/100 conceals the structure of the conclusion. Two addresses can receive the same score for completely different reasons and require completely different responses.

Confidence should be decomposed into independent evidence dimensions, such as:

  • claimant-control confidence;
  • incident-causality confidence;
  • transaction-path continuity;
  • common-control evidence;
  • cluster continuity;
  • known malicious-infrastructure exposure;
  • independent corroboration;
  • temporal consistency;
  • beneficiary linkage;
  • control persistence;
  • counter-evidence;
  • contestation status.

The API may still expose a compact confidence class for operational use, but it must also return reason codes and the underlying evidence categories.

Report volume must not be mistaken for evidence independence.

One hundred coordinated reports produced by one operator are not one hundred independent confirmations. They are one source repeated one hundred times. Reporter reputation may help prioritize review, but it cannot substitute for transaction-level evidence.

5. Separate historical truth from current operational risk

A confirmed incident does not cease to exist because time has passed. What may change is the current relevance of an address-level warning.

OTS should therefore maintain two separate objects:

  1. Permanent incident history
    The record of what occurred, which evidence supported it, and how the conclusion evolved.
  2. Time-varying operational risk state
    Whether the address is still active, still controlled by the same entity, still receiving related funds, contested, dormant, recovered, or no longer suitable for an active warning.

This resolves the expiry problem cleanly.

Evidence should not silently disappear. Operational relevance can decay or be re-evaluated.

Likewise, an appeal should not delete the original record. It should append counter-evidence, open a contested state, and produce a new version that explicitly supersedes the previous assessment.

A suitable state model could distinguish:

  • REPORTED;
  • CLAIMANT_BOUND;
  • STRUCTURALLY_VALID;
  • EVIDENCE_VERIFIED;
  • ATTRIBUTION_SUPPORTED;
  • CONTESTED;
  • SUPERSEDED;
  • CLOSED.

Confidence level and workflow state should remain separate. A procedural status is not an analytical conclusion.

6. Risk propagation must be bounded

The most dangerous failure mode is uncontrolled graph propagation.

A malicious actor can send dust to an innocent address, route funds through public infrastructure, touch a major protocol, or deliberately interact with a known entity. If every connected node inherits risk, the attacker can weaponize OTS against arbitrary targets.

Each graph edge therefore needs explicit semantics:

  • transfer;
  • approval;
  • contract call;
  • delegation;
  • bridge message;
  • deposit;
  • withdrawal;
  • consolidation;
  • dispersal;
  • fee payment;
  • ownership or control evidence.

Propagation rules must account for:

  • direction;
  • edge type;
  • value significance;
  • temporal proximity;
  • path length;
  • infrastructure role;
  • confidence loss across each transition;
  • evidence of common control.

Public routers, bridges, contracts, liquidity pools, exchange clusters, and other shared infrastructure must act as typed boundaries, not as ordinary ownership edges.

Risk should propagate through evidence of control, not through mere proximity.

7. The API must explain every output

A consumer should never receive only an address and a score.

A useful signal should expose:

  • incident ID;
  • subject chain and address;
  • incident-specific role;
  • workflow status;
  • confidence class;
  • reason codes;
  • evidence classes present;
  • first observed block;
  • last observed block;
  • evidence root;
  • policy version;
  • schema version;
  • review state;
  • contestation state;
  • superseded-record reference;
  • current operational validity.

This allows wallets to show a warning, exchanges to trigger enhanced review, and forensic systems to inspect the evidence without all consumers being forced into the same policy decision.

It also makes every result auditable and reproducible.

8. Governance should define evidence rules, not manufacture truth

The first governance question is not “which council decides whether an address is bad?”

The first governance question is:

What evidence is admissible, how is independence measured, how are roles assigned, how is graph propagation bounded, and what exact conditions permit each public signal state?

A reviewer or council should operate inside a versioned evidence policy. It should not assign unexplained scores by discretion.

Governance should control:

  • evidence taxonomy;
  • reviewer conflicts;
  • required independence for corroboration;
  • escalation thresholds;
  • appeal procedure;
  • version changes;
  • public auditability;
  • emergency handling;
  • retention policy;
  • high-impact label requirements.

High-impact attributions should require independent review. Routine machine-verifiable facts should not require a governance vote.

Every published result should be reproducible from the same evidence root and the same policy version.

9. The first prototype should be an adversarial benchmark

Before exposing a live oracle or allowing automated enforcement, OTS should be tested retrospectively against a frozen corpus containing:

  • confirmed theft incidents;
  • benign transfers with superficially suspicious topology;
  • bridge routes;
  • pooled exchange addresses;
  • router and aggregator interactions;
  • compromised intermediary accounts;
  • dust-poisoning attempts;
  • coordinated false reports;
  • conflicting claimant signatures;
  • repeated incidents linked to common infrastructure;
  • control changes over time.

The source packages should be cryptographically fixed before evaluation.

The benchmark should measure:

  • false-positive rate;
  • unsupported-attribution rate;
  • evidence coverage;
  • time to provisional warning;
  • time to supported attribution;
  • resistance to coordinated report manipulation;
  • propagation errors;
  • appeal reversal rate;
  • cross-reviewer consistency;
  • deterministic reproducibility.

The first deployment stage should be warning-only. Automated restrictive actions should come only after the evidence model and propagation rules have survived adversarial testing.

Conclusion

OTS should not be designed as another blacklist, reputation registry, or opaque wallet-scoring service.

Its strongest form is an auditable incident-evidence and attribution protocol:

  • claims remain distinct from facts;
  • facts remain distinct from attribution;
  • attribution remains distinct from enforcement;
  • address roles remain incident-specific;
  • confidence remains explainable;
  • history remains immutable;
  • operational risk remains updateable;
  • every result remains reproducible.

The correct first deliverable is not a front end and not a generic risk-score API. It is the evidence ontology, incident state model, bounded propagation specification, versioning model, and adversarial validation corpus.

Once those foundations are correct, the API, oracle layer, reviewer structure, and ecosystem integrations can be built without turning OTS into another centralized source of unexplained suspicion.