Skip to content

Issues: hats-finance/Mento-0x2a1b9b1f6fa7c2e73815a7dff0e1688767382694

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

45 Open 0 Closed
45 Open 0 Closed
Author
Filter by author
Loading
Label
Filter by label
Loading
Use alt + click/return to exclude labels
or ⇧ + click/return for logical OR
Projects
Filter by project
Loading
Milestones
Filter by milestone
Loading
Assignee
Filter by who’s assigned
Sort
Sort by
Newest Oldest Most commented Least commented Recently updated Least recently updated Best match
Most reactions
👍 👎 😄 🎉 😕 ❤️ 🚀 👀

Issues list

overflow risk in safeInt() function invalid This doesn't seem right
#45 opened Jan 29, 2025 by hats-bug-reporter bot
1
Insufficient Validation of Lock Duration Parameters invalid This doesn't seem right
#44 opened Jan 25, 2025 by hats-bug-reporter bot
1
Locking::__Locking_init can be frontrun by an attacker low
#43 opened Jan 24, 2025 by miaowu311
2
Should maintain the protocol's core functionality of linear voting power decay invalid This doesn't seem right
#42 opened Jan 23, 2025 by hats-bug-reporter bot
1
All lock parameters should remain within protocol-defined bounds, maintaining the integrity of the voting power mechanism. invalid This doesn't seem right
#41 opened Jan 23, 2025 by hats-bug-reporter bot
1
Voting power should remain proportional to locked tokens while maintaining the intended governance mechanics. invalid This doesn't seem right
#40 opened Jan 23, 2025 by hats-bug-reporter bot
1
Incorrect slope calculation during cliff-to-slope transition invalid This doesn't seem right
#39 opened Jan 23, 2025 by hats-bug-reporter bot
1
voting power should decays strictly linearly as required by the protocol invalid This doesn't seem right
#38 opened Jan 23, 2025 by hats-bug-reporter bot
1
The protocol should maintain consistent state between token balances and internal accounting, protecting core voting power mechanics. invalid This doesn't seem right
#37 opened Jan 23, 2025 by hats-bug-reporter bot
1
Division by zero in lock function invalid This doesn't seem right
#36 opened Jan 23, 2025 by hats-bug-reporter bot
4
Emergency withdrawals are blocked because getWeekNumber reverts when paused invalid This doesn't seem right
#35 opened Jan 22, 2025 by hats-bug-reporter bot
1
Individual account balance reduction without corresponding totalSupplyLine update invalid This doesn't seem right
#34 opened Jan 22, 2025 by hats-bug-reporter bot
1
The voting power calculation in getLock() can reduce the effective voting power based on slope/cliff parameters, while the raw token accounting remains unadjusted. invalid This doesn't seem right
#33 opened Jan 22, 2025 by hats-bug-reporter bot
1
Insufficient validation of total lock duration allows exceeding maximum intended lock time invalid This doesn't seem right
#32 opened Jan 22, 2025 by hats-bug-reporter bot
1
Non-atomic voting power transition during relock operations invalid This doesn't seem right
#31 opened Jan 22, 2025 by hats-bug-reporter bot
1
During cliff period, bias is incorrectly reduced linearly invalid This doesn't seem right
#30 opened Jan 22, 2025 by hats-bug-reporter bot
1
Time calculations could be incorrect during transition invalid This doesn't seem right
#29 opened Jan 22, 2025 by hats-bug-reporter bot
1
rebalance() focuses on residue comparison but misses validating the total locked amount doesn't decrease invalid This doesn't seem right
#28 opened Jan 22, 2025 by hats-bug-reporter bot
1
Withdrawal doesn't properly decrease the voting power represented by the BrokenLine structure, allowing users to maintain voting power even after withdrawing the underlying tokens. invalid This doesn't seem right
#27 opened Jan 21, 2025 by hats-bug-reporter bot
2
State change before token transfer creates risk of locked funds invalid This doesn't seem right
#26 opened Jan 21, 2025 by hats-bug-reporter bot
2
LibBrokenLine.sol's update() function must be called explicitly to apply pending slope changes and update the bias/slope state. invalid This doesn't seem right
#25 opened Jan 21, 2025 by hats-bug-reporter bot
1
The order of operations needs to be rearranged to maintain consistent voting power accounting throughout the delegation transfer process. invalid This doesn't seem right
#24 opened Jan 21, 2025 by hats-bug-reporter bot
1
ownership verification can be bypassed due to improper validation of lock existence before ownership checks. invalid This doesn't seem right
#23 opened Jan 21, 2025 by hats-bug-reporter bot
2
week calculation changes at L2 transition without preserving relative voting power invalid This doesn't seem right
#22 opened Jan 21, 2025 by hats-bug-reporter bot
1
The validation require(slopePeriod <= amount) is placed after the slope calculations have already occurred, allowing the incorrect math to happen first. invalid This doesn't seem right
#21 opened Jan 21, 2025 by hats-bug-reporter bot
1
ProTip! Adding no:label will show everything without a label.