[CRITICAL] `withdraw_fees` lets fee recipient drain entire accumulator — no cap, no provenance

[grantfox-oss]

Summary

prediction_market/src/lib.rs withdraw_fees (lines ~1630-1660) allows the designated fee recipient to withdraw the entire AccumulatedFees in a single call, with:

1. No per-transaction cap — a single call can drain 100% of accumulated fees.
2. No provenance tracking — fees from market A can be withdrawn by a recipient who is only authorized for market B.
3. No per-market segregation — the accumulator is a single global pool mixing fees from all markets.

Impact

• A compromised or malicious fee recipient can steal the entire platform fee reserve in one transaction.
• If the fee recipient is a contract, it can chain withdraw_fees → place_bet → claim in a single transaction to drain additional value.
• Cross-market contamination: fees earned by market A are indistinguishable from fees earned by market B, so a recipient authorized for only one market can steal from the other.

Fix

• Cap single withdrawals to a percentage of the accumulator (e.g., 10% per call) with a timelock.
• Track fee provenance per market and only allow withdrawal of fees earned by markets the recipient is authorized for.
• Require a timelock between request_withdraw_fees and execute_withdraw_fees so governance can intervene.
• Emit a FeesWithdrawn event with the source market IDs and amounts.

[praizeD10]

Hi Maintainer, I’d like to apply for this issue.

I understand that withdraw_fees can currently drain the entire global fee accumulator without per-market tracking or a withdrawal delay. My approach would be to introduce safer withdrawal limits, track fee provenance by market, and add a timelocked withdrawal flow where appropriate.

I’ll add tests covering withdrawal limits, market authorization, timelock behavior, and fee accounting to ensure funds cannot be improperly drained. I’ll follow the repository requirements and wait for assignment before starting.

[DanProtocol]

Hi maintainers,

I’d like to contribute to this feature by working on the voting-power concentration and decentralization risk monitor.

I’d start by reviewing the existing governance and voting-power logic, then define the key concentration metrics and thresholds that make sense for the protocol. From there, I’d implement the monitor with a focus on accurate calculations, edge cases, and useful risk signals rather than adding unnecessary complexity.

I’d also include the relevant tests and keep the implementation modular so it can be extended as the governance system evolves.

Happy to start with the implementation and iterate based on maintainer feedback.

[grantfox-oss]

🦊 GrantFox — @praizeD10 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #172)
2. Your PR will be reviewed by the SPulse-Org maintainers

Good luck! Track your progress on GrantFox.