It’s only been a few Epochs since Stake Pools started making blocks, but already the rewards are flowing! Some pools have risen to the top and attracted a lot of stake, while others are struggling to attract enough delegators to make blocks.

Introduction

We wanted to take some time today to look at ROA  (Return of ADA) across pools, particularly how it’s effected by the size of the pool, and what we as pool operators can do to ensure that our delegators are receiving the maximum returns. Our hope is that delegators can consume this information to gain a deeper understanding of  how their rewards will be affected by which pool they choose to stake with. We will also go over a change we will be making to our business model to help overcome the ‘small pool tax’ which they incur when delegating with a pool which is smaller than 10M ADA – see below for more details.

Note that the visualizations below are best viewed in desktop for maximum interactivity.

Executive Summary

At the current level of ‘d’, the variability in ROA across pools due to luck is very large, particularly in the smaller size range. Because of this, we looked at the theoretical ROA based on pool size and visualized the ‘small pool tax’ which is a result of the fixed fee making a larger percentage of the fees charged to delegators staking with smaller pools.

Using this, we created a variable fee schedule for our delegators in order to target a minimum acceptable ROA for our pool. This way we hope to be fair to our delegators by providing them a good ROA, while also providing us as pool operators a roadmap to achieving enough margin to pay for expenses, and be compensated for our time in a predictable and transparent manner.

Please note that this analysis is based on the information we have as of the date of writing this article. Things are changing very quickly and with every new piece of data, and every new release/change to Cardano, we’ll be reassessing our position and adjusting accordingly. As always, we’ll be sharing what we find as we go.

The fee schedule is as follows:

• At pool size < 13M – 1%
• When pool size reaches 13M – 2%
• When pool size reaches 19M – 3%
• When pool size reaches 23M – 3.5%

Refer to the analysis below to see how we reached this schedule.

Analysis

The main data source for this was adapools.org which provides pool data in a json format for analysis. The data in this analysis has been updated as of 2020-09-09. We also constructed a theoretical dataset in order to model some scenarios and come up with thresholds.

For this analysis, we need to determine what is the maximum expected ROA for a pool performing well with a high level of stake. For this looked to two areas:

First, the staking calculator  on cardano.org – this tells us if we delegate to a saturated pool charging 0% Fee – we should see an annual ROA of 5.31%

Second, we looked at what the data tells us – specifically we looked at the actual 6 epoch average ROA from adapools.org – take a look at the viz below which is showing ROA vs Active Stake. The colors indicate the fees for the pool, red indicating high fees. Feel free to hover over a circle for details on the pool.

As you can see, on the lower end of the active stake, the variation is extremely high – which is to be expected given that with lower stake pools, there is a lower number of expected blocks. This means that a lucky streak could result in an extremely high ROA. What is more surprising is that there is still a reasonable variability in the higher ranges of stake. Given that the ‘d’ parameter is still fairly high, this translates to a large value per block created. This means that a variation in a single block produced by a small pool can create an extremely high swing in ROA. Takeaway: luck is a big factor right now.

In order to get a cleaner view, we created a normalized metric which removes the variability caused by the stake pool fee, and also removed pools which produced less than 8 blocks. See below for the normalized view:

What we can also see, is that if we attempt to plot a line to represent the average normalized ROA without fees, it looks to be higher than the theoretical maximum from the calculator of 5.31%, and is closer to 5.6%. We will use this as the theoretical maximum number in our calculations below.

Calculating Theoretical ROA

When determining the ROA of a pool, 3 factors come into play:

1. The Fixed Fee of the pool (currently set to a minimum or 340 ADA)
2. the Variable Pool Fees, which tend to range from 1%-5%
3. The size of the pool itself

Below, we plot theoretical ROA vs Pool Size. The individual lines represent different variable fee structures for the pool. What you can see from the plot below, is that the fixed fee has a much larger impact on pools with smaller stake, meaning the theoretical ROA for smaller pools will tend to be lower.

From this, we determined, what should our target minimum ROA be for our delegators. We looked at the limit of the 5% curve, which would approximate theoretical rewards which delegators to a large popular pool  such as  ‘BLOOM’ would get. BLOOM is a popular pool run by @bigpey.

This sets our minimum desired ROA to be in the neighborhood of 5.3%.

Using this minimum as a parameter, we can zoom in to see what this looks like in the range of smaller stake pools for different fee structures:

What we can see from this, is there are some inflection points where this minimum desired ROA can be reached at different Fee structures. 

Our goal from this analysis was to determine, what is the required variable fee that we would need to set, in order to achieve the minimum desired ROA for our delegators. 

To do this, we treated the ROA as a constant, and calculated the variable fee required to reach it. We plotted this variable fee vs pool size. The graph below illustrates this.

The red line is the true variable theoretical ROA line, (which starts at a negative number), the blue line is uses a minimum and maximum fee as limits.

Finally, graphed the ROA if we were to step the fee at our inflection points to always maintain our minimum ROA.

The actual theoretical ROA for our delegators would look like the following as the size of the pool grows. 

Conclusion

Based on this, we believe we should consider a fee schedule which encourages delegation by attempting to minimize the impact of what I’ll call the ‘Small Pool Penalty’ by lowering our fee until certain thresholds are met, thereby giving our delegators maximum return.

By raising our fee as we reach certain milestones, our delegators are still making a high return and not being penalized for choosing to stake to smaller pool, however our pool is still getting compensated for our efforts once we reach our milestones. 

This schedule would look like the following:

• At pool size < 13M – 1%
• When pool size reaches 13M – 2%
• When pool size reaches 19M – 3%
• When pool size reaches 23M – 3.5% – which is our current desired fee structure to cover our costs and provide enough profit to be viable

