ELAnodes Voter Rewards Metrics : An Introduction and Overview
Voter rewards tracking is now live on ELAnodes.com. There are two separate metrics supplied for each supernode: (1) the actual percentage of the supernode’s income that is paid out to voters, and (2) the projected annual return on investment (ROI) for voters. The reason behind separate metrics is not punish nodes for earning less. For instance, a supernode giving out 80% can easily produce a lower ROI than a higher ranked node giving away 50%. In this article, we will provide an explanation about how we’re calculating these values, the variables we’ve accounted for, and outline any potential sources of error.
Before we begin, a quick disclaimer. The Starfish team developed these metrics because we felt that a universal metric was important for transparency. In our opinion, supernodes should be not focused on the pursuit of personal profits, so empowering voters to see exactly how funds are being dispersed is an important piece of the puzzle to creating a healthy delegated-proof-of-stake ecosystem. However, we encourage voters to not vote based on rewards alone. The reality is that DPoS profits are a drop in the bucket if Elastos achieves its vision. Accordingly, it behooves us to support the organizations that are building and working toward making Elastos stronger. Voter incentives are vital to establishing a thriving community, but ultimately, profits for the community doesn’t directly benefit Elastos, whereas funds allocated for development, strategic marketing or onboarding just might. Please consider this when casting your votes.
What’s the problem?
We decided to only track voting wallets. We do not attempt to track producer addresses as there simply too many payout methods and practices to have any confidence in the results. For example, a supernode might send some of their income to an expense wallet, some to team members, and the rest to voters. But there is no reliable way for us to know which is which. Accordingly, tracking how much the voters actually earn is the only realistic solution.
In other words, the data we’re collecting to produce these metrics is calculated only from payments received by voting wallets. It is not based on what any particular node said they would pay, but what they are actually paying. For instance, if a supernode claimed that they would reward 80% of their income to voters after expenses, and their expenses total ~20% of their income, the metric will display ~64%, not 80%.
That said, identifying which payment came from which node in a wallet voting for 36 supernodes is a logistical nightmare and could easily break if a payout address were to change. Therefore, it is our opinion that the only way to guarantee that a node is paying (or not) is to use a wallet that votes for a single supernode. That way we can say with a high degree of confidence that all payments received by the voter originate from a specific node. In response, over a month ago, we spun up 90+ wallets with various balances, voted for each supernode individually, and developed scripts that retrieve transaction histories for each address and convert the data into universal metrics that can be compared against each other.
How are the metrics calculated?
The main script is about 600 lines of Javascript written in NodeJS and is executed every few minutes to retrieve real time data and pipe it into ELAnodes.com. There are three possible conditions the script handles for wallet histories depending on the frequency of payout transactions that occurred.
Condition 1: No payments are received from the supernode for the last 30 days. This is a termination condition. It is assumed that the supernode does not pay any rewards, regardless of their prior history.
Condition 2: If a supernode passes condition 1, and two or less payments are received from the supernode in the two weeks prior to their most recent transaction, the metrics are calculated based on the time elapsed between their most recent payment and the one prior to that using the following formulas:
Annual ROI = [Value of the most recent payment]*[Projected number of payout intervals annually]/[Balance of the voting wallet]
The number of payout intervals are approximated by taking the time elapsed between the two most recent transactions and calculating the number of payments the voting address should receive over the course of a year. The equation above produces a value that represents the amount of ELA a voter would earn by voting for a specific supernode with 1 ELA for a year. For example, a supernode with an ROI of 0.3% would reward 3 ELA per year to a voter with 1000 ELA.
Real Payout Percentage =[Value of the most recent payment]*[Average number of votes for the supernode between the last two payments]/[Sum of minted coins awarded to the supernode between the last two payments]/[Balance of the voting wallet]
This formula outputs the amount of ELA rewarded to voters for each ELA earned. As a simple example, a supernode that pays out 0.7 ELA to its voters for each 1 ELA they earn would show up on ELAnodes as rewarding 70%.
One thing worth noting is that calculating the metrics in this manner keeps the data as current as possible. If a supernode rewards plan changes, or their income changes as a result of their rank, the metrics will update to the new circumstances as soon as a new payment is received. As a result, historical payouts are not factored in and the metrics reflect what a voter will earn right now. This has the added benefit of not positively weighting a node that previously rewarded a higher percentage, or negatively weighting a node that previously rewarded a lower percentage.
However, we discovered that this solution doesn’t cover all the payout circumstances. If a node does not pay out on a reguarly timed interval, or has more than one payout schedule (i.e. ELAlliance nodes), this will not produce an accurate metric, which leads us to the final condition.
Condition 3: If a supernode passes condition 1, and three or more payments are received from the supernode in the two weeks prior to their most recent transaction, the metrics are calculated based on a two week rolling average. This condition sums all the transactions received in the two week window time window using similar formula:
Annual ROI = [Sum of payments received within the two week window]*[Projected number of payout intervals annually]/[Balance of the voting wallet]
Real Payout Percentage =[Sum of payments received within the two week window]*[Average number of votes for the supernode in the two week window]/[Sum of minted coins awarded to the supernode in the two week window]/[Balance of the voting wallet]
How accurate are the metrics?
One problem we encountered in the testing of this methodology was that if a node changed state (Active/Inactive) or their vote totals fluctuated significantly, the metric would not be able to properly account for the new conditions.
The solution to fixing this was to base our earnings and vote total tracking on historical data as opposed to live data. The script sends out API requests and grabs information from the supernode receiving address to identify exactly how much a supernode was awarded with minted coins for a given period in 72 minute intervals. This way the metrics are invariant to changes in ranks and projected earnings. As an added benefit, nodes can even go offline for a while and the metrics will still report accurately assuming any payments were received within the last month.
Additionally, the script pulls historical voting data based on API requests for the block height of the transactions at the beginning and end of our tracking windows and averages them together. Vote totals are important to calculate the total percentage of earnings that are paid out to voters, so in this manner we are able to reduce the impact of large swings in vote totals.
All combined, the metrics appear to be accurate to within about 3%. Fees are source of error, though minor. We think this is exceptional considering all the factors in the play. Implementing a tool like this was much more complicated than we originally envisioned.
Is there any concern about bad actors trying to manipulate the metrics?
If payout intervals are irregular or any attempt is made to artificially inflate a payout metric by identifying our wallet and sending ELA to it that is not part of a regular voter payout, our scripts have filtering built in to flag the inconsistency and either ignore those transactions or return an error. If we discover any intentional manipulation like this, the node will be flagged as dishonest.
It’s also entirely possible that something occurs that we haven’t considered. Keep in mind that the same methodology is being used for all 96 supernodes. We have no direct control over the data produced. It’s 100% automated and governed by the logic within our script. If you notice any results that might not be correct, please let us know through Telegram, Twitter, or E-mail and we’ll investigate.
Final Thoughts
An important point is that the metrics do not account for any ELA distribution besides direct voter payouts. The Starfish monthly lottery is a good example. Since the lottery winnings are awarded to a just a single address, it is not included in the payout statistics. The ELAlliance 24-supernode voting bonus is another example. Nodes are tracked independently and on their own merits. Similarly, funds designated for development, marketing, or community building are not traceable. Please keep these points in mind when you vote!
We hope that these metrics provide some value to the community and make it easier for voters to decide which organizations are worthy of their vote. Enjoy!
Thanks for reading,
The Starfish Team
