If you saw our earlier post where we performed an analysis on ROA (Return on Ada) for pools vs their active stake, you would have seen where we visualized what we called the ‘small pool tax’. This refers to the negative effect on returns that the 340 fixed fee per epoch disproportionately has on smaller pools vs larger ones.

Today we are implementing a fee change based on this analysis.

Effective immediately we are reducing our fee to 1% and will implement scheduled increases based on our achieved stake. See below for a more detailed explanation as to how this will work.

If you look at the chart below, it shows the theoretical ROA based on pool size, taking into account this 340 ADA fee.

As you can see, even at different fee structures, all small pools suffer from this penalty introduced by the 340 ADA fee, however the effect of this fee is greatly reduced as the pool gets larger, eventually flattening out and having a negligible effect as the pool approaches saturation.

In order to be fair to our delegators, and not penalize their ROA while we are still relatively small, we are implementing the schedule we proposed in an attempt to maintain a minimum (theoretical) ROA for our pool.  We specify theoretical, because luck is till a large factor while d is high, and the value of individual blocks is still high.

Below is our new fee schedule, implemented in epoch 216 (taking effect epoch 218)

Pool SizeFee
Pool size < 13M ADA1%
Pool size – 13M < 19M2%
Pool size – 19M < 23M3%
pool size – 23M +3.5%
Variable Fee Structure

Using this structure, we can significantly offset the tax imposed by the minimum fee and provide our delegators a much improved ROI while we are still relatively small. The theoretical ROA given the above schedule is illustrated below:

As you can see, once we reach 10M we will reach our minimum desired theoretical ROA, and we maintain this minimum until we reach 23M at which point our ROA will continue to trend upwards.

Let us know what you think of this change, we’ve already implemented this prior to the epoch change tomorrow.

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.


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.


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. 


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. 

September Updates


Rounding out August 2020

In August, we saw a lot of great progress. IOHK has been busy with improving stability and performance through updates to the node software (v1.19.0), as well as Daedalus. In addition, the team has been working tirelessly to get the exchanges up and running with the upgrade to Shelley. The only outlier at the moment is Bittrex, which was one of the first exchanges to list ADA and was running extremely outdated code.

Emurgo has released the new version of Yoroi, which now supports Shelley delegation, as well as Ledger and Trezor support. Yoroi mobile is also out, with Ledger support almost ready to go! 

It has been a tremendous month with a lot of action!


SEPTEMBER 2020 – What the team is working on


Partial delegation

This describes the ability to delegate to multiple pools from a single wallet. This capability will vastly simplify delegation in the future, while enabling people to more easily select exactly which pools they would like to support, and by how much.

Delegation portfolios – As mentioned in a previous post, IOHK is working on providing the ability to individuals to create groups of stake pools. This will be enabled by the partial delegation pool. People can then delegate to this group, similar to how mutual funds currently work. This is an exciting feature that many of us are eagerly looking forward to, as it will help to promote decentralization instead of encouraging people to only stake to the largest pools.



Presentation of stake pools

If you have been paying as much attention to pool rankings as we have, you would have seen pools soar and dive through the rankings. The ability to sort/rank pools by different criteria is somewhat limited right now. Addressing this will be a very welcome priority for the IOHK team for September. The idea is to improve the UX and allow people to rank pools based on different criteria. This is one of the updates we’re really looking forward to.

SMASH – the Stakepool Metadata Aggregation Server (not sure what the H is for…) is the service that Daedalus uses under the hood to aggregate all of the metadata about stake pools and present that information to end users. IOHK will be working on allowing more ability to customize the presentation and ranking so that people can view and rank pools the way they like


Ledger – the “Stake Pool Operator Update”

Vacuum Labs has submitted a proposal, which includes 1-to-many delegation from the ledger device, as well as a host of features aimed at Stake Pool Operators (SPOs) 

One of the primary features for SPOs will be the ability to store their pledge address keys offline in a Ledger device. This will greatly enhance the security of running a stake pool with a large pledge.

In addition, they are also looking into allowing KES proxy keys to be created / stored on the Ledger, but this is likely a future feature. We’ll keep you posted as we hear more.

As with most things, IOHK is moving things along in a timely fashion. They expect to work out the final details of the contract with Vacuum Labs and sign this week.



One of the biggest upcoming updates to Daedalus is the “Harware Center” which will enable staking from a hardware wallet (like Trezor or Ledger), similar to the capability currently offered by Yoroi and AdaLite.
Additionally, they eventually want to allow other hardware security devices such as YubiKeys to be used to enhance the Daedalus experience.


Multisig[nature] pledging

One of the more interesting updates coming up is the ability for people to contribute to the pledge of a stake pool from a multisig wallet, which alleviates some of the trust concerns with working with other parties. This will enable smaller pool operators to work together to create a larger pledge.


The “k” parameter