At Cardano Canucks, we approach running our stake pool as a business, and don’t believe in the race to the bottom which would result in everyone lowering their fees to zero. We love what we do, but if you want a strong stable ecosystem, you need to have competent operators running the network, that are compensated for the many hours they put in.

Let us know what you think. Should we implement a tiered fee structure which slowly goes up as we hit certain milestones? 

Feel free to reach out to us on our social channels, or join our Telegram Group for a realtime chat. 

As we count down to the first block producing epoch, Cardano Canucks has been working hard behind the scenes to ensure that our pool is ready to provide our delegators with the most reliable performance and security.

Included in our site is an architecture page which should answer most high level questions about our architecture, however we have made some recent updates to the architecture to improve two main areas – uptime / reliability and security.

The updates are focused around 2 main areas, availability (up-time) and security. In this blog we will focus on the availability updates.

As for security, we were already following security best practices and had a system to be proud of, however in light of the recent hack into the HAPPY pool where the pool operators node was hacked and pledge stolen, we have further hardened our infrastructure to ensure our pledge is safe, and our delegators rewards are un-interrupted.

Availability Updates

The CANUK pool runs 4 relays and 2 producer nodes in order to maintain maximum uptime. Should up to three of our relays fail, our producer will still be communicating to the network and be able to produce blocks. If our primary producer should fail, we are able to promote the standby leader to be a producing node within minutes of the primary failing.

The existing architecture would ensure high availability should any of the  nodes fail, however it did not take into account the possibility of a data center failure – so we’ve updated our architecture to account for that.

For people not familiar with AWS, their infrastructure is divided into Regions and Availability Zones. AWS maintains multiple geographic Regions, including Regions in North America, South America, Europe, China, Asia Pacific, South Africa, and the Middle East. Within these regions they maintain separate “Availability Zones” which are physically separated data centers within a region.

For philosophical reasons, we choose to keep all of our nodes within the Canadian Region, which is located in and around Montreal Quebec. This region has 3 separate availability zones, which are geographically distributed to ensure that unforseen events which take down a single data center (i.e. cut cables, flooding etc.) will not effect the other data centers. 

To take advantage of this, the CANUK pool architecture has been modified as per the following diagram:

As you can see from the diagram above, our infrastructure is now spread among the three availability zones within the Canadian region. Should any of the availability zones go down from a network issue or datacenter problem, the remaining infrastructure will still stay up and available. 

Availability Zone A contains two relays and our main producer node. If the other two availability zones should fail, our pool will still be operational with no intervention on our part.

Availability Zone B contains our backup producer, a single relay as well as our monitor node which collects metrics and serves up dashboards for our technical team. Should Zone A fail, the producer in this zone would be promoted to our primary producer node and uptime could be re-established within minutes of receiving an alert. Should zones A and D fail we would need to spin up a new management subnet within this zone in order to deploy our changes, however due to our automation processed this would be able to be accomplished quite rapidly.

Availability Zone D (yes… not C) contains a single relay, as well as our management server which provides secure connectivity to the rest of the nodes. If zones A and B were to both fail, we would be required to to spin up a new producer node and sync it with the network prior to coming back online, however with our infrastructure automation and frequent snapshots of our synced notes this is also achievable quite quickly.

That concludes are architecture updates. At the time of writing we are coming up quickly to the switch to epoch 211 which will be the first epoch which stake pool operators are creating blocks.

As always if you have any questions, always feel free to reach out to us via Telegram, Twitter or Email.

It’s been an epic (epoch?) five days for the Cardano ecosystem! The Shelley hardfork went off without a hitch, and with that, the project has transitioned from a centralized federated network to a decentralized open one where every ADA holder has a stake in the success of the system!

Below are some of the highlights over the first epoch of the Shelley era.

For Cardano:

• The Shelley hard fork occurred at 5:46 EST on July 29!
• Stake pools started registering immediately after the fork
• A new version of Daedalus was released with full Shelley functionality which allows staking to stake pools
• 747 (and counting) stake pools registered on the Cardano blockchain
• Almost 5.17 B ADA staked so far(and counting)

For the Cardano Canucks:

• Registered our pool on the mainnet – we were one of the first 25 pools to appear in Daedalus
• Moved our ADA out of cold storage and funded our pledge address
• Performed security scans on our two AWS accounts and remediated all high and medium priority items
• Developed CloudWatch alerts to monitor underlying virtual machine performance
• Updated our Grafana dashboards for mainnet to monitor our stake pool nodes

The next few epochs will also be exciting! This is what you can expect from the Cardano Community:

• During the month of August, IOHK will be focused on optimizations and fixes as well as some well deserved rest
• Exchanges which have frozen ADA wallets to upgrade infrastructure will start coming back online
• The Yoroi wallet will come back online and support staking soon
• Ledger and Trezor hardware wallets will start supporting delegation
• Expect more stake pools to come online

What are we planning for the next month?

• Continued monitoring and optimization of our stake pool to ensure we achieve maximum uptime and performance
• Marketing planning to ensure we are attracting delegators
• Continued communications with our delegators and community
• Public facing Grafana dashboards for our delegators

Finally, what we are going to see over the next few months is a gradual lowering of the decentralization (‘d’) parameter, which controls the percentage of blocks which are created by pools vs the federated nodes run by IOHK, Emergo and the Cardano Foundation. What this means for stakers is that for the first several epochs, rewards will be lower until the fully decentralized state is reached. You can keep an eye on the status of the d parameter in Daedalus via the Info tab of the staking center.