RFP-0006: Setup and Operate 10 Stake Pools Note: This RFP is open to you. You are asked to submit proposals if you are competent in this area and the money will go to you if your application is successful upon completion of the work proposed. Guidance/advice can be provided by @jolan and @jy-p. Please send all proposals to: rfp2016 <at> decred.org. If you had previously sent an e-mail to stakepool <at> decred.org, you need not send another - you will be contacted shortly. Closing Date The closing date will be set when there are 10 approved stake pools. Description Company 0 recently brought the first stake pool online several weeks ago, but the percentage of stake tickets it manages is soft-capped at 5%. The purpose of capping the percentage of stake tickets managed by a single stake pool is to prevent centralization with this first pool. Since there is further demand for stake pool services, 10 new stake pools will be brought online to add another capacity for another 50% of the stake tickets. These pools will be soft-capped at 5% of the stake tickets each and the operator(s) will be compensated to setup and operate the stake pool for a 3 month period. Requirements Familiarity with system administration work on Linux, e.g. configuring and running nginx, MySQL, ssh, IPSec, duplicity, monit. Familiarity with compiling from source, setting up and maintaining dcrd and dcrwallet. Ability to effectively communicate in English. Scope Instead of decentralizing stake pools by simply open sourcing the code for them, it makes sense to first seed the stake pool network with a number of reliable operators. This is being done to avoid people missing votes because someone sets up a stake pool using a single machine at their home or similar. It is important for users to have several known safe choices for their stake pool. Once there are 10 stake pools up, the code for the stake pool will be made freely available. Each stake pool setup via this RFP will be soft-capped at 5% of the stake until all 10 stake pools are up, at which point the soft caps will be removed. There are several requirements for the stake pool configuration: The physical or virtual machines used to host the configuration must be spread across 3 or more physical locations. More specifically, voting wallets must be in 3+ physically separate locations. The web frontend must have an IP that is distinct from those of the voting wallets, and is ideally located in another physical location. Source code for the stake pool will be provided and binaries must be compiled from source. The pool must be run on testnet for 1 week to confirm it is working properly. Uptime and number of votes made versus missed will be checked. Company 0 will verify each stake pool configuration is proper before moving to mainnet. Unprivileged shell accounts will be made available so the configuration can be verified after running for 1 week on testnet. The pool must be run on mainnet in test mode (no public access) until a pool operator demonstrates they have successfully voted 1 ticket of their own using the pool. The operator must demonstrate their monitoring solution by temporarily sending alerts to a specified email address. An example monit configuration will be supplied to avoid requiring operators to setup their own monitoring solution from scratch. After this has been verified, the pool will be opened to the public. Per the temporary soft cap of 5% of the tickets, pool operators will be required to turn off new registrations for their pool once they have >= 5.0% of the tickets in their pool. Once the initial 3 month period is over, the pool can re-enable registrations and remove its soft cap. The steps to setup a stake pool are straightforward for a skilled system administrator, and should take less than 12 hours of work. We require that proposals come from pairs of individuals or larger groups, e.g. corporate entities, so that the unavailability of a single person does not lead to extended outages in their absence. After the 3 month term of this RFP expires, it is expected that there will be a working solution for collecting fees from users of the stake pool. Here are some quick calculations to give an idea of what would be considered acceptable fees and projected costs: There are roughly 288 blocks / day, 5 votes / block, and 30 days / month, giving 288 x 5 x 30 = 43,200 votes per month. A pool with 5% of the stake tickets would vote roughly 43,200 x 0.05 = 2,160 times / month. A fee of USD 0.20 per ticket would yield the equivalent of USD 432 / month. The cost of an average VPS is USD 10 / month, and a pool should have 4-10 separate VPSes, for a charge of USD 40-100 / month in hosting fees. Per the numbers above, a stake pool can easily pay for itself once there is a proper fee structure and provide a steady monthly output of DCR. We would like stake pools to have both a diverse group of operators and physical locations where voting wallets are hosted. In particular, we are interested in having pools with citizens, residents and voting wallets located in the following jurisdictions: AR, AU, BR, CN, DE, IN, KR, JP, RU, UK, US, and ZA. This list is not intended to exclude any particular jurisdiction so much as communicate we would like to see stake pools run in and by citizens of many different countries. Estimated Working Time 2-3 days FTE to setup initial testnet configuration and verify it, and ongoing episodic maintenance over a 3 month period. Proposal Proposals should include: An overview of your qualifications as they apply to operating a pool. A list of jurisdictions where you plan to run the voting wallets. Your countries of citizenship and residence. Milestones Partial payments shall be made at the following milestones: Pool has been successfully tested for 1 week on testnet and configuration verified - USD 1,000. The end of month 2 of operating the pool, assuming no major outages - USD 500. The end of month 3 of operating the pool, assuming no major outages - USD 500. Under no circumstances shall payments be made in advance of work being completed.