HIP 149: add deployer earnings cap (overflow to stakers)#1217
Merged
Conversation
…takers) Decision 1 becomes a band: the existing target minimum (floor at 50% of the payer rate) plus a cap at 200%. When HNT appreciates faster than carrier revenue and baseline would pay above twice the payer rate, deployers earn the cap and the excess HNT is redirected to veHNT stakers instead of deployers. The cap is net-supply-neutral: it redirects within an already-emitted epoch total rather than minting or burning. Floor and cap are mutually exclusive. Implemented on the existing reward fields (issue_rewards_v0 shifts the escrow/delegator split on the Mobile pass; the verifier oracle sizes the data pool as the escrow residual after the flat Operations Fund cut), so no new account or schema is required. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The "in practice" paragraph blended two timelines: the HIP 143 payer-rate reduction (set before the vote, not part of this proposal) and the floor/cap band (this proposal's mechanism, live at passage). Reframe so the rate cut is clearly the input and the $0.05/$0.20 band is the post-passage example that keys off it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The example implied the band was dormant at current conditions. At today's HNT price (~$0.27) the baseline sits at the $0.05/GB floor, so the target minimum is the live protection, not dormant; the cap (~$1.09) is the far tail. Reframe so the floor/cap thresholds are stated against the actual price level. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Doubles the flat Mobile Operations Fund; the increase comes from the data bucket (delegators stay 6%, PoC is 0), so data deployers move from 84% to 74% of Mobile sub-DAO emission (+4pp vs today's 70%). Drops the relative-uplift framing (was +20% at the 84% bucket) and leads with the target minimum + earnings cap as the deployer value; at the current HNT price (~$0.27) the target minimum is binding. Updates the Decision 1 in-practice numbers (alpha 0.75 → 0.66, baseline ~16,640 → ~14,660 HNT/day, floor threshold ~$0.27 → ~$0.31, cap ~$1.09 → ~$1.24), the Decision 3 allocation table and top-up flow (~66/~18/~6/~10), Stakeholders, Deployment Impact, and the execution sequence. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Covers the cost of operating and growing Mobile network infrastructure, and keeps Nova (which administers the fund) aligned with network success at a level comparable to the up-to-24% Service Provider allocation it replaces. Added inline in Decision 3 and as a Rationale bullet. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…estriction Recast the Decision 1 opening and Stakeholders around deployers gaining on both ends: downside protection from the target minimum, plus upside participation in HNT (rewards are HNT-denominated) up to twice the payer rate, with surplus above the cap shared with veHNT stakers. The old $/DC peg gave neither. Removed the Drawbacks bullet that framed the cap as limiting deployer upside; the cap is fully and positively disclosed in Decision 1. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…rry it) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…rations Fund reframe Service Provider Rewards stay a flat 24% and data deployers stay at 70% (PoC retirement is the only Mobile allocation change). Decision 1 renumbers: alpha 0.66→0.625, baseline ~13,870 HNT/day, floor below HNT ~$0.33, cap above ~$1.31, top-up flow ~62/21/6/10. HIPs 82/87 removed from the retired list; "Why 20%" rationale removed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an earnings cap to Decision 1, turning the deployer reward mechanism into a band:
Effective earn rate becomes
clamp(baseline_$/GB, 0.5 × R_payer, 2.0 × R_payer).Why. The baseline pool is fixed in HNT and paid pro-rata, so its USD value rises without limit as HNT appreciates; the cap keeps deployer pay from running more than 2× ahead of the revenue the network collects. The 4× band ($0.05–$0.20/GB at the current $0.10 payer rate) leaves full appreciation exposure through normal ranges and engages only on sustained appreciation (above HNT ~$1.09 at current conditions, so dormant today).
Supply. The cap redirects within an already-emitted epoch total rather than minting or burning, so it is net-supply-neutral. The excess goes to veHNT stakers (claimed DAO-wide pro-rata of total veHNT) rather than being burned, giving lockers a revenue-linked upside that activates exactly when deployer pay outruns revenue.
Implementation. Rides the existing reward fields, verified against the program and verifier-oracle code:
issue_rewards_v0shifts the escrow/delegator split on the Mobile pass (reducinghnt_rewards_issued, raisingdelegation_rewards_issued), and the verifier oracle sizes the Mobile data pool as the escrow residual after the flat Operations Fund cut. No new account, proto, or schema. Floor and cap are mutually exclusive within an epoch.Updates: Summary, Stakeholders, Decision 1 (band framing, condition table, formula, thresholds, immutability), Drawbacks, and Rationale.