Enhancing Prediction: Mode Flag & Storage Separation

Hey everyone! Today, we're diving into a crucial upgrade for our prediction protocol. We're talking about implementing a mode flag and separate storage for different prediction styles. This is a game-changer, folks, and will significantly impact how we approach predictions, making it more user-friendly and rewarding for everyone involved. Let's break it down!

🌊 The Big Picture: Why This Matters

At the heart of our protocol lies the mission to foster progressive prediction skills. We want to make it easy for beginners to jump in while also providing a playground for seasoned experts to hone their craft. This is why introducing the Up/Down mode and the Legends (Precision) mode is so important. The Up/Down mode lowers the entry barrier, allowing anyone to start making predictions. On the other hand, the Legends mode rewards skill, accuracy, and confidence, providing a more challenging and rewarding experience for those looking to level up their prediction game. Right now, the ideas are conceptually supported but not structurally enforced. This means that while we understand the concept, we haven’t fully integrated it into the system. This change introduces a mode flag per round and separate prediction storage, which will allow both styles to coexist cleanly without complicating the core logic. This is like giving a chef two separate sets of tools to cook different kinds of dishes. It keeps everything organized and makes the entire process smoother. This is a foundational change that unlocks future gameplay possibilities, enhances the user experience, and creates clearer mental models for both our contributors and users. It’s a step towards making our protocol more robust, versatile, and enjoyable for everyone.

This update is not just about adding features; it's about fundamentally improving how we structure and manage predictions. Imagine having a system that not only supports different prediction styles but also streamlines their storage and processing. That's what we're aiming for! This change is a building block that supports future growth and innovation. Implementing this update is like laying the groundwork for a whole new ecosystem of prediction games and features. This improvement makes it easier to add new modes, features, and challenges in the future. By separating the storage, we're ensuring that the system can handle different types of predictions without creating conflicts or confusion.

Think about it: the more organized our system is, the easier it is to innovate and add new functionalities. This is a move that benefits everyone – from the casual predictor to the seasoned pro. It's about enhancing the core experience and setting the stage for even more exciting developments down the line. We want to create an environment where everyone feels welcome and challenged. This is a step towards achieving that goal, making our protocol more user-friendly, and helping users improve their prediction skills.

🎯 Goal: Clear Mode and Organized Storage

The primary goal of this update is to allow each round to explicitly declare its prediction mode and store predictions in mode-appropriate structures. What does that mean? It means we'll add a way for each prediction round to specify whether it's an Up/Down round or a Precision round. Based on the selected mode, predictions will be stored in separate structures. This targeted approach is like setting up distinct filing cabinets for different types of information. It avoids clutter, simplifies searching, and enhances overall efficiency. This separation is crucial for streamlining the prediction process and making it more user-friendly.

By explicitly declaring the mode, we reduce potential confusion. Think of it as labeling each box of predictions with a clear identifier. This enables us to: (a) clearly distinguish between different prediction styles, (b) store data efficiently, and (c) simplify processing. This will make it easier to add new prediction styles in the future. The benefits extend beyond the immediate improvements, making it simpler to introduce new features and enhancements. This update lays the groundwork for future innovations, ensuring the protocol remains adaptable and user-centric.

Imagine the benefits this will bring. For beginners, it means a less intimidating environment, with clear instructions and easier entry points. For experts, it means a more refined and challenging prediction arena. And for the protocol itself, it means greater flexibility and scalability. By ensuring that the system knows what type of prediction it's dealing with, we’re setting the stage for a more robust and efficient system.

This goal also addresses the need for structured data storage. The way we store the prediction data has a direct impact on the performance and flexibility of our protocol. The goal of this update is to not only make the prediction process more streamlined but also provide a more organized and accessible data environment for the benefit of all users. This targeted approach aims at enhancing the entire prediction journey, offering a smoother and more rewarding experience for everyone involved.

✅ Acceptance Criteria: How We Get There

Here’s the game plan, folks! We're implementing specific changes to ensure that we meet our goals effectively. This is the checklist that will ensure everything is working correctly and the implementation is running smoothly. We’re going to be adding a few key elements to the protocol to make this happen.

