By Bob Miles (Co-founder & CEO), Kyle Dodson (CTO) & Cory Rieth (Head of Product)
Milestones 1 and 2 of RNP-023 are live: Chefs can take rewards in RENDER, and customers can fund their accounts with it. Milestone 3 is the big one: moving Salad's payment rails onto the Render Network's burn-mint-equilibrium model. Here's the design we're building, in the open, while it's still cheap to change.
When the Render community approved RNP-023, Salad committed to becoming a Render Network subnet and migrating our compute marketplace, SaladCloud's container engine (SCE) and gateway service (SGS), onto RENDER as the transactional layer. Milestone 1 (RENDER rewards for Chefs) and Milestone 2 (RENDER deposits for customers) shipped on schedule. Milestone 3 moves the rails themselves: every transaction flowing through the burn-mint-equilibrium (BME) model, with burns, fees, and rewards visible on-chain.
This post is the implementation design for that milestone. We're publishing it before we finish building for the same reason the RNP process exists: so the Render Foundation and community can kick the tires while the design is still cheap to change. Everything here implements RNP-023 as written: the same revenue splits, the same burn model, the same pricing source. What's new is how we deliver it. Since Milestones 1 and 2 shipped, we've redesigned the crypto payment path around x402 batch settlement, an open standard that fits this problem almost exactly, and built a settlement engine with one job: making every number on the dashboard provably correct. We've workshopped the approach with the Render Foundation along the way; now we want the community's eyes on it.
Two promises first
Before the architecture, the two things people ask us about most.
If you're a customer: nothing about how you pay changes, and if you pay in RENDER, you keep custody of unused funds. Cards, bank transfers, stablecoins: every payment method you use today keeps working, through the same checkout you use today. Your credits stay denominated in US dollars, so a $500 balance is a $500 balance regardless of what the RENDER market does overnight. And paying in RENDER gets materially better: your RENDER goes into your own on-chain settlement account, not into Salad's wallet. We draw from it once a day, for exactly the usage you consumed, and anything we haven't drawn stays yours. After the settlement window, unused RENDER is yours to withdraw, no support ticket required. Paying in crypto will carry the strongest consumer protection of any rail we offer.
If you're a Chef: your storefront isn't going anywhere, and volatility will be a choice, not a mandate. Your rewards balance will be displayed in RENDER and settled to you in daily epochs, per the RNP. Your earnings accrue against the US-dollar value of the work you do, and we're designing explicit options, described below, for Chefs who want stable value rather than RENDER exposure. Chefs who want RENDER exposure get it natively, including withdrawal to their own wallet.
Design principle: USD inside, RENDER at the edges
Salad has processed usage-based billing for years with boring, reliable infrastructure: a payment processor for fiat, a usage-billing ledger that tracks customer credits in USD, an orchestration layer that meters every GPU-second and bandwidth byte, and a payout system that turns metered work into Chef earnings. That machinery works. Milestone 3 doesn't replace it. It adds a settlement engine alongside it.
Internally, value is accounted in US dollars: customer credits, metered usage, Chef accruals. RENDER enters and leaves the system at well-defined settlement boundaries: escrow drafts, burns, Foundation fees, and Chef reward conversion. This keeps volatility handling in exactly one layer of the stack, preserves every existing customer and Chef experience, and dramatically reduces the amount of new code that has to be correct on day one.
The new code that does have to be correct lives in one place: the BME Settlement Engine. It's a single database with two tiers separated by a deliberate seam. The metering tier ingests priced usage events from our orchestration layer (roughly 17 million a day in our stress scenario), deduplicates them exactly, and maintains the rollups behind live pending balances. The ledger tier is an append-only, double-entry ledger holding every balance in the system, with a single posting API that enforces zero-sum entries. The two tiers touch only through staging tables written at the daily epoch close, so the high-volume firehose and the company's books never share a query path.
The Milestone 3 target architecture: existing platform unchanged, one new settlement engine, and a small set of on-chain wallets for escrows, burns, fees, and Chef rewards.
Everything public-facing, from the stats dashboard to the reporting API the RNP specifies to the monthly reconciliation reports, is a read-only view over this same ledger, not a separate reporting pipeline that could drift from reality. If a number appears on our dashboard, you'll be able to click through to the transaction that backs it.
Following the value
RNP-023 defines how revenue splits between burns, the Render Foundation's protocol administration fee, and Salad as the network operator:
| Product | Burned | Render Foundation | Salad |
|---|---|---|---|
| Salad Container Engine (SCE) | 60% | 5% | 35% |
| Salad Gateway Service (SGS) | 35% | 5% | 60% |
The interesting question is how value travels from a customer's payment to those splits. The answer differs by rail, and the crypto rail is where the design has changed most since Milestone 2.
The RENDER rail: x402 batch settlement
When a customer pays in RENDER, their RENDER doesn't transfer to Salad. They go into the customer's own on-chain settlement account: an escrow governed by x402 batch settlement, the open HTTP-native payment standard's scheme for exactly this shape of problem: deposit once, meter usage off-chain, settle on-chain in batches. Three rules govern the account:
-
Salad can draw only what you've consumed. Our drafting rights are capped by metered usage, and usage is throttled against your remaining escrow balance (with a safety buffer for price moves), so an account can't overrun between settlements.
-
We draw once a day. At each epoch close, we draft exactly the day's consumption, converted from USD at the same 24-hour TWAP used everywhere else in the system, into our Receipts wallet, and the burn splits execute from there the same day.
-
Unused RENDER stays yours. After the predefined settlement window, you can withdraw whatever we haven't drawn: self-serve, on-chain, no support ticket. Refunds stop being a policy and become a property of the contract.
This design has a consequence we care about a lot: payment is received at the draft. Until we draw from your escrow, we haven't been paid; we've been authorized. The moment RENDER revenue is received and the moment the corresponding usage was delivered are therefore the same moment, so burning at receipt, as RNP-023 specifies for RENDER payments, and burning for delivered usage are the same transaction. The burn schedule in the RNP applies exactly as written, and every burn corresponds to real, delivered compute.
The Solana smart contract for x402 batch settlements is under development, and we're working with both Render and the Solana Foundation to ship it. We're also working with Coinbase, who will power our x402 payments, to provide support for Solana x402 batch settlements once live.
The fiat rails
Cards and bank transfers work as they always have: payment up front, credits in USD, consumption burning credits down. Per the RNP's schedule for these rails, the RENDER burn follows consumption: each day's consumed value converts at the TWAP, is sourced from treasury inventory (more on that below), and flows through the same Receipts fan-out. Unconsumed credits remain refundable. Our invoiced SGS business bills monthly in arrears, so it settles as a single monthly burn matching the month's accumulated usage. Salad fronts the daily Chef payouts in between, and you'll see that burn as a visible monthly spike on the dashboard, not a bug.
The x402 batch settlement flow: deposits stay in the customer's escrow until drafted for delivered usage; fiat burns follow consumption; every rail converges on the same daily fan-out.
On the supply side, Chefs accrue earnings in USD as work completes, and those accruals convert to RENDER at the close of each daily epoch using the 24-hour TWAP from Jupiter that the RNP mandates. That's the same price, in the same epoch, as the burns. We'll walk that path in the Chef section below.
The daily epoch: where burns meet emissions
Once a day, the settlement engine closes the books:
The daily settlement sequence. Burns and Chef rewards settle in the same epoch, at the same 24h TWAP, and a paused epoch settles late rather than wrong.
One design choice here matters more than it looks: burns and Chef rewards settle in the same epoch, at the same 24-hour TWAP. That makes "RENDER burned vs. RENDER emitted" an exact daily comparison rather than an approximation across different timestamps and prices: one pair of numbers, published every day, each side traceable to its transactions.
That comparison is the heart of RNP-023's economics. The model is built so that burns exceed the emissions that fund Chef rewards, structurally, by burning 4% of revenue over and above what Chefs earn. We're designing this integration to deliver on that intent, and we want to be equally clear about the honest caveat: the differential is structural, not guaranteed per-epoch. Because burns and emissions are priced when they settle, sharp moves in RENDER's price between epochs can compress the gap in some periods and widen it in others. The RNP's own worked examples show the spread ranging from roughly 2% to 18% depending on price path. Two things keep this honest over time: the monthly top-up burn the RNP requires, which trues up aggregate burns against actual margins, and the daily public numbers, which let anyone audit the cumulative ratio rather than taking our word for it.
One more expectation to set: the burn line will not be a smooth curve, and it shouldn't be. Daily burns track daily consumption, which already varies meaningfully: customers scale up and down, hardware mixes shift, workloads come and go. On top of that you'll see the monthly SGS settlement spike, occasional one-time burns from large prepaid contracts, and, if our price cross-check ever diverges, an epoch that settles late at the next good price. We'd rather explain a gap than defend a bad number.
The Chef experience: volatility as a choice
Chefs told us two opposite things, often in the same week: "why am I not earning crypto upside?" and "never make my balance fluctuate." Both are reasonable. Milestone 3's reward system is designed so each Chef picks their own point on that spectrum.
The baseline, per the RNP: rewards accrue against the USD value of work during the epoch, convert to RENDER at the daily close, and land in a rewards balance that is backed by the on-chain Rewarded wallet managed by Salad, holding all Chef RENDER. This is the wallet where Chefs will withdraw RENDER to self custody if they choose to. From there, Chefs can opt into automatic payout every epoch or keep redeeming through the storefront they use today: gift cards, PayPal, subscriptions, games.
Salad Balance isn't going away, either. Earning bonuses, referral and affiliate rewards, and similar programs stay denominated in USD as Salad Balance, entirely outside the BME flow, so the on-chain reward numbers remain a clean record of network earnings, and your bonus value doesn't move with RENDER.
For Chefs who want stable value, we're designing three mechanisms:
-
Lock in your reward.
-
Stable conversion at payout.
-
Automation APIs.
These are design candidates, not shipped commitments. Final mechanics, including how balances are held and withdrawn, will be confirmed as we complete the legal and operational review that handling RENDER for tens of thousands of Chefs across 180+ countries deserves. What we are committing to: Chefs who want stability will have a real path to it, and Chefs who want RENDER will hold RENDER.
Treasury: automated, with human gates
Most of Salad's revenue arrives in fiat, and burning 60% of an SCE dollar means acquiring RENDER with that dollar first. Two design choices keep this from turning into a trading desk. First, the RENDER rail needs no acquisition at all: escrow drafts arrive as RENDER and flow straight through the Receipts fan-out to the burn. Second, the fiat rails run on a small operating inventory, sized in days of forecast burns as a working float rather than a treasury position, topped up with programmatic purchases executed in small slices with strict slippage limits. The reward side is funded independently of all of this: the Render Foundation mints monthly into the Reward Pool, sized from our revenue forecast and prior actuals, with in-month top-ups if volume or RENDER's price moves against the forecast.
Everything routine runs unattended inside policy caps. Everything unusual (an above-cap purchase, a venue change, a policy change, a fiat off-ramp) requires multi-party human approval, enforced by policy rather than by promises. And the people who hold exchange credentials are deliberately not the people who hold on-chain wallet keys.
Treasury operations: the crypto rail self-sources, the fiat rails run on a small working float, the reward side is independently funded, and humans approve anything unusual.
Settlement also fails safe. Every price used anywhere in the system is a 24-hour TWAP from Jupiter, cross-checked against an independent feed, snapshotted and signed for audit. If the cross-check diverges or infrastructure is degraded, settlement pauses and the epoch closes late at the next good price, because a late burn is visible and explainable, while a mispriced one can't be taken back.
Transparency: the dashboard is the contract
RNP-023 asks for a public stats dashboard, a public API, and monthly reconciliation reports. We're building all three as thin views over the same ledger that drives settlement itself, not as a separate reporting pipeline that could drift from reality. Concretely:
-
A public dashboard that tracks the flows, not just the balances: escrow drafts → Receipts → burn and fee splits; monthly mints → Reward Pool → Rewarded → Chef redemptions. Every arrow is deep-linked to its Solana transaction, with daily burned vs. emitted and the cumulative ratio front and center.
-
A public API implementing the endpoint specification in the RNP appendix (burns, daily stats), served from a read replica, with amounts as string-encoded smallest units so nothing is ever lost to floating point.
-
Monthly reconciliation reports: fiat vs. RENDER payment mix, rewards by product line, top-up burns, and any late or paused settlements with explanations.
What we want from you
This design will change. That's the point of publishing it now. We're not asking the community to vote on anything: RNP-023 already set the economics, and this design implements them as written. We're asking you to find the weak spots while they're still cheap to fix.
If you're in the Render community: pressure-test the settlement model. Does the escrow design give you what you need to audit us directly? What would the dashboard have to show for you to trust it without asking? Where would you expect this design to bend under load, price shocks, or bad incentives?
If you're a Chef: tell us which stability option you'd actually use and what would make you keep, or start, taking rewards in RENDER.
And if you're neither: tell us what's confusing. If a section of this post took a second read, that's a bug in the design or a bug in the writing, and we want to know which.
Find us in the Salad Discord and the Render community channels, or open a discussion against the RNP repo. Milestones 1 and 2 got better because people pushed on them. This one is bigger. Push harder.
This post describes Salad's current engineering design for RNP-023 Milestone 3. It is shared for community feedback, not as a finalized specification; details, including settlement windows, epoch mechanics, reward mechanics, and provider choices, may change as we iterate with the Render Foundation and community and complete legal and operational review. Figures from RNP-023 are illustrative.