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 https://nut.link. 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.
A question we often get is, “what do I need to think about when choosing a pool?”. As part of that discussion, margin always comes up. If you look at adapools.org or pooltool.io, you can quickly see that margins range from 0% as high as 10%+. What is not well understood is how this number actually impacts rewards for you, the delegator.
One of the reasons that many pools set their margin to 0% or 1% is simply to attract delegators. On the surface it appears that a 1% or 0% pool is very favorable for a delegator. However, this may not be the whole story. If it were, then everyone would be at 1% and there would be a race to the bottom.
The Math
Here we’ll illustrate how the margin actually affects your rewards. Since we are focusing on margin, we will use a simple assumption of 5.5% total annual ROA for a pool. For a detailed analysis of the rewards equation see here.
In our example, we’re using a total stake of 40M ADA and an average ROA (return on ADA) of 5.5%. Also, we’ve set the fixed fee to the minimum of 340 ADA per epoch. Here you can see the Margin set to 1%, 2% and 3%. For a 1% pool, the net rewards (i.e., the rewards to you, the delegator), is approximately 5.384% of your delegation. For a 2% pool, that number is about 5.329%, and for a 3% pool, it is about 5.275%. As you can see, the difference between a 1% and 2% pool is actually only about 0.05% difference in rewards to the delegator. Similarly, the difference between a 1% and 3% pool is actually only about 0.1% difference in rewards to the delegator.
The So What
As you can see, a change in margin translates to a very small impact to the delegator, but enables the pool operator to invest in infrastructure, security and the ability to support its delegators. In fact, a very low margin pool is likely either subsidizing their costs through alternate income, or simply putting the bare minimum time and effort in managing their pool. There is nothing wrong with these cases, but it may influence the way delegators choose their pools.
With the launch of Shelley, IOHK introduced the notion of the “k” parameter. We mentioned it briefly in our September update. We described it as way of limiting the rewards a stake pool can earn based on its size. The intention of increasing key is to encourage decentralization of the network. If a pool exceeds the size limit, it will not generate additional rewards for the incremental ADA.
On December 6, 2020, k will be set to 500 and the new saturation point for a stake pool will be around 64M ADA. When a pool exceeds 64M ADA, the rewards per delegator will be reduced. The number 500 means that the network will be optimized for approximately 500 stake pools. The plan is for an increase of k to 1000 in March 2021.
As a delegator, you will want to ensure you are in a pool that is does not have 64M ADA or more to gain full benefit from your staked ADA.
This will result in a lot of movement from the pools that currently have more than 64M ADA to mid-sized or smaller pools. This is great news for smaller pool operators and the network as a whole. It will certainly encourage a better distribution of ADA, and allow the smaller pools to more consistently received and mint blocks. When k goes to 1000 in March, the upper limit will again be decreased to about 32M before rewards are reduced.
What CANUK is planning
Cardano Canucks have been looking at our long-term business plan, which includes considerations for “k” going to 1000 in March. At that time the saturation point will be 32M ADA. In order to build a sustainable operation, we believe that increasing our pool count to 3 will provide us enough capacity to continue building our community and contributing to the Cardano ecosystem, while not negatively affecting decentralization by creating too many pools. We will not be splitting our pledge, but rather pledging additional funds to create these new pools.
Our goal is to ensure that all of our delegators maximize their potential rewards. We also want to offer different options for different delegator risk profiles. For example, smaller pools may have higher volatility allowing lucky delegators to perhaps make greater than the average 5.5% ROA, where larger pools will be more consistent in rewards, but stay closer to that 5.5%.
We currently don’t have plans to open more than 3 pools, however we will continue to adapt as the network and landscape changes. As always, we will continue to focus on community, including delegators as well as our fellow stake pool operators.
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 Size
Fee
Pool size < 13M ADA
1%
Pool size – 13M < 19M
2%
Pool size – 19M < 23M
3%
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.
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:
The Fixed Fee of the pool (currently set to a minimum or 340 ADA)
the Variable Pool Fees, which tend to range from 1%-5%
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.
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.
Daedalus
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.
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.
HARDWARE UPDATES
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
One-to-many delegation as discussed above, except managed via an offline device
Multi-signature pledge – many people can come together and create a pooled pledge governed by good access control, protecting participants
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.
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.
THE BOTTOM LINE
This is what we should expect:
Decentralization will take time for a strong, stable network
Starting decentralization (lowering the d parameter) won’t happen until one more epoch (the week after next)
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.
