Introduce a deflationary mechanism: burn 1 BLD for every staking reward claim

Governance
1

Summary

This proposal introduces a simple and transparent deflationary mechanism for the Agoric ecosystem.

Whenever a user claims staking rewards, 1 BLD will be burned permanently.

The goal is to:

  • introduce a predictable supply sink

  • align network activity with BLD value

  • strengthen the long-term sustainability of the token economy

The mechanism is intentionally simple: 1 claim → 1 BLD burned.

Motivation

Currently, the BLD token economy faces three structural dynamics:

  1. Ongoing inflation through staking rewards

  2. Limited mechanisms that reduce circulating supply

  3. Low fee capture directly tied to token value

While staking secures the network, the ecosystem lacks a systematic way for normal network activity to contribute to reducing supply.

Introducing a burn tied to reward claims creates a natural counterbalance to inflation while remaining simple and transparent.

Proposal

When a user executes a staking reward claim transaction, the following will occur:

  1. The standard transaction gas fee applies (unchanged).

  2. An additional fixed fee of 1 BLD is charged.

  3. That 1 BLD is sent to the burn address, permanently removing it from circulation.

  4. The staking rewards are then delivered to the user.

Rule:

1 claim transaction = 1 BLD burned

If multiple rewards are claimed in a single transaction (for multiple validators), the burn still applies once per transaction, not per validator.

Why a Fixed Burn Fee

A fixed fee was chosen because it is:

  • Simple

  • Predictable

  • Transparent for users

Unlike percentage-based fees, a fixed burn does not require reward calculations or variable logic.

Users can simply choose to claim rewards less frequently if they prefer to minimize the relative impact.

Expected Benefits

1. Introduces a Supply Sink

Each reward claim permanently removes BLD from circulation.

Example scenarios:

Claims per day BLD burned per day BLD burned per year
1,000 1,000 365,000
5,000 5,000 1,825,000

This creates a deflationary pressure tied directly to network activity.

2. Aligns Network Usage with Token Value

Currently, claiming rewards extracts value from staking emissions.

With this mechanism:

  • every claim also strengthens the token economy.

3. Encourages Efficient Claiming Behavior

The fee encourages users to:

  • avoid unnecessary frequent claims

  • accumulate rewards before claiming

This can reduce unnecessary transaction volume.

4. Simple to Understand and Implement

This proposal:

  • does not modify staking rewards

  • does not introduce complex tokenomics

  • adds a single clear rule

Simplicity reduces governance and implementation risk.

Impact on Delegators

The impact is minimal for most users.

Rewards continue to accumulate normally.

Users who prefer can simply claim rewards less frequently.

Example:

Rewards claimed Burn fee Effective impact
50 BLD 1 BLD 2%
100 BLD 1 BLD 1%
500 BLD 1 BLD 0.2%

Governance Flexibility

If the ecosystem determines that the burn amount should be adjusted in the future, governance can revisit the parameter and modify it through a future proposal.

Conclusion

This proposal introduces a simple, transparent, and sustainable deflationary mechanism:

Burn 1 BLD every time staking rewards are claimed.

Benefits include:

  • reducing circulating supply

  • aligning network activity with token value

  • improving long-term tokenomics

  • maintaining simplicity and transparency.

Every reward claim should strengthen BLD.

2

This looks really good.

3

A question from discord:

could this be done easily from dev side?

I asked ChatGPT:

Sketch a plan for this software change https://community.agoric.com/t/introduce-a-deflationary-mechanism-burn-1-bld-for-every-staking-reward-claim/930

This .go stuff is outside my wheelhouse, but at a glance, it looks reasonably straightforward.

1 Like
4

Yes — from a high-level review, this looks feasible and reasonably straightforward for the dev side, but not completely trivial.

The change is fairly well-scoped around the distribution module (staking rewards flow) and app wiring. It would likely involve modifying the reward withdrawal logic, enabling burn permissions for the module account, and ensuring the “once per transaction” rule is enforced safely.

That said, since this touches consensus-critical logic, it would require careful handling of:

