Skip to content

Commit 067abb7

Browse files
EmpieichOEmpieichO
committed
Update PoS - added new section 'Refernce'
1 parent decac40 commit 067abb7

File tree

13 files changed

+1168
-1
lines changed

13 files changed

+1168
-1
lines changed

‎docs/img/pos/staking_manager.png‎

231 KB
Loading

‎docs/pos/how-to/operating/validator-node/rewards.md‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
---
2+
id: rewards
3+
title: Rewards
4+
sidebar_label: Rewards
5+
description: Learn about the Polygon Network staking incentives.
6+
keywords:
7+
- docs
8+
- matic
9+
- polygon
10+
- rewards
11+
- staking
12+
- incentives
13+
image: https://wiki.polygon.technology/img/polygon-logo.png
14+
---
15+
16+
In Polygon, validators stake their MATIC tokens as collateral to work for the security of the network, and in exchange for their service, earn rewards.
17+
18+
To leverage Polygon's economics, you should either become a validator or a delegator.
19+
20+
To be a validator, you need to **run a full validator** node and stake MATIC.
21+
22+
Also check the [Validator Responsibilities](/pos/design/validator/responsibilities) page.
23+
24+
To be a delegator, you only need to **delegate MATIC to a validator**
25+
26+
## What is the incentive?
27+
28+
Polygon allocates 12% of its total supply of 10 billion tokens to fund the staking rewards. This is to ensure that the network is seeded well enough until transaction fees gain traction. These rewards are primarily meant to jump-start the network, while the protocol in the long run is intended to sustain itself on the basis of transaction fees.
29+
30+
**Validator Rewards = Staking Rewards + Transaction Fees**
31+
32+
This is allocated in a way to ensure gradual decoupling of staking rewards from being the dominant component of the validator rewards.
33+
34+
|Year|Target Stake (30% of circulating supply)|Reward Rate for 30% Bonding|Reward Pool|
35+
|---|---|---|---|
36+
|First|1,977,909,431|20%|312,917,369|
37+
|Second|2,556,580,023|12%|275,625,675|
38+
|Third|2,890,642,855|9%|246,933,140|
39+
|Fourth|2,951,934,048|7%|204,303,976|
40+
|Fifth|2,996,518,749|5%|148,615,670 + **11,604,170**|
41+
42+
Below is a sample snapshot of the expected annual rewards for the first 5 years considering staked supply ranging from 5% to 40% at 5% interval
43+
44+
|% of circulating supply staked|5%|10%|15%|20%|25%|30%|35%|40%|
45+
|---|---|---|---|---|---|---|---|---|
46+
|Annual reward for year|
47+
|First|120%|60%|40%|30%|24%|20%|17.14%|15%|
48+
|Second|72%|36%|24%|18%|14.4%|12%|10.29%|9%|
49+
|Third|54%|27%|18%|13.5%|10.8%|9%|7.71%|6.75%|
50+
|Fourth|42%|21%|14%|10.5%|8.4%|7%|6%|5.25%|
51+
|Fifth|30%|15%|10%|7.5%|6%|5%|4.29%|3.75%|
52+
53+
## Who gets the incentives?
54+
55+
Stakers running validator nodes and stakers delegating their tokens toward a validator that they prefer.
56+
57+
Validators have the option to charge a commission on the reward earned by delegators.
58+
59+
The funds belonging to all stakers are locked in a contract deployed on the Ethereum mainnet.
60+
61+
No validator holds custody over delegator tokens.
62+
63+
## Staking rewards
64+
65+
The yearly incentive is absolute — irrespective of the overall stake or the target bonding rate in the network, the incentive amount is given out as a reward to all signers periodically.
66+
67+
In Polygon, there is an additional element of committing periodic checkpoints to the Ethereum mainnet. This is a major part of the validator responsibilities and they are incentivized to perform this activity. This constitutes a cost to the validator which is unique to a Layer 2 solution such as Polygon. We strive to accommodate this cost in the validator staking reward payout mechanism as a bonus to be paid to the proposer, who is responsible for committing the checkpoint. Rewards minus the bonus is to be shared among all stakers, proposer and signers, proportionally.
68+
69+
## Encouraging the proposer to include all signatures
70+
71+
To avail the bonus completely, the proposer must include all signatures in the checkpoint. Because the protocol desires ⅔ +1 weight of the total stake, the checkpoint is accepted even with 80% votes. However, in this case, the proposer gets only 80% of the calculated bonus.
72+
73+
## Transaction fees
74+
75+
Each block producer at Bor is given a certain percentage of the transaction fees collected in each block. The selection of producers for any given span is also dependent on the validator’s ratio in the overall stake. The remaining transaction fees flow through the same funnel as the rewards which get shared among all validators working at the Heimdall layer.

