See What You Get
This is a real audit report from a 3-contract token system (476 lines of Solidity). Independent analysis, adversarial falsification, and execution verification reduced raw findings to 8 confirmed.
Sample Findings
Owner can burn user tokens without approval (by design)
The agentBurn function allows the owner to burn any holder's tokens without ERC-20 allowance. Both passes flagged it, but execution verification could not reproduce an exploit — the function is intentionally designed for platform-managed burns with daily rate limits. Falsification downgraded from HIGH to LOW: documented design choice, not an attacker-exploitable vulnerability.
Cross-token burn coupling
If one token hits its burn floor, the other token's scheduled burns also stall due to atomic transaction failure.
Access control role divergence
Admin roles don't auto-transfer with ownership change. Both passes identified this as an operational risk.
30-day interval drift
Burn schedule uses 30-day intervals (not calendar months), completing ~25 days early over 5 years.
Allowance exhaustion risk
5-year burn schedule requires pre-approved allowances. If allowance runs out, burns stall silently.
Year index fragility
Array index safe with current constants but would fail if parameters are modified without array update. Both passes flagged.
No emergency stop on burn schedule
Once started, scheduled burns cannot be paused. Halt requires revoking permissions across multiple contracts. Both passes flagged.
Missing initial event emission
Constructor sets a parameter without emitting the update event, making off-chain tracking harder.
The full report includes more
Each finding comes with detailed description, impact analysis, code location, fix recommendation with code snippets, and proof-of-concept where applicable. Plus the full correction log showing how each finding was cross-verified.
Get Your Own Report — $99