In December 2020 Cartesi launched its Proof of Stake (PoS) system to bootstrap Noether’s validator network. Noether is a high-performance side-chain tailored for temporary data availability, and you can read more about it in this Medium article.
This article is a guide to individuals or organizations who intend to provide staking services for users by creating Staking Pools and managing Noether nodes.
With staking delegation, users can stake CTSI through Staking Pools, created and managed by third-party organizations or individuals, without the need to hand their tokens directly to third parties. In this case, pool operators are responsible for managing a Noether node, and they earn a commission out of the blocks rewards as compensation for operating the pool and the ETH fees they have to spend.
Staking Pools were built on top of the Staking smart contract, so they are subject to the same rules any other direct stakers are, such as the maturation time windows of a minimum of 6 hours for staking and 48 hours for unstaking. Additionally, pools need a larger time window to make sure that the staking, unstaking and withdrawal requests from their users are handled properly. Individual pool users staking requests may take up to an additional 6 hours, and unstaking requests may take up to an additional 48 hours to complete. The pool performs aggregate staking and unstaking requests to the PoS and at the moment a user issues their individual request, the pool is probably in the middle of waiting for a previously issued staking/unstaking request to be completed. As it would happen with individual users, issuing an overlapping staking/unstaking request would restart the maturation/unlocking counter associated with the pool stake.
Pools are built on top of the current PoS and aggregate the staking requests from their users.
Pool operators have two main responsibilities:
- Make sure the Noether node is online and works properly 24×7
- Pay the Ethereum fees that are necessary for block production and also maintenance operations like staking, unstaking and withdrawing from the Staking contract, on behalf of the users that delegate to their pool.
Pool creators can choose from 2 different commission models to be economically viable: flat-rate commission, and gas-based commission.
The Flat rate commission model is straightforward. A flat percentage is taken of the block reward before it is distributed among the pool stakers.
A pool is configured with a 10% flat rate. Upon producing a block the pool receives 2,900 CTSI as a reward. It takes 290 CTSI as commission, and distributes the remaining 2,610 CTSI to its users, in proportion to each user’s share in the total pool stake.
A gas-based commission model takes into account the gas costs of producing the block. If the gas price at the moment of production is high, the cut will be higher, if the gas price is low, the cut will be lower. This model accommodates a variable gas price and CTSI price, but it’s harder to predict the final fee because of its complexity.
A pool is configured to charge 400,000 gas. Upon producing a block this cost is “converted” to CTSI to calculate the commission. First, it’s multiplied by the gas price at that moment, provided by a ChainLink oracle. Then it’s converted to CTSI by using a CTSI/ETH Chainlink oracle as well.
Consider the following scenario: gas price = 20 Gwei. 1 ETH = 4,000 CTSI
400,000 gas x 20 Gwei = 0.008 ETH
0.008 ETH x 4000 = 32 CTSI
Now consider that the gas price surges to 400 Gwei, and the CTSI price goes up in relation to ETH such that 1 ETH = 3200 CTSI
400,000 gas x 400 Gwei = 0.16 ETH
0.16 ETH x 3,200 = 512 CTSI
In the first example (20 Gwei gas price) the commission for that block is 1.1% (32/2,900) considering a reward of 2,900 CTSI. In the second example (400 Gwei gas price) the commission for the block is 17.6% (512/2,900) for the same reward amount. Compared to a flat rate pool with a 10% rate, for instance, the gas-based commission can have a lower or higher fee depending on the gas price, CTSI price, and ETH price as shown in the previous examples.
No matter the selected commission model, the Cartesi Explorer will show the actual historical commission taken by each pool.
Now, let’s focus on the creation of a staking pool!
Any organization or individual can create and manage a staking pool. The creation of pools can be made using the Cartesi Explorer by navigating to https://explorer.cartesi.io/pools/create. When the pool is created, the account connected to metamask is assigned as the pool owner and management operations can be done using that same account.
The first decision the pool owner has to make when creating a pool is choosing the commission model. There are two models available: flat rate and gas tax commission (as explained in detail in the previous section).
The flat-rate model is easier to calculate and explain to your users. The gas tax model is more elaborate and harder to explain, but can accommodate varying layer 1 costs and reward token prices.
Once created and configured, the pool manager cannot change the selected commission model. The value of the commission can be increased up to 5% of the block reward per week, for flat-rate commission-based pools, or 20 000 gas per week, for gas tax commission-based pools, but can be decreased at any time without any limitations. This allows for fine adjustments of the economics of the pool while protecting the pool users from steep increases in the commission parameter.
Noether is a layer-2 solution. It rewards block producers with CTSI and requires ETH to pay for layer 1 transaction costs. The fees for block production are paid by the pool manager. Users pay ETH fees to initiate staking, unstaking and withdrawal requests, but the pool also needs to pay ETH fees to fulfill those requests (as the users interface with the pool smart contract and the pool then has to fulfill the requests on the PoS smart contracts).
The ETH to fund these transactions must be deposited in the wallet managed by the Noether node, created and managed by the pool manager (this topic will be revisited in a while, on the section “running a node”). As a pool manager, one must keep track of the node’s wallet balance and replenish it as needed to make sure the node always has enough funds to operate correctly.
After the transaction for creating a pool is processed, the pool will immediately be listed on the pools page and available for staking. The list shows basic information about each pool and a “Stake” button to navigate to the pool page, like this one:
If the current metamask user is also the pool owner there will also be an “Edit” button available as well to navigate to the pool management page:
The pool management page allows the pool owner to do the following operations:
- Hire a node to represent the pool
- Set an ENS name for the pool
- Change the commission value
- Pause the pool
Each operation is described in detail in the following sections.
Pool managers are responsible for running a Noether node and making sure it works properly 24×7, with a reliable internet connection, well funded, and using a reliable Ethereum provider.
We recommend running the pool node on a VPS server, with appropriate monitoring tools and using a professionally managed Ethereum provider, like Infura or Alchemy. However, any Linux, Mac OS, or Windows box with Docker support, and any Ethereum provider might work.
The steps to run a node are very similar to the ones to run a node for a single staker (“How to Run a Node” article). You have a couple of prerequisites:
- Having the Docker Engine installed: https://docs.docker.com/engine/install/
- Have the url to the Ethereum Mainnet Gateway of your choice (Infura, Alchemy, your own well maintained Ethereum node, or another reliable one)
To run your node, open a terminal on the computer you wish to run it and fetch Cartesi’s reference Noether software using the command:
docker pull cartesi/noether
docker run -it --rm --name cartesi_noether -v cartesi_wallet:/root/.ethereum cartesi/noether --url <YOUR_ETHEREUM_MAINNET_GATEWAY_URL_HERE> --wallet /root/.ethereum/key --create --verbose
When the worker node starts, it creates a new Ethereum wallet, asking for an encryption password. It is very important to remember the password you set as there is no way to decrypt the node wallet without it. You are also strongly encouraged to backup your node’s wallet (please refer to the FAQ for the procedure) as if something happens to your node, you are able to start up a replacement one in no time when you are in possession of the wallet backup.
Once the node is initialized, you should see output log lines like the following in your console:
INFO: starting worker 0x807f6a0bae5ab9a1d5110d08a32bc6a0bd837e08
After the node is running you need to hire it for the pool. You can navigate to the pool management page and paste the address of the node. You can also change the default initial funding for the node (set to 0.1ETH). Next, click the “Hire” button.
After the transaction is processed the node should accept the job and print messages like the ones below to its log:
accepting job from <pool_address>…
worker hired by pool <pool_address>
From this point forward the node will keep polling the blockchain and try to produce blocks whenever possible. It will also eventually send transactions to fulfill staking, unstaking, and withdrawal requests from pool stakeholders. At this point, you might want to detach from the docker container, so that it keeps running in the background when you close the terminal you are using for setup. To detach from the container, you can use the default sequence
Pool operators should monitor their nodes and maintain a reasonable amount of ETH to submit transactions. Metamask can be used to send ETH to the node address from the pool owner address directly.
Users usually choose a pool to stake based on a number of criteria: i.e. current stake, total rewards, number of users or charged commission. Additionally, trust also plays an important role, as users feel more comfortable about staking through a pool managed by a trusted party that manages their node well.
Pool owners can name their pool addresses to provide additional trust (or just make it easier to identify their pool). The system relies on authority information provided by ENS domains. The process to name a pool is twofold: the first step is done using the ENS application and the second step is performed on the Cartesi Explorer pool management page.
The pool owner must register a domain or subdomain to use as the pool name. That can be done at the ENS application hosted at https://app.ens.domains/ which integrates with Metamask.
For the purpose of this tutorial we will use a subdomain under the “cartesi.eth” domain called “pool1.cartesi.eth”. Registering domains on Mainnet has costs involved. For a step-by-step guide on how to register an ENS domain, please refer to this article.
The subdomain page starts as shown in the picture above. Click on the “Add/Edit Record” button on the top-right of the “Records” table. Then, fill the ETH address with the pool address (you can retrieve it on the Cartesi Explorer, be sure to double-check it) and click the “Confirm” button in the bottom right. You can also fill the “avatar” field with an URL of an image to be used as the icon for the pool. Once you click “Confirm”, you will be presented with a confirmation dialog like the one below.
This first step configures the name to resolve to the pool address. Now it’s time for the second step, which consists of configuring a reverse lookup from the pool address to the name. This step is performed using the Cartesi Explorer, on the pool management page.
Fill out the fully qualified pool domain name in the “Pool ENS name” field, click the “Save” button and confirm the transaction on Metamask to issue an Ethereum transaction that does that.
After the transaction is processed, you can go back to the pools page and you should see the name (and optionally icon) you set instead of the pool address.
The associated costs of the operations performed by the pool are of the essence to determine if the setup pool commission is enough to cover the costs of keeping the pool node running or not. The pool manager spends ETH in three operation categories: setup costs, management costs, and operational costs.
Setup costs are incurred during the pool creation and its effect over the pool long-term cost diminishes over time. It includes pool creation cost, ENS setup, and hiring a node, which have been discussed in the above sections. There might also be eventual costs involved with PoS/Pool upgrades or management costs, like setting a new commission value or pause/unpause operations (which might be used by the pool manager to limit the amount of CTSI staked).
The operational cost includes the block production itself and the rebalancing operations.
The pool block production imposes some overhead over the normal non-pool block production, due to additional logic necessary to allocate block rewards.
The rebalance operation is related to managing the inflow and outflow of tokens from users into the pool and to the Staking contract, in order to provide adequate liquidity to the pool. A pool can have multiple users depositing/staking or unstaking/withdrawing at a given time without producing many blocks, can have few users moving tokens while producing many blocks, or anything in between. The pool rebalancing operation respects the Staking contract maturation periods (6h for staking, 48h for unstaking), which means that there will be a maximum number of 10 rebalancing operations in a 48h period (worst case scenario).
It is very hard to predict the cost of a pool because of the uncontrolled and random nature of the events around it. For that reason we allow the pool manager to change the commission, as explained in the “Creating a Pool” section.
As always, we’re ready for any questions or support in our development community on Discord, see you there!
Cartesi is a multi-chain layer-2 infrastructure that allows any software developer to create smart contracts with mainstream software tools and languages they are used to while achieving massive scalability and low costs. Cartesi combines a groundbreaking virtual machine, optimistic rollups, and side-chains to revolutionize the way developers create blockchain applications.