Tezos Reward Distributor (TRD) v8.5 Delphi - Development Overview

We (TRD maintainers) would like to inform the community especially bakers about a new TRD release. There have been many changes in the development of the TRD since a grant was awarded by the @tezosfoundation in 2020. Many new features have been added and some are planned. It is gratifying that the open-source tool is being further developed by developers all over the world and that the compensation with Tez is done via a multi-sig wallet depending on the effort spent. There are plans to move it into a TreasuryDAO as soon as there is a stable release.

Here is an overview of the features for version 8.5:

Remove dependency from Tezos Client
This was probably the heaviest feature within 8.5. The purpose of the PR was to completely remove the dependency from the (OCaml) Tezos-Client. This has two reasons: First, the use of the Tezos-Client is linked with some unnecessary code/performance overhead. TRD now uses the standard RPC interface (HTTP) to retrieve status codes and content in JSON format directly from the Tezos Node. It is more stable, reliable, and also faster. However, we are still using the RPC interface of the Node which is not exceptionally well performant. As for the case of larger bakers where they have a lot of delegators, accelerating the queries would be helpful.

Second, dropping the Tezos-Client dependency will allow access for a larger target group. Users who would like to do payouts using Docker or Kiln will now have the ability to do it. The setup of the TRD will be easier since you need only one dependency that you can install directly without having to compile the entire Tezos source code.

Payouts to KT1 contracts with default entry points are now possible
It is now possible to send rewards to KT1 contracts with default entry points. The transaction costs are simulated and optimized individually for each contract. For security reasons, we introduced a hardcoded upper boundary which is set to 21000 mTez. Within the next release, fee limits will be revised and part of the baker configuration. TRD marks transactions as failed if it’s above the upper boundary. This lets the baker investigate the transaction individually and protects him from an attack vector that drains him with high fees from complex contracts. Those KT1 contracts with default entry points are currently used within StakerDAOs wrapped XTZ (wXTZ) and Kolibri (kUSD). Special thanks to @keefertaylor and @maht0rz for their valuable feedback. If a payout to a smart contract fails, please check if the smart contract has a default entry point. Sometimes the only solution is to redirect payments to the corresponding manager.

Individual Fees for Dexter LPs
In the previous release, we included support for Dexter. We encourage bakers to reach out to them to diversify the baker set, especially if a baker already uses TRD. Within 8.5 it is now also possible to set an individual reward split for the pool. However, please make sure to have a commercial license agreement with Blockwatch/tzstats because it is currently the only backend supporting Dexter LP payouts. We also opened an issue in the TzKT GitHub in November to provide another option.

Ideal Payout Rewards
This was a highly requested feature by a couple of bakers. There are now two options for calculating the total rewards “earned” by a baker at the end of each cycle: actual rewards and ideal rewards. If this parameter is missing in the config, actual rewards take effect (same behavior as TRD always has used). Ideal rewards are calculated using the number of baking rights granted at priority 0, plus the count of all endorsing slots. If a bake or endorsement is missed, rewards are calculated as if there was no miss. No additional block rewards or transaction fees are included in this method.

Additional features for the plugin system
We have introduced additional features for the plugin system. There are now specific admin messages including additional information (i.e. how many cycles the payout account holds sufficient funds). Those messages are considered irrelevant for the delegators.

Several bugs were fixed and minor improvements were made. You can find the list of merged pull requests here.

Have fun trying out!

Habanoz (TezosLand), @krixt (Baking Tacos), @jdsika (StakeNow), amzid (StakeNow), @dansan566 (StakeNow)


In addition to the post I would like to clarify on the versioning.

As the upgrade of the tezos protocol will follow a cadence of ~3-4months the TRD will follow this rythm.

A major version v8.0 is a “stability release” e.g. indicating the compatibility with the Delphi protocol. We normally do not introduce a large feature increase as the release should give the confidence in supporting a new protocol version.

The versions v8.1 (and e.g v8.6) are reserved for bug fixes in between and are not planned ahead.

The v8.5 (+0.5) version is introducing new features and the feedback of the community is crucial here. We introduce features according to the requirements given in the Github issues and the community can see the priorities and time of implementation by looking at the tags of the milestones.

If you have any questions contact our maintainer using the Github issues or the baking slack channel #trd