Add competition docs (#67)

Author: HudsonGraeme

docs/competitions/QUICKSTART.md

@@ -0,0 +1,48 @@
+# Competition Quick Start Guide
+
+## Prerequisites
+
+- Python 3.8+
+- Storage provider credentials (R2/S3)
+- Registration on subnet 2 (use `btcli register` if not already registered)
+
+> [!NOTE]
+> While miners can run on any platform, testing on macOS arm64 is recommended since validators use this architecture for evaluation. This helps ensure your circuit will perform consistently when being evaluated.
+
+## Getting Started
+
+1. **Configure Storage**
+
+The following variables configure remote storage for your circuit files.
+
+```bash
+export STORAGE_PROVIDER="r2"  # or "s3"
+export STORAGE_BUCKET="your-bucket"
+export STORAGE_ACCOUNT_ID="your-account-id"
+export STORAGE_ACCESS_KEY="your-access-key"
+export STORAGE_SECRET_KEY="your-secret-key"
+export STORAGE_REGION="auto"  # or AWS region for S3
+```
+
+2. **Start Miner**
+
+Start the miner process normally using `pm2` or your preferred process manager.
+
+## Circuit Submission Flow
+
+1. **Prepare Circuit Files**
+
+   - Compile your circuit
+   - Generate proving/verification keys
+   - Test locally with sample inputs
+
+2. **Deploy Circuit**
+
+- Move your files into the `competition_circuit/` directory.
+- The miner process will automatically detect your circuit
+- New circuit files are uploaded to remote storage
+- Verification key is committed to the chain
+
+3. **Monitor Evaluation**
+   - Watch logs for validator requests for your circuit
+   - Track SOTA competition metrics on https://accelerator.omron.ai

docs/competitions/README.md

@@ -0,0 +1,47 @@
+# Competition Technical Guide
+
+## Overview
+
+This guide provides a deep technical dive into participating in competitions as a miner. Competitions are a mechanism for miners to submit optimized zero-knowledge circuits that prove neural network execution, with rewards based on circuit performance across multiple metrics.
+
+## Circuit Evaluation
+
+The scoring system evaluates circuits based on accuracy (40% weight), proof size (30% weight), and response time (30% weight). Accuracy measures how closely circuit outputs match the baseline model using MSE loss and exponential transformation. Proof size evaluates the compactness of generated zero-knowledge proofs relative to current SOTA. Response time measures proof generation speed normalized against SOTA performance.
+
+The final score calculation uses an exponential decay formula that creates a score between 0 and 1, where higher scores indicate better performance relative to the current SOTA. The formula penalizes poor performance exponentially, encouraging continuous improvement and optimization:
+
+```
+score = exp(-(
+    0.4 * max(0, sota_accuracy - accuracy) +
+    0.3 * max(0, (proof_size - sota_proof_size)/sota_proof_size) +
+    0.3 * max(0, (response_time - sota_response_time)/sota_response_time)
+))
+```
+
+## Technical Requirements
+
+Your circuit must process inputs matching the competition config shape and produce a matching output shape.
+
+The submission package must include several key files: a compiled circuit (model.compiled), proving and verification keys (pk.key and vk.key), and a settings.json configuration file. These files work together to enable proof generation and verification.
+
+## Evaluation Process
+
+The evaluation process runs through multiple rounds of testing to ensure consistent performance. Each round generates random test inputs that are fed through both your circuit and a baseline model. The baseline comparison uses either PyTorch or ONNX models, supporting flexible implementation approaches.
+
+Your circuit must generate valid proofs that verify successfully. The system measures proof generation time and size across 10 evaluation rounds, averaging the metrics to determine final scores. All verifications must pass for a valid submission - a single failure results in disqualification.
+
+## Deployment Architecture
+
+The competition system uses cloud storage (R2/S3) for circuit file management. When validators request your circuit, they receive signed URLs for secure file access.
+
+The commitment process anchors your verification key hash on-chain. This creates an immutable record of your submission and prevents tampering. The system verifies that local and chain commitments match before proceeding with evaluation.
+
+## Optimization Guidelines
+
+Circuit optimization requires balancing multiple competing factors. Reducing circuit complexity generally improves proof generation speed and size but may impact accuracy. The scoring formula's weights guide this tradeoff - accuracy carries the highest weight at 40%.
+
+Resource management plays a crucial role in performance. Proof generation demands significant GPU power and memory. Monitor system resources during testing to ensure your circuit operates within validator timeout limits. Profile your operations to identify and eliminate bottlenecks.
+
+## Platform Requirements
+
+Currently, validators run using macOS arm64 architecture. This requirement ensures consistent evaluation environments across all participants. While you can develop and test on other platforms, final submissions must be validated on the required architecture to maintain consensus and provide the most optimal benchmark for the use case.

neurons/_validator/core/validator_loop.py

@@ -175,7 +175,8 @@ def log_health(self):
         log_queue_metrics(queue_size, est_latency)
 
     def update_processed_uids(self):
-        if len(self.processed_uids) >= len(self.queryable_uids):
+        total_processed = len(self.processed_uids) + len(self.active_tasks)
+        if total_processed >= len(self.queryable_uids):
             self.processed_uids.clear()
 
     @with_rate_limit(period=ONE_MINUTE)
@@ -274,6 +275,7 @@ async def maintain_request_pool(self):
                     pass
 
                 slots_available = self.current_concurrency - len(self.active_tasks)
+
                 if slots_available > 0:
                     self.update_processed_uids()
                     available_uids = [