refactor(REO): rename to RewardsEligibilityOracle, reduce initial requirements (#39)

* chore(SQO): lint markdown docs

* chore(REO): update ServiceQualityOracle refs to RewardsEligibilityOracle

* feat(REO): Reduce requirements for launch

Indexers are now only expected to serve queries on 1 subgraph, at launch, to be eligible for rewards.

* test(REO): update SQL snapshot for MIN_SUBGRAPHS=1

Updates the BigQuery SQL query snapshot to reflect the reduced MIN_SUBGRAPHS requirement from 10 to 1 for launch.

* Empty commit

Author: MoonBoi9001

CHANGELOG.md

@@ -40,7 +40,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ### Added
 - Daily BigQuery performance data fetching from Google BigQuery
 - Indexer eligibility processing based on threshold algorithms
-- On-chain oracle updates to ServiceQualityOracle contract
+- On-chain oracle updates to RewardsEligibilityOracle contract
 - RPC provider failover with circuit breaker pattern
 - Slack notifications for monitoring
 - Docker containerization with health checks

CLAUDE.md

@@ -7,7 +7,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 Service Quality Oracle is a Python-based Docker containerized service that:
 - Fetches indexer performance data from Google BigQuery daily at 10:00 UTC
 - Processes data to determine indexer issuance rewards eligibility based on threshold algorithms
-- Posts eligibility updates on-chain to the ServiceQualityOracle contract
+- Posts eligibility updates on-chain to the RewardsEligibilityOracle contract
 - Implements resilient RPC failover with circuit breaker pattern
 - Sends Slack notifications for monitoring
 
@@ -145,6 +145,7 @@ The system follows a clear data pipeline with daily scheduled execution:
 ### ⚠️ CRITICAL: This is a PUBLIC repository
 
 ### Sensitive Information Handling
+
 - **NEVER commit secrets, keys, or credentials** to the repository
 - **NEVER commit actual config.toml files** - only commit config.toml.example with placeholder values
 - Always follow security best practices when handling private keys and API tokens
@@ -153,26 +154,31 @@ The system follows a clear data pipeline with daily scheduled execution:
 - Verify that .gitignore properly excludes sensitive files before committing
 
 ### Protected File Types (automatically ignored by .gitignore)
+
 - Environment files: `.env`, `.env.*`
 - Configuration: `config.toml`, `credentials.json`
 - Keys/Certificates: `*.key`, `*.pem`, `*.p12`, `*.pfx`
 - Secret directories: `**/secrets/`, `**/private/`, `.secrets`
 
 ### Security Checklist Before Commits
+
 1. ✅ Run `git status` and verify no sensitive files are staged
 2. ✅ Review `git diff --cached` for any accidentally included secrets
 3. ✅ Ensure all examples use placeholder values (e.g., `"your_key_here"`)
 4. ✅ Never hardcode real addresses, URLs, or API endpoints
 5. ✅ Use descriptive placeholder text that shows expected format
 
 ### Emergency: If Sensitive Data is Committed
+
 1. **DO NOT** just delete the file in a new commit - the data remains in Git history
 2. Immediately rotate/invalidate the exposed credentials
 3. Contact repository administrators to discuss history rewriting if necessary
 4. Consider the credential permanently compromised
 
 # Session Context Import
+
 @./SESSION_CONTEXT.md
 
 # Style Guidelines Import
+
 @./STYLE_GUIDELINES.md

ELIGIBILITY_CRITERIA.md

@@ -1,8 +1,10 @@
+# Indexing Rewards Eligibility Criteria
+
 This document defines the requirements an Indexer must meet to be eligible for indexing rewards. It includes the current active criteria, a schedule of any upcoming changes, and a log of all historical requirements. The goal is to provide a transparent and predictable set of standards for all network participants.
 
 ---
 
-# Upcoming Eligibility Criteria
+## Upcoming Eligibility Criteria
 
 **We will announce changes to the eligibility criteria in the table below.** Once the change goes live, it will be reflected in the [Active Eligibility Criteria](https://github.com/graphprotocol/service-quality-oracle/blob/main/ELIGIBILITY_CRITERIA.md#active-eligibility-criteria) section of this document.
 
@@ -15,32 +17,32 @@ This document defines the requirements an Indexer must meet to be eligible for i
 
 ---
 
-# Active Eligibility Criteria
+## Active Eligibility Criteria
 
 The following criteria are used to identify indexers that should be eligible to receive indexing rewards.
 
 - **Days Online Requirement:** Indexers must be active for **5+ days** in a given **28 day** period for rewards eligibility.
-- **Daily Query Requirement:** To be active, an indexer must serve at least **1 qualifying query** on **10 different subgraphs**.
+- **Daily Query Requirement:** To be active, an indexer must serve at least **1 qualifying query**.
 - **Query Quality Requirements:** A qualifying query is one that simultaneously meets **all** of the following criteria:
   - Query Response HTTP Status: **200 OK**.
   - Query Response Latency: **< 5,000 ms**.
   - Query Freshness: **< 50,000 blocks** behind chainhead.
 
-Eligibility for indexing rewards is typically refreshed daily via the ServiceQualityOracle contract.
+Eligibility for indexing rewards is typically refreshed daily via the RewardsEligibilityOracle contract.
 
 > **Note**:
-> Once an indexer has successfully qualified for indexing rewards by satisfying the active eligibility criteria, and a corresponding transaction has been submitted on chain by an authorized Oracle into the ServiceQualityOracle contract, the now eligible indexer can continue claiming indexing rewards from the protocol for the duration of the qualification period (default is 14 days), even if the active eligibility criteria change.
+> Once an indexer has successfully qualified for indexing rewards by satisfying the active eligibility criteria, and a corresponding transaction has been submitted on chain by an authorized Oracle into the RewardsEligibilityOracle contract, the now eligible indexer can continue claiming indexing rewards from the protocol for the duration of the qualification period (default is 14 days), even if the active eligibility criteria change.
 
 ---
 
-# Eligibility Requirements Changelog
+## Eligibility Requirements Changelog
 
 This table tracks changes to the indexing rewards eligibility requirements over time.
 
 | Requirement Category | Requirement Details | Effective Date (YYYY-MM-DD) | Change Type: Initial, Updated, New, Removed | Justification | Notes |
 |----------------------|---------------------|-----------------------------|-------------|---------------|-------|
-| **Indexer Activity** | Indexers must be active for **5+ days** in a given **28 day** period for indexing rewards eligibility. | TBD | Initial | Encourages indexers to familiarize themselves with infrastructure maintenance and ongoing operations. | Planned for Service Quality Oracle launch |
-| **Query Qualification** | Indexers must serve **≥1 qualifying query** on **≥10 different subgraphs** in a day for the day to count towards the **Indexer Activity** requirement. | TBD | Initial | Encourages indexers to become familiar with the process of syncing a range of subgraphs. | Planned for Service Quality Oracle launch |
-| **Query Response Quality** | *•* Query Response HTTP Status: **200 OK**<br>*•* Query Response Latency: **< 5,000 ms**<br>*•* Query Freshness: **< 50,000 blocks** behind chainhead. | TBD | Initial | *•* Indexer infrastructure needs to serve successful queries to benefit data consumers.<br>*•* Fast query responses are important to data consumers.<br>*•* Encourages indexers to sync to chainhead. | Planned for Service Quality Oracle launch |
+| **Indexer Activity** | Indexers must be active for **5+ days** in a given **28 day** period for indexing rewards eligibility. | TBD | Initial | Encourages indexers to familiarize themselves with infrastructure maintenance and ongoing operations. | Planned for Rewards Eligibility Oracle launch |
+| **Query Qualification** | Indexers must serve **≥1 qualifying query** in a day for the day to count towards the **Indexer Activity** requirement. | TBD | Initial | Encourages indexers to become familiar with the process of syncing and serving subgraph data. | Planned for Rewards Eligibility Oracle launch |
+| **Query Response Quality** | *•* Query Response HTTP Status: **200 OK**<br>*•* Query Response Latency: **< 5,000 ms**<br>*•* Query Freshness: **< 50,000 blocks** behind chainhead. | TBD | Initial | *•* Indexer infrastructure needs to serve successful queries to benefit data consumers.<br>*•* Fast query responses are important to data consumers.<br>*•* Encourages indexers to sync to chainhead. | Planned for Rewards Eligibility Oracle launch |
 
 ---

README.md

@@ -2,14 +2,14 @@
 
 ## Overview
 
-This repository implements a Docker container service for the Service Quality Oracle. The oracle consumes data from BigQuery, processes it to determine indexer issuance rewards eligibility, based on a defined threshold algorithm, and posts issuance eligibility data on-chain.
+This repository implements a Docker container service for the Rewards Eligibility Oracle. The oracle consumes data from BigQuery, processes it to determine indexer rewards eligibility, based on a defined threshold algorithm, and posts rewards eligibility data on-chain.
 
 ### Key Features
 
 The oracle runs with the following functionality:
 - **BigQuery Integration**: Fetches indexer performance data from Google BigQuery
-- **Eligibility Processing**: Applies threshold algorithm to determine issuance rewards eligibility based on service quality
-- **Blockchain Integration**: Posts issuance eligibility updates to the ServiceQualityOracle contract
+- **Eligibility Processing**: Applies threshold algorithm to determine rewards eligibility based on service quality
+- **Blockchain Integration**: Posts rewards eligibility updates to the RewardsEligibilityOracle contract
 - **Slack Notifications**: Sends success/failure notifications for monitoring
 - **Docker Deployment**: Containerized and running with health checks
 - **Scheduled Execution**: Runs daily at 10:00 UTC
@@ -43,7 +43,7 @@ export SLACK_WEBHOOK_URL="your_webhook_url"
 
 ## Eligibility Criteria
 
-Please refer to the [ELIGIBILITY_CRITERIA.md](./ELIGIBILITY_CRITERIA.md) file to view the latest criteria for issuance. We are also posting upcoming criteria in that document.
+Please refer to the [ELIGIBILITY_CRITERIA.md](./ELIGIBILITY_CRITERIA.md) file to view the latest criteria for rewards eligibility. We are also posting upcoming criteria in that document.
 
 ## Data Flow
 

STYLE_GUIDELINES.md

@@ -5,33 +5,43 @@ This document defines the coding style guidelines for Python code in this reposi
 ## Core Style Guidelines
 
 ### 1. Comments Before Logical Blocks
+
 Add descriptive comments above logical blocks when the purpose needs clarification or when explaining complex operations and error handling.
 
 ### 2. Blank Lines Before Comments (Except After Docstrings)
+
 Include a blank line before each comment that is before a logical block, except when the comment directly follows a function's docstring.
 
 ### 3. Blank Lines After Logical Sections Complete
+
 After a logical block completes (end of loops, after appending to lists, etc.), include a blank line before the next comment/section. This helps improve readability of the code.
 
 ### 4. Comments Describe "What" Not "How"
+
 Comments should describe what the code accomplishes rather than implementation details.
 
 ### 5. Spacing Within Control Structures
+
 Inside try/except blocks and if/else statements, include a blank line after each branch's code block completes.
 
 ### 6. Comments for Primary and Fallback Logic
+
 Both the main execution path and fallback/error handling should have descriptive comments when their purpose isn't immediately self-evident.
 
 ### 7. Comments for Final Actions
+
 Simple operations at the end of functions should have descriptive comments when the purpose needs clarification.
 
 ### 8. Two Blank Lines Between Functions/Methods/Classes
+
 Two blank lines before all function/method/class definitions, whether top-level or nested.
 
 ### 9. Compress long comments, don't truncate
+
 When comments exceed the 115-character line limit, compress them by removing unnecessary articles and prepositions while preserving full meaning, rather than truncating important information.
 
 ### 10. Code clarity not guideline following perfection
+
 The code is more important than the style guidelines
 
 ## Integration with Code Formatting Tools
@@ -42,6 +52,7 @@ These style guidelines work in conjunction with automated formatting tools:
 - **Custom formatter**: Applies additional spacing rules via `scripts/ruff_check_format_assets.sh`
 
 Always run the formatting script before committing:
+
 ```bash
 ./scripts/ruff_check_format_assets.sh
 ```

config.toml.example

@@ -13,7 +13,7 @@ BIGQUERY_TABLE_ID = ""
 
 [blockchain]
 BLOCKCHAIN_CONTRACT_ADDRESS = ""
-BLOCKCHAIN_FUNCTION_NAME = ""
+BLOCKCHAIN_FUNCTION_NAME = "renewIndexerEligibility"
 BLOCKCHAIN_CHAIN_ID = ""
 BLOCKCHAIN_RPC_URLS = [
     "",
@@ -44,7 +44,7 @@ FORCE_BIGQUERY_REFRESH = "false"
 
 [eligibility_criteria]
 MIN_ONLINE_DAYS = "5"
-MIN_SUBGRAPHS = "10"
+MIN_SUBGRAPHS = "1"
 MAX_LATENCY_MS = "5000"
 MAX_BLOCKS_BEHIND = "50000"