exact trigger point (which reward claim messages are affected)
enforcing 1 burn per transaction deterministically
failure behavior (e.g., insufficient balance for burn)
upgrade handling and backward compatibility
proper testing to avoid unintended side effects

Overall, it does not appear to require major architectural changes — more of a targeted protocol-level adjustment — but still needs proper review and implementation discipline.

Would it make sense to move forward and formalize this into a full governance text proposal for discussion?

1 Like
5

Is the primary goal adding the fee or burning it? Claim isn’t that frequent, so wouldn’t just increasing the fee be better? Then have some percentage of fees get burnt generally.

2 Likes
6

Why 1 BLD? What are the economics behind it?
Can we see a bit more math as to how this will help counterbalance inflation in the long term?

1 Like
7

Great question — the goal is actually both: introducing the fee and burning it.
The fee by itself doesn’t solve the problem unless it’s tied to a supply sink.
The burn is what creates the long-term value alignment.
The idea is to connect network usage (reward claims) with supply reduction, even if the individual amounts are small.
Also, something important I’ve observed while reviewing wallets during previous voting periods:
There are accounts claiming rewards multiple times per day, even when the rewards are extremely small.
In those cases:
Increasing general fees wouldn’t necessarily change that behavior
But adding a fixed cost per claim encourages more efficient claiming
And at the same time, each interaction contributes to reducing supply
So this mechanism:
discourages inefficient micro-claims
introduces a predictable burn
keeps everything simple and transparent
A global fee increase + partial burn could be explored in the future, but it introduces more complexity and affects all transactions.
This proposal is intentionally scoped to be:
minimal, targeted, and directly tied to staking behavior
Just to add some context:
This proposal has been publicly available and open for discussion on the community forum for over 24 days prior to going on-chain.
:backhand_index_pointing_right: https://community.agoric.com/t/introduce-a-deflationary-mechanism-burn-1-bld-for-every-staking-reward-claim/930⁠�
During that time, there was an opportunity for early feedback, iteration, or alternative suggestions.
It’s worth noting that this discussion is now gaining traction after the vote is already underway, which is still valuable, but highlights the importance of engaging earlier in the process to shape proposals more effectively.
More broadly, I also shared a previous discussion in Discord around a potential “PoS 2.0” direction during earlier voting cycles, since the underlying challenge here — token value pressure and weak value capture — is not unique to Agoric.
It’s something that most Proof-of-Stake ecosystems are currently facing.
This proposal is a small, focused step in that direction: introducing a simple mechanism that begins to align usage with value.
That said, I’m very open to continuing the conversation and exploring more comprehensive approaches with the community.

8

@BCMO @dtribble Just to share an observation in a constructive spirit:
This proposal was publicly available on the community forum for over 24 days prior to going on-chain, and during that time it did not generate significant engagement or concern.
Now that the vote is underway, we’re seeing a sudden increase in feedback and opposition.
While all input is welcome and valuable, the timing is somewhat notable — especially as the discussion appears to be converging in a more coordinated way at this stage of the process.
From a governance perspective, it would be ideal for these types of concerns to surface earlier, when proposals can still be iterated collaboratively and more efficiently.
That said, I appreciate the engagement now and remain fully open to refining ideas together — whether in this proposal or in future iterations.

2 Likes
9

@Jericho – You are 100% on point to call me out on that. I missed the discussion previously. I own that lapse.

I am speaking mostly as a community member at the moment. A few curiousities:
”But adding a fixed cost per claim encourages more efficient claiming” - If the burn fee discourages frequent claiming, how does the model account for the compounding losses for small stakers waiting longer to claim?

10

The more I dig in, I feel that the risks and drawbacks outweigh the benefits.

As I mentioned previously, the flat fee punishes small stakers.

The proposal discourages on-chain activity rather than encouraging it.

Is there a model that shows the impact it will have if the BLD price goes up? Does this theory scale? I tend to think it doesn’t.

I love the community participation and the principle. However, I’m not sure this has been thought through enough from a tokenomics and economic standpoint to garner my support on a personal level.

3 Likes
11

As a validator, we appreciate the intention behind this proposal. Specifically the goal of introducing a supply sink and improving long-term tokenomics. However, after careful consideration, we do not support this proposal in its current form.

