Fix #1399: Validate event creation before charging fees

[Peolite001]

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 #1399

Priority Level

• 🔴 Critical (blocking other development)
• 🟡 High (significant impact)
• 🟢 Medium (moderate impact)
• 🔵 Low (minor improvement)

---

📝 Detailed Description

What does this PR do?

This PR ensures that create_event correctly validates the event's end_time parameter before collecting the creation fee. It correctly processes the creation fee via FeeManager after all validations have passed, and modifies emit_event_created to record the dynamically calculated fee instead of a hardcoded constant.

Why is this change needed?

Previously, create_event did not properly validate that the event's end_time was in the future, nor did it charge the proper creation fee. This could have led to a situation where invalid events are created without adequate validation, circumventing required fee models and resulting in inconsistent state or security regressions. The changes enforce least privilege and input validation bounds to be fully deterministic.

How was this tested?

This change was verified against the existing test suite:

• Validated that create_event rejects past end_time.
• Validated that create_event successfully collects the configured fee and emits the event.

Alternative Solutions Considered

N/A

---

🏗️ 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

cargo test
# All existing tests now pass and validate the new fee checking logic accurately.

Manual Testing Steps

1. Create an event with a past end_time and observe it failing with Error::InvalidDuration prior to fees being assessed.
2. Create a valid event and observe the dynamic fee properly being processed and tracked via the EventCreatedEvent.

---

📚 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:

• None.

Migration Guide:

• N/A

---

🔍 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 a basic end_time validation and dynamically grabs the configured fee amount, mirroring similar operations in create_market.
• Storage Impact: None.
• Computational Complexity: O(1).

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: N/A
• Migration Required: No
• Special Instructions: None.

Integration Points

• Frontend integration considered
• API changes documented
• Backward compatibility maintained
• Third-party integrations updated

---

📊 Impact Assessment

User Impact

• End Users: No major disruption. Validations now correctly prevent bad parameters.
• Developers: Ensure any event creation flow properly covers fees.
• Admins: Reliable fee processing for newly created events.

Business Impact

• Revenue: Prevents missed fee collection on create_event.
• User Experience: Clear deterministic failures for invalid times.
• Technical Debt: Reduced inconsistencies between create_market and create_event.

---

✅ Final Checklist

Pre-Submission

• Code follows Rust/Soroban best practices
• All CI checks passing
• 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

---

📸 Screenshots (if applicable)

N/A

🔗 Additional Resources

• Related Discussion: Issue [Quality-2][High] Validate event creation before charging fees #1399

---

💬 Notes for Reviewers

Please pay special attention to:

• Validations mapping into the newly inserted end_time <= env.ledger().timestamp() check.
• Parameter signature modifications on EventEmitter::emit_event_created.

Questions for reviewers:

• Should the InvalidDuration error be specific to create_event, or is the reused error correctly appropriate for this bounding logic?

---

Thank you for your contribution to Predictify! 🚀

[drips-wave]

@Peolite001 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