Render Network has opened the final governance vote on RNP-024, a proposal to introduce Forth as a privacy-focused gateway for routing AI workloads across multiple infrastructure providers while connecting paid usage more directly to the RENDER economy. Under the official RNP-024 proposal, Forth would provide users, developers and autonomous agents with a single API for accessing AI models, compute infrastructure and related services without requiring separate integrations for each provider.
The final vote began November 3 at 5:00 p.m. PT and remains open for six days on NATION. An earlier community vote ended with 2.4 million RENDER voting in favor and no opposing votes, allowing the proposal to advance. Final approval requires both a majority of at least 50% of votes cast and participation representing at least 15% of eligible RNDR and RENDER supply. The official NATION governance page confirms that the decisive voting round is now active.
Forth Links AI Spending to RENDER and Compute
Forth is designed as a routing layer rather than a single AI model or dedicated Render-only inference service. It could direct requests toward privately controlled infrastructure, anonymized external AI providers, distributed Render compute and future confidential-computing environments. Its privacy model varies according to the selected route: private workloads can remain inside user-controlled infrastructure, while external-provider requests can separate user identity from the model request. RNP-024 does not claim that every workload routed through Forth remains entirely private.
Payments form another part of the architecture. The current specification supports wallet-native settlement through x402 on Solana using RENDER or USDC, alongside card payments through MoonPay Commerce. A user or autonomous agent could therefore purchase AI services programmatically without a conventional account or API-key workflow. The proposal would give additional incentive weight to users paying with RENDER and to compatible workloads routed through Render Network compute.
That structure extends infrastructure already operating elsewhere in the ecosystem. Render has expanded into on-demand AI execution through its Dispersed subnet, where developers can submit containerized workloads that are provisioned across distributed GPU resources. Forth would sit further upstream in that stack by aggregating demand and deciding where compatible requests should be routed. Governance approval would authorize the Forth program, but it would not mean that the complete gateway was already running in production.
Incentives Depend on Paid Usage
RNP-024 would authorize up to 500,000 RENDER for a maximum 12-month incentive program, plus a separate marketing allocation of up to 150,000 RENDER. Both would come from existing Render Network Foundation resources rather than new token emissions. The maximum Foundation exposure is therefore 650,000 RENDER, while actual incentive distributions are designed to depend on measurable economic activity.
The scoring model specifically excludes free requests, promotional credits, refunded jobs and circular activity. Paid usage generates the base score, while RENDER payments, Render Compute routing and sustained activity can increase a user’s weighting. Monthly distributions would initially be capped at 50,000 RENDER and could not exceed the RENDER equivalent of 20% of qualifying paid activity. The design attempts to tie rewards to spending rather than simply subsidizing account creation or wallet connections.
That approach resembles Render’s broader effort to connect compute demand with token settlement. The network’s integration of Salad as an exclusive GPU subnet has already progressed to operational RENDER customer funding and provider redemptions, while broader BME settlement remains under development. Earlier discussions around moving distributed compute payments onchain similarly focused on making real workload demand, rather than available GPU capacity alone, the basis of the network’s economics. Forth would extend that model by attempting to create a demand-routing layer before workloads reach the underlying compute provider.
If RNP-024 clears the final vote, OTOY would lead development and production implementation, while operational responsibility for the live service must be disclosed before launch. The proposal also divides the incentive allocation into stages, with later tranches dependent on paid activity, reporting, Render Compute usage and resistance to incentive abuse. The vote would therefore authorize Forth’s rollout and funding framework, while actual adoption would still have to be demonstrated through paid usage, RENDER payments and workloads successfully routed into Render compute.