While the mechanism is simple, it introduces several structural issues that we believe outweigh its potential benefits:

1. Penalizing core user behavior
Claiming staking rewards is a fundamental and necessary action for delegators. Introducing a fixed burn tied to this action effectively taxes normal participation rather than value-generating activity. This creates unnecessary friction and may discourage engagement.

2. Disproportionate impact on smaller delegators
A fixed 1 BLD fee is inherently regressive. Smaller stakers will experience a significantly higher percentage impact compared to larger holders, which over time may contribute to stake centralization—something we should actively avoid.

3. Negative impact on compounding and network security
By discouraging frequent reward claims, this proposal reduces compounding efficiency. This can lead to lower effective staking yields and, in turn, reduce incentives to stake—potentially weakening network security.

4. Weak linkage to real economic value
The burn mechanism is tied to reward claims rather than actual network usage or value creation. As a result, it does not meaningfully align token value with real economic activity, which is a key objective for sustainable tokenomics.

5. Uncertain and easily optimized effectiveness
Rational users will adjust behavior (e.g., batching claims), which reduces the frequency of burns. This makes the mechanism unpredictable and limits its effectiveness as a consistent counterbalance to inflation.

6. UX and integration concerns
This change adds complexity for wallets, auto-compounding tools, and general user experience. It introduces additional decision-making and overhead for what should remain a simple interaction.

Conclusion

While we agree that introducing supply sinks is important, we believe this approach targets the wrong layer of the system. Mechanisms should ideally be tied to real economic activity (e.g., fees, protocol revenue, or demand-driven usage) rather than penalizing routine user actions.

4 Likes
13

@BCMO Thanks for the thoughtful feedback — these are valid concerns and worth discussing.
A few points from my perspective:
First, regarding the flat fee and small stakers:
Yes, a fixed fee has a higher relative impact on smaller claims. However, it also naturally encourages less frequent, more efficient claiming, which reduces unnecessary on-chain noise.
And importantly, users are not forced to claim frequently — rewards continue to accumulate.
On scalability and price impact:
If BLD price increases significantly, this mechanism can absolutely be adjusted, reduced, or even removed through governance.
This is not meant to be a permanent rigid rule, but rather a practical step for the current stage of the network.
Right now, the reality is:
We have very limited value capture mechanisms.
For example, Fast USDC fees over nearly a year are still under ~$600 total — which is negligible at the network level.
On encouraging vs discouraging activity:
At the moment, this mechanism could actually become one of the primary sources of consistent on-chain value flow.
Not because it’s ideal long-term — but because there are currently very few mechanisms generating meaningful economic activity tied to BLD.
On the broader tokenomics concern:
We started with a market cap around ~$80M — and the trajectory since then is clear.
The risk today is not over-optimization — it’s lack of value capture and continued emission without counterbalance.
In that context, doing nothing is also a decision — and likely the riskier one.
Zooming out:
This is not just an Agoric-specific issue.
Many Proof-of-Stake ecosystems are currently facing the same structural problem:
inflation through rewards
weak value capture
sell pressure from large holders
PoS tends to work well once the asset already has strong price and demand (Ethereum is a good example).
But in earlier-stage ecosystems, we often see:
Large holders continuously selling rewards to secure fiat before further downside.
That creates a negative loop that is hard to break without introducing mechanisms that link usage to value.
So this proposal is not presented as a perfect or final solution.
It’s a simple, controlled intervention:
minimal complexity
easy to understand
directly tied to staking behavior
adjustable via governance
I fully agree that deeper tokenomics modeling and broader mechanisms should be explored.
But given the current state, this is intended as a practical starting point, not the end state.
Happy to keep refining this together :+1:

14