• First, the create_round function will get a new parameter: mode: u32. This parameter will determine which prediction mode the round will use. The mode parameter will decide which prediction style will be used for the round. The value of 0 will represent Up/Down mode, and the value of 1 will represent Legends (Precision) mode. This direct declaration ensures that the system knows exactly which mode to use from the start.
• Second, the mode parameter is stored in the round state. This ensures that the system remembers the chosen mode for the duration of the round. The mode will be stored in the state of the round. This provides context throughout the prediction process. The mode value will be consistently accessible.
• Third, the prediction storage will be separated:
  • For Up/Down mode, we will use a Map<Address, i128>. This is an efficient way to store predictions for the Up/Down style.
  • For Precision mode, we will use a Vec<(Address, u128)>. This will store precision predictions, with the price scaled to four decimals (e.g., 0.2297 → 2297). This separation ensures that each type of prediction is stored in an appropriate structure, optimizing storage and retrieval.
• Fourth, the default mode is set to 0 if no mode is passed. If the mode isn’t explicitly specified, the system will default to Up/Down mode, ensuring that the process is straightforward for new users.
• Fifth, we'll emit a round creation event that includes the selected mode. This will provide transparency and enable us to track and analyze round data efficiently. The inclusion of the mode in the event ensures that all activities are easily auditable. This is like a logbook entry for each round, helping us keep track of all that happens.

These acceptance criteria ensure a clear and structured implementation, laying the groundwork for a more adaptable and user-friendly prediction protocol. By following these steps, we're not only implementing the requested features, but also ensuring that the system is set up for future growth and scalability. We are laying the groundwork for future innovations and enhancements by making sure the system is flexible and adaptable.

🧭 Implementation Guidelines: Building the Framework

Alright, let’s talk about how we're going to build this. We need to be specific about the technical aspects to guarantee a smooth and functional integration. We're going to use some of Soroban’s native tools to get the job done right. This is all about ensuring that we're using the right tools for the job to make everything work together seamlessly.

• Use Soroban-native Map and Vec: We'll leverage Soroban’s native Map and Vec structures for data storage. This ensures efficient data management and leverages the existing functionality of the Soroban ecosystem.
• Validate the mode parameter: We’ll validate that the mode parameter is either 0 or 1. This simple validation step guarantees that only valid modes are used, reducing the chance of errors. This is crucial for maintaining the system’s integrity and preventing unexpected issues.
• Reuse existing logic: We'll reuse existing round IDs and ledger timing logic. This helps keep things consistent and reduces the amount of new code. This keeps things efficient by using what we already have and minimizes redundant efforts.
• Do not alter resolution logic: The resolution logic will remain untouched in this update. This ensures that the core functionality is preserved, and we don’t need to worry about disrupting the existing process. We’re keeping the focus on mode and storage. This is to ensure we remain focused on the key objectives and avoid unnecessary complexity.

These guidelines make sure we’re building on a solid foundation and that the new features integrate well with the existing infrastructure. We're ensuring that the new features work together seamlessly and efficiently by sticking to these guidelines. These are all critical steps that ensure a smooth implementation process, resulting in a reliable and functional protocol.

🔍 Review Expectations: What We're Looking For

To ensure a smooth transition, we have a few expectations for the review process. We want to be thorough and make sure everything works perfectly. When submitting the changes, there are a few things that need to be included. These are important steps to ensure everything works correctly and that the integration is robust.

• Invoke tests: The code changes should include invoke tests to cover both modes. This is vital to verify that the mode flag and storage separation are working correctly in different scenarios.
• Contract ID and deployment log: Include the contract ID and deployment log in the pull request. This provides transparency and enables us to track the deployment. This will help with tracking, and it makes it easier to refer back to the deployment details in case of any issues.
• Clear commit message: Your commit message should be clear and concise. A suggested message format is feat: add mode flag and separate prediction storage. This ensures that everyone knows what the commit changes. This makes the review process smoother.

This issue will be considered complete once rounds can be created with an explicit mode, and predictions are separated by design. We want to make sure that everything functions as intended. These requirements are in place to ensure a smooth transition and that all the new features work as expected. These steps help us identify and address any potential issues. By following these guidelines, we can ensure the smooth integration of the new features. We are striving to ensure that the prediction process is enhanced, and the user experience is improved for everyone involved.

By ensuring these details are included, we can facilitate a faster and more efficient review process, guaranteeing the quality and reliability of the update. This process promotes transparency and ensures that the updates are done correctly and efficiently, leading to a better product for everyone.