Extremely bad luck

The lottery hasn’t been favoring ADA4Profit – A4PEU [JUNO] recently. After a 100% epoch 221 we are thrown back by the results of epoch 222.

We are very disappointed by the assignment of zero slots during this epoch (222). We were just catching up on our stake pool performance.

Unfortunately there is not much we can do about indirect influence factors other than to accept the situation ‘as is’ and continue. The assignment of zero slots (or possibility to produce blocks) has nothing to do with our stake pool setup that could directly influence our stake pool performance.

Direct influence factors on a stake pool performance

Below are a few direct influence factors that could potentially have a negative impact on our stake pool performance.

1. Bad network connectivity, relay nodes that are not connected to the network (other public relay nodes)
2. Bad inter network connectivity. nodes that are not connected to the block producer
3. Downtime of the relay nodes, due to maintenance by us or the hosting service provider
4. Downtime of the block producer, due to maintenance by us or the hosting service provider
5. DDOS attacks, public known relay nodes are being flooded with requests
6. Hacking, someone is compromising the stake pool

Guarantee

We can guarantee you that none of the above direct influence factors were in play during epoch 222.

1. Our relay nodes were 100 % connected to the network, with a minimum of 20 public connections per relay node
2. Our relay nodes were 100% connected with the block producer
3. We have 4 public and 1 hidden relay node, although we upgraded our relay nodes to version 1.21.1, the downtime per relay node was very limited and we were always connected since upgrades are not executed simultaneously
4. Our block producer was only very shortly not connected due to the upgrade to 1.21.1, because of a hot standby this is only seconds since we are changing our DNS ip-address in such a scenario limiting our downtime to a minimum
5. We had no DDOS attacks on our public relay nodes, besides our hosting provider is delivering first level protection against DDOS attacks all our relay nodes were processing continuously transactions
6. Our stake pool was not compromised and was processing transactions during the whole epoch

Leader logs

Since shortly we are able to analyze the leader logs. From the leader logs we are able to detect the slot assignment for a stake pool during an epoch. We analyzed two epochs, epoch 221 (past epoch) and 222 (current epoch) to provide full transparency on the situation to our delegators.

First of all above the estimated amount of slots assigned (or blocks) we could produce in epoch 222. From the graph we can see that there is a 1.43% chance to produce zero blocks.

Below the outcome after analyzing the leader logs for epoch 221 (d=0.62) and 222 (d=0.60) and a fully decentralized Cardano Mainnet or d=0.00.

We can see from the images above that in epoch 221 we had over 100% luck and that in epoch 222 no slots were assigned to us by the protocol. In a situation of a decentralization of 100% or d=0.00 we would have been assigned with 8 slots. Expected slots (or blocks to produce) where min 4 with a decentralization of 40% or d=0.60. Due to the fact that the network still is not fully decentralized all the slots were overlapped by the 60% that is taken by IOG to support the further decentralization of the Cardano network.

We are on a regular basis communicating with other stake pool operators. Read below what our colleague stake pool operator from TITANstaking is saying about this situation.

cardano-leader-logs: Yesterday I talked to a SPO (pool has 8m ADA stake), who didn't see any block assignments for e222. Doing the calculation with d=0 revealed, that the pool had 8 slots, but all of them were overlayed by BFT node blocks. Exceptionally unlucky.

— TITANstaking 💪 (@titanstaking) October 12, 2020

Any stake pool could get zero slots assigned, unfortunately we are the unlucky one this time.

Getting no slots assigned could devastate a small stake pool when delegators decide to stake with another stake pool on basis of last epochs performance. This would be very short sighted since the protocol was developed so that stake pool performance should even out over time. We have trust in our delegators and are confident that they understand this and will continue supporting our stake pool with their stake.

We are looking forward for your support swallowing this bitter pill. In case you like to delegate with a transparent, informative and dedicated stake pool, consider us. We should have faced all possible bad luck by now and expect soon a few great epochs.

Thanks, Ron