Ironically, centralization among several very large stake pools is emerging. The “k” parameter is intended to counteract this by limiting the rewards a stake pool can earn based on its size. This will encourage greater distribution to mid-sized and smaller pools. If a pool exceeds the size limit, it will not generate additional rewards for the incremental ADA. There is a big urge to increase “k” (thereby decreasing the pool size limit), from it’s current value of 150 sooner than later. 


The “d” parameter

Decentralization is the name of the game. Currently (as of epoch 215), 26% of the blocks produced are minted by stake pools. The network will continue to become more decentralized as “d” steadily decrements on autopilot.


New potential partner – Bison Trails

IOHK is in conversations with Bison Trails to implement staking as a service. Essentially this would make the management of staking much simpler. In addition, it would enable people to delegate directly from an exchange. It’s still early, but significant enough for Charles Hoskinson to mention.

There’s a lot going on. Technology and the community are evolving very quickly, giving us a shiny outlook in the months ahead. It’s astonishing to see the theories and discussions of the past few years finally become reality. There is greatness ahead.

Here’s the video where Charles gave his update:



“Become a stake pool portfolio manager.”

Currently, to delegate to a pool, you need to go into Daedalus (or Yoroi) and delegate an entire wallet to your pool of choice. This means, the entire contents of that wallet will be delegated.

If you want to delegate to multiple pools, you need to manually split to multiple wallets, move your ADA to those individual wallets, then delegate each to a different pool. This simplified approach that was taken to ensure Shelley could be released on time.

Most people are not going to do the split step, so they’ll likely delegate all of their ADA in  their wallet to one pool, which is tougher on smaller pools.

Delegation Portfolios

IOG is introducing one-to-many delegation. The concept is that you can create delegation portfolios in Daedalus which become user-created groups of pools. You can select your favourite ones, assign ratios to each pool (represented by tiles in Daedalus), creating a portfolio. The aim is to put that in a JSON file, which contains preferences of pools to amounts or percentages. You can delegate to that portfolio, and optionally export/share the portfolio, similar to how you might share a play list to a friend.


This opens the world up to curation of these portfolios (like a fund manager would), which can be “themed”. Examples are “small pool only” portfolio, or a “socially responsible” or “eco-friendly” portfolio, etc. 


Charles announced that Atlas – a next gen explorer – is coming out. It will include a portfolio explorer, which would aggregate metadata and portfolio descriptions, etc. This should help diversity in the ecosystem,  giving more exposure to smaller pools included in some of these portfolios. The most exciting part of this is that these lists/portfolios can be created and curated by the community.



IOG is working with a company called Vacuum Labs to enable the following functionality in offline devices Ledger and Trezor. Learn more about these devices if you are unfamiliar with them.

Update Ledger and Trezor

  1. One-to-many delegation as discussed above, except managed via an offline device
  2. Multi-signature pledge – many people can come together and create a pooled pledge governed by good access control, protecting participants
  3. KES (Key Evolving Signature) management – after a certain period, the key will evolve to a new key, increasing security. This will allow for further protection of private keys, as they will reside in an offline device, further reducing the opportunity for malicious attacks.

One of the absolute pleasures of participating in the Cardano community is the speed and effectiveness at which IOG and the greater community collaborate, producing tangible updates and results. These latest planned updates are a testament to that. 

See and hear the details directly from Charles Hoskinson:


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.


What we should expect
Managing expectations as we enter the exciting unknown will make for a great experience.


We are all quite excited as we come to the end of the first epoch since the launch of Shelley, and we’re all looking forward to that first allocation of rewards. After all, it’s one of the primary reasons we jumped on the opportunity to find a stake pool and delegate our ADA out of the gate. So, what should we expect?


Decentralization will take time. Slow and steady makes for a strong network.


The first thing we need to be aware of is the d parameter. The d parameter represents the proportion of the block that is generated by stake pools, like Cardano Canucks. Currently, the network is supported by IOHK (i.e., it is centralized with IOHK). The goal is to decentralize the network, so that it is supported by stake pool operators. We started with d=1 (fully centralized with IOHK), and over time, d will be reduced to 0, at which point the network will be fully decentralized across the stake pools.

What’s the timing?

The rate at which we move from phase 0 through phase 3 has been a topic of considerable discussion over the last few days. The IOHK team will create and set a parameter called alpha (α), which represents the rate of decay of the d parameter. The example given by Charles Hoskinson is if they set α=0.025, it will take about 200 days to get to d=0, or end of Phase 1. The idea is that every epoch will decrement d by a minimum of α , so it’s possible that it’ll be faster, but likely they’ll keep the pace. Charles also introduced a notion of network health. The overall rationale is that they’ll monitor the network health at each epoch and reduce d by α to ensure the network is stable and there are no issues. If an issue occurs, they may stay at the same d value for a couple of epochs.

