Unusual mempool pattern from deployer wallet
A real-time signals factor in the v1.7.0 rubric. Measured per protocol on a rt cadence.
Methodology how we score #
**What this measures** This real-time signal fires when the protocol's deployer wallet (or admin wallet) submits a mempool transaction sequence that deviates from its established behavioral baseline — for instance, new contract deployments, unusual approval grants, or high-frequency transaction bursts from an address that has been dormant. The signal is generated by maintaining a behavioral baseline for the deployer wallet and flagging deviations beyond a configurable standard-deviation threshold. Category 6 context: deployer wallet re-activation is a documented precursor pattern in insider-drain exploits, where the attacker waits for a dormancy window before re-activating privileged access.
**Why it matters** The Infini exploit ($49.5M, 2025) demonstrated a 114-day dormancy period before the rogue developer re-activated the retained admin key and executed the drain. Merlin DEX ($1.82M) showed the Feeto privileged EOA activating unexpectedly. When a deployer wallet that has been dormant for weeks or months suddenly submits transactions — particularly contract deployments or admin function calls — it is structurally similar to the pre-exploit pattern. The signal is P2 in priority because the mempool monitoring infrastructure required is substantial and the false positive rate from legitimate protocol upgrades is high.
**Green / Yellow / Red** Green is the baseline state when the deployer wallet shows transaction patterns consistent with its 30-day behavioral baseline. Yellow fires when the deployer submits an unusual transaction type (e.g., new approval or deployment) that deviates from baseline but is within explainable operational activity. Red fires when the deployer wallet re-activates after 30 or more days of dormancy and immediately submits admin-category transactions, particularly if the wallet is not a multisig and the transactions are not preceded by governance discussion.
**Common gray cases** Gray applies when the deployer wallet is a multisig and individual signer actions are not separately monitorable, or when the protocol has a documented active upgrade schedule that normalizes frequent deployer activity.
**Notable historical examples** No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for #
Detect whether the deployer wallet submits an unusual sequence (new contract deploys, mass approvals) vs its historical baseline.