Behind the scenes of RadixScan 
In this section we would like to describe the setup, and structure of RadixScan for those who are interested.
Web and Data:
Hosting / Server location:
The site is hosted at netcup, netcup is a German datacenter operator and hoster. One of our backup nodes, the full node and gateway server are also located there. RadixScan can be reached via the following domains: RadixScan.io, .com and .de. The .com domain was kindly given to us by Wylie from Radnode.io (see Acknowledgements ). Included in the hosting package is also a MySql database, which we use to store the various logged data and a cache.Data retrieval:
On our full node, various Python scripts are executed which read the current data from the local ledger file, the ledger and from CoinGecko and store it into the database. To improve the speed of the page the validator data is cached. The maximum time in the cache is 120 seconds. On the full node a script is executed which refreshes the data every 60 seconds, so the data should always be more up-to-date than one minute. The dashboard data is retrieved every 20 seconds and stored in the database.Calculations:
View:
Per epoch there are 10,000 views on the ledger, the percentage progress is calculated as View / 100.StakeTop100:
For each new epoch, the top 100 validators by stake are selected for consensus and receive distributions corresponding to the participation in the consensus (Proposals). The possible participation in the consensus is proportional to the stake of the validator. During the distribution missed proposals are deducted. The payout is reduced in the range from 100% of the possible proposals up to 98%. The maximum payout occurs when all possible proposals have been made, at a value of 98% or less no payout occurs. The StakeTop100 value shows how many of the staked XRD are involved in the consensus via the Top100 validators.APY:
Per year about 300MXRD are distributed to the validators. To estimate the possible APY, the 300MXRD are put in relation to the XRD accumulated in the Top100. The actual number depends on the duration of each epoch. If the epoch duration is shorter than the theoretical value, more XRD are distributed per year, which increases the APY. If the epoch duration is longer, this results in a reduction of the distribution. Not included in the value are deductions for missed proposals and validator fees. The APY value fluctuates over time, if more XRD are staked the value decreases, if XRD are unstaked it increases.Nominal fee:
The nominal fee indicates which share of the staking rewards will go to the validator.Example: With an APY of 10% and a validator fee of 1%, the APY of the staker is 9.9% (NOT 9%).
Effective fee:
The effective fees indicate how high the fees are for the staker when staking with this validator. They are calculated as the product of the nominal fees and the APY last 30 days.Effective fee = Nominal fee * APY last 30 days
"NA": If the value "NA" is displayed, the effective fee cannot be calculated, e.g. because the validator does not allow external stakes or has not been active for more than 30 days.
APY last 30 days:
As soon as a validator has allowed stake, we have staked 100XRD. We record the value of this stake once at the beginning of a new epoch in the database. From the ratio value 30 days ago to current value we calculate the APY.APY = 100* ((ValueNow - ValueOld)/ValueOld * 365.25 * 24 * 3600) / (TimestampNow - TimestampOld)
ValueOld is the value 30 days ago, ValueNow the current value and analogously the timestamps
In the value calculated in this way, all penalties due to missed epochs etc. are taken into account since the values are read directly from the ledger.
"NA": If the value "NA" is displayed, the APY cannot be calculated, e.g. because the validator does not allow external stakes or has not been active for more than 30 days.
Uptime value:
Currently (before the Xi'an network update) the proposals are only created by the top 100 validators by stake. The network determines the uptime as the ratio between made and assigned proposals. If no proposals were assigned to the validator because it did not make it into the top 100 by stake, the value 0 is displayed (the calculation is done over 150 epochs).A value of 0 does not mean that this validator is not reliable! Please also include this validators in your staking decision to achieve an as equal as possible stake distribution.
Initial stake:
For the Initial stake value, all stake transactions are added and the unstake transactions are subtracted for each validator in ascending order. A negative intermediate value is set to 0 (Stake 100 ; Unstake 104 (Stake + Reward) -> =0 ; Stake 50 ; results in a value of 50). The interpretation is like an account: Deposit, interest is paid and after everything is withdrawn the balance is zero. A negative balance would mean that something is owed to the bank.Transaction size on Ledger:
The size of the transactions on the ledger is calculated based on the fee for the transaction. The fee consists of the base fee and an amount per byte. The following table shows the base fees on the ledger for the different transactions (sending tokens has no base fee):| Fee type | Fee amount |
|---|---|
| Overall transaction size (including messages) | 0.0002 XRD per byte |
| Stake tokens to a validator | 0.5 XRD per stake action |
| Unstake tokens from a validator | 0.5 XRD per unstake action |
| Register a validator node to the network | 5 XRD per registration action |
| Update a validator node’s metadata | 5 XRD per item of metadata updated |
| Create a new token type with its own symbol , name, and supply |
100 XRD per token type creation |