Today CANUK is joining a small group of other stake pools who are utilizing the metadata feature of Cardano to implement first generation oracles on the Cardano blockchain!

You may be asking, “What the hell is an oracle and why do I care?”

Oracles are a way of getting real world data onto the blockchain for use by smart contracts or other utilities which run on top of the blockchain. A fundamental problem with smart contracts is that they are only aware of data existing on the blockchain, and have no knowledge of real world events. Oracles are ways of bridging this gap between the blockchain and the real world by providing a mechanism for real world data to be made available on the blockchain.

The simplest example of why this would be important is a DeFi application which needs to send a particular amount of value measured in fiat currency to another party. Utilizing an oracle, the smart contract could determine the current exchange rate for the cryptocurrency, and calculate how many tokens it needs to send to the other party to add up to the appropriate amount in fiat. Another example would be loan contracts, where someone uses a cryptocurrency asset as collateral, which gets liquidated if the value of the collateral asset dips below a certain amount. This means that oracles are a fundamental building block of a financial operating system, which is why projects such as Chainlink have done so well in the Ethereum ecosystem.

There has been a lot of progress in the oracle front within the Cardano ecosystem, including a partnership with Wolfram Blockchain Labs to provide oracle data, as well as excellent research by Emergo into Oracle Pools, which is a fundamentally different way of implementing oracles which leverages the unique properties of extended UTXO (EUTXO) blockchains.

Since the Canucks love data, and were also in need of ADACAD for our own financial reporting purposes, we decided to join an initiative started by Marek at Stake Nuts Pool to implement a first generation oracle on the Cardano blockchain by sourcing open data and posting it via metadata transactions onto the Cardano Blockchain. You can read more about the technicals of how we’re posting data in the the original post at We’ve added data for ADACAD and BTCCAD to this list.

Currently we’re funding the transaction fees for this oracle. If you would like to feed the oracle, you can send some lovelaces to our oracle address to keep it running!


You can see this data on the blockchain now through a transaction explorer here, or access it directly via the blockchain though a db-sync instance by querying the metadata transactions for key=1968. We’ll update our github repository of db-sync queries to include oracle queries shortly for folks who might find this data useful.

Thank you, and keep building!

Update – 2020-10-28

We’ve had a few great epochs and have already hit the first milestone referenced below for our tiered fee structure. This happened significantly quicker than we were anticipating!

Given the speed we got here, and the rapidly changing environment, we thought it prudent to do some further analysis around the current fee landscape before making any changes.

While we are performing this new analysis we will not implement any fee changes, as always we want to be fair to our delegators and provide transparency and plenty of notice before performing any updates.

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.

CANUK has implemented a tiered fee structure based on this analysis.

Effective as of epoch 218, we reduced our fee to 1% and implemented 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 our analysis, 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, at 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 believe this schedule provides the most fairness to delegators, and also allows us a pool operators to be fairly compensated without penalizing delegators during the bootstrap phase.

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 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 – 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 – 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. 


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.