@Kristaps_Jahimovics Thank you for the detailed and thoughtful feedback — this is exactly the type of discussion that helps improve the ecosystem.
I’d like to respond to a few of the points raised:

  1. “Penalizing core user behavior”
    I agree that claiming rewards is a fundamental action. However, today we are also seeing patterns where rewards are claimed very frequently, even when economically insignificant.
    This proposal is not about penalizing participation, but about:
    encouraging more efficient behavior while introducing a minimal value capture mechanism.
    Rewards continue to accumulate normally, and users retain full control over when to claim.
  2. “Disproportionate impact on smaller delegators”
    This is a valid concern in percentage terms.
    However, in absolute terms, the cost is fixed and predictable, and users can optimize by:
    claiming less frequently
    batching rewards
    Also, if the ecosystem evolves and BLD price increases, this parameter can be adjusted or reduced via governance.
    This proposal is intentionally simple and adaptable.
  3. “Negative impact on compounding and security”
    The impact on compounding exists, but it is relatively small in practice and can be mitigated by adjusting claim frequency.
    More importantly, we should also consider the opposite risk:
    continued inflation with no counterbalancing mechanism.
    Over time, that can have a much larger negative effect on staking incentives and network security than a small reduction in compounding efficiency.
  4. “Weak linkage to real economic value”
    I agree that, ideally, value capture should come from real economic activity.
    However, today:
    we have very limited sources of meaningful on-chain value capture tied to BLD.
    For example, Fast USDC fees over nearly a year are still under ~$600 total, which is negligible at the protocol level.
    Given the current state of the network, this mechanism can act as:
    a temporary but consistent value anchor tied to actual user interaction.
    It’s not the end state — but it is a step toward better alignment.
  5. “Easily optimized / reduced effectiveness”
    Yes, users will optimize behavior — and that is expected.
    Even with batching:
    burns still occur
    they remain predictable
    and they scale with actual usage
    This is not intended to perfectly counter inflation, but to introduce a continuous supply sink where none currently exists.
  6. “UX and integration concerns”
    This is an important consideration.
    However, from an implementation perspective, the mechanism can remain:
    simple
    deterministic
    easy to communicate (“1 claim = 1 BLD burned”)
    Compared to more complex alternatives (dynamic fees, percentage models, etc.), this approach minimizes cognitive and technical overhead.
1 Like
15

@Kristaps_Jahimovics @BCMO @dtribble Just an observation based on the current voting data:

If you look at the votes, it’s not only larger holders participating — there is also clear support coming from smaller holders, including accounts holding roughly 100 to 6,000 BLD, who are voting YES on this proposal.

This is important because one of the main concerns raised is the impact on smaller delegators.

However, the data suggests that:

a portion of smaller holders are actually supportive of introducing a simple burn mechanism tied to reward claims.

That doesn’t mean the concern is invalid — but it does indicate that perspectives across smaller participants are not uniform, and some see value in this approach.

It may be worth taking that into account when evaluating the overall sentiment of the community.

1 Like
16

@Jericho
89 addresses voted as of now. Nice to see small holders showing up, but it doesn’t really paint a picture of sentiment. 75.3% of addresses voted Yes, but only 64.3% of tokens did. The people with more at stake are less enthusiastic. The Abstain block is 12.4% of addresses but 25.9% of voting power.

None of this changes the core problem: a flat fee is regressive regardless of who votes for it. 1 BLD on a 50 BLD claim is 2%. On a 5,000 BLD claim it’s 0.02%. People can vote against their own economic interest, especially when a proposal is wrapped in language about “strengthening BLD” without spelling out who bears the proportional cost.

17

Did you actually run the numbers before putting this proposal forward?

Based on current activity, we’re seeing roughly 2,500 reward claim transactions per month. That would translate into 2,500 BLD burned monthly which at current prices is around $10.

Do you genuinely believe this has any meaningful economic impact?

It introduces unnecessary complexity and confusion for delegators without solving the underlying issues in the tokenomics.

2 Likes
18

@Kristaps_Jahimovics Thanks for running the numbers — that’s a fair point.
I agree that at current activity levels, the absolute burn is small.
But I think the key question is not:
“Does this solve tokenomics today?”
but rather:
“Do we currently have any mechanism that links usage to value at all?”
Right now:
~2,500 claims/month → ~$10 burned
Fast USDC → <$600/year
So effectively:
we have near-zero value capture mechanisms
This proposal is not meant to be a full solution.
It’s a baseline mechanism that:
introduces a predictable supply sink
ties it to real user interaction
and can scale with activity, not remain static
If usage grows, this scales automatically.
If it doesn’t, that actually reinforces the core issue:
lack of demand and activity — which is a bigger problem than the burn itself.
So I would turn the question around:
What mechanism do you propose that improves tokenomics today?
Because doing nothing while waiting for a future model also has a cost.
Happy to explore alternatives — but we should be moving toward some form of value capture, not staying at zero.

