As some of you may have heard in the past few days, there was a new issue discovered (credit to Adi_daz Barrio Bakery for reporting) with payments to KT addresses, specifically Kolibri ovens, which ended up causing irregular payments for the KTs and reward dilution for the baker and all their other delegators.
An excellent description thread of the issue by La Boulange ꜩ can be found here:
As you can see, the situation is pretty serious and solutions are needed. In addition to losing up to 50% of their protocol rewards with Adaptive Issuance starting, this issue would cause further frustration and losses for our delegators and bakers.
THE TEAM INFORMATION
Name: Primate & V from Tez Capital
Email or contact method: contact@groktech.xyz
Geographic location: Florida, USA
Are you applying on behalf of a company, or as an individual: Company
Name of project or idea: TBD (suggestions welcome)
Detailed description of your project or idea and why you believe it deserves funding: Provide an API service that provides accurate rewards for bakers of delegations, accounting for the protocol level changes, without causing anyone dilution or missed rewards.
What type of background or experience do you have and your team have in building out a project like this: We have been building in the Tezos ecosystem since 2021 with tools such as: TezBake (BakeBuddy), TezPay, TezGov (https://gov.tez.capital), TezPeak, TezBox (the smart contract dev environment) and Starlords (https://starlords.app). We’re confident in our ability to provide this service.
Funding amount being requested (please make sure the DAO treasury can currently support it, suggested range is 500–20,000 tez depending on project requirements and value): 12000 XTZ
Tez address to be funded (please verify accuracy): tz1Y48SaNNg3a5fjexaeh59tELfVaoUFu44v
Proposed goals/GPIs to deliver for the requested funding (funding may be broken into two tranches, with final half distributed after some proven deliverables): We will work with the following milestones in mind: (1) Working proof of concept (2) Working mainnet service, including documentation (3) Optimizations and automations. Costs include: development, maintenance and infrastructure for a year or until protocol changes significantly.
THE SOLUTION
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.
KEY FEATURES
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.
That’s clearly a need. Reward engines need to follow the same rules as the protocol, and such an API would make it possible.
Delegation is a crucial feature of Tezos that should be preserved, as it allows participants to be rewarded without taking any risk while remaining liquid. If the issue described above remains unresolved, most bakers would understandably stop rewarding delegations and only accept staking.
The Protocol does not need the share of the delegated tez for rights computation, only the amount.
During the discussion with Max (the discussion he told about Paris B: Minimal Balance · Issue #170 · baking-bad/tzkt · GitHub), it appears that either in TzKT or in the Protocol will be too costly in terms of performance, while having an intermediary tool will help. This tool will have to open a context and compute the share on it. We then sketched a really early draft pseudo-algorithm:
open end-of-cycle block,
for each delegate ,
iterate over delegator
compute overstaked
for delegate_of_interest in delegates
block_min = block_of_min(delegate_of_interest)
open predecessor block_min,
// Compute delegators
for each delegate,
iterate over delegator,
if delegate = delegate_of_interest
remember spendable,
sum (unstake frozen deposit for delegate_of_interest)
iterate on receipts_of_block(block_min) until spend(operation_hash)
update balances of delegators
delegate changes
Hope it helps, do not hesitate to ask for questions, we will do our best but can only answer asynchronously.
It’s important to understand that there is no longer such a protocol rule that tells you how to fairly split delegated balance.
A very simple example, let’s say you have two delegators: A (with 100tez) and B (with 100tez), so your delegated balance is 200tez. Then A spends 50 tez, so your delegated balance is now 150tez. Then A receives 50tez and B spends 50tez, so your delegated balance is the same - 150tez. So, the protocol absolutely doesn’t care whether 150tez is 50 from A + 100 from B, or 100 from A + 50 from B. The only thing the protocol use is just the fact that the minimal value was 150tez. That’s it. And what to choose (50+100 or 100+50) is completely up to you, and, for example, if the delegator A asks you why you pay him for 50tez, instead of 100, you won’t be able to say “because of the protocol”, but just “because I decided so”
Don’t get me wrong, I completely for developing such the tool, it will definitely be more precise than end-of-cycle snapshots. Just want you to understand, that even then it will still be subjective
That makes complete sense.
I should have said “find a way to distribute as closely as possible what the protocol rewarded for that specific delegation minus the baker fees”.
That’s another discussion, but it would be very interesting to see different models emerge. For instance, I spoke with a baker who would like to reward his delegators with NFT utilities. Why not, as long as everything is transparent and the delegators are satisfied! That would even create new value.
Is there a way to get a full description of the issue somewhere it can be viewed and disseminated without having to have an account and login? Only the quoted tweet, which contains virtually no information about the issue, and none of the replies are visible otherwise.
This is a screenshot of roughly the same content as posted on our Telegram group. Please let me know if the image does not appear properly, I will send you the raw text outside this conversation.
