Introducing Protocol-Rewards by Tez Capital: Enhancing Reward Distribution in Adaptive Issuance
What Changed?
The way staking and delegation mechanics work has fundamentally changed with the advent of Adaptive Issuance, starting with the Oxford protocol with further changes in Paris. For the purposes of this blog post, it’s not necessary to go over all the staking changes.
Previously, delegation rewards were determined by a random snapshot taken sometime in an earlier cycle. This made it convenient for Tezos reward distribution tools such as TezPay and TRD to use the TzKT API to determine exactly how much each delegator contributed to the protocol recorded balance.
As part of the Adaptive Issuance protocol changes, the snapshot-based reward determination heuristic has been changed to a “minimum delegated balance” during a cycle determination. The new way uses a delegator’s minimum delegated balance from a previous cycle, to determine how much the delegator is due.
This means that if you had 100 tez in your wallet during a given cycle and you sent it all to a different address, then you sent it back, you would not be eligible to receive rewards for this cycle. This in and of itself is not really very concerning because most people usually don’t send their whole balance out just to send it back immediately.
Please note…
This article addresses only liquid delegation reward distribution, which is done manually by bakers. The new locked staking mechanism on Tezos pays rewards automatically on-chain and is not addressed here, other than being mentioned along with delegation as part of the way Adaptive Issuance works.
So, what’s the problem?
The problem is that rewards for delegators are still determined by snapshot-based mechanics when one uses TRD, via the TzKT API alone. Meanwhile at the protocol level, rewards are determined using the new minimum delegator balance system.
There are some scenarios which affect everyday Tezos delegators:
- When a delegator decides to stake, the delegator’s delegated balance drops in a commensurate way and should no longer be eligible for payments. The snapshot based way of keeping track of delegator payments could end up paying this — technically ineligible by protocol rules — delegator, resulting in dilution for all other delegators.
- When a delegator spends or moves a big part of their tez, if a snapshot system is used, this may not accurately reflect how much the big spending delegator should be paid. This also results in dilution for other delegators.
- If a delegator increases their balance, in may get snapshotted — diluting others, while they shouldn’t get rewarded for the difference because the minimum was without the extra balance. The delegator may be rewarded with extra balance if minimum is triggered after the deposit by another delegator.
- Certain DeFi instruments such as the Kolibri Vaults work in a way that’s incompatible with the new way to determine delegator rewards. As part of sending or receiving tez in or out of the vault, the vault is first completely emptied, before the new total is added to the vault. This means that each time a Kolibri vault receives a baker payment or moves any of its tez, it makes the vault temporarily ineligible — according to the protocol — for payment for the current cycle, when paid in the future. A snapshot based payment approach may pay the Kolibri vault when no rewards are due, causing dilution for all other delegators, proportional to the size of the Kolibri vault.
Protocol-Rewards
We have developed an open source service — and implemented it into TezPay — which works in tandem with the TzKT API to strictly use the new protocol reward system to determine how much each delegator contributed to the protocol recorded balance.
Source Code: https://github.com/tez-capital/protocol-rewards
Protocol-Rewards Technical Specifications
We have built the Protocol-Rewards using TzGo as the blockchain facilitator SDK, to be compatible with TzKT API endpoints.
Key Features:
- Decentalization: Ability to specify baker for reward monitoring and self-host a private instance.
- Tezos Cycle Monitoring: Track cycles in the Tezos blockchain to compute reward allocations for delegators based on their participation.
- API Mirroring: Mimic the TzKT API’s endpoints to provide seamless integration and interaction capabilities for users.
- No Frontend Interface: The system will operate as a backend service only, with potential scope for frontend development in the future.
Technology Stack:
- Programming Language: Go (Golang)
- Blockchain SDK: TzGo for interacting with the Tezos blockchain.
- Web Framework: Fiber for efficient API development with a focus on speed and simplicity.
- Database: PostgreSQL to store and manage data regarding delegators, rewards, and cycle information.
- API Compatibility: Compatibility with TZKT API endpoints to ensure seamless integration for users already familiar with the TZKT infrastructure.
FAQ
Q: How should bakers pay Kolibri Vaults?
- Tezos bakers are encouraged to use the payouts-substitutor extension, developed by La Boulange, to automatically redirect all Kolibri Vault payments into the vaults’ respective tz1–3 manager address. This will not result in the vault changing its balance and being automatically ineligible for payments.
Q: I thought staking rewards were now automatic on Tezos?
- The new staking role in Adaptive Issuance does indeed have automatic reward distribution and does not need any external tools or actions taken by bakers, to distribute staking rewards. On the other hand, delegation rewards remain manual and must adhere to a new system that tracks what delegators are due to be paid.
Q: Are there any changes expected in the future for delegation reward distribution?
- Yes, delegation reward distribution accounting/indexing is an active topic on the Tezos source code repository. As protocol improvements related to delegations are implemented, we will update the baker and delegating community on how this changes the use case of Protocol-Rewards.
Acknowledgements
Tez Capital would like to thank Tezos Commons as well as the Tezos Ecosystem DAO for funding the Protocol-Rewards software.
We would also like to thank Julien Tesson, Research Engineer at Nomadic Labs for helping us untangle the complexities of Adaptive Issuance.
Helpful Links
Tez Capital Website > https://tez.capital
Tez Capital Discord > https://dsc.gg/tzc
Tez Capital Telegram > https://t.me/tezcapital
Tez Capital Documentation > https://docs.tez.capital (find out more about our tools here)