Two things start today: a public catalog of contracts, and this blog.
A public catalog of 400 contracts
The catalog has a page for each of 400 active contracts: 200 on Ethereum and 200 on BNB Chain1. Anyone can open it. You do not need an account.

How the 400 were chosen
Not by size. The largest contracts on a network by transaction count are mostly stablecoins and bot routers. A page about them tells nobody anything new, and no team behind them is waiting for it.
A contract gets into the catalog when, over the last 30 days, it:
- emitted at least three different events, a sign of real application logic, not a plain token;
- emitted at least one event, so the page is not dead;
- was deployed more than 30 days ago, which cuts out fresh spam and test deployments.
Among those, contracts are ranked by activity and taken until the network's budget runs out. No single contract may take more than 5% of the budget, so one busy pool cannot push out a hundred interesting contracts2. The result is tokens with real logic, AMM pools, lending markets, oracles, bridges and registries. Pools are named by their pair and venue, for example "USDC/WETH 0.05% · Uniswap V3". Test networks are not in the catalog.
What a contract page shows

Each page shows neutral facts, the same ones a block explorer would give you, but already counted:
- events per day, how many different events the contract emits, and the most frequent one;
- transactions per hour, as a chart;
- events per hour, a chart for each event signature;
- the date the data starts.
The public page has hourly resolution, a 15-minute delay and the last 7 days1. We store 30 days for each catalog contract. The extra 23 days are not shown publicly. They are kept for the team that claims the page, as described below.
What a contract page never shows
- alerts, or rules anyone has set on the contract;
- deviations from the norm and anomalies;
- the share of failed calls;
- who else is watching the contract.
This is a decision, not a missing feature. A page we put up uninvited with "30% of calls fail" on it reads as an accusation, even when the number is correct. Without knowing the protocol, nobody can say whether 30% is a problem or normal for this contract. Those numbers belong to the team that runs the contract, in the private part of the product2.
Claim the page if it is your contract
Every page has a block "Is this your contract?" with a Claim this page button. The proof is one signature:
- SmartAlert gives you a message to sign. It names the network, the contract and your project. It works once and expires in five minutes.
- You sign it with the address the contract itself names as its controller. Any of three works:
- the address
owner()returns; - a holder of
DEFAULT_ADMIN_ROLE; - the proxy admin, or the owner of the
ProxyAdmincontract.
- the address
- If that address is a Safe, the Safe signs. Its owners collect signatures in Safe{Wallet} as usual, and the message stays valid for 24 hours so they have time.
- SmartAlert reads the current owner from the chain and checks that the signature matches it.
We do not accept "I deployed it" as proof. The current right to control the contract, read from the chain, is the only proof. If a contract has renounced ownership and has no admin role or proxy admin, there is nobody who can sign for it, and we say so2.
If you do not have the owner key at hand, you can still add the contract to a project by address. You get the same data, without the claim.
What you get after the claim
- The history already collected. The page shows 7 days, but your project reads everything we stored. A new project runs as Pro for 14 days and reads up to 90 days back3. For a catalog contract that history is already there. There is nothing to backfill and nothing to wait for.
- Suggested rules, checked on that history. SmartAlert offers rules for the contract, and you can see how each would have fired on past data before you turn it on. A threshold you test on a month of data does not wake you up at 3 a.m. for nothing.
- Control over the page. You can hide it from the catalog in one click, without writing to support. Hiding is immediate, and the next catalog refresh does not bring it back. Only you can return it2.
- A public status page, if you want one. A claimed project can turn on
/status/<name>with incidents its team has confirmed, and a badge for a README. Nothing private goes there: no metrics, thresholds or values2.
A blog about real incidents
It is easy to say a monitor would have caught the last hack. We show the minutes instead.
Each incident post takes a hack the protocol itself acknowledged and links to its post-mortem. It then walks through what happened:
- how the attacked contract works, in plain words, for readers who have not read the post-mortem;
- the attack step by step, every transaction with its block time and a link to Etherscan;
- where a SmartAlert rule would have fired, with the rule's name, the time the alert would arrive, and how many minutes were left before the withdrawal;
- where no rule of ours would have helped, and why.
The delay is our real one. On Ethereum we read a block after 12 confirmations, about 144 seconds, so a reorg cannot send a false alarm. With polling, storage and a 60-second check on Pro, an alert arrives about 2.5–4 minutes after the block4.
The rules for these posts:
- We write "signal N minutes before the withdrawal", never "would have prevented". An alert gives time. People with keys save funds, and whether they could have is a separate question every post asks.
- Every post says what the rule does not catch. Bybit and KiloEx lost their funds within seconds or a couple of minutes of the first sign. No event or state monitor gets there in time, and we say so.
- Every number has a source. Footnotes point to the protocol's post, Rekt and auditors. What we checked ourselves on-chain (block times, balances,
eth_callon archive blocks) is marked separately.
The first three posts:
- IoTeX ioTube, February 2026: an ownership signal 14 minutes before the first withdrawal from the reserves, and the team found out almost seven hours later.
- Orbit Bridge, December 2023: five transfers over 17 minutes; after the first alert, $61.5M was still in the vault.
- Ronin Bridge, August 2024: the vote threshold was 0 for 48 minutes before the first withdrawal, and no event said so.
To get new posts, follow @smartalert_alex on X.
Sources
- 1.SmartAlert public catalog API,
GET /api/public/contracts, checked on 2026-10-23: 200 live contracts onethereum-mainnet, 200 onbsc-mainnet. Resolution, delay and depth as printed on each contract page. ↩ - 2.SmartAlert, business rules of the public catalog: selection criteria, what is public, claim, status page and page removal. ↩
- 3.SmartAlert, tariff rules: a new project's 14-day Pro window and 90-day read depth. ↩
- 4.SmartAlert, alert delay model for Ethereum: 12 confirmations, head polling up to 12 s, storage P95 up to 15 s, rule check every 60 s on Pro. ↩