HIP-149 tracking #1212
Merged
Merged
Conversation
* Tracking branch for HIP-149 implementation * Add a new DC reward allocator DC is going to eat all the rewards regardless of how much data transfer happened during the epoch. There are some tests to makes sure rounding errors cannot get out of hand, and cannot underflow. * Add test to ensure unallocated can never exceed the number of gateways unallocated should only ever come from rounding DC down. If it exceeds the number of input gateways, something was rounded incorrectly. * Remove test helper poc reward getters, ack sink senders * Test no poc rewards are output * swap out data transfer allocator and drop poc rewards using a new simpler dc allocator, and no longer sending the underflow to the poc pipeline. * newtype wrapper for RewardableDataByHotspot, break out scale telemetry * Record scale infallibly * Add telemetry around target vs actual price per gb Due to rounding of bones, the actual should always be a hair lower than target. * bring back old reward pipeline to ease diff * add tests for hip-149 implementation rather than changing existing Always ack in the filesink so we can use write_all for rewards. I'm not sure if we should indeed move all rewards to unallocated when there are no gateways, but I think adding the test is clear enough of a call out to start the conversation. * add examples used for helping to verify DC rewards
…#1214) The 3x cap and backstop shift HNT between hnt_rewards_issued and delegation_rewards_issued, so a fixed 70% data-transfer share would over-allocate (over the cap) and under-allocate (under the backstop) the HNT the rewarder is handed. Carry both hnt_rewards_issued and delegation_rewards_issued through EpochRewardInfo (the latter for completeness; the rewarder doesn't distribute it) and split hnt_rewards_issued as: service providers = flat 24% of total emissions data transfer = hnt_rewards_issued - service providers (residual) so service_provider + data_transfer == hnt_rewards_issued exactly, every epoch. New reward_shares::emissions_split holds the split, with proptests pinning that invariant across the cap / backstop / baseline range. Cleanup: - centralize floor_to_u64 so every reward pool rounds the same way (ToZero) - drop now-unused get_scheduled_tokens_for_{data_transfer,service_providers}
* Add gaurd for reward pipeline waiting on burned data transfers This is to gaurd against the scenario where Solana is down and no burns have made it for the day. An alarm will go off, and we can intervene at the data level or with the disable_complete_data_checks_until() function. Also contains metrics for count differences between postgres and trino. Until we fully transition the strangler, we're still using postgres as the source of truth. And are noting any count differences. * gaurd is past the end of the epoch the gaurd only cares that we have data session past the end of the epoch, similar to heartbeats and speedtests. Then the regular strangler can come in and report differences between counts during rewards. * when we check something with postgres, check the same thing with trino the gaurd check is where we determine if trino thinks it would have been ready, we don't compare if both agree here. But that's less important, the other metrics during rewarding will tell us what was wrong.
* unallocated reward type is for Data now that POC is no longe rewarded * Remove individual rewards proptest The invariant would not hold in the extremes, and those were likely to never be produced. A gateway with 0 rewards would have less reward than is unallocated. I feel this test is safe to remove because we test this condition in an integration test, where 0 rewards are filered out to not be output. Here, however, before any filtering, the invariant is kind of a moot point. And the stronger proeprty to keep is that the unallocated rewards never exceeds the number of gateways. * add more tests around backstop/cap don't use circular logic to verify values * protect against an unclosed epoch by checking both rewards_issued columns over/under flow of rewards because of HIP-149 has changed what used to be the static 6% of delegation_rewards_issued to something that could potentially be a valid 0. We only want to break on non-closed epochs where there are no values for anything rewarded.
bbalser
approved these changes
Jul 2, 2026
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
2 participants
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.
This is tracking branch for all HIP-149 related changes.