‎docs/pos/reference/commands.md‎

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
This guide provides a curated list of common commands and Polygon-specific operations essential for node operators. Whether you're setting up a full node, validator node or troubleshooting, these commands will assist you in managing your Polygon PoS environment effectively.
2+
3+
## Frequently Used Commands for Bor & Heimdall
4+
5+
Use the tabs below to switch between commands for Bor and Heimdall:
6+
7+
<Tabs
8+
defaultValue="bor"
9+
values={[
10+
{ label: 'Bor Commands', value: 'bor', },
11+
{ label: 'Heimdall Commands', value: 'heimdall', },
12+
]
13+
}>
14+
<TabItem value="bor">
15+
16+
To execute Bor IPC commands, use the following syntax:
17+
18+
```bash
19+
bor attach .bor/data/bor.ipc <command>
20+
```
21+
22+
| IPC Command | RPC Command | Description |
23+
| ----------- | ----------- | ----------- |
24+
| `admin.peers.length` | `curl -H "Content-Type: application/json" --data '{"jsonrpc": "2.0", "method": "net_peerCount", "params": [], "id": 74}' localhost:8545` | Retrieves the number of peers connected to the node. |
25+
| `admin.nodeInfo` | | Provides detailed information about the node. |
26+
| `eth.syncing` | `curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "eth_syncing","params": []}' localhost:8545` | Indicates whether the node is syncing (`true`) or not (`false`). |
27+
| `eth.syncing.highestBlock - eth.syncing.currentBlock` | | Compares the current block of your node to the highest block. |
28+
| `eth.blockNumber` | `curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "eth_blockNumber","params": []}' localhost:8545` | Returns the latest block number processed by the node. |
29+
| `debug.setHead("0x"+((eth.getBlock('latest').number) - 1000).toString(16))` | | Rewinds the blockchain to 1000 blocks prior. |
30+
| `admin.nodeInfo.enode` | | Retrieves the public enode URL of the node. |
31+
| `eth.syncing.currentBlock * 100 / eth.syncing.highestBlock` | | Calculates the remaining percentage for block synchronization. |
32+
| `eth.getBlock("latest").number` | `curl http://YourIP:8545 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"bor_getSigners", "params":["0x98b3ea"]}'` | Queries the height of the latest Bor block. |
33+
| | `curl http://YourIP:8545 -X POST -H "Content-Type: application/json" --data '{"method":"eth_chainId","params":[],"id":1,"jsonrpc":"2.0"}'` | Retrieves the `chainID`. |
34+
35+
</TabItem>
36+
<TabItem value="heimdall">
37+
38+
| Command | Description |
39+
| ------- | ----------- |
40+
| `curl localhost:26657/net_info?` | Returns the number of connected peers using `jq .result.n_peers`. |
41+
| `curl -s localhost:26657/status` | Retrieves Heimdall's current block height using `jq .result.sync_info.latest_block_height`. |
42+
| `curl localhost:26657/net_info` | Queries the node using its moniker with `grep moniker`. |
43+
| `curl -s localhost:26657/status` | Checks if Heimdall is in sync using `jq .result.sync_info.catching_up`. |
44+
| `curl -s localhost:26657/status` | Verifies Heimdall's sync status using `jq .result \| jq .sync_info`. |
45+
| `heimdalld unsafe-reset-all` | Resets the database in case of issues. |
46+
| `curl localhost:26657/status` | Provides comprehensive information about Heimdall. |
47+
48+
</TabItem>
49+
</Tabs>
50+
51+
## Node Management Commands
52+
53+
| Description | Command |
54+
| ------------------------------------- | ---------------------------------------------- |
55+
| **Locate Heimdall genesis file** | `$CONFIGPATH/heimdall/config/genesis.json` |
56+
| **Locate heimdall-config.toml** | `/etc/heimdall/config/heimdall-config.toml` |
57+
| **Locate config.toml** | `/etc/heimdall/config/config.toml` |
58+
| **Locate heimdall-seeds.txt** | `$CONFIGPATH/heimdall/heimdall-seeds.txt` |
59+
| **Start Heimdall** | `$ sudo service heimdalld start` |
60+
| **Start Heimdall rest-server** | `$ sudo service heimdalld-rest-server start` |
61+
| **Start Heimdall bridge-server** | `$ sudo service heimdalld-bridge start` |
62+
| **Locate Bor genesis file** | `$CONFIGPATH/bor/genesis.json` |
63+
| **Start Bor** | `sudo service bor start` |
64+
| **Retrieve Heimdall logs** | `/var/log/matic-logs/` |
65+
| **Check Heimdall logs** | `tail -f heimdalld.log` |
66+
| **Check Heimdall rest-server logs** | `tail -f heimdalld-rest-server.log` |
67+
| **Check Heimdall bridge logs** | `tail -f heimdalld-bridge.log` |
68+
| **Check Bor logs** | `tail -f bor.log` |
69+
70+
## Useful Configuration Commands
71+
72+
### Sync Status of Heimdall
73+
74+
To check if Heimdall is synced, run:
75+
76+
```bash
77+
curl http://localhost:26657/status
78+
```
79+
80+
### Latest Block Height on Heimdall
81+
82+
To check the latest block height on Heimdall, run:
83+
84+
```bash
85+
curl localhost:26657/status
86+
```
87+
88+
### Latest Block Height on Bor
89+
90+
To check the latest block height on Bor, use:
91+
92+
```bash
93+
curl http://<your ip>:8545 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"bor_getSigners", "params":["0x98b3ea"]}'
94+
```
95+
96+
### Cleanup: Deleting Remnants of Heimdall and Bor
97+
98+
**For Linux package:**
99+
100+
```bash
101+
sudo dpkg -i matic-bor
102+
sudo rm -rf /etc/bor
103+
```
104+
105+
**For Binaries:**
106+
107+
```bash
108+
sudo rm -rf /etc/bor
109+
sudo rm /etc/heimdall
110+
```
111+
112+
### Terminate Bor Process
113+
114+
**For Linux:**
115+
116+
```bash
117+
ps -aux | grep bor
118+
sudo kill -9 <PID>
119+
```
120+
121+
**For Binaries:**
122+
123+
```bash
124+
cd CS-2003/bor
125+
bash stop.sh
126+
```
127+
128+
### Retrieve Latest Peer Details
129+
130+
To retrieve the latest peer details, run:
131+
132+
```bash
133+
bor attach bor.ipc
134+
admin.peers.forEach(function(value){
135+
console.log(value.enode+',')
136+
})
137+
exit
138+
```
139+
140+
### Stop Heimdall and Bor Services
141+
142+
**For Linux packages:**
143+
144+
```bash
145+
sudo service heimdalld stop
146+
sudo service bor stop
147+
```
148+
149+
**For Binaries:**
150+
151+
```bash
152+
pkill heimdalld
153+
pkill heimdalld-bridge
154+
cd CS-2001/bor
155+
bash stop.sh
156+
```
157+
158+
### Remove Heimdall and Bor Directories
159+
160+
**For Linux packages:**
161+
162+
```bash
163+
sudo rm -rf /etc/heimdall/*
164+
sudo rm -rf /etc/bor/*
165+
```
166+
167+
**For Binaries:**
168+
169+
```bash
170+
sudo rm -rf /var/lib/heimdalld/
171+
sudo rm -rf /var/lib/bor
172+
```