19

@BCMO

Thanks for the detailed breakdown.
I agree that a flat fee is regressive in percentage terms — that’s mathematically correct.
But I think we’re missing the bigger picture.
Over the past few years, Agoric reached a valuation of around $80M, and today we are sitting at under $4M.
That’s not a minor fluctuation — that’s a massive destruction of value.

BLD was originally sold in the range of roughly $0.50–$0.80 per token, and today we are at a fraction of that value.
So when you say that people may be voting against their own economic interest, I would frame it differently:
many participants are reacting to a situation where their economic interest has already been significantly impacted.
So the question is not whether this proposal is perfect.
The real question is:
What has actually been done over the past 4+ years to build sustainable tokenomics and value capture?

Because today we are still in a position where:
emissions continue
real fee generation is negligible
value capture is almost non-existent
and the ecosystem is still described as “subsidized”
At some point, we have to acknowledge:
waiting for a future, more complete model has not worked so far.
So while this proposal may not be perfect, it is at least:
simple
immediate
and introduces a real (even if small) link between usage and value
If the argument is that this is not the right mechanism, that’s completely fair.
But then the natural follow-up question is:
What concrete mechanism should be implemented instead — and when?
Because continuing without any form of value capture is not neutral — it’s actively contributing to the current trajectory.
I think the community would benefit from a clear answer on:
what the actual plan is
what timeline is realistic
and how we avoid repeating the same outcome over the next few years
Happy to engage constructively, but I do think we need to be honest about where we are today.

21

First, apologies for taking so long to reply. I’ve been following along and discussing this with folks offline.

The signal here is clear: we need to introduce a burn mechanism, tied to real network activity.

For the 1 BLD fee, there are some practical details to resolve. For example, Keplr’s “claim and restake” bundles multiple claims into a single transaction, so we need to define clearly:

  1. whether the 1 BLD is charged per transaction or per individual reward-withdraw message

  2. whether it applies only to delegator rewards, or also validator commission withdrawals

  3. how “withdraw all rewards” flows are treated

  4. whether transactions should fail up front if the extra fee isn’t present

There are also mechanics to get right. The fee needs to surface cleanly to wallets and custodians without requiring changes, and we need to decide where the burn is applied. A claim-specific fee is the narrowest path, but it’s also a one-off. A more general approach (e.g. burning a portion of fees or commissions) would fit better long term, but is a larger step.

We’re currently upgrading to 0.53, so I’ll also check what burn-related options it enables.

In parallel, it’s worth considering other fee surfaces that could be burned, such as:

  • gas fees

  • swingset message fees

  • orchestration commissions (as they come online)

These may provide a more scalable and durable source of burn as usage grows.

So the next step is to refine the 1 BLD approach and compare it against these alternatives. There are real tradeoffs between simplicity, predictability, and long-term fit with the fee model.

I’ll be looking at how these options behave in practice as part of the 0.53 work. It would also be valuable for the community to weigh in with analysis on which mechanisms produce the most meaningful and durable burn over time.

3 Likes
23

@dtribble

I was removed from the Discord without any clear reason or prior communication.

I want to address this openly and respectfully: I’ve been actively participating in the community, sharing feedback, and engaging in discussions because I care about the future of Agoric. Being removed without explanation raises concerns about transparency and how community members are treated.

If there was a specific issue with my behavior, I’m fully open to hearing it and addressing it. But without any context, it’s difficult to understand what happened or how to improve.

More broadly, I think situations like this matter. If contributors—regardless of size—feel they can be removed without explanation, it can discourage open participation, which is critical at this stage of the ecosystem.

I would appreciate clarification from the team on:

  • Why I was removed

  • Whether this was intentional or a mistake

  • What the expectations are for community participation going forward

I’m still here because I believe in the potential of this project, and I want to continue contributing constructively.

Thank you.