skills knowledge certificate vetting checks control SOC NIST CIS handbook video
No vetting and no checks. No one controls the creation of pools. Stake pools will be able to provide a website for marketing and to provide additional information on who they are, and you can use this in your choice.
Server maintenance and devops/sysops experience will be a very big plus. Linux system administration skills.
There will be tools to assist the installation, but potential pool operators are expected to have basic sysop skills for this.
You can participate in the testnet stakepool by following the instructions on the testnet site when it is published. Similar instructions will be provided online when it is deployed to mainnet.
Your stake pool may go down with a subsequent release on testnet if an update isn’t made within the timeframe advertised. This will potentially be a shorter time frame of notification on testnets compared with the mainnet.
Our Technical Support will field questions during the life of the test stake pool and answer questions. We will provide regular updates of our documentation, FAQs and code, and publish new releases. We will broadcast updates to the community on our social media channels.
You will need to download a Cardano node and run it.
We agree. We don’t have this yet but we will work towards it. Please keep in mind that pool operators will be expected to have Linux sysadmin skills.
None, a stake pool registration is a transaction on the blockchain.
We have not yet arrived at the cost for the pool certificate.
This is the point of this group, to gather questions for IOHK to create a stake pool handbook.
risks risk size minimum amount
To operate a public competitive stake pool, the owners of the pool have to pledge ada to their pool. The details of this are covered in the documentation on staking incentives. No minimum amount of ada is required to run a pool or to delegate to a pool, though you do need some ada to pay the transaction fees.
Technically yes, but you need to pay fees to create your staking keys and the pool. This is possible so that people can run their own pools without having much of a personal stake; they can act as service providers for people who have stake, but don’t want to run their own node.
A pool operator doesn’t even need a wallet. The fees would be paid by the pool owner.
This is a market decision made by the combination of individual delegators making their individual decisions based on their perceptions of competing stake pools.
No risk, except that this pool will go down, and you will start getting no rewards, so you need to monitor if they are doing well, and re-delegate to someone else if they are bad.
It is not true that owners have to pledge >0, but if owners do pledge ada to their pool then they must actually delegate the amount they pledged to do, otherwise the rewards are zero. The pool owner might stake no ada and still operate the pool. But the more a pool owner stakes their personal coins, the more profitable a pool will be. The pool is deactivated if the owner’s stake is less than the pledged amount, but the pool creator can pledge 0.
It will not affect your Cardano staking as long as you provide 100% uptime for your node.
You can have many staking keys in one wallet.
The initial release of Daedalus and Yoroi will only support one stake pool delegation choice for a wallet. This may change later, with support for many accounts in a single wallet, each with its own delegation choice. Third-party wallets are free to implement other policies.
Yes, you will be able to delegate to a pool from a hardware wallet or a paper wallet.
Keywords bandwidth Ram processor hardware IP maintenance CPU port WAN node HSM security Benton Stark Python iOS PC domain address
There is no minimum. We have tested running a stake pool on a small single-board, running at 4-7 watts. But that is unlikely to be optimal, and operators will need to experiment to get the right combination of cost, performance, and energy efficiency to maximize their pool’s profitability and attractiveness to delegators.
No. But we’ve tested on other higher-spec minimal single-board computers, just for fun. As mentioned above, this may not be optimal hardware, but it will run.
Network security: 7
Network/system administration: 6
Ability to use monitoring tools: 7
You need an IP and port open to the internet with a decent bandwidth.
The exact minimum bandwidth needed for a competitive stake pool is not yet known.
The Cardano network is a distributed system, but each stake pool will require running only a single node (plus relay nodes that help with distributing information across the network). Load balancing core nodes with the same key is seen as adversarial by the system. The node itself does not have huge requirements on storage or processing power, and is thus designed to run on a single machine.
Not unless you make sure that only one node ever produces a block for any given slot. Otherwise, you would end up creating different blocks for the same slot, which is an attack on the protocol.
No, we do not plan to stop the progress of the chain, and that is not necessary for reboots of individual nodes. When nodes are rebooted or disconnected, they will catch up with the chain on their own, and continue to produce blocks.
For the moment there is no built-in redundancy mechanism for individual stake pools. In particular, it is important not to run multiple active servers using the same stake pool keys because this is classed as adversarial behavior by Ouroboros. Missing a few slots during downtime is not as bad as producing more than one block in the same slot. Check out these links:
We expect the requirements on CPU(s) to be fairly moderate. We have designed the code for Shelley in a way that deliberately avoids the bursts in CPU activity that you observed in the currently deployed Cardano SL code.
A reliable internet connection of sufficient bandwidth is needed, but there is no particular advantage for faster CPUs or any GPU, provided it is over the baseline requirements.
The stake pool node itself can be completely firewalled from the internet, so long as one or more public relays are provided and the stake pool node can communicate through the firewall with the relays.
No. When you run a Daedalus wallet you run a full node. And the protocol is the same as between pools because pools are just full nodes.
Yes, stake pools need to provide near 100% uptime.
Currently, it takes 3-6GB. A guesstimate is less than 50MB per epoch using similar parameters to the mainnet, but it depends on overall usage of the network.
No. Load balancing core nodes with the same key is seen as adversarial by the system. Only one core node should be creating blocks in a given stake pool.
If you are talking about delegating from a wallet on an iOS device or a PC, there is no difference
Writing the code for Shelley, we are removing the inefficiencies that we found during the benchmarks that limited us to fewer than 20 core nodes.
The first release will not include any hardware support for server keys. This may be added later. However, the stake pool server keys use a hot/cold scheme so that if a server is compromised then the operator can issue a new hot key and replace the compromised server. In addition, key-evolving signatures are used for the server hot keys, meaning that no history before a server compromise can be forged
We will advise on any future hardware support well in advance, so we would not recommend investing time in this yet.
Information statistics advertising Telegram
They are not required but many future pools already have websites as part of their marketing strategy.
Only if the pool provides this information for themselves, then it will be available right in the wallet. Many delegators may choose stake pools based on reasons such as brand perception and affinity rather than raw profitability. Otherwise you will need to rely on the community providing information in discussions. This level of info will not be available during the testnet.
No direct interaction is required. Users select your pool in a Daedalus or Yoroi wallet by reading the information about your wallet you provided to the chain. You are encouraged to have external marketing too, such as websites or events.
Stake pools will be encouraged to maintain a public website for this information, and the URL to those websites will be shown by wallets. However, this won’t be the case for the initial testnets.
Daedalus will have a delegation centre that will display information on stake pools. For the initial testnet will we have a command line interface; Daedalus will follow in due course.
There will be a central communication process during the testnet. Mainnet stakepool operator communications are beyond anyone’s control, by design, but there will be both official and unofficial channels where IOHK and stakepool operators communicate.
Not for now.
Some simple statistics will be available in Daedalus and Yoroi. Explorers might provide more detailed information. Anyone has access to the data, since it’s all on the chain. User reviews will have to go on some external third-party service.
Keywords exchange wallet Daedalus Yoroi vote voting spampaper smart contracts
You will be able to delegate to a pool from Daedalus or Yoroi.
Your coins never leave your wallet and are never locked.
The testnet in under development and will be ready soon. The timing for the mainnet will depend on the amount of effort, adjustment, and enhancement needed to get the testnet capability and code to mainnet readiness.
No, for now there's no slashing.
No coin burns.
You will be able to delegate to a pool with no computer experience just by using a Daedalus or Yoroi wallet.
No. At this time it’s not possible to delegate from an exchange, but we may enable this and some exchanges may support delegating in the future.
On Cardano you can only stake ada.
Yes. Your coins never leave your wallet, and you can change your delegation choice at any time.
You can delegate to a stake pool with even only a few minutes of internet access, but you cannot run a stake pool without being up 24/7. This is by design as the node that is staking needs to make blocks and the rewards for the node are based on its performance.
No. Anyone can join any pool; all pools are open, visible, and transparent.
Then its stake share stays equal to the founder’s stake. Nothing special happens.
Yes, that’s one of the aims.
We will first introduce staking on a testnet, to gain some experience, and deploy the feature to the mainnet later.
In the current design, it will be possible to automatically send the rewards that the pool operator would get (cost, margin, and rewards for their own stake) to a charity. Giving only a fraction to charity in an automated way is not something that is in the design, but if people want that, it should be possible to add that feature (possibly after the initial release). Good idea, by the way.
Costs are likely to be a race to zero. And that's not too much of a problem.
Initially only Linux will be supported for running stake pools, so no anti-virus software is required, but we recommend operators use best practice when securing their platform.
None, it’s up to the pool operator to secure their systems and ward off attacks.
In addition to normal server hygiene (patching, security hardening, etc) stake pool operators will need to watch for new Cardano releases and update the software on the pool. This is especially true in the case of forks where the node cannot participate in the system at all without upgrading. Stake pool operators will also have to generate new keys once every 90 days and deploy them to the server and restart the service.
NixOps deployment scripts initially, which will require installing Nix on a Linux system to deploy. This will include the core nodes, a few public relays and a monitoring instance that can be configured to alert the pool operator of issues when they occur. Shell scripts will also be provided for build and execution. In the future, we will provide docker containers that can be deployed in whatever manner is wanted.
Not initially, but in the pipeline for later. Initially we will only be providing NixOps deployment scripts.
You need to provide 100% online uptime for your node. If a node has no internet access it will be a pretty bad node and get a low score. You would also need enough bandwidth, upstream and downstream. The ports required depend on the implementation.
The initial Shelley deployment will not have sidechains, so there will only be the settlement layer.
In future we will ask stake pool operators to run some additional relay nodes to support the P2P network, and these will be included in stake pool registration metadata, but this is not required for the stake pool testnet. It is better for operators to provide relay nodes too, but you can't force it.
Relay nodes are not required for the Rust implementation.
There will be no GUI support initially. Docker support will be added later, but initially deployment scripts will be using NixOps.
Stake pools don’t vote. Only the genesis key holders will be able to vote initially.
The intention of selecting a stake pool is that it is a user choice, and information will be provided on what the most likely profitable choice will be. The incentives system is designed so that a rational selfish choice is a good choice for the overall system.
The wallet API will provide the ability to set delegation choice, and so you could write a program to automate this; however, changing delegation choice does cost transaction fees, so any automated program would want to take that into account. Network spam is discouraged using the transaction fees, which are set to make spamming the system unprofitable for the attacker.
There is nothing special about delegation in this regard. All transactions are subject to these fees for DDoS protection. The whole point of delegation is so that people ‘vote’ with their stake for good pools, and not just select the most profitable one. Delegation to a pool will require signing a transaction, so you would pretty much give those scripts allowance to do whatever with your wallet and private keys.
No maximum number of users; anyone can join. But there’s a level of stake after which joining this pool will give less and less reward.
Yes, when the epoch ends.
A pool will be able to change its information, like description, website, etc. Not sure about the name for now. But pools will also have short unique tickers and you won’t be able to change those. Plus every pool is identified by its unique blockchain ID, and that cannot be changed.
Yes, and in addition you will be alerted if the profitability of the pool changes significantly, even if it has not gone offline entirely.
All this will be available on-chain and Daedalus and Yoroi will display some stats and an historical pool performance score. Also, both Daedalus and Yoroi will notify users if their selected pools change their parameters suddenly. So if your pool changes their costs or fees unexpectedly, you will be notified.
Daedalus and Yoroi will show this metric for all pools and also will sort pools in UI so that those pools close to being saturated go lower. Also, both wallets will notify users explicitly if their pool of choice is overflowing.
The pledge is trustless, the rewards are trustful.
First, we are about to release a 'testnet' so people can practise setting up stake pools. The timing for the mainnet launch has not yet been fixed.
Ideally, some stake pools will use different cloud providers, but there are no restrictions on which providers a stake pool can run on.
Yes, but you should only run one core node in a stake pool at a time.
It would also be inadvisable to use a 'burst' style VM, as the CPU and network load for a stake pool is continuous and not bursty. Burst-style cloud VMs will severely limit performance if they are used continuously.
They have to have their own copy.
Not initially, balancing across nodes would be perceived as hostile behavior attacking the network.
It is beneficial for overall system robustness to have stake pool nodes in a diversity of environments and internet locations, so that we can avoid correlated failures. This is however very hard to measure and enforce or incentivize. This is an issue of interest to IOHK.
The IP address and public keys of the relays will be listed in the metadata of the stake pool which could be used to determine the geographic location of the relays, but there is no way to tell the geographic location of the core node-creating blocks.
If you are talking about the location of the node that’s running the stake pool and the wallets of the people delegating to the pool, that is irrelevant to the efficiency, other than potential impacts to latency from some locations.
The Shelley release will not feature sidechains. Once they are introduced, stake pools will need to support sidechains.
We will recommend running at least one relay to allow the stake pool node itself to be firewalled from the internet. We will also recommend later that multiple relays are provided to support the P2P network. However, this is not required for the testnet.
There is no relationship between running a test stake pool and a production pool. Anyone can run a production pool even if they have not run a test one.
Keywords rewards costs profit margin service charge treasury tax
When you host a pool you get a percentage of rewards from all delegates.
All pools follow the same in-protocol reward scheme. Pool creators determine 'costs' in ada, and 'profit margin' in percentage.
There will be a percentage taken from all rewards and sent into the treasury. But, for now, no-one will be able to take any funds out of the treasury.
It's the tax on all rewards that goes to treasury every epoch.