SuperRare Exploit Post-Mortem: How Olympix Would Have Prevented the $730K Loss
Date of Incident: July 28, 2024
Amount Lost: $730,000 (11,907,875 RARE tokens)
Exploited Contract: 0xffb512b9176d527c5d32189c3e310ed4ab2bb9ec (RareStakingV1)
Transaction Hash: 0xd813751bfb98a51912b8394b5856ae4515be6a9c6e5583e06b41d9255ba6e3c1
Executive Summary
The SuperRare NFT platform suffered a $730,000 exploit due to a critical access control vulnerability in its staking contract. The vulnerability was caused by inverted logic in the updateMerkleRoot() function, which allowed any address to modify the Merkle root instead of restricting access to authorized addresses only. This exploit represents a textbook case where mutation testing could have prevented the incident entirely.
Technical Analysis
The Vulnerability
The core vulnerability resided in the updateMerkleRoot() function within the RareStakingV1 contract. The function contained inverted access control logic:
What was intended:
The Attack Flow
- Initial Reconnaissance: The attacker identified the vulnerability in the permission check
- Merkle Root Manipulation: Called updateMerkleRoot() with a malicious Merkle root under their control
- Token Drainage: Used the malicious root to generate valid proofs for claiming 11,907,875 RARE tokens
- Front-running: The actual exploit was executed by a front-runner who detected the vulnerability one block after the original exploit contract was deployed
Root Cause Analysis
The vulnerability can be attributed to several factors:
Primary Cause:
- Logic Inversion: The access control check used != (not equal) instead of == (equal) operators
- Inadequate Testing: Unit tests failed to cover negative test cases for unauthorized access
Contributing Factors:
- Post-Audit Changes: The bug was introduced after the initial audit without re-auditing
- Insufficient Code Review: The obvious nature of the bug suggests lack of proper peer review
- Missing Automated Security Tools: No continuous security analysis during development
How Olympix Would Have Prevented This Exploit
1. Static Analysis Detection
Olympix's advanced static analyzer, which achieved 75% accuracy compared to Slither's 15% accuracy in a case study on the Eigen Layer codebase, would have immediately flagged this access control flaw. The inverted logic in the require statement represents a classic anti-pattern that static analysis tools are designed to detect.
Specific Detection Capabilities:
- Access Control Analysis: Olympix specifically looks for inverted permission checks
- Logic Contradiction Detection: The tool would identify that the function logic contradicts its intended purpose
- Real-time VS Code Integration: The vulnerability would be flagged the moment the code was written
2. Mutation Testing - The Game Changer
Mutation testing is Olympix's core differentiator, introducing controlled modifications to smart contract code to evaluate test suite effectiveness. For the SuperRare exploit, mutation testing would have been the perfect prevention mechanism:
How Mutation Testing Would Have Caught This:
- Operator Mutation: Olympix would systematically mutate the != operator to ==
- Test Suite Validation: If properly written, unit tests should fail when this mutation is applied
- Gap Identification: In SuperRare's case, the tests would have passed even with the mutated (correct) logic, indicating a critical testing gap
- "Mutant Survival": The surviving mutant would immediately alert developers to insufficient test coverage
Example Mutation Process:
3. Automated Unit Test Generation
Olympix can accelerate unit testing by automating up to 90% line and branch coverage in seconds, matching style and quality requirements on even the most complex contracts.
Missing Test Cases That Would Have Been Generated:
4. Continuous Security Integration
Olympix integrates seamlessly into development environments, providing real-time feedback while writing code. This would have prevented the vulnerability through:
CI/CD Integration:
- Every commit would trigger static analysis
- Mutation testing would run on critical functions
- The vulnerable code would never reach production
Pre-Deployment Validation:
- Olympix systematically modifies contract code and verifies that test suites detect these changes
- The deployment would be blocked until proper test coverage was achieved
Industry Impact and Lessons Learned
The Broader Context
0xAw, lead developer at Base decentralized exchange Alien Base, noted that the vast majority of serious vulnerabilities originate from common human errors that are easily preventable with proper tooling. The SuperRare exploit exemplifies this pattern: a straightforward logic error with significant financial consequences.
Expert Consensus:
- ChatGPT would have caught this vulnerability
- Unit tests would have caught this mistake
- Any half-competent Solidity dev would've caught this
The Testing Coverage Illusion
Traditional code coverage metrics gave SuperRare a false sense of security. Standard coverage measures which lines execute during tests, while mutation coverage measures whether tests detect when code behavior changes.
The Reality:
- 100% Line Coverage: The vulnerable function was executed during tests
- 0% Mutation Coverage: Tests didn't detect the behavioral change when logic was corrected
- False Security: Coverage metrics showed green while critical vulnerabilities remained
Prevention Strategy with Olympix
Implementation Roadmap
Phase 1: Immediate Integration
- Integrate static analysis into every commit
- Set up VS Code extension for real-time vulnerability detection
- Configure CI pipeline to block deployments on security violations
Phase 2: Advanced Testing
- Implement mutation testing workflow to systematically modify contract code
- Generate comprehensive unit tests for access control functions
- Establish minimum mutation score thresholds (95%+ recommended)
Phase 3: Continuous Security
- Enable automated security scanning for post-audit changes
- Implement adversarial testing scenarios
- Set up monitoring for runtime security validation
Cost-Benefit Analysis
Investment in Olympix:
- Tool licensing and integration costs
- Developer training time
- Initial setup and configuration
Prevented Losses:
- $730,000 direct loss prevention
- Reputation damage mitigation
- Regulatory and legal cost avoidance
- User trust preservation
ROI Calculation: The SuperRare exploit alone represents a loss that would justify years of proactive security investment across multiple projects.
Recommendations
For SuperRare
- Immediate: Implement mutation testing on all existing contracts
- Short-term: Mandate re-audits for any post-audit code changes
- Long-term: Establish comprehensive DevSecOps pipeline with Olympix integration
For the Industry
- Shift Left Security: Integrate security tools at development time, not pre-deployment
- Beyond Coverage: Move from line coverage to mutation coverage metrics
- Automated Testing: Use AI-powered tools to generate comprehensive test suites
- Continuous Validation: Implement ongoing security monitoring throughout the development lifecycle
Conclusion
The SuperRare exploit was entirely preventable with proper testing and security tooling. Mutation testing provides a critical tool in achieving security and reliability of smart contracts, ensuring that as we build the decentralized future, we do so on a foundation of rigorously tested and highly secure code.
The incident serves as a stark reminder that in decentralized systems, even a single-character mistake can have severe consequences. However, with tools like Olympix, such mistakes can be caught and corrected before they reach production, protecting both user funds and platform
Security tools should run as you code. Every commit, every pull request, every deployment should trigger analysis. SuperRare's $730,000 loss could have been a $0 loss with the right security infrastructure in place.
More post-mortems
See every post-mortem →See what Olympix finds on your own code
Send us a repo that's already been audited, and we'll run Olympix at the same commit and show you what comes back.




