Render Network holders are casting the final vote on RNP-024, a governance proposal that would authorize Forth, a privacy-focused gateway designed to route AI demand across multiple model and compute providers. According to the official RNP-024 specification, Forth would combine AI routing, payments and usage incentives behind a single API while giving Render Network compute preferential treatment when workloads are compatible.
The final NATION vote remains open until November 9 at 5 p.m. PT. Render Network says approval requires at least 50% support and the required 15% quorum. The vote would authorize Forth’s rollout and funding framework rather than immediately place the complete service into production.
Forth Would Route AI Demand Across Providers
Forth is designed as an intermediary between applications and multiple AI infrastructure options. Developers, users and autonomous agents could use a common endpoint rather than integrating separately with every model or compute provider. The router would handle functions including model selection, authentication, metering, spending controls, payments, privacy policy and fallback infrastructure.
Its privacy model varies depending on where a workload is executed. Sensitive jobs could remain on user- or organization-controlled hardware, while external cloud requests could separate the user’s identity from the request sent to a model provider. Compatible workloads could also be directed toward decentralized Render compute, with confidential-computing environments contemplated for later development. “Privacy-first” therefore describes a routing architecture with different privacy options, not a guarantee that every Forth request remains entirely private.
That model would sit above compute infrastructure Render has already been developing. Its Dispersed subnet provides on-demand GPU execution for AI workloads, while the Salad integration adds another distributed GPU subnet. Forth’s proposed role is primarily demand aggregation: directing compatible AI requests toward those resources rather than creating a new GPU network underneath them.
Payments are another major component. The specification supports x402 payments on Solana using RENDER or USDC, alongside card payments through MoonPay Commerce. Chat usage would generally draw from prepaid credit, while predictable generation jobs could be paid separately. The architecture is intended to let both people and autonomous agents purchase AI services programmatically without requiring every interaction to become an individual onchain payment.
Incentives Depend on Paid Usage
RNP-024 would authorize up to 500,000 RENDER for a maximum 12-month growth program, plus as much as 150,000 RENDER for marketing. Both allocations would come from existing Render Network Foundation resources. The proposal would therefore authorize maximum Foundation exposure of 650,000 RENDER without increasing the existing token emissions cap.
The incentive design specifically attempts to distinguish real consumption from easily farmed activity. Free requests, promotional credits, failed or refunded jobs and circular transactions would not qualify. Paid usage forms the base of the scoring system, while paying with RENDER could provide a 1.10× multiplier and eligible workloads executed through Render Compute a proposed 1.25× multiplier.
Sustained paid usage could increase the score further, although combined payment, routing and retention multipliers would initially be capped at 1.50×. Monthly distributions would also be constrained to the lowest of 50,000 RENDER, the remaining program allocation or the RENDER equivalent of 20% of qualifying paid usage, tying token rewards to measurable economic activity rather than account creation alone.
That approach extends Render’s existing work connecting compute with token settlement. The network has already explored onchain payment rails with Salad, where RENDER customer funding and provider redemptions are operational while broader Burn-and-Mint Equilibrium settlement remains under development. Forth would attempt to create another source of demand upstream from that compute infrastructure.
If approved, OTOY would lead development and production implementation through multiple stages covering payments, incentive accounting, Render Compute integration and eventual BME expansion. Approval would establish the mandate and resources to build Forth, while actual adoption would still need to be demonstrated through paid usage, repeat customers, RENDER payments and workloads successfully routed into Render infrastructure.