Add per market dispute stake floor

[GiftedGiftB]

Pull Request Description
📋 Basic Information
Type of Change
Please select the type of change this PR introduces:

🐛 Bug fix (non-breaking change which fixes an issue)
✨ New feature (non-breaking change which adds functionality)
💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
📚 Documentation update
🧪 Test addition/update
🔧 Refactoring (no functional changes)
⚡ Performance improvement
🔒 Security fix
🎨 UI/UX improvement
🚀 Deployment/Infrastructure change
Related Issues
Closes #844

Priority Level
🔴 Critical (blocking other development)
🟡 High (significant impact)
🟢 Medium (moderate impact)
🔵 Low (minor improvement)
📝 Detailed Description
What does this PR do?
This PR implements a configurable per-market dispute stake floor. It updates the core Market and MarketCreationParams data structures to accept an optional dispute_stake_floor. Additionally, it integrates logic into the dispute handling flow so that the effective minimum stake required to file a dispute is the maximum of the global anti_grief_floor and the market's specific dispute_stake_floor.

Why is this change needed?
To prevent grief-disputes and ensure that the cost of initiating a dispute remains economically significant, even for high-volume or high-stakes markets. While the global anti-grief floor provides baseline protection, this feature allows individual markets to enforce stricter requirements based on their specific risk profiles.

How was this tested?
A focused unit test suite (test_market_specific_anti_grief_floor) was added to disputes.rs to validate the dispute floor enforcement logic across various edge cases (e.g., when the market floor is higher or lower than the global floor). Existing test fixtures across the test suite were updated to initialize dispute_stake_floor: None.

Alternative Solutions Considered
We considered relying solely on a dynamic global floor based on market size, but decided against it to give market creators explicit deterministic control over their dispute parameters.

🏗️ Smart Contract Specific
Contract Changes
Please check all that apply:

Core contract logic modified
Oracle integration changes (Pyth/Reflector)
New functions added
Existing functions modified
Storage structure changes
Events added/modified
Error handling improved
Gas optimization
Access control changes
Admin functions modified
Fee structure changes
Oracle Integration
Pyth oracle integration affected
Reflector oracle integration affected
Oracle configuration changes
Price feed handling modified
Oracle fallback mechanisms
Price validation logic
Market Resolution Logic
Hybrid resolution algorithm changed
Dispute mechanism modified
Fee structure updated
Voting mechanism changes
Community weight calculation
Oracle weight calculation
Security Considerations
Access control reviewed
Reentrancy protection
Input validation
Overflow/underflow protection
Oracle manipulation protection
🧪 Testing
Test Coverage
Unit tests added/updated
Integration tests added/updated
All tests passing locally
Manual testing completed
Oracle integration tested
Edge cases covered
Error conditions tested
Gas usage optimized
Cross-contract interactions tested
Test Results
bash

Focused test run for dispute logic (due to existing API drift in the wider suite)

cargo test -p predictify-hybrid test_market_specific_anti_grief_floor

Expected output: test test_market_specific_anti_grief_floor ... ok

Manual Testing Steps
Validated that create_market appropriately maps dispute_stake_floor to the underlying Market storage.
Simulated dispute workflows where the user stakes lower than the effective floor (Error::InvalidStakeAmount returned).
Verified compilation success for test fixtures adjusted with dispute_stake_floor: None.
📚 Documentation
Documentation Updates
README updated
Code comments added/updated
API documentation updated
Examples updated
Deployment instructions updated
Contributing guidelines updated
Architecture documentation updated
Breaking Changes
Breaking Changes:

MarketCreationParams::new now requires a 7th argument (Option) for the dispute stake floor.
Market structure sizing changed (requires migration if interacting with existing state).
Migration Guide: Any manual instantiation of Market or MarketCreationParams::new must provide None or a valid Some(i128) value for dispute_stake_floor.

🔍 Code Quality
Code Review Checklist
Code follows Rust/Soroban best practices
Self-review completed
No unnecessary code duplication
Error handling is appropriate
Logging/monitoring added where needed
Security considerations addressed
Performance implications considered
Code is readable and well-commented
Variable names are descriptive
Functions are focused and small
Performance Impact
Gas Usage: Negligible impact. Only adds an additional .max() comparison during dispute processing.
Storage Impact: Increases the Market struct size slightly by adding one Option.
Computational Complexity: O(1) impact on dispute validation.
Security Review
No obvious security vulnerabilities
Access controls properly implemented
Input validation in place
Oracle data properly validated
No sensitive data exposed
🚀 Deployment & Integration
Deployment Notes
Network: Testnet/Mainnet
Contract Address: TBD
Migration Required: Yes (due to changes in the Market struct layout).
Special Instructions: Test suite contains unrelated compilation failures from API drift that must be resolved prior to full deployment.
Integration Points
Frontend integration considered
API changes documented
Backward compatibility maintained
Third-party integrations updated
📊 Impact Assessment
User Impact
End Users: Predictors and disputers will experience stricter, localized stake requirements for select markets, reducing spam.
Developers: Must update parameter lists when programmatically creating markets or invoking test fixtures.
Admins: Can now deploy markets with bespoke grief-prevention thresholds.
Business Impact
Revenue: No direct impact.
User Experience: Increases trust by safeguarding community resolution from inexpensive griefing vectors.
Technical Debt: Clean integration with minimal overhead.
✅ Final Checklist
Pre-Submission
Code follows Rust/Soroban best practices
All CI checks passing (Note: see API drift in unrelated modules)
No breaking changes (or breaking changes are documented)
Ready for review
PR description is complete and accurate
All required sections filled out
Test results included
Documentation updated
Review Readiness
Self-review completed
Code is clean and well-formatted
Commit messages are clear and descriptive
Branch is up to date with main
No merge conflicts

[drips-wave]

@GiftedGiftB Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits