[CRITICAL] `set_config` can re-point market to malicious contracts — total fund theft

[grantfox-oss]

Summary

prediction_market/src/lib.rs set_config (lines ~375-420) allows the governor to replace the token, referral, leaderboard, and XLM Sac contract addresses without any validation. There is no allowlist check, no code-hash pinning, and no event emission for config changes.

Impact

• A compromised or malicious governor can redirect all place_bet XLM deposits to a malicious token contract that absorbs funds and never credits outcomes.
• A malicious referral registry can intercept 100% of referral fees.
• A malicious leaderboard can inflate rewards to arbitrary addresses.
• No off-chain monitoring is possible — no event is emitted when the config changes.

Fix

• Pin WASM hashes for all dependency contracts and verify on set_config.
• Require a timelock (7+ days) between config request and approval.
• Emit a ConfigChanged event with old/new addresses.
• Maintain an allowlist of approved dependency deployments.

[samjay8]

Hi team,

I'd like to work on resolving this issue. Here is my proposed plan of approach to secure set_config against arbitrary contract replacement risks:

Plan of Approach

1. WASM Hash Pinning & Allowlist Validation:

   • Update set_config in prediction_market/src/lib.rs (~lines 375-420) to validate new target contract addresses against an allowlist of approved WASM executable code-hashes.
   • Verify that any updated target contract address matches expected WASM bytecode before allowing state updates.

2. Implement Timelocked Configuration Updates:

   • Introduce a two-step timelock mechanism (request_config_change and execute_config_change) with a mandatory delay window (e.g., 7 days).
   • Ensure pending configuration changes are stored temporarily and cannot take effect until the timelock expires, giving off-chain monitors time to react.

3. Emit ConfigChanged Event:

   • Define and emit a structured ConfigChanged event containing old/new contract addresses, parameter identifiers, and execution timestamps to enable off-chain indexing and security alerts.

4. Testing & Security Assertions:

   • Write unit tests verifying that unauthorized WASM code-hashes are immediately rejected during set_config.
   • Add integration tests validating timelock delay enforcement and confirming ConfigChanged event emissions upon execution.

I can implement these security enhancements and test cases promptly.

[grantfox-oss]

🦊 GrantFox — @samjay8 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 #173)
2. Your PR will be reviewed by the SPulse-Org maintainers

Good luck! Track your progress on GrantFox.