Vault Outflow Alerts: Webhooks After Admin Key Changes

TL;DR: Subscribe to confirmed token-transfer events on the vault contract. Watch the admin or owner address separately. When an outflow burst follows a privileged transaction, raise the alert priority. Crypto APIs Blockchain Events delivers each confirmed transfer as a webhook in under 100ms, so your burst detector runs on pushed events instead of polling.

A vault on Base was drained of about $6 million in Aave deposit tokens, The Defiant reported. Incidents like this follow a familiar sequence. A privileged action changes who can move funds. Then the funds move, usually in a tight cluster of transactions. The gap between those two steps is the only window in which a monitoring system can still be useful. This post covers how to build a detector for that window. It does not reconstruct this specific exploit.

The problem

Consider a security engineer at a protocol, or a risk engineer at an exchange or custodian that holds positions in third-party vaults. Their brief is narrow. If a watched contract starts bleeding tokens, someone has to be paged before the last transfer confirms.

Two things make this hard. First, normal withdrawals look like attack withdrawals when you examine them one at a time. The signal is rate and context, not any single transfer. Second, the context that matters most is a recent change to admin keys, roles, or whitelists, and it lives in a different place than the outflows. Polling a block explorer cannot connect the two quickly enough. You need pushed events for outflows and a separate watch on the privileged address, joined in your own backend.

What you need

• A Crypto APIs account and API key. The free tier requires no credit card.
• The vault contract address and the address of every privileged actor: owner, admin multisig, guardian, or whitelist manager. Collecting this list is the hard part. Many vaults delegate roles across several contracts, and the list goes stale after upgrades.
• A public HTTPS endpoint (Hypertext Transfer Protocol Secure) that accepts webhook callbacks, returns a 2xx status quickly, and processes the payload asynchronously.
• A small state store such as Redis or Postgres for sliding-window counters and an "armed" flag per vault.
• A baseline: normal hourly outflow count and volume for each vault. Without it, any threshold you set is a guess.

How it works

1. Subscribe to vault token outflows. Create a subscription with POST /blockchain-events/{blockchain}/{network}/address-tokens-transactions-confirmed, using base as the blockchain, mainnet as the network, and the vault contract as the watched address. Each confirmed ERC-20 transfer touching that address is pushed to your callback URL. If your workflow needs to see a transfer at every confirmation depth, use the address-tokens-transactions-confirmed-each-confirmation variant. Store the referenceId returned for each subscription. You will need it to list, inspect, or delete the subscription later through GET /blockchain-events/{blockchain}/{network}/{referenceId} and DELETE /blockchain-events/{blockchain}/{network}/{referenceId}. The monitor addresses with webhooks guide covers callback verification and subscription setup in detail.

2. Watch the privileged addresses. No event type is dedicated to role or whitelist changes. Treat the admin address itself as the signal instead. Subscribe to block-mined on the same chain. On each block, call GET /addresses-latest/evm/{blockchain}/{network}/{address}/transactions for each admin address through address latest. Admin keys should rarely transact, so any new transaction is worth inspecting. Pull its event logs with GET /transactions/evm/{blockchain}/{network}/{transactionHash}/logs and match them against the vault's role-change and ownership-transfer event signatures. A match sets an armed flag on the vault for a fixed number of blocks.

3. Run the burst detector. On every outflow webhook, increment two sliding-window counters keyed by vault: transfer count and token amount over the last N blocks. Use two thresholds. The relaxed one applies normally and is set well above your baseline. The tight one applies while the vault is armed. Consider a vault that normally sees three withdrawals per hour. Seven outflows within five blocks of an admin transaction should page someone immediately, even if the same seven spread across an hour would not.

4. Enrich the alert with counterparty risk. Before paging, screen the receiving address with Verify Address, the Anti-Money Laundering (AML) screening endpoint. It is a GET request with the address in the path and no request body:

GET https://rest.cryptoapis.io/aml/addresses/{address}
X-API-Key: <your key>

A flagged recipient returns:

{"apiVersion":"2024-12-12","requestId":"6aa3c4642f6f68835e3dbd6c","data":{"item":{
  "blockchain":"ethereum","isFlagged":true,"riskScore":80,"riskBand":"high",
  "severity":"high","categories":["malicious","sanctions"],
  "sources":[{"provider":"graphsense","label":"tornado.cash","categories":["malicious"],
              "severity":"high","listingTimestamp":1784210009,"sanctionPrograms":[]}],
  "attribution":{"entity":"tornado-cash","type":"mixer","label":"Tornado.Cash: Donate"},
  "listingTimestamp":1784210009}}}

A clean recipient returns isFlagged set to false, with empty categories and sources arrays. Optional fields such as attribution are omitted, not null. Your parser has to handle missing keys. An armed vault, a burst over threshold, and a recipient with riskBand of high or severe together justify the highest page tier. Fresh attacker addresses usually come back clean. Do not suppress an alert because screening found nothing.

What to watch for

• Confirmed means after inclusion. The token events above fire on confirmed transactions. Sub-100ms is the delivery time from our side once the event exists. It does not mean you can front-run a transaction that is already mined. The detector buys response time for pausing contracts, revoking approvals on your own positions, and halting deposits. It does not reverse transfers.
• Proxy upgrades move the target. If the vault is upgradeable, an attacker can route funds through a new implementation or helper contract. Watch the proxy address and treat implementation changes as admin events.
• Bridged outflows leave your subscription. When drained tokens cross to another chain, your Base subscription stops seeing them. Add subscriptions on the destination chain for known bridge recipients. Our post on Real-Time Compliance for Cross-Chain Bridge Exploits (2026) covers this handoff.
• Webhook retries create duplicates. Deduplicate on transaction hash and log index before incrementing counters, or a single retried delivery can trip a burst threshold.
• Polling cost scales with admin count. Calling address-latest on every block for many admin addresses consumes credits. Batch the calls, and stop watching addresses that have been confirmed as decommissioned.
• Thresholds drift. Vault usage changes with yields and incentives. Recompute baselines on a schedule instead of hardcoding them.

Outflow monitoring is a backend problem: pushed events, joined state, and a short decision path to a human. Blockchain Events handles the first part on Base, Ethereum, and 20+ other chains, with sub-100ms webhook delivery and the same envelope on every response. Teams at Ledger, Nexo, and Swyftx build on Crypto APIs from a company registered in Delaware, USA. Start on the free tier, point a subscription at a vault you hold, and tune the thresholds against real traffic before you need them.