
This account was created to stream news about $RENDER & monitor $RENDER burns on chain (burns over $1000). Created by Jāy® (@JayJayKan)
Joined February 2025
- Tweets3.2K
- Following4
- Followers1.2K
- Likes27
“NeRFs are a very important intermedia format intersecting latent space (AI) and ray tracing space - but the goal is to convert NeRF to full scene graph model (mesh, volume , or more useful - SDF/ Vectron) for full composability and speed - but with Neural Rendering coming in the roadmap we also plan to render NeRF and related AI generated objects directly without any conversion - so we can apply AI effects and operators- it’s very similar to how we have done Vectron (SDF) which are pure code shaders for meshes , volumes and scene graph composition operators - neural rendering nodes will work a lot like that”
@JulesUrbach 18.11.22
$RENDER
2
169
🔥Burns Update🔥
$4,528 (2,831 $RENDER) across 124 tx burned.
Median $4, biggest burn $781.
Burns removed 17.26% of daily emissions.
What's happaning on $RENDER Discord, what's currently being discussed in the channels?
Let's dive in
🧵👇🏻👇🏻👇🏻🧵
🧵 general
Governance updates and October ecosystem highlights were posted, while @netes_85 raised an unresolved bridge-support question for Polygon RNDR to Solana RENDER.
⭕️ Team member Luke reminded the community that it was the final day to vote on RNP-024 (Forth), with voting expected to close at 5 PM PT on Nov 9. The proposal covers a privacy-first AI gateway, incentives for paid usage, RENDER payments, and Render compute. Historical context: earlier governance reminders noted that voting eligibility requires RENDER in self-custodial wallets.
⭕️ Team member Luke also shared the October Render Network Foundation report. Key highlights included the redesigned Render Network web app, rollout of a new Render Network performance tier, RNP-024/Forth as a gateway to privately access top-tier AI models, Sunspark reaching 60 film festivals, continued media coverage, and BEYOND THE FRAME, an immersive art event in London on Nov 16.
⭕️ @netes_85 asked whether the official bridge for transferring RNDR from Polygon to RENDER on Solana is currently working. No team reply or confirmation appeared in this message set.
❗ Focus for the team: Clarify the current status of the official Polygon RNDR → Solana RENDER bridge, including whether it is operational, any known delays/issues, and the safest official link or process users should follow.
3
13
441
🧵 rnp-023-salad-integration
Daily RENDER burns for Salad’s Milestone 3 have moved into testing, shifting the discussion from architecture to verification and rollout details.
⭕️ Team member Luke shared Salad’s update: “Daily Render Burns Have Started Testing for Milestone 3.”
This points to progress on the RNP-023 Salad integration, specifically the Milestone 3 burn flow. Earlier context in this channel centered on daily settlement, shared TWAP usage for burns/rewards, and tying the dashboard/API to the same ledger used for settlement. Prior discussion also clarified that on-chain revenue would be represented in RENDER, with Salad expected to manage some days’ worth of RENDER for burns/rewards and bear risks such as exchange-rate overruns or chargebacks via top-up burns if needed.
❗ Focus for the team: clarify what “testing” includes, whether test burn transactions or dashboards will be public, what metrics define Milestone 3 success, the expected timeline to production daily burns, and whether the earlier open question around RENDER operating float sourcing/reconciliation has been fully resolved.
63
🔥Burns Update🔥
$2,256 (1,456 $RENDER) across 63 tx burned.
Median $12, biggest burn $409.
Burns removed 8.88% of daily emissions.
🔥Burns Update🔥
$1,170 (747 $RENDER) across 56 tx burned.
Median $9, biggest burn $247.
Burns removed 4.55% of daily emissions.
28
749
What's happaning on $RENDER Discord, what's currently being discussed in the channels?
Let's dive in
🧵👇🏻👇🏻👇🏻🧵
🧵 general
Team member Dino signaled that an awaited feature/update “will come,” with @hugo.psd responding positively.
⭕️ Team member Dino gave a brief reassurance that the requested or discussed item is on the way. The exact feature, delivery timing, and scope are unclear from this snippet; @hugo.psd simply acknowledged the update with “nice!”
❗ Focus for the team: Clarify what “that” refers to, expected timing, and whether there is a public roadmap or next update users should watch for.
313
“Vinny of course has built civic (civic.com/) for something like this, we have our own metatdata (ITMF) used by Render (which also builds on the Adobe proposed content standards)”
@JulesUrbach 06.03.25
$RENDER
1
368
🚀 Monster $RENDER burns!🚀
$26,628 (16,995 RENDER) destroyed in 147 tx!
Median $6, biggest burn $18,469.
🔥 103.60% of daily emissions wiped out!
What's happaning on $RENDER Discord, what's currently being discussed in the channels?
Let's dive in
🧵👇🏻👇🏻👇🏻🧵
🧵 general
Node-distribution controls are in progress, while RNP-024’s final vote remains open for eligible RENDER holders.
⭕️ Bandwidth control for node distribution.
@hugo.psd asked for the ability to limit how many nodes a scene is sent to, specifically to reduce bandwidth costs. Team member Dino replied that this “will come” and followed up that the team is already working on it. The exact mechanics are still unclear: no limits, rollout timing, UI flow, or cost-saving estimates were shared.
⭕️ RNP-024 final vote reminder.
Team member Luke reminded the community that the Final RNP Vote for RNP-024, covering Forth, is still open. Forth is framed as a privacy-first AI gateway that brings multiple AI models and compute providers into one interface. The proposal includes a performance-based incentive program intended to encourage paid usage, payments in RENDER, and eligible Render Network workloads. The final voting window is 6 days, and eligible RENDER holders should review the proposal and vote via NATION.
❗ Focus for the team: clarify when node-send limits will ship, what controls users will get, and how RNP-024 incentives define “eligible Render Network workloads.”
1
8
533
🔥 $1,959.64
🔥 1,217.22 RENDER
Transaction: 5Xz42A1by4XuSpWAQSSEYyo4JtEwtTtX3E1E3gKNfT3xBUDWUhdyPads3nFiSGvv1XnEXEVKEN2nVaj3GUJ4PUfe
🔥 $1,471.27
🔥 918.70 RENDER
Transaction: 59FY3fMy6LMMUndrUgdqCKFngbannGWGGAbJKjYcGneeGMEA9eS2Ra7qaGw5io2SZdjwuDLbRmUDMPzLKR5aXwAh
12
310
🔥Burns Update🔥
$2,913 (1,853 $RENDER) across 152 tx burned.
Median $9, biggest burn $163.
Burns removed 11.30% of daily emissions.
What's happaning on $RENDER Discord, what's currently being discussed in the channels?
Let's dive in
🧵👇🏻👇🏻👇🏻🧵
🧵 node-revenue
Node operators are seeing unusually large weekly payouts while also asking for clearer reward visibility at node level.
⭕️ Current discussion: @thebigwhart said the latest weekly payout was “huge,” around 6x their usual weekly amount, and @smooshworkstations._91563 confirmed seeing the same pattern. No exact token amount, wallet, epoch, or reason for the increase was provided, so it is unclear whether this reflects higher network work, delayed/catch-up payouts, a reporting artifact, or another payout-cycle change.
⭕️ Reward visibility: @leo.inspect asked how to check each node’s rewards, whether this can be done in Dune, and whether upgrading Dune is needed. Team member Foxx clarified that rewards cannot be checked per individual node; users can only check rewards at the wallet level. This means Dune access/upgrading does not appear to solve per-node attribution based on the current answer.
❗ Focus for the team: confirm whether the roughly 6x weekly payout spike is expected, and clarify if any official dashboard/query can break rewards down beyond wallet-level reporting.
1
10
422
🧵 general
Bandwidth charges are again being flagged as a blocker when identical 2.7GB ORBX scenes with only material changes show materially different distribution costs.
⭕️ @gregleuey asked the team to fix bandwidth pricing/optimization after three same-size Standalone exports produced different costs: scenev33 was 3.69 render / 4.71 bandwidth, scenev30 was 2.78 render / 3.84 bandwidth, and scenev25 was 3.13 render / 2.4 bandwidth. His core concern: bandwidth is sometimes higher than render cost, and it is unclear why bandwidth nearly doubles when scene size stays at 2.7GB. He attributes the issue to ORBX packaging static geometry into a large point cache, with no obvious asset caching benefit when only materials change. @hugo.psd backed the point and suggested users should at least be able to limit how many nodes receive a scene to reduce bandwidth spend. @_marvinop only checked in casually.
Historical context: @gregleuey raised the same ORBX/CAD-file bandwidth problem in late October; Team member Dino previously clarified that alembic data can cache on nodes, but cache size/persistence depends on node operators.
❗ Focus for the team: clarify why equal-size jobs generate different bandwidth fees, whether asset/geometry caching applies to ORBX point-cache workflows, and whether node-count limits or automatic static-geometry optimization can be added so users are not forced into manual scene splitting.
104
🔥 $18,350.47
🔥 11,839.01 RENDER
Transaction: A4SNvxSgpTECE4dq95184Zg6To9ejFezjh3sZQ9cjmHAZ7GyQmS3HSP138j5smxNgR8LUFRb37jjTn8PW2xcDer
🔥Burns Update🔥
$5,404 (3,516 $RENDER) across 173 tx burned.
Median $5, biggest burn $1,128.
Burns removed 21.43% of daily emissions.
What's happaning on $RENDER Discord, what's currently being discussed in the channels?
Let's dive in
🧵👇🏻👇🏻👇🏻🧵
🧵 node-revenue
Tier-structure changes appear to have shifted node payouts, with operators questioning why idle/underclocked capacity may now outperform active rendering.
⭕️ @wildichigoappeared said they reinstated underclocks and earned more while mostly idle than they did rendering many frames in the previous epoch. This echoes an earlier node-revenue concern from @wildichigoappeared that more completed frames/OBH did not necessarily translate into higher RENDER under the reward mechanics. @thebigwhart also asked whether others saw a “huge payout,” clarifying it was about 6x their usual weekly payout.
⭕️ Team member Foxx clarified that the tier structure was changed and that the update had been announced in the Render node operator channel. Foxx also noted @thebigwhart had not claimed a node role yet and pointed them to the role-claim channel, which will tag Foxx if support is needed. Historical context: Foxx has previously reminded operators that payout comparisons need uptime, OB score, and OBH context, not just the final dollar/token amount.
❗ Focus for the team: clarify how the new tier structure weighs idle availability vs rendered work, and whether underclocking can unintentionally improve payouts relative to active rendering.
1
260
🧵 general
Bandwidth charges are again being flagged as undermining Render’s cost advantage for large ORBX scenes.
⭕️ @gregleuey reported that three near-identical 2.7GB scenes, differing only by material changes, produced materially different bandwidth bills: scenev33 was 3.69 render / 4.71 bandwidth, scenev30 was 2.78 render / 3.84 bandwidth, and scenev25 was 3.13 render / 2.4 bandwidth. Their core issue: bandwidth is now higher than render cost in some cases, and for the same scene size the bandwidth charge appears to nearly double without an obvious explanation. They argued this “doubled the cost” of the rendering service.
⭕️ The technical pain point is ORBX packaging: @gregleuey says Standalone exports clump all geometry into a giant point/geometry cache even when much of it is static, so users end up paying to distribute oversized files. Earlier context: this same issue was raised on Oct. 22, when @gregleuey cited a $24 render with $34 bandwidth and an 8GB ORBX reduced to about 1.8–2GB only after manually separating static and animated geometry. Team member Dino previously clarified that alembic can be cached on nodes, but cache size/persistence depends on each node operator.
❗ Focus for the team: clarify why equal-size 2.7GB scenes can generate different bandwidth fees, whether asset/geometry caching applies to ORBX point caches, and whether scene-size optimization or bandwidth estimation can be automated instead of requiring manual user setup.
76
“Then there is node staking where job flows to your node based on the staked wallet”
@JulesUrbach 22.05.21
$RENDER
1
14
491
🔥 $1,128.03
🔥 716.87 RENDER
Transaction: 3LSU4MkoHo8ppQTesACFaYX1fbTkP3fms8h64VJasD6CjCsH9JMeNSSWBnqtyacmt2k33YwbQNuYhFAZ35LQWcFK
1
185
🔥Burns Update🔥
$4,307 (2,865 $RENDER) across 151 tx burned.
Median $4, biggest burn $455.
Burns removed 17.47% of daily emissions.
What's happaning on $RENDER Discord, what's currently being discussed in the channels?
Let's dive in
🧵👇🏻👇🏻👇🏻🧵
🧵 node-revenue
Lowest-tier node economics are the concern: @tanzla says rewards need to be calculated per pool to keep smaller operators viable.
⭕️ @tanzla argued that without per pool rewards, the lowest tier is no longer economical. No specific tier threshold, reward rate, pool size, or cost assumptions were provided in the message, so the exact break-even issue is unclear.
❗ Focus for the team: clarify whether per pool rewards are being considered, how the current reward structure impacts the lowest tier, and what concrete metrics operators should use to assess whether participation remains economical.
1
5
319
🧵 rnp-024-forth
RNP-024 has moved into an active voting phase for the Forth growth and adoption incentive program.
⭕️ Team member Luke announced that voting is now open for RNP024, covering the proposal to support Forth’s growth and adoption incentive program within the Render Network ecosystem. The active voting link is nation.io/a/RenderNetwork/pr…, and voters can review the governance voting guide here: know.rendernetwork.com/about…. Recent context from the same channel noted this follows the earlier RNP-024 voting round opened on Oct 28, with voter eligibility tied to holding RENDER in self-custodial wallets.
❗ Focus for the team: Ensure voters understand whether this is a subsequent/final voting round, the current voting deadline, and any eligibility or snapshot details if they differ from the earlier RNP-024 round.
1
1
101









