Enhancing Prediction Accuracy: Mode Flags & Storage

Hey guys! Let's dive into an exciting enhancement for our protocol that's all about boosting prediction skills and creating a better user experience. We're talking about implementing a mode flag and separate storage for different prediction styles. This is a game-changer, trust me!

🌊 Why This Matters: Unleashing Progressive Prediction Skills

Our protocol is designed to be a learning platform for anyone to develop their prediction abilities. We want to make it easy for beginners to start, and then reward skill and precision as users become more experienced. So, what does this mean in practice? Well, we have two primary modes of prediction:

• Up/Down Mode: This is your entry point. It's designed to be simple and accessible, perfect for newcomers to get their feet wet. It's all about predicting whether something will go up or down – easy peasy!
• Legends (Precision) Mode: This mode is for those who are ready to level up their game. It's all about accuracy and confidence, rewarding those who can make precise predictions. This is where the real experts shine.

The current setup supports these ideas, but it's not super structured. Our proposal introduces a mode flag for each round and separate prediction storage. This will make it easier for both modes to coexist without complicating the core logic. This is not just a tweak; it's a foundational change that will unlock future gameplay, improve the user experience, and create clearer mental models for everyone involved.

Expanding on the Benefits

This change will not only improve the user experience but also streamline the development process. By separating the storage, we can tailor the system to better accommodate the specific needs of each prediction style. This means faster, more efficient operations and a more enjoyable experience for everyone. Plus, it will allow for more advanced features down the road. This allows for a more focused and optimized experience for users. The addition of a mode flag per round ensures that each prediction type is handled separately.

🎯 Goal: Clear Mode Declaration and Organized Storage

Our primary goal is to make it easy for each round to explicitly declare its prediction mode and store predictions in the correct structure. The main idea here is to create a much more flexible and scalable system. This is crucial for long-term growth and ensures that the protocol can accommodate new features and prediction styles as needed.

This also sets the stage for future integrations and partnerships. This update is not just a small improvement; it's a big step forward in our commitment to create a superior and more user-friendly prediction platform. Think of it as laying the groundwork for exciting new features and expanded capabilities in the future. By getting this right, we're building a system that is robust and adaptable, one that can evolve and grow with the community's needs.

Why Separate Storage is Key

The separation of storage is critical for several reasons. For Up/Down mode, it provides a simple and efficient storage mechanism. For Precision mode, it allows us to store the necessary details for accurate calculations and rewards. This focused approach makes the system more efficient and easier to manage, reducing potential errors and improving overall performance. By keeping things neat and organized, we're ensuring that everything runs smoothly. We want to provide a reliable and efficient platform.

✅ Acceptance Criteria: Defining the Implementation

Let's break down the technical aspects of this update. Here's what we need to get it done:

• create_round Parameter: The create_round function needs a new parameter: mode: u32.
  • 0 = Up/Down
  • 1 = Legends (Precision)
• Mode Storage: The mode needs to be stored in the round state.
• Prediction Storage: We need separate storage for each prediction mode.
  • Up/Down: Map<Address, i128>
  • Precision: Vec<(Address, u128)> (price scaled to 4 decimals, e.g., 0.2297 -> 2297)
• Default Mode: If a mode isn't explicitly passed, it should default to mode = 0 (Up/Down).
• Round Creation Event: We'll emit a round creation event that includes the selected mode. This will help with transparency and provide a clear record of each round's configuration. The event will make it easier to track and verify the mode of each round.

Technical Deep Dive

The implementation involves careful use of Soroban's native data structures. For the Up/Down predictions, we're leveraging the Map data structure, which provides a straightforward way to store address-based predictions. For Precision mode, we'll use Vec, which allows us to store precise predictions along with associated addresses. The system also includes validation of the mode parameter to prevent incorrect values from being used. Existing round IDs and ledger timing logic will be reused to maintain consistency.

🧭 Implementation Guidelines: Step-by-Step Approach

To make this happen, here's the plan:

• Soroban-Native Structures: Use Soroban-native Map and Vec to store and manage the data. This approach is efficient and well-suited for our needs.
• Mode Validation: Ensure that the mode parameter is either 0 or 1. This simple validation step ensures data integrity.
• Leverage Existing Logic: Reuse the existing round IDs and ledger timing logic to maintain consistency across the system. We don't want to reinvent the wheel, so we will use existing and proven functionalities.
• Resolution Logic: Do not modify the resolution logic in this issue. That will be handled separately. This will help to focus on the key features of the current update.

Best Practices for Implementation

This project will need a focus on code readability, performance, and adherence to established best practices. Clear and concise code is always important, especially when working with others. Performance optimization is crucial. We should look to find the best possible way to use the Soroban native structures. This would enable faster operations. Make sure that all code adheres to the best standards. Code reviews and thorough testing are essential to ensure everything works properly and securely.

🔍 Review Expectations: What to Include in Your PR

When you submit your pull request (PR), make sure to include the following:

• Comprehensive Tests: Include invoke tests that cover both modes. Testing will ensure that everything works as expected.
• Contract Details: The contract ID and deployment log.
• Clear Commit Message: Include a clear commit message like feat: add mode flag and separate prediction storage. This helps other contributors understand the changes.

The Importance of a Well-Structured PR

Your PR should be a comprehensive package that enables other developers to review and understand your changes effectively. Detailed tests are vital. These will ensure that all the features are properly implemented and are working as intended. A clear commit message, contract details, and the deployment log will provide important context and help others understand your changes. With clear documentation and detailed testing, we ensure that the changes are implemented and are working as intended. A well-organized PR is also essential for a smooth and collaborative development process.

🏁 Conclusion: Completion Criteria

This issue is considered complete when rounds can be created with an explicit mode and the predictions are separated cleanly. When these requirements are met, we can celebrate a successful implementation! This will set us up for even more exciting developments in the future. We're on the right track!