If the admin removes a collection from the whitelist, all escrowed native tokens associated with that collection will become inaccessible until the collection is re-whitelisted. This poses a centralization risk, as users are dependent on the admin to regain access to their funds.
The protocol relies on a whitelist managed by the admin to control which collections are active. If a collection is removed from the whitelist, any tokens escrowed under that collection are stuck and cannot be retrieved by users. This forces users to rely on the admin to re-enable the collection, leading to potential loss of assets and undermining the decentralized nature of the system.
The impact is significant, as users can lose access to their escrowed funds indefinitely, exposing the protocol to centralization risks and potential abuse by the admin.
Grace Period for Delisting: Implement a grace period before a collection is fully removed, allowing users to withdraw funds.
Automated Withdrawals: Ensure users can automatically withdraw escrowed tokens if a collection is delisted.
Decentralize Whitelist Management: Use decentralized governance to manage the whitelist, reducing reliance on a single admin.
Transparency: Provide clear communication before any whitelist changes.
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.