Hashvard watches your Safe multisig, admin keys and contracts. Every queued transaction is decoded from raw calldata, its hashes are recomputed for your hardware wallet, and risky actions land in your team's Telegram — usually while only the proposer has signed.
Most watchers forward what the Safe service says. Hashvard does not trust the UI or the service: it recomputes safeTxHash, domain and message hashes from the raw fields and decodes calldata itself.
When it fires: as soon as a transaction is proposed, not after execution. The Bybit transaction carried 3 signatures (visible in its calldata), so an alert at the first one would have reached the signers who came after.
Inputs read from chain: tx 0x46de…7882, block 21,895,238. The recomputed safeTxHash matches the ExecutionSuccess event of the Bybit Safe exactly.
The biggest incidents of 2025–2026 were not code bugs. People approved something other than what they were shown.
Signers were shown a routine transfer. The Safe actually delegatecalled into an attacker contract.
On-chain transaction ↗Security-council signers were socially engineered into pre-signing an admin transfer.
TRM Labs ↗ · BlockSec ↗Spoofed transfers passed the normal approval flow. Keys were not stolen.
CoinDesk ↗The same transaction, three views. Hashvard reads the third one.
A routine transfer from the cold wallet, presented by a compromised web interface.
operation = 1 (DELEGATECALL) to 0x9622…7242, an unknown contract, calling transfer(0xbDd0…9516, 0). Executed with delegatecall, that call runs inside the Safe and rewrites its storage.
CRITICAL — DELEGATECALL to non-standard contract. Only the official MultiSend, SignMessageLib and CreateCall libraries are expected here. Plus the exact hashes the hardware wallet displays.
Watching the Safe queue is necessary but not enough: an upgrade, a role grant or an owner change can also come from a timelock, a module or another key. Hashvard runs two independent watches — the signing queue and the on-chain admin surface.
Anything other than the official Safe libraries gets full control of your Safe. Flagged at the top level and inside batches.
Owners, threshold, modules, guard, fallback handler, singleton — queued or already executed.
We recompute safeTxHash, domain and message hashes ourselves. If the service disagrees, you hear about it.
Proxy implementation, ProxyAdmin owner, beacon, owner(), roles granted or revoked, timelock delay.
ERC-20 approvals, Permit2 allowances and setApprovalForAll from your treasury, decoded per call.
Everything else that changes who controls the protocol, explained in plain words.
No contracts to deploy, no keys to share. Read-only from day one.
Send your Safe, proxy, timelock or token contract to @Hashvard_bot — or use the form below.
Signers, threshold, modules, guard, proxy admin, owner, roles, pause state, timelock delay.
Every new queued transaction and every change to the baseline. Add the bot to your signers' group so everyone sees it.
Where the data comes from. The queue of proposed transactions comes from the Safe Transaction Service. Everything we judge it by is our own: the hashes are recomputed from the raw fields, every signature in the queue must recover to a current owner for our hash, and owners, threshold, modules and proxy implementations are read from the chain over our own RPC — not from the service's answer. A service that shows different fields than the ones signed breaks those signatures, and that is a CRITICAL alert.
Quiet by default. The official Safe MultiSend libraries are allowlisted, and each team can allowlist its own contracts and known spenders (/allow in the bot), so routine batches do not shout. A delegatecall into anything else, or an owner change, always does.
Timing, honestly. The Safe queue is read from the Safe Transaction Service every minute; contract state is re-checked every 5 minutes. A new transaction is flagged when it is proposed — with a 2-of-3 or 3-of-5 threshold that is normally while only the proposer has signed, so the other signers compare the hashes before adding theirs.
Hashvard alerts; it does not block. It does not replace your hardware wallet or a careful signing process — it gives every signer an independent second view.
Every critical and high alert ends with this checklist, filled in for that transaction.
If you already signed, tell the other signers now.
safeTxHash on your device vs. the alert. Different hash = stop.
The alert lists owners who have not signed yet. Reach them directly.
Sign and execute a rejection (0 value to the Safe itself) with the same nonce.
Decode the calldata calmly. Need help fast: SEAL 911.
Our hash recomputation is regression-tested against live Safes before every release.
Check one case yourself. Safe 0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4 · Ethereum · Safe v1.1.1 · nonce 71 · transaction 0x46de…7882.
Expected flag: CRITICAL · DELEGATECALL to non-standard contract. safeTxHash 0xb3476d061aeb8fc1d605a873c483a2402d88a68a9cdd1a8b47655dd55ba004f8 equals the hash in the Safe's ExecutionSuccess event. All 3 signatures were blind eth_sign — the signers' devices showed only a hash. Raw replay: bybit-replay.json.
What you need to know before giving us a treasury address.
/remove <id> in the bot. Ask in the bot to delete everything for your chat.Small protocols, DAOs and treasuries. Alerts start the same day.
ethereum 0x….