Joystream Stats fcbd88a006 merge archived helpdesk | 2 år sedan | |
---|---|---|
.. | ||
img | 2 år sedan | |
README.md | 2 år sedan |
This page contains all information on how to setup your node and become a Validator
on the Joystream Testnets. It will be updated for improvements, and when something changes for new testnets.
If you want to earn more tJOY
tokens, but for some reason can't or won't become a Validator
, you can Nominate
instead.
The instructions below cover Mac and Linux (64 bit and armv7). Windows binaries are currently not available.
Note
If you are just running a node, and don't want to be a Validator
, you can skip the flags
--pruning archive
and --validator
<brackets>
, it means you have to replace this with your input, without the <>
."double_quotes"
, it means the number/data will vary depending on your node or the current state of the blockchain.For terminal commands, $
means you must type what comes afterwards. #
Means it's just a comment/explanation, and must not be typed.
# This is just a comment, don't type or paste it in your terminal!
$ cd ~/
# Only type/paste the "cd ~/, not the preceding $ !
Open the terminal (Applications->Utilities):
$ cd ~/
$ wget https://github.com/Joystream/joystream/releases/download/v9.3.0/joystream-node-5.1.0-9d9e77751-x86_64-macos.tar.gz
$ wget https://github.com/Joystream/joystream/releases/download/v9.3.0/joy-testnet-5.json
----
# If you don't have wget installed, paste the link in your browser save.
# Assuming it gets saved in your ~/Downloads folder:
$ mv ~/Downloads/joystream-node-5.1.0-9d9e77751-x86_64-macos.tar.gz ~/
---
$ tar -vxf joystream-node-5.1.0-9d9e77751-x86_64-macos.tar.gz
$ ./joystream-node --chain joy-testnet-5.json --pruning archive --validator
--name <nodename>
--log runtime,txpool,transaction-pool,trace=sync
Your node should now start syncing with the blockchain. The output should look like this:
Joystream Node
version "Version"-"your_OS"
by Joystream, 2019-2020
Chain specification: "Joystream Version"
Node name: "nodename"
Roles: AUTHORITY
Initializing Genesis block/state (state: "0x…", header-hash: "0x…")
Loading GRANDPA authority set from genesis on what appears to be first startup.
Loaded block-time = BabeConfiguration { slot_duration: 6000, epoch_length: 100, c: (1, 4), genesis_authorities: ...
Creating empty BABE epoch changes on what appears to be first startup.
Highest known block at #0
Local node identity is: "peer id"
Starting BABE Authorship worker
Discovered new external address for our node: /ip4/"IP"/tcp/30333/p2p/"peer id"
New epoch 0 launching at block ...
...
...
Syncing, target=#"block_height" ("n" peers), best: #"synced_height" ("hash_of_synced_tip"), finalized #0 ("hash_of_finalized_tip"), ⬇ "download_speed"kiB/s ⬆ "upload_speed"kiB/s
From the last line, notice target=#"block_height"
and best: #"synced_height"
When the target=#block_height
is the same as best: #"synced_height"
, your node is fully synced!
Keep the terminal window open.
Now you need to generate your keys. Go here to do that now.
Now it's time to configure your keys to start validating. Go here to configure your Validator
.
<brackets>
, this means you have to replace this with your input, without the <>
."double_quotes"
, it means the number/data will vary depending on your node or the current state of the blockchain.For terminal commands:
$
means you must type what comes afterwards#
means it's just a comment/explanation for the readers convenience
# This is just a comment, don't type or paste it in your terminal!
$ cd ~/
# Only type/paste the "cd ~/, not the preceding $ !
Open the terminal:
$ cd ~/
# 64 bit debian based Linux
$ wget https://github.com/Joystream/joystream/releases/download/v9.3.0/joystream-node-5.1.0-9d9e77751-x86_64-linux-gnu.tar.gz
$ tar -vxf joystream-node-5.1.0-9d9e77751-x86_64-linux-gnu.tar.gz
# armv7 (eg. raspberry pi)
$ wget TBD
$ tar -vxf TBD
# For both
$ wget https://github.com/Joystream/joystream/releases/download/v9.3.0/joy-testnet-5.json
$ ./joystream-node --chain joy-testnet-5.json --pruning archive --validator
--name <nodename>
--log runtime,txpool,transaction-pool,trace=sync
Your node should now start syncing with the blockchain. The output should look like this:
Joystream Node
version "Version"-"your_OS"
by Joystream contributors, 2019-2020
Chain specification: "Joystream Version"
Node name: "nodename"
Roles: AUTHORITY
Initializing Genesis block/state (state: "0x…", header-hash: "0x…")
Loading GRANDPA authority set from genesis on what appears to be first startup.
Loaded block-time = BabeConfiguration { slot_duration: 6000, epoch_length: 100, c: (1, 4), genesis_authorities: ...
Creating empty BABE epoch changes on what appears to be first startup.
Highest known block at #0
Local node identity is: "peer id"
Starting BABE Authorship worker
Discovered new external address for our node: /ip4/"IP"/tcp/30333/p2p/"peer id"
New epoch 0 launching at block ...
...
...
Syncing, target=#"block_height" ("n" peers), best: #"synced_height" ("hash_of_synced_tip"), finalized #0 ("hash_of_finalized_tip"), ⬇ "download_speed"kiB/s ⬆ "upload_speed"kiB/s
From the last line, notice target=#"block_height"
and best: #"synced_height"
When the target=#block_height
is the same as best: #"synced_height"
, your node is fully synced!
Keep the terminal window open.
Now you need to generate your keys. Go here to do that now.
Now it's time to configure your keys to start validating. Go here to configure your Validator
.
While the node is syncing, you can start the process of setting up the rest.
My Keys
in the sidebar. Click the Add account
button.Names are entirely optional, but the next steps will be easier if you follow the system suggested.
If you want to be able to recover your keys later, write down your mnemonic seed, key pair crypto type and secret derivation path.
Depending on your browser, you might have to confirm saving the json file.
Repeat the process for your "controller" key.
You should now have two sets of keys, namely:
If you already have tokens, transfer the bulk to your "stash" account. If you don't yet have any tokens, ask in the Discord chat, and you shall receive :)
Send at least 1 token to your "controller".
In order to be a Validator
, you need to stake. Note that you may have to refresh your browser if you're not seeing the options right away.
IMPORTANT: Your node needs to be fully synced, before proceeding to step 7.
In a terminal window on the machine/VPS your node is running, paste the following:
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933
If your node is running, this should return:
{"jsonrpc":"2.0","result":"0xa0very0long0hex0string","id":1}
This will save the session keys to your node. Make sure you don't close the window before copying the 0xa0very0long0hex0string
somewhere.
If your node is not running, is running on a different port, or curl
is not installed, it will return something like:
curl: (7) Failed to connect to localhost port 9933: Connection refused
# or
{"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":1}
Validators
in the sidebar, and then the Account actions
tab.+ Stash
button, and select the keys from the first two dropdowns.Set Session Key
button next to your "stash" and "controller" keys in this window. Click it, paste in your 0xa0very0long0hex0string
in the field, and confirm.Validate
button instead. IF your node is fully synced click it, and set your reward commission percentage
, a number between 0 and 100. Your input here depends on your preferences. A "high" number means you are less likely to get Nominators.Refresh your browser, and select the Waiting
tab. If your account shows under intentions
, wait for the next era
, and you will be moved to the validators
list (in the Staking Overview
tab).
Unless you want to risk getting slashed, you need to "gracefully" stop validating. This can be done easily in Pioneer
Validators
in the sidebar, then choose the Account actions
tab.If you are running your node on a Linux and want to run it as a service, you can set it up this way. Note that you should avoid this unless you know what you are doing, are running your node on your own VPS or a single board computer. With great (sudo) privileges, comes great responsibilities!
If you are already running as a validator
, consider unstaking first, as you may experience some downtime if you make any mistakes in the setup.
Either as root, or a user with sudo privileges. If the latter, add sudo
before commands.
$ cd /etc/systemd/system
# you can choose whatever name you like, but the name has to end with .service
$ touch joystream-node.service
# open the file with your favorite editor (I use nano below)
$ nano joystream-node.service
The example below assumes the following:
joystream
to run the nodeThe path to the joystream-node
binary is /home/joystream/joystream-node
This can be confirmed by typing pwd
in the directory you downloaded the binary to
[Unit]
Description=Joystream Node
After=network.target
[Service]
Type=simple
User=joystream
WorkingDirectory=/home/joystream/
ExecStart=/home/joystream/joystream-node \
--chain joy-testnet-5.json \
--pruning archive \
--validator \
--name <memberId-memberHandle> \
--log runtime,txpool,transaction-pool,trace=sync
Restart=on-failure
RestartSec=3
LimitNOFILE=10000
[Install]
WantedBy=multi-user.target
The example below assumes the following:
root
to run the nodeThe path to the joystream-node
binary is /root/joystream-node
This can be confirmed by typing pwd
in the directory you downloaded the binary to
[Unit]
Description=Joystream Node
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=/root/
ExecStart=/root/joystream-node \
--chain joy-testnet-5.json \
--pruning archive \
--validator \
--name <memberId-memberHandle> \
--log runtime,txpool,transaction-pool,trace=sync
Restart=on-failure
RestartSec=3
LimitNOFILE=10000
[Install]
WantedBy=multi-user.target
You can add/remove any flags
as long as you remember to include \
for every line but the last. Also note that systemd is very sensitive to syntax, so make sure there are no extra spaces before or after the \
.
After you are happy with your configuration:
$ systemctl daemon-reload
# this is only strictly necessary after you changed the .service file after running, but chances are you will need to use it once or twice.
# if your node is still running, now is the time to kill it.
$ systemctl start joystream-node
# if everything is correctly configured, this command will not return anything.
# To verify it's running:
$ systemctl status joystream-node
# this will only show the last few lines. To see the latest 100 entries (and follow as new are added)
$ journalctl -n 100 -f -u joystream-node
# To make the service start automatically at boot:
$ systemctl enable joystream-node
You can restart the service with:
systemctl restart joystream-node
If you want to change something (or just stop), run:
systemctl stop joystream-node
Before you make the changes. After changing:
$ systemctl daemon-reload
$ systemctl start joystream-node
If you make a mistake somewhere, systemctl start joystream-node
will prompt:
Failed to start joystream-node.service: Unit joystream-node.service is not loaded properly: Invalid argument.
See system logs and 'systemctl status joystream-node.service' for details.
Follow the instructions, and see if anything looks wrong. Correct it, then:
$ systemctl daemon-reload
$ systemctl start joystream-node
If you don't want to use the default settings, here are some of the options you can configure.
The bonding preferences decide on how your (tJOY) staking rewards are distributed. There are three alternatives:
Stash account (increase the amount at stake)
(default).This automatically sends all rewards the stash
address, where it gets bonded as additional stake. This will increase your probability of staying in the validator
set.
Stash account (do no increase the amount at stake)
As for 1. this automatically sends all rewards the stash
address, but does not get bonded as stake, meaning it will not help "guard" your spot in the validator
set.
Controller account
This sends all rewards to the controller
, at your disposal.
The reward commission
determines how the (tJOY) staking rewards are split between yourself and any potential nominators. The default - 0(%) - means that the reward is split based on the number of bonded stake the validator
and nominators
have put up. Example:
v
be the bonded tokens by the validators stash
keyc
be the reward commission
decided by the validatorn1
be the bonded tokens by the nominator1 stash
n2
be the bonded tokens by the nominator2 stash
Let r
be the reward for the individual validators that era
# payout for the validator
c*r + r*(1 - c)*v/(v + n1 + n2)
# payout for the nominator1
r(1 - c) * n1/(v + n1 + n2)
reward commission
set to 10%after the end of the era, the total rewards are 25,000 tJOY
# All validators get an equal share, before sharing with nominators:
R_v = 25,000tJOY / 10 = 2,500tJOY
# payout for validator 1
R_v.1 = 0.1 * 2,500tJOY + 2,500tJOY *(1 - 0.1) * (100,000tJOY / 250,000tJOY) = 1,150tJOY
# payout for nominator A
R_n.A = 2,500tJOY *(1 - 0.1) * (100,000tJOY / 250,000tJOY) = 900tJOY
# payout for nominator B
R_n.B = 2,500tJOY *(1 - 0.1) * (50,000tJOY / 250,000tJOY) = 450tJOY
As the Validator carries the cost of operating and maintaining their nodes, it makes sense for them to take a slice of the pie before sharing.
If you want to get some return on your tokens without running a node yourself, you can nominate
another validator
and get a share of their rewards.
This might also come in handy if there are too many validators
and you don't have enough tokens get a spot, or if you have to shut down your own node for a while.
My keys
in the sidebar. Click the Add account
button.Names are entirely optional, but the next steps will be easier if you follow the system suggested.
If you want to be able to recover your keys later, write down your mnemonic seed, key pair crypto type and secret derivation path.
Depending on your browser, you might have to confirm saving the json file.
Repeat the process for your "controller" key.
You should now have two sets of keys, namely:
If you already have tokens, transfer the bulk to your "stash" account. If you don't yet have any tokens, ask in the Discord chat, and you shall receive :)
Send at least 1 token to your "controller".
In order to be a Nominator
, you need to stake. Note that you may have to refresh your browser if you're not seeing the options right away.
Validators
in the sidebar, and then the Account actions
tab.+ Stash
button, and select the keys from the first two dropdowns.Nominate
button next to your "stash" and "controller" keys in this window. Click it, and select the "stash" account(s) of the Validator(s)
you want to Nominate
for.Rewards are the most critical part of any blockchain infrastructure, block production, whether it's from Proof of Work (using miners, e.g. Bitcoin) or Proof of Stake (using validators, like Joystream). Validators are rewarded for producing, propagating and securing the network.
Rewards are no longer paid out automatically to the validators, and it must be done manually. We have made it so you have ~2 weeks to claim your rewards, but after that, they can no longer be claimed.
This was not a voluntary decision from Jsgenesis, but part of the new staking module from Substrate. The reason is simply that if your validator set is very large and with a lot of nominators (which will be the case for many Substrate based chains), every payout would require a lot of transactions. By instead making it manual, this will be spaced out.
Note: Claiming rewards for a specific Validator can be done by anyone, not just the Validator themselves. However, only the Validator (and Nominator) can batch up multiple claims in one bulk.
This can only be done if you have the keys for the Validator or Nominator you want to claim for:
In the UI, Validators can claim rewards in "bulks" of 40 eras
at the time:
Validators
in the sidebar, and then the Payouts
tabMax, x eras
are selectederas
you can claim rewards foravailable
you are "owed"remaining
to claim (your "oldest") rewardPayout
button at the right end of the row, and confirm to claim the "oldest" 40 era
rewards for you, and any potential Nominators that has claim to some of your rewardseras
, you can repeat this after the first transaction is completeNote:
eras
for which they claim rewards, the Nominator(s) will automatically get their rewards for said eras
eras
, the Validator(s) they nominated in said eras
will automatically also get their rewards.era
at the TimeThis can be done by any account:
staking.payoutStakers(validator_stash, era)
stash
account you want to claim on behalf of/forera
you want to claim for, and submitTo find out if a "stash" claimed reward(s) from era(s)
:
chain state query of ledger(AccountId): Option<StakingLedger>
with the any current, or "historic" controller. Output:
{
stash: 5YourStashAddress,
total: <tot_bonded> JOY,
active: <act_bonded> JOY,
unlocking: [],
claimedRewards: [
<era_a>,
<era_b>,
...
<era_i>,
]
}
Note:
To understand what unlocking
means, go here.
For Substrate based blockchains, the validator rewards depend on some dynamic parameters, that will change continuously, and some fixed parameters in the chain spec.
V_a
) - the number of validators
currently running. This can be found:
V_a
/ V_i
)session.validators()
(and count them)V_i
- the max number of active validators. This number can be changed through proposals, but was initially set to 20. Current value can be found:
V_a
/ V_i
)staking.validatorCount()
I
- total tJOY tokens in circulation. This can be found:
balances.totalIssuance()
S_v
) - i.e. the total stake of the validators
set, corresponding to the sum of the stakes of each validator
, plus the stake of their nominators if any. This can be found:
I
, and the percentage of S_v / I
- also known as the Active staking ratio, S_v,ar
, see 5.)staking.erasTotalStake(<EraIndex>)
<EraIndex>
can be found by staking.activeEra()
S_v,ar
- the current ratio of tokens staked by active validators (and their nominators) and the issuance. So S_v,ar = S_v / I
I_min
- the min yearly inflation distributed to validators.
5%
.I_max
- the max yearly inflation distributed to validators.
75%
.S_v,ir
- the ideal ratio of effective stake over issuance for maximum validator rewards.
30%
.F_v
- how quickly the validator rewards drop when the actual staking rate S_v,ar
exceeds the ideal staking rate S_v,ir
.
5%
.session_l
- each session
(or epoch
) should last ~10 minutes / 100 blocks *
era_l
- each era
lasts 60 minutes should last 6 sessions
-> ~60 minutes / 600 blocks *
*
For a variety of reasons (such as latency, validators going down, etc.) an era
can be as little as 1 session
and a session
can be a lot fewer blocks than 100.At the end of each era, a new set of active validators V_a
is determined by sorting all those that have declared their intention (e.g. both the active and next up) by their stake, and selecting up to V_i
in a descending order.
Those selected are treated as equals, and will have the same chance of being selected to produce blocks and thus get an equal share of the rewards. Slashes however, are applied as a percentage of stake, so a validator with more stake risks getting slashed more despite earning the same.
As shown, the maximum total validator reward per year is 75% for S_v,ar = S_v,ir = 0.3
. With an era length of 600 blocks, each era, the maximum total, R_vm,te
and individual, R_vm,ie
reward for the validators are:
Note For all calculations, we assume there are (365.2425×24×60×60s)/year.
R_vm,te = I * I_max * era_l / year
= I * 0.75 * 3600s / (31556952s)
= 0.0000855596*I
R_vm,ie = R_vm,te / V_a
= 0.0000342238*I/V_a
For S_v,ar<S_v,ir
, the total rewards drop linearly down to the minimum inflation rate I_min
for S_v,ar = 0
For S_v,ar>S_v,ir
, the total rewards drop exponentially down to the minimum inflation rate for I_min
S_v,ar = 1
.
The exact formula:
R_v,te = I * (I_min + (I_max - I_min) * 2^((S_v,ir − S_v,ar) / F_v)) * era_l / year
The tJOY rewards for the validators can be calculated using this spreadsheet. The examples below should assist in using it:
In addition to the fixed parameters above (except S_v,ir
= 25%
), suppose:
V_a = 20
I = 100,000,000tJOY
S_v = 25,000,000tJOY
As S_v / I = 0.3
, meaning S_v,ar = S_v,ir
the maximum yearly inflation rate I_max = 75%
will be shared among the validators. Each era, the total, R_v,te
and individual, R_v,ie
reward for the validators are:
R_v,te = I * I_max * era / year
= 100,000,000tJOY * 0.75 * 3600s / (31556952s)
= 8,556tJOY
R_v,ie = R_v,te / V_a
= 8,556tJOY / 20
= 428tJOY
In addition to the fixed parameters above, suppose:
V_a = 20
I = 100,000,000tJOY
S_v = 20,000,000tJOY
With S_v / I = 0.2
. Each era, the total, R_v,te
and individual, R_v,ie
reward for the validators are:
R_v,te = I * (I_min + (I_max - I_min) * S_v,ar / S_v,ir) * era_i / year
= 6,959tJOY
R_v,ie = R_v,te / V_a
= 6,959tJOY / 20
= 348tJOY
In addition to the fixed parameters above, suppose:
V_a = 20
I = 100,000,000tJOY
S_v = 30,000,000tJOY
With S_v,t=S_v,eff/I=0.3
. Each era, the total, R_v,te
and individual, R_v,ie
reward for the validators are:
R_v,te = I * (I_min + (I_max - I_min) * 2^((S_v,ir − S_v,ar) / F_v)) * era_l / year
= 4,563tJOY
R_v,ie = R_v,te / V_a
= 4,563tJOY / 20
= 228tJOY
As seen above, the difference from staking 5% more or less than the ideal, is quite substantial.
More information on the staking, rewards and slashing mechanics can be found on the Web3 Foundation's research papers here.
Just as the Validators are rewarded for producing, propagating and securing the network, they are punished for misbehaving. The slashing mechanics are more complex, so it will not be covered as detailed as the rewards.
Although there are other reasons for getting slashed as a Validator, the reasons that stem from intentional malicious behavior will not be covered here. If you want to learn more about the details of slashing, visit this guide from the Polkadot wiki guide on slashing (and staking).
The most likely reason a Validator will get slashed is for going offline without first stopping gracefully.
If n
Validators go offline, there will be two "events" at the end of that session
:
imOnline:SomeOffline
offences.Offence
Suppose we have two Validators offline, - v_0
and v_1
. v_1
has one nominator n_1
(all accountId
/address of their "stash").
When selecting the block the event occurred in from the explorer, it will appear like so:
1 imOnline:SomeOffline
:
At the end of the session, at least one validator was found to be offline.
Vec<IdentificationTuple>
0: IdentificationTuple: IdentificationTuple
[
<v_0>,
{
total: <v_0 stake> JOY,
own: <v_0 stake> JOY,
others: []
}
]
1: IdentificationTuple: IdentificationTuple
[
<v_1>,
{
total: <v_1+n_1 stake> JOY,
own: <v_1> JOY,
others: [
{
who: <n_1>,
value: <n_1 stake> JOY,
}
]
}
]
This identifies which valididators are reported "offline".
2 offences.Offence
:
There is an offence reported of the given `kind` happened at the `session_index` and (kind-specific) time slot. This event is not deposited for duplicate slashes. Last element indicates of the offence was applied (true) or queued (false).
Kind
im-online:offlin
OpaqueTimeSlot
0xsomething
bool
<Yes> or <No>
The key here is whether bool
is Yes
(true
) or No
(false
).
Yes/true
, this means a slash will be applied.No/false
, this means no slash will be applied.The magnitude of the slash (and whether one will be applied at all), depends on the max number of Validator slots allowed (V_max
), and the number of Validators reported offline V_off
.
V_off / V_max
< 1/10
V_off / V_max
> 1/3
*
The exact formula, from the comment in the codebase, is presented below (with variables changed for clarity):
// the formula is min((3 * (V_off - (V_max / 10 + 1))) / V_max, 1) * 0.07
// basically, 10% can be offline with no slash, but after that, it linearly climbs up to 7%
// when 13/30 are offline (around 5% when 1/3 are offline).
*
A single Offence
adds an entry to the Validators slash span
. The actual slashing (burning) of tokens will happen ~24h hours later. For more info, we again refer to the Polkadot Wiki
If you had any issues setting it up, you may find your answer here!
Due to an unfortunate error in Pioneer which we are working to fix, unstaking requires either lots of patience, or using the chain state/extrinsics tab for certain tasks.
If you stop validating by killing your node before unstaking, you will get slashed and kicked from the Validator
set. If you know in advance (it can take up to 70min) you can do the following steps instead:
Validator -> Account Actions
, click Stop
.If you are just pausing the validator
and intend to start it up later, you can stop here. When you are ready to start again, fire up your node, go to Validator Staking
, and click Validate
.
If you want to stop being a validator
and move your tokens to other/better use, continue.
Validator -> Account Actions
), next to your keypair, click the rightmost triple dotted "settings" button, select Unbond funds
, and choose the amount you wish to unbond.After the transaction has gone through, you will see a new line appearing in the bonded
column, showing the amount and a "clock" icon. Hovering over this with your cursor will tell you when your unbonding is complete (starts at <24h / <14,400 blocks), and you can go to the third and final step.
bonded
column, showing the amount you can claim and a blue "lock" button. Click the button to finalize the unbonding, and your tokens will be "free" to spend from your "stash".Notes:
eras
:
<amount>, <time_left>, <block_left>
First, make sure you have set Fully Featured
interface in the Settings
sidebar.
<tot_bonded>
Is the total amount you have staked/bonded<act_bonded>
Is the number of tokens that is not being unlocked<unbonding_n>
Is the number of tokens that is in the process of being freed from your n
th Unbond funds
requestsum <unbonding_n>
+ <act_bonded>
= <tot_bonded>
<era_unbonded_n>
Is the era
when your n
th Unbond funds
request tokens will be "free" to transfer/bond/voteTo find out if you have started/completed your n
unbonding(s):
chain state query of ledger(AccountId): Option<StakingLedger>
with the controller. Output:
# If you have successfully initiated unbonding, but the tokens are not unlocked:
{
stash: 5YourStashAddress,
total: <tot_bonded> JOY,
active: <act_bonded> JOY,
unlocking: [
{
value: <unbonding_0> JOY,
era: <era_unbonded_0>
},
{
value: <unbonding_1> JOY,
era: <era_unbonded_1>
},
...
{
value: <unbonding_n> JOY,
era: <era_unbonded_n>
}
],
claimedRewards: [
<era_a>,
<era_b>,
...
<era_i>,
]
}
Note:
To understand what claimedRewards
means, go here.
The era
should only change every 600 blocks, but certain events may trigger a new era. To calculate when your funds are "free" In Chain State
-> staking.currentEra()
. Let output be <era_current>
If <era_unbonded_n>
>= <era_current_n>
, you can claim the unbonded funds in step 3.
controller
, select staking.withdrawUnbonded(num_slashing_spans)
Note: If you have any "pending" slashes, this will require some more chain state queries, to find the input num_slashing_spans
.
Your tokens will be "free" to spend from your "stash".