Staking & Reward Auditor
When to Use
- Auditing staking mechanisms, reward distribution, yield farming
- User mentions: staking, rewards, yield, farming, rewardPerToken, deposit, withdraw, claim, first depositor
- Analyzing reward calculations, index updates, share dilution
- Reviewing deposit/withdraw flows, precision handling
Audit Workflow
IMPORTANT: Announce skill usage at the start of analysis
Begin with: "I'm using the audit-staking skill to analyze this contract for staking and reward vulnerabilities..."
Scan for staking operations
- Search:
stake, deposit, withdraw, claim, rewardPerToken, totalSupply, balanceOf, earned, updateReward
- Focus: reward calculations, first depositor, direct transfers, precision loss, flash actions
Check against vulnerability patterns
- Reference
reference.md for complete checklist
- Compare code against
example.md
Validate exploitability
- Check access control first - grep for
onlyOwner|onlyAdmin|onlyGovernance modifiers
- Can non-privileged actors exploit? (first depositor steal, direct transfer dilution, flash griefing)
- Can direct transfers dilute rewards?
- Do small amounts round to zero?
- Can flash deposits/withdraws grief stakers?
- Is update called after distribution?
- Are balances cached correctly?
- Verify no compensating protections exist
- Downgrade severity if admin-only unless direct user impact
Generate report
- Use deliverable template below
- Include reward theft/dilution analysis and PoC
- Rank by severity
Core Vulnerability Patterns
See reference.md for full checklist. Key patterns:
- Front-running first deposit → attacker steals initial WETH rewards via sandwich attack
- Reward dilution via direct transfer → sending tokens directly increases totalSupply without staking
- Precision loss in rewards → small stakes or frequent updates cause rewards rounding to zero
- Flash deposit/withdraw griefing → large instant deposits dilute rewards for existing stakers
- Update not called after distribution → stale index causes incorrect reward calculations
- Balance caching issues → claiming updates cached balance incorrectly
Code examples: See example.md
Severity Criteria
Critical: First depositor can steal all initial rewards, direct transfer dilution enabling theft, flash deposit/withdraw draining rewards, MUST be exploitable by non-privileged actors
High: Precision loss causing rewards to round to zero for legitimate users, stale index after distribution, MUST be exploitable by non-privileged actors
Medium: Suboptimal reward distribution timing, griefing via large flash actions without theft, admin-only reward configuration issues with user impact
Low: Gas inefficiencies in reward calculations, missing events, admin-only parameter issues without immediate user impact
IMPORTANT: Admin-only reward functions (onlyOwner, onlyAdmin, onlyGovernance) are MEDIUM or LOW severity unless:
- Invalid reward parameters directly steal/brick user rewards
- Missing validation enables admin rug pull of staking pool
- Error cascades to all users immediately (e.g., division by zero in reward calculation)
False Positives - Do NOT Flag
- Protocols requiring minimum stake amounts (prevents dust)
- Reward tokens same as staking tokens by design
- Intentional admin-only initial deposit
- View functions with documented staleness
- Protocols with explicit front-running protection
Deliverable Format
MANDATORY: Before deliverable, verify each checklist.md item against codebase. Flag violations as findings.
Use template: templates/report-template.md
Each finding includes: severity, pattern #, file/lines, description, vulnerable code, reward theft analysis, PoC, remediation.
Key Principles
- Separate tokens - reward token must differ from staking token
- No direct transfers - track staked amounts separately from balances
- Precision protection - minimum stake, scale factors for small amounts
- Index updates - call updateReward before and after distribution
- Flash protection - time locks or minimum stake duration
- Balance integrity - careful caching during claims
Output Guidelines
DO:
- Reference specific lines and functions
- Provide reward theft scenarios with calculations
- Show PoCs demonstrating reward extraction
- Calculate precision loss magnitude
- Map update call timing
DON'T:
- Report intentional design choices (same token staking)
- Flag missing features with alternative mechanisms
- Ignore precision implications (critical for accuracy)
- Miss edge cases (first deposit, zero stakes)
1---2name: audit-staking3description: Audits Solidity staking and reward protocols for vulnerabilities including front-running first deposit to steal initial rewards, reward dilution via direct transfers, precision loss in reward calculations causing rounding to zero, flash deposit/withdraw griefing diluting rewards, update not called after reward distribution causing stale index, and balance caching issues during claims (project)4license: MIT5---67# Staking & Reward Auditor89## When to Use10- Auditing staking mechanisms, reward distribution, yield farming11- User mentions: staking, rewards, yield, farming, rewardPerToken, deposit, withdraw, claim, first depositor12- Analyzing reward calculations, index updates, share dilution13- Reviewing deposit/withdraw flows, precision handling1415## Audit Workflow1617**IMPORTANT: Announce skill usage at the start of analysis**1819Begin with: "I'm using the **audit-staking** skill to analyze this contract for staking and reward vulnerabilities..."20211. **Scan for staking operations**22 - Search: `stake`, `deposit`, `withdraw`, `claim`, `rewardPerToken`, `totalSupply`, `balanceOf`, `earned`, `updateReward`23 - Focus: reward calculations, first depositor, direct transfers, precision loss, flash actions24252. **Check against vulnerability patterns**26 - Reference `reference.md` for complete checklist27 - Compare code against `example.md`28293. **Validate exploitability**30 - **Check access control first** - grep for `onlyOwner|onlyAdmin|onlyGovernance` modifiers31 - Can non-privileged actors exploit? (first depositor steal, direct transfer dilution, flash griefing)32 - Can direct transfers dilute rewards?33 - Do small amounts round to zero?34 - Can flash deposits/withdraws grief stakers?35 - Is update called after distribution?36 - Are balances cached correctly?37 - Verify no compensating protections exist38 - Downgrade severity if admin-only unless direct user impact39404. **Generate report**41 - Use deliverable template below42 - Include reward theft/dilution analysis and PoC43 - Rank by severity4445## Core Vulnerability Patterns4647See `reference.md` for full checklist. Key patterns:48491. Front-running first deposit → attacker steals initial WETH rewards via sandwich attack502. Reward dilution via direct transfer → sending tokens directly increases totalSupply without staking513. Precision loss in rewards → small stakes or frequent updates cause rewards rounding to zero524. Flash deposit/withdraw griefing → large instant deposits dilute rewards for existing stakers535. Update not called after distribution → stale index causes incorrect reward calculations546. Balance caching issues → claiming updates cached balance incorrectly5556**Code examples:** See `example.md`5758## Severity Criteria5960**Critical:** First depositor can steal all initial rewards, direct transfer dilution enabling theft, flash deposit/withdraw draining rewards, **MUST be exploitable by non-privileged actors**61**High:** Precision loss causing rewards to round to zero for legitimate users, stale index after distribution, **MUST be exploitable by non-privileged actors**62**Medium:** Suboptimal reward distribution timing, griefing via large flash actions without theft, admin-only reward configuration issues with user impact63**Low:** Gas inefficiencies in reward calculations, missing events, admin-only parameter issues without immediate user impact6465**IMPORTANT:** Admin-only reward functions (onlyOwner, onlyAdmin, onlyGovernance) are **MEDIUM or LOW severity** unless:66- Invalid reward parameters directly steal/brick user rewards67- Missing validation enables admin rug pull of staking pool68- Error cascades to all users immediately (e.g., division by zero in reward calculation)6970## False Positives - Do NOT Flag7172- Protocols requiring minimum stake amounts (prevents dust)73- Reward tokens same as staking tokens by design74- Intentional admin-only initial deposit75- View functions with documented staleness76- Protocols with explicit front-running protection7778## Deliverable Format7980**MANDATORY:** Before deliverable, verify each `checklist.md` item against codebase. Flag violations as findings.8182Use template: `templates/report-template.md`8384Each finding includes: severity, pattern #, file/lines, description, vulnerable code, reward theft analysis, PoC, remediation.8586## Key Principles8788- **Separate tokens** - reward token must differ from staking token89- **No direct transfers** - track staked amounts separately from balances90- **Precision protection** - minimum stake, scale factors for small amounts91- **Index updates** - call updateReward before and after distribution92- **Flash protection** - time locks or minimum stake duration93- **Balance integrity** - careful caching during claims9495## Output Guidelines9697**DO:**98- Reference specific lines and functions99- Provide reward theft scenarios with calculations100- Show PoCs demonstrating reward extraction101- Calculate precision loss magnitude102- Map update call timing103104**DON'T:**105- Report intentional design choices (same token staking)106- Flag missing features with alternative mechanisms107- Ignore precision implications (critical for accuracy)108- Miss edge cases (first deposit, zero stakes)