‎docs/pos/reference/commit-chain-multisigs.md‎

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
2+
## Purpose and capabilities
3+
4+
The primary role of multi-signature wallets (multisigs) is to facilitate contract upgrades during the early stages of development. As these contracts become more robust, Polygon plans to:
5+
6+
- Transition from multisigs to governance-controlled proxies.
7+
- Implement timelocks for added security.
8+
- Phase out multisigs entirely in the long term.
9+
10+
**It's important to note that the existing multisigs do not have the capability to censor transactions, including bridge transactions.**
11+
12+
## Active multi-signature wallets
13+
14+
### Ethereum chain multisigs
15+
16+
| Multisig Address | **5/9 Multisig**<br/>`0xFa7D2a996aC6350f4b56C043112Da0366a59b74c` |
17+
|:----------------:|---------------------------------------------------------------------|
18+
| Purpose | To upgrade PoS and staking contracts on Ethereum. |
19+
| Chain | Ethereum |
20+
| Rights | - Update staking contracts for optimizations and upgrades.<br/>- Address unexpected bugs in PoS contracts. |
21+
| Signatories | Quickswap, Curve, Polygon, Horizon Games, Cometh |
22+
23+
### Polygon commitchain multisigs
24+
25+
| Multisig Address | **5/8 Multisig**<br/>`0x355b8E02e7F5301E6fac9b7cAc1D6D9c86C0343f` |
26+
|:----------------:|---------------------------------------------------------------------|
27+
| Purpose | To update custom ChildERC20s on Polygon Commitchain. |
28+
| Chain | Polygon Commitchain |
29+
| Rights | Ability to upgrade custom child contracts. |
30+
| Signatories | Quickswap, Curve, Polygon, Horizon Games, Cometh |
31+
32+
### Custom child ERC20s mapping
33+
34+
| Multisig Address | **4/8 Multisig**<br/>`0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4` |
35+
|:----------------:|---------------------------------------------------------------------|
36+
| Purpose | To enable the mapping of custom ChildERC20s with Mainnet contracts. |
37+
| Chain | Ethereum |
38+
| Rights | Limited to mapping; no access to Child tokens or deposit/withdrawal rights. |
39+
| Signatories | Polygon |
40+
41+
### Permissionless mapping
42+
43+
| Multisig Address | **Permissionless Mapping of Standard ChildERC20 Tokens (No Multisig Required)** |
44+
|:----------------:|--------------------------------------------------------------------------------|
45+
| Purpose | FxPortal supports permissionless token mapping of standard ChildERC20 for any ERC20 token on Ethereum. |
46+
| Chain | Permissionless |
47+
| Rights | Permissionless |
48+
| Signatories | Permissionless |
49+
50+
<sub>*Plans are underway to transition these functions to governance. We are currently exploring options such as Aave's governance contracts and Compound’s timelock contracts.</sub>

0 commit comments

Comments
 (0)