Task/betting events v7

[Kingsley4867]

Close #927

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

Priority Level

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

---

📝 Detailed Description

What does this PR do?

This PR introduces structured lifecycle events for the betting contract by implementing standardized event definitions in contracts/betting/src/events.rs. The new events provide a consistent format for tracking betting-related actions and improve observability for off-chain consumers.

In addition, focused tests were added to verify that the expected events are emitted with the correct topics and payloads.

Why is this change needed?

Structured events make contract activity easier to monitor, index, and consume by wallets, explorers, analytics platforms, and other integrations. They also establish a stable event interface for future development while improving contract transparency.

How was this tested?

• Added focused unit tests covering event emission.
• Verified event topics and payloads for supported betting lifecycle operations.
• Ran the project's standard test suite using cargo test.
• Confirmed existing behavior remains unchanged aside from the new emitted events.

Alternative Solutions Considered

Using ad-hoc event emission throughout the contract was considered, but centralized structured events provide a more maintainable and consistent interface for both developers and downstream consumers.

---

🏗️ Smart Contract Specific

Contract Changes

• 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

# Replace with your actual output

cargo test

<insert full cargo test output here>

Manual Testing Steps

1. Implemented structured betting lifecycle events.
2. Added unit tests covering event emission.
3. Ran cargo test.
4. Verified emitted event topics and payloads match the expected structure.

---

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

No migration is required. Existing consumers can continue functioning, while indexers and integrations may optionally begin consuming the new structured events.

---

🔍 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: Minor increase due to event emission.
• Storage Impact: None.
• Computational Complexity: Negligible impact.

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: N/A
• 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 direct user-facing changes.
• Developers: Easier event consumption and improved debugging.
• Admins: Better visibility into contract activity.

Business Impact

• Revenue: None.
• User Experience: Improved monitoring and ecosystem integrations.
• Technical Debt: Reduced through standardized event definitions.

---

✅ 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: Add structured events on betting (v7) #927

---

💬 Notes for Reviewers

Please pay special attention to:

• The structure and naming consistency of emitted betting events.
• Event topics and payloads for compatibility with downstream consumers.
• Test coverage for all newly introduced lifecycle events.

Questions for reviewers:

• Do the event names and payload structures align with the project's conventions?
• Are there any additional betting lifecycle events that should be standardized in this PR?

---

Thank you for your contribution to Predictify! 🚀

[drips-wave]

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