> For the complete documentation index, see [llms.txt](https://docs.oncompute.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.oncompute.ai/ocean-network-dashboard/ocean-network-incentives-program.md). # Ocean Network Incentives Program ### Why This Matters for Incentives To receive incentives from the network, your node must meet a set of eligibility and performance criteria. Keep in mind, Ocean Nodes are continuously monitored for health and computational performance. The Ocean Network runs a paid benchmarking system on eligible nodes that receive paid Compute-to-Data benchmark jobs(GPU, CPU, and bandwidth tests), funded from a weekly pool. Nodes that consistently pass these benchmarks build a performance track record that directly influences their eligibility for future jobs and incentive payouts. Nodes that fail repeatedly are temporarily removed from the pool. *** ### Node Eligibility Requirements Before your node can receive a benchmark job, the monitoring system checks several conditions. All of the following must pass. #### 1. Reachability via P2P Your node must be **reachable over libp2p** from the monitoring service. Specifically: * The node must advertise at least one **public IP multiaddr**. Relay-only connections (without a direct public address) are not accepted. * The P2P `status` command must respond successfully within the timeout window. **Action:** Ensure your node is publicly accessible and that its P2P port is not blocked by a firewall. Configure your node so it announces a real public IP, not just a local or relay address. #### 2. Minimum Node Version Your node software must be running **version 3.0.6 or later**. Nodes on older major versions are skipped entirely. **Action:** Keep your Ocean Node software up to date. Check your running version via the node's status endpoint. #### 3. Escrow Address Configuration Your node must have an **`escrowAddress`** configured that includes the **Base** chain, pointing to the Ocean Protocol `Escrow` contract for that chain. **Action:** Configure the escrow address in your node settings. Refer to the Ocean Contracts deployment for the correct Escrow contract address on Base. #### 4. Eligible Compute Environment Your node must expose at least one compute environment that passes **all** of the following sub-checks: | Check | Requirement | | ----------------- | --------------------------------------------------------------------------------------------------- | | **Chain support** | The compute environment must support Base (chain ID 8453) | | **Payment token** | Must accept the Base USDC token as `feeToken` | | **Pricing** | The **sum** of all resource prices (CPU + RAM + GPU + disk) must be **less than 1 USDC per minute** | | **GPU resource** | The environment must include a GPU resource entry | > **Important on pricing:** The threshold is a strict `=< 1 USDC/min`. A price above disqualifies the environment. Set your pricing to a value between 0 and 1. > **Important on GPU:** Even if your node has a CPU-only environment, it will not qualify. At least one environment with GPU resources is required. **Action:** In your node configuration, define at least one compute environment with: * Base chain fees enabled * USDC as the accepted fee token * A total resource price between 0 and 1 USDC/min * GPU listed as an available resource > **Automated setup:** You can have an eligible environment configured automatically by setting `enableBenchmark: true` in your node configuration (or via the `ENABLE_BENCHMARK=true` environment variable). When enabled, the node will register Base chain (8453) and USDC as the payment token, set the GPU fee to 1 USDC/min, and update the access list with the monitoring service address, no manual steps required. It automatically detects and utilizes all available CPU, RAM, disk, and GPU resources to ensure your benchmark achieves maximum throughput. #### 5. Allowlist Address The monitoring service requires its address to be present in your compute environment's `accessLists`. If this address is missing, the job starter will skip your node even if all other criteria pass. **Action:** Ensure your compute environment's `accessLists` includes the official Ocean monitoring allowlist address: ``` 0xcb7Db55Ca9Aa9C3b25F5Bc266da63317fa02086a ``` #### 6. Performance History If benchmark data exists for your node from the **current epoch**, your **success rate must be at least 50%**. Nodes with insufficient history are still considered, but nodes with a documented success rate below 50% are excluded from the scheduling pool. Each epoch spans **7 days**, running from **Thursday to Thursday**. **Action:** Monitor your node's benchmark results on the Nodes Dashboard. Address failures promptly to keep your success rate above the 50% threshold. *** ### Eligibility Refresh and Suspension The monitoring system re-evaluates all nodes on a rolling basis. * **Freshness window:** Your node's eligibility record must have been updated within the **last 1 hour** to be considered for a benchmark job. The system continuously monitors nodes to keep records fresh. * **Consecutive failure suspension:** If your node fails monitoring checks **3 consecutive times**, it enters an exponential suspension period: * Starts at **4 hours** * Doubles with each additional failure * Capped at **7 days** During suspension, your node is excluded from monitoring and benchmark job scheduling. Suspension lifts automatically once the timer expires, at which point your node is re-evaluated. **Action:** Ensure your node has high uptime and stable connectivity. Temporary outages can trigger suspension, which compounds with repeated failures. *** ### The Benchmarking Process When your node is selected for a benchmark, the system runs three concurrent tests inside a single compute job using a Docker image. The total job duration is capped at **3 minutes**. #### 1. GPU Benchmark * **Goal:** Measure GPU hashing performance. * **Method:** Generates SHA-256 hashes, builds a Merkle tree, and exports cryptographic proofs using GPU-accelerated compute. * **Duration:** Up to 1 minute. * **Output score:** Hash operations per second. * **Weight in final score: 70%** #### 2. CPU Benchmark * **Goal:** Measure CPU hashing and Merkle proof performance. * **Method:** SHA-256 seed generation, Merkle tree construction, and random proof generation. Parses `/proc/cpuinfo` for device metadata. * **Duration:** Up to 45 seconds. * **Output score:** Total hashes / (total time in seconds). * **Weight in final score: 20%** #### 3. Bandwidth Benchmark * **Goal:** Measure internet download speed. * **Method:** Downloads a \~200 MB file in 1 MB chunks repeatedly over a fixed window, calculates average throughput. * **Duration:** Exactly 45 seconds. * **Output score:** Average bandwidth in Mbps. * **Weight in final score: 10%** #### 4. Composite Score The final benchmark score is: ``` totalScore = (gpuScore × 0.7) + (cpuScore × 0.2) + (bandwidthMbps × 0.1) ``` Results are stored on your node's status record and are visible on the Ocean Network Dashboard. #### 5. Result Verification After the compute job completes, the monitoring service: 1. Downloads the result archive 2. Extracts `outputs/cpu.json`, `outputs/gpu.json`, and `outputs/bandwidth.json`. 3. Verifies Merkle proofs. 4. Calculates the composite score. A job is marked as **failed** if: * The job times out * The result download or Merkle proof verification fails. *** ### Job Execution and Scheduling Rules * Jobs are distributed to eligible nodes. The interval between jobs for the same node is randomised based on how many eligible nodes are currently in the pool * A node must not already have a running compute job to be scheduled immediately (it remains in the pool for future rounds). * The benchmark job requires a total resource price of **≤ 1 USDC/min** to be scheduled (stricter than the 3 USDC/min listing threshold). *** ### Banning & Unbanning #### 1. When Is a Node Banned? At the **end of each weekly epoch**, nodes with a benchmark **success rate below 50%** over the past 7 days are flagged as banned. Banned nodes are removed from all benchmark scheduling until the ban is lifted. #### 2. Requesting an Unban If your node is banned, you can request an unban directly from the **Ocean Network Dashboard**: 1. Navigate to your node's detail page. 2. Click the **Request Unban** button. 3. The request is processed asynchronously via a Backend API call. 4. A new **high-priority** benchmark job is scheduled specifically for your node. **Outcomes:** * **Pass:** The ban is lifted immediately. * **Fail:** The node remains banned until the next epoch. **Escalation:** If your node fails the unban verification **3 consecutive times**, the ban duration is escalated. All unban attempts are recorded and visible on the dashboard. *** ### 6. Budget and Per-Node Job Limits To ensure fair distribution and cost control: | Limit | Value | | ------------------------------------ | --------- | | Weekly system budget | 2000 USDC | | Max benchmark jobs per node per day | 3 | | Max benchmark jobs per node per week | 21 | Once either the per-node or system-wide budget is exhausted, no further benchmark jobs are scheduled for that period. **Unban verification jobs bypass these limits.** *** ### Ocean Network Dashboard Features The Nodes Dashboard provides full visibility into your node's performance and eligibility: * **Eligibility Status:** Shows whether your node is currently eligible, suspended, banned, or excluded, including the specific reason if it is not eligible. * **Compute Job History:** A full log of all benchmark jobs, including scores, and pass/fail outcome. * **Latest Benchmark Results:** GPU, CPU, and bandwidth scores from your most recent job, plus the composite score. * **Ban Status:** Clear indicator if your node is banned, with an unban request button. * **Unban History:** All unban attempts and their outcomes, including escalation status. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.oncompute.ai/ocean-network-dashboard/ocean-network-incentives-program.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.