Open hats-bug-reporter[bot] opened 3 months ago
Upgradability deals with this issue.
Thank you for the comment, will wait for sponsor review.
Upgrading the contract might overkill and affecting others unrelated orchestrator module. Instead of upgrading, it's better to just assign in init function for a custom DEPOSIT_CAP, instead of hardcoding 100_000_000e18
.
@PlamenTSV thank you, but i think the issue is valid.
We do see the argument that low-value tokens (like meme coins) or high decimal tokens will lead to a (speaking from a value perspective) low cap for the funding manager. We do not see this as a problem though, as upgradeability can fix this and it was intentionally designed this way.
Github username: -- Twitter username: -- Submission hash (on-chain): 0xee679aac7efed8d163ae50ab1c3c1559a73fe8b045b0e7db76c0b99ffd61a35a Severity: low
Description: Description
DEPOSIT_CAP
should not be a constant value, as some token might easily overpass the cap, for example for a low price token.Instead this
DEPOSIT_CAP
should be defined by the owner on initialization.For example, if the token is PEPE, this will easily filled up as PEPE token is large amount (with same 18 decimal)
Recommendation
Consider to add a custom
DEPOSIT_CAP
value when initializing