[CRITICAL] Configuration parameter interactions create hidden systemic risks — no safe combination of constants exists

[grantfox-oss]

Summary

The four contracts use interdependent configuration constants (fee BPS, minimum bet, TTL values, MAX_TOP_PLAYERS, decay parameters, referral bonus multipliers) that interact in ways the individual tests do not cover. There is no invariant test that verifies the combination of all constants produces safe behavior across all contract boundaries simultaneously.

Key interactions at risk

1. cancel_market reclaim vs. withdraw_fees cap (issue [CRITICAL] cancel_market fee reclaim uses wrong fee rate denominator — reclaims 200 bps but market only holds 150 bps platform fees #87 vs [CRITICAL] withdraw_fees lets fee recipient drain entire accumulator — no cap, no provenance #94): cancel_market reclaims fees_in_pool = net_pool * TOTAL_FEE_BPS / (BPS_DENOM - TOTAL_FEE_BPS) from the global AccumulatedFees, but withdraw_fees draws from the same accumulator. If both fire in the same ledger sequence, the order of operations determines whether fees are under- or over-accounted.

2. TTL vs. market duration: MarketTTL (30 days) is shorter than max_duration_secs (60 days). A market that runs its full duration and is then claimed will have an expired BetEntry before the claim window closes.

3. Leaderboard points vs. PULSE minting: reward mints points * REWARD_RATE PULSE per call. If MAX_TOP_PLAYERS is increased without adjusting REWARD_RATE, the leaderboard can exceed the token supply cap in a single distribution round.

4. Referral depth vs. fee caps: withdraw_fees takes from a global accumulator with per-market fee tracking. If referral chains are deep and fees compound, a single cancel_market reclaim can wipe the accumulator, leaving withdraw_fees with nothing for active markets.

Why it's critical

No single constant is individually unsafe, but the combination creates state-invariant violations that no per-issue patch can address. This is effectively unsolvable without a coordinated cross-contract redesign.

Fix

• Add a cross-contract invariant test suite that exercises every constant combination.
• Document the invariant matrix (fee BPS × market duration × TTL × reward rate × referral depth).
• Introduce a governance process for constant changes that requires re-verification of all invariants.

[praizeD10]

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

I understand that the contracts’ configuration constants can interact in ways that are not covered by the current individual tests. My approach would be to build cross-contract invariant tests covering fees, TTLs, market duration, rewards, and referral behavior, then document the important combinations.

I’ll verify the identified edge cases and ensure future constant changes can be checked against the defined invariants. I’ll follow the repository requirements and wait for assignment before starting.

[Samaro1]

Gm gm boss. I would like to take this one on. I can build the cross-contract invariant test suite exercising the fee BPS, market duration, TTL, reward rate, and referral depth interactions, document the invariant matrix showing where the cancel_market/withdraw_fees accumulator conflict and the TTL/duration mismatch and PULSE-supply-cap risks live, and put forward the governance re-verification process for future constant changes. Please assign it to me.

[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 #175)
2. Your PR will be reviewed by the SPulse-Org maintainers

Good luck! Track your progress on GrantFox.