Discussion: Updating RAD Tokenomics

Discussion: Updating RAD Tokenomics

Last week, a new product within our ecosystem was announced. In addition to the recent product launches across the Radworks Ecosystem, I would like to start the conversation with regards to refining the tokenomics model for the $RAD token.

The goals of this initiative are:

  1. To Strengthen Governance with Long-Term Commitment
    Empower long-term aligned RAD holders by increasing their influence in governance decisions.
  2. To Incentivize Reliable Node Operation
    Encourage active and dependable participation from infrastructure providers by rewarding nodes that meet defined performance standards, inspired by work token models.
  3. To Enable Value Participation Across the Ecosystem
    Create opportunities for RAD holders to benefit from the value generated throughout the Radworks Ecosystem, aligning incentives across all participants.

The core idea: RAD holders lock tokens to unlock governance power and participate in value generated by Radworks-related services. But with a crucial addition: only those who both lock tokens and operate reliable infrastructure are eligible. This dual requirement of RAD commitment and real network contribution fosters long-term alignment between users, node operators, and token holders.

Background: RAD and the Radworks Ecosystem

RAD has historically been a governance token for the Radworks treasury. With the growth of products like a) the Drips protocol and application for funding open source software and b) the emergence of the Radworks App for secure and verifiable front-ends, the ecosystem is now starting to generate distributable value.

Proposal to introduce veRAD to Radworks

I am proposing that Radworks introduces veRAD, a vote-escrowed token system that rewards long-term participation and active node service. The key parameters are described below:

  • Lock Duration: Lock RAD for 1 week to 4 years to receive veRAD. Longer locks = more veRAD (linear scale).
  • veRAD Decay: Voting power and reward share decrease over time as the lock approaches expiry.
  • Eligibility Filter (Uptime): To receive rewards, nodes must meet a minimum uptime threshold during each epoch (e.g., 95% availability). Nodes that do not meet this operational requirement will not be eligible for that week’s rewards, regardless of veRAD balance. These eligibility requirements may evolve over time through governance to include additional metrics such as latency, data throughput, and delivery success rate for certain RIDs and NIDs related to the new Radworks app.

Governance Power

In this model, 1 veRAD = 1 vote in Radworks governance. veRAD holders guide major decisions including:

  • Treasury allocations
  • On-chain contract upgrades
  • Emissions schedules and parameters

Value Generated and RAD Emissions

Additionally, as long as the eligibility filter is met, veRAD holders receive a portion of RAD (and potentially USDC) based on their pro rata share of the total veRAD, half of which derived from value generated across the Radworks Ecosystem (Community services & products) and half of which is derived from the community treasury (Treasury Portion).

The Community Portion consists of 50% of the cross-community value created from:

  • Radworks App (frontend infra)
  • Drips App
  • Potentially from Garden hosting & compute (to be announced)

The remaining 50% of the value created across the above-mentioned applications will be used for continuous development and operations.

For the Treasury Portion (ie RAD emissions), I would like to propose the following schedule that attempts to kickstart veRAD participation and locking, while the new services are finding their footing in the market, by providing meaningful rewards without exhausting the treasury.

Year RAD % of Total Supply % of Current Supply % of Treasury Weekly Rewards
Y1 2500000 2.5% 4.8% 5.2% ~48077 RAD
Y2 2000000 2% 3.85% 4.17% ~38461 RAD
Y3 1500000 1.5% 2.88% 3.13% ~28846 RAD
Y4+ 750000 0.75% 1.44% 1.56% ~14423 RAD

Weekly Epoch Distribution

  • Rewards (RAD) are distributed weekly, based on veRAD balance snapshots.

To streamline rewards and minimize complexity, Radworks may also introduce a RAD buyback mechanism instead. In this model, protocol funds (USDC/ETH) are used to purchase RAD from the open market before distribution, enabling all rewards to be delivered in a single token. This simplifies the user experience and consolidates economic value directly into the RAD token.

  • If you hold 2% of all veRAD, you receive 2% of that week’s reward pool.
  • This system supports predictable and compounding engagement, while keeping governance aligned with epoch cycles.

Node penalties

To maintain the integrity of the reward system, the model may introduce gradual penalties for node operators who are found to be misbehaving. The penalty severity can escalate based on recurrence or severity of the violation, and all enforcement actions would be transparent and governed by community-approved protocols.

Let me know your thoughts.

2 Likes

Hi @lftherios

Thanks for sharing this — I’m excited to see the ecosystem finding ways to reward participation.

This sounds really promising — reminds me of a Curve/veCRV-style model. Some feedback and thoughts below.

I’m in agreement with this idea, just noting things that would be good to address in the subsequent formal discussions.

Transparency

  • How will we make node/network rewards transparent? Would be good to have an automated dashboard that is baked into any final plan.
  • Node Operating Costs: it might be good to share Radworks own operating costs or some rough estimates to give prospective node operators an idea of the costs involved (i.e. is it worth the reward?)

Risk Mitigation/Question

  • Are there risks of a Convex-style aggregator capturing governance? Might be worth considering safeguards here. Mostly thinking of the bribing that took place. Is this more or less mitigated by the requirement for both (a) staking of RAD and (b) serving a node with good uptime?

For Node Operators

  • I love this concept already — might it be worth linking (or starting) docs to help potential node operators get started?
  • Will there be any form of delegation, whereby someone can participate as a node operator without actually doing the technical work (i.e. delegate my staking to a technical team)?

Addressing this second point may be important because the veRAD token requires both (a) financial commitment and (b) technical work. Many people might want to make that financial commitment (locking up RAD), but not have the technical abilities to run a node. So having some sort of side-door that opens both paths to anyone might help. If we don’t do this, I imagine someone else will via a secondary market. I’ve seen this happen with some protocols, like the official POKT network and delegation run by an unrelated group called POKT Pool.

Suggestions for the Post

  • Radworks runway: Assuming nothing else, if ~13% of the Treasury is awarded over 4 years, that implies a ~30-year runway. But that’s a naive calc. It could be helpful to add a more robust analysis here, given the importance of Treasury longevity.
  • Radworks revenue: Might also be worth linking to revenue plans (e.g. node services, Radworks Apps). Even though that’s not the main focus of this post, anyone less involved might immediately wonder how the Treasury will be sustained if it’s being drawn down for rewards.
  • The emissions table: The two columns “RAD” and “Weekly Rewards” both being denominated in RAD is a bit confusing — could they be labeled more distinctly? Right now it’s not fully clear how to read them together.
  • Docs on running a node: This is a compelling plan, and I imagine others (like me) will want to learn more about how to qualify for node rewards. Recommend linking to useful docs in this or more finalized plans.

Hey @lftherios

I’m only seeing this post now, after coming to the forum to see the quarterly updates - I didn’t seem to receive a notification from this specific category - just thought I’d mention this, in case others who are generally tracking the forum have also missed it.

Otherwise, I’m completely new to this area and wanted to get a better understanding of the proposed model. The link to the vote-escrowed token system seems to be broken however ( 404 not found | Wintermute? ) . Any chance of another recommended link ?