Red gates
A green test is not evidence that a guard exists.
For each guard on the roster, the guard was removed from the source, the test that claims to catch it was run, and the run was required to fail.
Nothing is deployed. No address exists on any chain.
There is no factory address, no vault address and no mine address, on mainnet or on any testnet. No transaction has been broadcast. What exists is source, a test suite, the measurements on these pages — and a deploy script that has not been run.
A green test is not evidence that a guard exists.
For each of the 26 guards in the recorded run, the guard was removed from the source, the test that claims to catch it was run, and the run was required to fail. The source was then restored and the tree checked clean. The tool, the exact edits and the last run are kept in the repository, so the claim is reproducible rather than reported.
The first pass found three tests that stayed green with their guard deleted. All three were real defects in the tests, and all three were fixed — the list is on the right, because a red-gate pass that found nothing would be the less interesting result.
The three that stayed green, and what was wrong with them
- The 256-block window test could not tell which of two guards had rejected, because both carried the same revert string. The strings are now distinct.
- The reentrancy test asserted only that it reverted — which the checks-effects flag produces on its own, and which the pay helper rewrites into one message anyway. The reentering contract now catches the inner call and the test asserts the inner reason.
- The project-snapshot test settled a period nobody had mined, so it exercised the empty-period branch and never executed the line it claimed to protect. It now cuts a block first.
Source: README.md, RULES.md. The run’s totals are Figs. 09 and 11; they are not repeated here.
Counts are the per-suite rows of RULES.md, which submission/suites.py checks against forge test --list on every run — a row that drifts from the build fails the check rather than quietly misreporting. The two fork suites are the ones whose names say so.
| Suite | What it covers |
|---|---|
| CoalVault.mainnet.t.sol | real fork: portal, launch, buy, dispatch, gas, schema, Guardian, settle, claim |
| CoalFactory.t.sol | portal boundary, malformed input, launch bounds, Flap schema surface |
| CoalVault.t.sol | splits, period isolation, pull paths, reentrancy, solvency |
| CoalMine.t.sol | the mechanism, every gate proven red |
| Beacon.t.sol | guardian-table agreement and upgrade authority |
| PeriodDos.t.sol | empty history, cursor frontier, immutable cadence |
| CoalVault.security.t.sol | forced balance, redirects, referral release |
| Solvency.t.sol | stateful invariants over tax, work, settle, claim, withdraw and forced BNB |
| Commission.mainnet.t.sol | where the commission goes, measured on chain |
Source: RULES.md — Suites. The test counts are Fig. 09; this table is the coverage column of the same rows, so neither repeats the other.
Each guard was deleted from the source, the test that claims to catch it was run, and the run was required to fail; the file was then restored and the tree checked clean. redgate/last-run.txt records 26 of 26 going red.
Measured inside a real TaxProcessor.dispatch() on a BSC mainnet fork by a differential whose control leg reads exactly zero. The reproducible fact is the assertion, not the point: adding one sstore to receive() pushed it to 130,227 and the test went red, which is what the third bar is.