The  IOHK team will announce the  α value in a blog post scheduled for August 14th. We’ll definitely let everyone know the  outcome via our social channels, with a follow-up via email. In addition, we should expect d to remain at 1 for at least the next epoch. Part of this is because a bug that has been identified related to how some exchanges are using the Cardano APIs, delaying the ability for people to retrieve their ADA from those exchanges. Also, 1/3 of stake pools did not appear in the Daedalus wallet until a patch was released (2.0.1) several days after the Shelley launch. So, to resolve those issues and ensure that everyone has a fair chance to delegate their ADA, they’ve decided to wait one more  epoch.

Charles also mentions that the d parameter doesn’t substantively impact profits of staking. It shouldn’t matter if d=0.9 or d=0.



This is what we should expect:

  1. Decentralization will take time for a strong, stable network
  2. Starting decentralization (lowering the d parameter) won’t happen until one more epoch (the week after next)
  3. The d parameter doesn’t substantively impact payout of rewards

This is all by design, and the whole world is experiencing this for the first time. We’re all in this together and the best we can do is disseminate information as we receive it, as we did during theShelley launch.

All of this information is based on the talk that Charles Hoskinson gave yesterday:

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.

Finding That Balance

Exciting times – Cardano switched over to Shelley yesterday and within seconds, people were downloading and syncing their wallets to move their ADA over. Within minutes, staking pool operators were registering and making the pools available for us to delegate to.


This is an unprecedented event, bringing us one step closer to the vision of a truly decentralized value network upon which many projects will be based in the near future. Everyone involved is very excited about the possibilities, and involved because of the shared vision of a better global future. On the flip side, this is new to everyone making it very difficult to know what to expect.

One of the difficult decisions for staking pool operators is how to set the margin. Like most tough decisions, there’s no right answer and there are counter-balancing factors.

Similar to any other industry, pricing is often driven by the market and competitors. If everyone else is selling the same product as you, then the further beyond the average market price you set your product, the fewer customers you will have. There is complexity around marketing and brand affinity, but for the purposes of this case, the pressure of “everyone else’s price” will have a considerable impact on your price.

In this particular case, If the vast majority of staking pools set their margin at 8%, then you need to set your margin at the same or below or you will have much fewer people staking to your pool. The problem with that is that a staking pool will be assigned blocks if they have enough ADA staked to them. So, to be a staking pool that will be valuable to those who staked to it, we need to have enough people staking.

On the other side of the coin, the whole purpose of the margin is to provide a way for pool operators to cover the cost of running the pool. The tough part of that is at the moment is no one really knows how much it will cost to run the pool, let alone tune it for performance. Once the operators start optimizing the performance of their respective pools, they’ll have a better idea of the longer term cost of running the pool.

Here’s a video that touches on the subject (about the 5min mark):

We are anticipating that it will be beyond the 3%-5% margin that we are currently seeing among different pools. As a result, we will likely see low margins as pools are trying to set up a base of people to delegate their ADA to their pool. Then we’ll see an increase in the margins as pool operators get a better handle on the actual operating costs.

The key will be transparency and understanding around operating costs and how it relates to the margin. We endeavour to maintain this transparency throughout this wild journey, and be available to learn, and share what we learn as we go. This is a great community, and we’re confident that we can sort through these things together as we make the stability of the mainnet a reality.

“It’s confirmed: Shelley arrives 29th of July at 21:44:51 UTC. “

We are on the precipice of a new world in which technology can deliver on the vision and possibilities of cryptocurrency on a whole. 

IOHK_Tim created a comprehensive post to cover all of the basics and answer questions that many of the community have. We’ll try to cover the most important information here.

First of all, let’s talk about what’s happening tomorrow. Tomorrow, there will be a hard fork, which is the release of a major upgrade to Cardano. 

This upgrade is called Shelley, which includes a new architecture along  with new functionality and features. Immediately after the hard fork, we will be in the new world where the Cardano mainnet will be running Shelley.

Rest assured, if you hold ADA, you don’t need to do anything and it’ll be safe in your wallet or on your exchange. If your ADA is in a Daedalus wallet, you’ll be guided to move your ADA to a new version of the wallet once the Shelley mainnet is live. Throughout this process, it’s a good idea to stay connected via Twitter and Cardano.org

Also, come back here and we’ll be providing information as we learn it.

Probably the most important part of IOHK_Tim‘s post was the inclusion of the Delegation Cycle. The question everyone has been asking is “when can I delegate?”, and the question we all want to ask is “when will we see the first rewards?”. Knowing this, the Cardano team has done a great job of showing us the timelines in which everything will be happening.

Here are the main points:

  • Delegation can start in Epoch 0, right after the switch-over to Shelley – Aug 29th
  • A snapshot will be taken at the beginning of Epoch 1 – the first one on Aug 3rd
  • During Epoch 2, the delegation that was done in  Epoch 0 will be active – Aug 8th – 13th
  • During Epoch 3, the rewards will be calculated – Aug 14th – 18th
  • At the beginning of Epoch 4, the rewards will be distributed  – Aug 18th

Cardano Canucks will be switching over to Shelley as early as we can to ensure people have the earliest opportunity to delegate and be eligible for rewards.

Pretty exciting stuff.