docs: update reveal interval documentation to reflect 24-hour commit cooldown

Author: aliyuldashev

docs/miner/concepts/reveal-interval.md

@@ -1,16 +1,16 @@
 ---
-title: Reveal & Timing
+title: Commit Cooldown & Timing
 tags: [reveal, submission, limits, incentives]
 ---
 
-# 🕒 Reveal & Submission Timing
+# 🕒 Commit Cooldown & Submission Timing
 
 ## Overview
 
-RedTeam miner uses a delayed reveal mechanism to ensure fairness and prevent real-time strategy leaks. Understanding the submission lifecycle is essential for maximizing your daily slots and ensuring your work is properly scored.
+RedTeam miner uses a Commit Cooldown delay to ensure fairness, prevent subnet spamming, and batch submissions for scoring. Understanding the submission lifecycle helps you use your daily slots and get scored reliably.
 
 !!! info "Version Requirement"
-    The **3-hour reveal interval** is a recent update. To ensure your submissions are processed correctly under this window, you **must** be running miner version **v3.0.5** or higher.
+    The **24-hour Commit Cooldown** is a recent update. To ensure your submissions are processed correctly under this window, you **must** be running miner version **v3.0.5** or higher.
 
 ## Submission Limits
 
@@ -23,24 +23,24 @@ To maintain network quality and prevent "trial-and-error" testing on production
 !!! danger "Spamming Prevention"
     The 2-commit limit is designed to allow you to fix critical issues discovered after your first submission is scored. It is **not** intended for simultaneous testing or spamming variations of a solution. Miners who attempt to bypass these limits or push multiple updates before scoring are treated as "testing in production," which can lead to status rejections or rate limiting.
 
-## The Reveal Lifecycle
+## The Commit Cooldown Lifecycle
 
-The path from `git push` to a dashboard score typically takes up to **6 hours**.
+The path from `git push` to a dashboard score typically takes a little over **24 hours**.
 
-### 1. Decryption (Reveal) 3 Hours
+### 1. Commit Cooldown (Delay) 24 Hours
 
-Once submitted, your code remains encrypted for approximately **3 hours**. During this time, it is visible on the dashboard as `encrypted_commit:...`.
+Once submitted, your code remains encrypted for approximately **24 hours**. During this time, it is visible on the dashboard as `encrypted_commit:...`.
 
-### 2. Scoring & Evaluation 3 Additional Hours
+### 2. Scoring & Evaluation (After Cooldown)
 
-After decryption, the [Comparison](comparison.md), [Validation](validation.md), and Scoring engines process your code. This phase can take an additional 3 hours depending on network load.
+After the cooldown ends, the [Comparison](comparison.md), [Validation](validation.md), and Scoring engines process your code in a batch. This phase starts after the 24-hour delay and may take some additional time depending on network load.
 
 | Phase | Duration | Dashboard Status |
 | :--- | :--- | :--- |
 | **Submission** | Instant | Pending |
-| **Reveal (Decryption)** | ~3 Hours | Reveal / Processing |
-| **Scoring** | ~3 Hours | Scored / Accepted / Rejected |
-| **Total Time** | **~6 Hours** | Final Result Visible |
+| **Commit Cooldown (Decryption)** | ~24 Hours | Reveal / Processing |
+| **Scoring** | After cooldown | Scored / Accepted / Rejected |
+| **Total Time** | **~24+ Hours** | Final Result Visible |
 
 ---
 
@@ -51,7 +51,7 @@ After decryption, the [Comparison](comparison.md), [Validation](validation.md),
 The RedTeam subnet uses a **Commit-and-Reveal** scheme:
 
 1. **Commit Phase**: The miner sends an `encrypted_commit` (ciphertext) to the validator. The decryption key remains secret on the miner's side.
-2. **Reveal Phase**: After the reveal interval, the miner automatically moves the key to `public_keys`, allowing the validator to decrypt the commit.
+2. **Reveal Phase**: After the Commit Cooldown, the miner automatically moves the key to `public_keys`, allowing the validator to decrypt the commit.
 
 **The Issue**: If you update your `active_commit.yaml` with a new Docker hash for an existing challenge *before* the previous one has finished its reveal cycle, the miner generates a new ciphertext but the validator might still see an old key. This mismatch causes `InvalidToken` or decryption errors.
 
@@ -61,11 +61,11 @@ The RedTeam subnet uses a **Commit-and-Reveal** scheme:
     - **Check Logs**: Wait for: `Revealed commit: <hash>, <challenge_name>`.
     - **Check Dashboard**: Ensure status shows **Decrypted** or **Scored** before pushing an update to the same challenge.
 2. **Versioning Your Submissions**: Challenge names in `active_commit.yaml` (e.g., `ab_sniffer_v5`, `humanize_behaviour_v5`) are fixed and cannot be changed. To avoid corruption, do not overwrite the Docker hash in your configuration while a reveal is pending. Instead, version your Docker images/tags and only update the configuration after the previous submission is scored.
-    - **❌ Avoid**: Updating `active_commit.yaml` with a new hash for the same challenge before the 3-hour reveal is complete.
+    - **❌ Avoid**: Updating `active_commit.yaml` with a new hash for the same challenge before the 24-hour cooldown is complete.
 3. **Clean State (Emergency Only)**: If you accidentally corrupted your local state, you can clear the miner's persistence file to force a full re-submission.
 
     !!! warning "Reset Warning"
-        This resets the reveal interval for **all** challenges. You will have to wait another 3+ hours before scoring begins.
+        This resets the Commit Cooldown for **all** challenges. You will have to wait another 24+ hours before scoring begins.
 
     ```bash
     # Default path for miner state in the mounted volume
@@ -90,7 +90,7 @@ Rewards follow a daily synchronization window:
 1. **Submit Your Best Version**: Treat your first daily slot as your primary submission.
 2. **Monitor the Dashboard**: Always wait until your first submission shows a final status (**Accepted**, **Rejected**, or **Invalid**) before pushing a second one.
 3. **Local Testing First**: Use the [Testing Manuals](../../challenges/README.md) to verify your script before pushing.
-4. **Timing Your Pushes**: Ensure your final commit is pushed at least **6-8 hours before 2:00 PM UTC** to hit the daily cutoff.
+4. **Timing Your Pushes**: Ensure your final commit is pushed at least **24+ hours before 2:00 PM UTC** to hit the daily cutoff.
 
 !!! tip "Dashboard Visibility"
-    If you do not see your submission transition to "Scored" within 6-12 hours, check the **Note** column on the dashboard for potential processing errors or validation failures.
+    If you do not see your submission transition to "Scored" within 24-36 hours, check the **Note** column on the dashboard for potential processing errors or validation failures.