docs: state the staked-service top-up rule in source, and correct entry 41 - #354
Merged
Merged
Conversation
…ry 41 Records in Tokenomics._trackServiceDonations why ownerOf() is the right read even though it diverges from StakingBase's own ServiceInfo.owner for a staked service: the NFT is held by the staking instance, that address holds no veOLAS, and a staked service is already earning staking rewards, so an owner-qualified top-up would be a second reward stream for the same service. Intended, not an oversight. The comment is the whole point of the change. The rule was enforced only as a side effect of NFT custody and written down nowhere, so a reader comparing the two contracts saw two notions of "owner" and no explanation. Also corrects an overstatement in entry 41, added yesterday. It said integrators "should not expect donation top-ups" for a staked service. That is too strong: the eligibility test is an OR over the service owner and the donator, so only the owner leg is neutralised — a donator whose own veOLAS is above the threshold still qualifies the donation. The entry now shows the condition and says which half is affected. Contract change is comment-only: 8 added lines, all //, nothing removed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BV3qNR96Ua8UoNkm3pTfY7
DavidMinarsch
force-pushed
the
docs/staked-service-topup-note
branch
from
September 2, 2026 08:24
288319a to
3f6bb59
Compare
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.
Two changes, both in this repo.
The rule, written down
Tokenomics._trackServiceDonations()readsownerOf(serviceId)to decide top-up eligibility. For a staked service that returns the staking instance, not the person who staked it —StakingBasekeeps the original caller in its ownServiceInfo.owner, so the two notions of "owner" diverge — and the staking instance holds no veOLAS. The owner leg therefore can never qualify a staked service.That is intended: a staked service is already earning staking rewards, and an owner-qualified top-up would be a second reward stream for the same service.
The problem was that this was enforced only as a side effect of NFT custody and stated nowhere, so a reader comparing the two contracts saw two different notions of owner and no explanation. The comment says so at the point of the read.
Contract change is comment-only — 8 added lines, all
//, nothing removed.Correcting entry 41
Entry 41 was added yesterday and overstates the consequence. It said integrators "should not expect donation top-ups" for a staked service. That is too strong. The eligibility test is an
OR:so a donator whose own veOLAS is above the threshold still qualifies the donation. Only the owner leg is neutralised. The entry now shows the condition and says which half is affected, rather than implying top-ups are unavailable entirely.
I noticed this while writing the source comment — getting the comment right required reading the condition properly, which the entry had not.