SixStar for projects
Menu
Theme

When an alert fires

A short playbook for the person on call. Print it, or keep it open next to your alert channel. It assumes you have done the setup in "Getting started", especially emergency actions.

SixStar reads public chains and tells you what changed. It never signs, sends or moves anything. Every action below is taken by your own team, with your own keys.

1. The first five minutes, for any urgent alert

  1. Read the whole alert. It names the watch, the network, the contract or wallet, the transaction and the block. Names from your address book are printed beside addresses.
  2. Open the transaction on the network's block explorer from the link or hash in the alert, and check it is what the alert says.
  3. Ask the person who should have done it. If the change came from one of your admin wallets, ask its holder directly, on a channel you already trust. Not in a thread the attacker could be reading.
  4. If nobody on your team did it, treat it as an attack. Go to the play below that matches the alert. Do not wait to be sure: the plays are designed so that acting on a false alarm costs little.
  5. Tell your team in your incident channel: the alert, the time, and who is leading.

2. Play A: someone may control your keys or your contract

Alerts such as: "Wallet code delegated" (Takeover Watch), "Owner changed", "Ownership transfer started", "Admin transfer scheduled", "Role admin changed", "Contract upgraded", "Upgrade admin changed", "Timelock admin changed", "Control moved", "Account permissions changed".

  1. Stop signing with the affected wallet. If one signer of a Safe is affected, the other signers should not co-sign anything with it until it is checked.
  2. Open the emergency action the alert links to, if you set one up. It is already built and checked against the chain. Read what it will do, then your signers decide and sign it in your own Safe. Typical ones: pause the contract, revoke the role, or cancel a queued Safe transaction by using up its nonce.
  3. If a transfer of ownership or admin is scheduled but not finished, this is your window. Cancel it through your timelock or contract if you can.
  4. Move what is still at risk. If you prepared "move a Safe's funds to an address you name", that address was chosen when nobody was under pressure. Use it.
  5. Rotate the keys that may be exposed, once the immediate risk is contained.

3. Play B: money is leaving

Alerts such as: "Outflow above your limit", "Slow outflow above your limit", "Payment out of a cold wallet", "Payment to a new address", "Many recipients", "Balance below your minimum", "Bitcoin left your watched addresses", "A payment left your XRP Ledger account".

  1. Assume every network is affected. After a drain alert you will also see: "Cross-chain warning: attackers often move on several networks within minutes. Check this team's wallets on every network now. For the next hour every network is read on every cycle and every alert is Urgent."
  2. Pause, revoke and move, using your emergency actions, in that order of what protects the most money fastest.
  3. Revoke open approvals. On "Open approvals", check which spenders can still move your tokens, and revoke any you do not recognise.
  4. If stablecoins were taken, open an issuer request pack straight away. It lists each transfer out, follows the tokens onward and shows who holds them now, grouped by the issuer to ask. Untick ordinary payments. Send the pack to each issuer it names. Whether an issuer acts is its decision, and speed matters, so send early and update later.
  5. Watch the pack. You are alerted when "Tokens in your issuer request pack moved" and when "Tokens in your issuer request pack are frozen".
  6. Contact the exchanges where the pack shows tokens arriving, through their official security or law enforcement contact. Give them the transactions. Whether they act is their decision.

4. Play C: a payment involved a sanctioned or stolen-funds address

Alerts: "Payment to a sanctioned address", "Payment from a sanctioned address", "Payment to an address linked to a theft", "Payment from an address linked to a theft".

  1. Do not send anything to that address, and do not send funds back on your own. Returning or moving funds that touched a sanctioned address can itself be a breach of sanctions law.
  2. Record what happened: the alert, the transaction, the time, and who on your team saw it.
  3. Get legal advice before you act. Your legal adviser can tell you whether and how to report it, and what to do with the funds.

The sanctioned addresses come from the US Treasury's public OFAC list, and the theft-linked addresses from public reports. A match is a reason to stop and check, not a legal finding.

5. Play D: your team's accounts changed

Alerts from your identity sources (Okta, Zoom, Google Workspace, GitHub, Cloudflare, Telegram or Discord), and "A signer's phone shows a change".

  1. Check with the person named in the alert, on a channel you already trust.
  2. If they did not do it, suspend the account or session in that provider's own admin console, and reset its sign-in.
  3. If that person holds a signing key, run Play A for their wallet as well. A taken-over email or phone often comes before a taken-over key.

6. Play E: something is waiting to be signed

Alerts: "Safe transaction proposed", "Flagged Safe transaction proposed", "Governance proposal created", "Governance proposal queued".

  1. Do not sign a transaction you did not expect. Compare its hashes and flags with the signing check on the site before anyone signs.
  2. For a flagged Safe transaction, ask the proposer directly. If nobody proposed it, cancel it by using up its nonce.
  3. For a governance proposal, read what it calls before it can run. The timelock delay is your window.

7. Afterwards

What SixStar does not do