Render Network hosted an X Spaces session with Salad on June 10, focusing on how onchain payments and self-custody could reshape distributed GPU infrastructure. The conversation came after community approval of RNP-023, which brings Salad into Render as an exclusive subnet for decentralized compute demand.
The timing matters because the integration is not only a branding partnership. Under the approved proposal, Salad is expected to connect its compute marketplace to Render’s token-based payment and reward infrastructure, making RENDER the economic rail for selected Salad customer payments and node rewards.
.@Salad_Chefs x @rendernetwork are hosting their first joint X Space.
Inside the Road to Integration: Why Compute Payments Are Moving Onchain
We're breaking down why compute payments are moving onchain, and what that means for node operators, builders, and the future of… pic.twitter.com/BiIv0Ce8S3
— The Render Network (@rendernetwork) June 3, 2026
RNP-023 Moves Salad Toward Render’s BME Model
RNP-023 approved Salad as a third Render subnet, alongside the existing Render and Dispersed subnets. The proposal is designed to route Salad’s real-world compute demand into Render’s Burn-and-Mint Equilibrium model, where customer activity can trigger token burns while node operators receive rewards for completed work. The goal is to connect distributed compute usage more directly to onchain settlement.
The integration covers Salad’s two main products: Salad Container Engine and Salad Gateway Service. Salad Container Engine supports distributed containerized workloads across consumer GPU infrastructure, while Salad Gateway Service supports bandwidth-related customer use cases under stricter onboarding. Both product lines are expected to move into Render-linked payment and reward flows over time.
The governance plan also sets staged implementation milestones. Salad first adds RENDER reward redemption for its node operators, then enables customers to fund accounts with RENDER, and later migrates broader payment rails into the Render model. That makes the subnet integration a phased infrastructure rollout, not a one-day switch.
Self-Custody Changes the Node Operator Relationship
One of the central themes of the June 10 discussion was self-custody. Salad’s existing contributors, known as Chefs, are expected to gain the option to receive rewards in RENDER and withdraw them to a self-custody Solana wallet. That changes the reward relationship from platform-managed balances toward direct token ownership.
For node operators, onchain settlement can improve visibility into how rewards are accrued and distributed. It can also reduce dependence on closed payment systems that require internal accounting, regional payout partners or delayed reconciliation. The appeal is faster, clearer and more portable compensation for distributed hardware providers.
For Render, the integration adds a large pool of distributed GPU supply and real customer demand into its economic framework. Salad has described its network as operating 60,000 daily active machines across more than 180 countries, creating a meaningful supply-side expansion if the migration proceeds as planned.
Still, operational details remain important. RNP-023 sets maximum timelines of 90 days for initial RENDER rewards, 180 days for customer RENDER payments and 365 days for full payment-rail migration. Until those milestones are implemented, the integration should be viewed as approved and underway, not fully complete across all Salad products.
For now, the clean takeaway is that Render and Salad are using the RNP-023 integration to move distributed compute payments and rewards onchain, with self-custody becoming a key part of the node operator model. The next signals to watch are milestone delivery, live RENDER reward withdrawals, customer payment adoption, burn activity and whether Salad workloads materially increase Render’s compute demand.