This tutorial helps you stake and manage XPRT tokens using the Keplr Browser Extension together with your Ledger device.
This guide will help you
Before you start:
See below for our step-by-step guide.
2. Type the account name you wish to use, then click ‘Next’.
3. Plug in and unlock your Ledger device. Open the Persistence app and click ‘Next’.
4. Your Keplr account should now be successfully connected to your Ledger device.
Now you will need to deposit XPRT into your wallet.
1. Open the Keplr Browser Extension and choose your Ledger account (via the ‘human icon’ on the top right).
2. Find your Persistence wallet by selecting the drop down menu on the top.
3. Copy your address by clicking on it as indicated in the image below. Alternatively you can select "Deposit" to find your address QR code.
Once you have deposited your XPRT and you own a balance on your Keplr wallet, you are now ready to start staking!
1. To start staking select "Stake". You will be prompted to the web version of the Keplr wallet where you will see a list of validators.
2. Choose your validator (P2P.ORG - P2P Validator) then click ‘Manage’ and ‘Delegate’ in the next picture.
3. Choose the amount of XPRT you want to stake and click ‘Delegate’.
4. Set your preferred fee and select "Approve".
5. Check the information on your Ledger device and click ‘Approve’ on it.
6. Use the Dashboard within the Keplr Web Wallet to see whether your delegation was successful.
Now let’s move on to managing your staking assets.
1. Open the Keplr Browser Extension and click ‘Claim’.
2. Set your preferred fee and select "Approve".
3. Plug in your Ledger device, unlock, and open the Persistence app on it, then click ‘Next’ in the Browser Extension pop-up.
4. Review the transaction on your Ledger device and confirm it.
To compound, you simply have to claim your XPRT rewards and go through the staking process again as in section III. That’s it!
Now you know how to delegate and compound your XPRT staking rewards using the Keplr Browser Extension together with your Ledger device.
If any questions arise, whether on XPRT staking or not, feel free to contact us via Twitter, Telegram, or email.
About P2P Validator
P2P Validator is a world-leading non-custodial staking provider with the best industry practices and proven expertise. We provide comprehensive due-diligence of digital assets and offer only high class staking opportunities securing more than 3 billion of USD value at the time of the latest update.
P2P Validator is trusted by over 24,000 delegators across 25+ networks. We are a major player in all networks we support because of our experience, commitments and our reputation. We pay special attention to the process of governance. P2P has the intention to contribute and provide long term support to the Persistence (XPRT) network.
Get the latest posts delivered right to your inboxSubscribe
<h2 id="summary"><strong>Summary</strong></h2><p>One of our Validator nodes went offline at the end of era 3281 until the start of era 3282 as the result of the corruption of a blockchain database that was being used. This led to the inability to produce blocks for <strong>2h:45m.</strong></p><h2 id="what-happened"><strong>What happened</strong></h2><p>A database that we were using to run our validator node crashed. We immediately took action and started deploying a new node using a recent snapshot of our disk. Once fully synced, new keys were generated and signed off before turning the validation service back on. As we created a new validator with the rotation of session keys, we were forced to chill for an additional epoch.</p><h2 id="customer-impact"><strong>Customer Impact</strong></h2><p>Delegators who nominated this validator and had their stake allocated to it will receive lower rewards than it could have potentially earned for 2 epochs.</p><h2 id="what-went-wrong"><strong>What went wrong?</strong></h2><p>Inadequate tools for this particular event. We did not deploy the db from our backups (pruned) because on occasion, we faced issues with our automation running too long. Additionally, we had not recovered the session keys since it’s always a risky option and the situation at hand did not warrant taking such risks.</p><h2 id="what-went-well"><strong>What went well?</strong></h2><p>It was immediately notified that the node stopped producing blocks and the root cause was identified almost instantly. This allowed us to swiftly amend the occurrence, and with the help of fully automated key rotation/verification and signing cycle, we were able to get a fully operational node running in an effective manner.</p><h2 id="lessons-learnt-and-action-plan"><strong>Lessons learnt and action plan</strong></h2><p>Improve our incident handling procedures and find a faultless and rapid fix for these kinds of events. We already improved and reached faster spin up for fully synced nodes and will implement a solution for safe session keys management.</p><p>P2P takes full responsibility for the event that led to the weak performance and we are sorry for the inconvenience. Please be assured that P2P is taking actions to eliminate even a small probability of such an event occurring in future.</p><hr><p><em>If you have any questions feel free to join our</em><a href="https://t.me/P2Pstaking"><em> Telegram chat</em></a><em>, we are always open for communication.</em></p>
<h2 id="tldr"><strong>TLDR</strong></h2><p><br>Due to a sudden spike of transactions, mainnet validator node ran out of disk space, leading to inability to produce blocks and corruption of the node state.</p><h2 id="what-happened"><strong>What happened?</strong></h2><p><br>Disk usage grew quite fast and mainnet pool p2p-org.poolv1.near stopped producing blocks since ~07:00 UTC on 16th of January. Epoch ended ~10:00 UTC and by that time the node had surpassed the epochal kick-out threshold for downtime. Therefore, it was scheduled for temporary kick-out for the next two epochs. While resolving the issue, the validator remained offline for the following epoch resulting in one additional forfeit epoch. Overall, the node was offline for ~3,25 epochs and the validator pool lost 4 full epochs of staking rewards.</p><h2 id="what-went-wrong"><strong>What went wrong?</strong></h2><p><br><strong>The potential impact of the issue was underestimated.</strong></p><p>It was expected to rely on a recent state snapshot that would be readily available. We had no cold backup of a recent node state while available backup nodes were subject to the same issue leading to a loss of access to a synced node. In fact, the official public back-up archives were corrupted too. A <a href="https://github.com/near/nearcore/issues/6095">GitHub issue</a> was created afterwards.</p><p><strong>Monitoring was insufficient.</strong></p><p>Near validation infrastructure was undergoing an overhaul, some monitoring facilities were offline. It was expected that the amount of space used on disk would grow more or less linearly. With ~100 GiB of free space it could last for a month. Space clogged up in a matter of days while disk monitoring was not set appropriately to catch the spike and warn in advance.</p><h2 id="what-went-well"><strong>What went well?</strong></h2><p><br>It was immediately notified that node stopped producing blocks and the root cause was identified almost simultaneously. Quite a few validators were affected by the issue, and the community was very helpful.</p><h2 id="impact-on-clients"><strong>Impact on clients</strong></h2><p><br>All our Near delegators were affected and lost four epochs of staking rewards. To compensate our delegators in full and mitigate their loss, P2P waived the fees until the end of February.</p><h2 id="lessons-learned"><strong>Lessons learned</strong></h2><p><br>We should have had better monitoring and collecting disk usage metrics from all nodes at all times including mainnet, backup and Near RPC node. It is important to ensure that back-up nodes are running & synced at all times. In addition, it is important to establish the process of making cold snapshots of the node state on a regular basis and spread this practice to all available networks.</p><p>P2P takes full responsibility for the event that led to the weak performance and we are sorry for the inconvenience. Please be assured that P2P is taking actions to eliminate even a small probability of such an event occurring in future.</p><hr><p><em>If you have any questions feel free to join our</em><a href="https://t.me/P2Pstaking"><em> Telegram chat</em></a><em>, we are always open for communication. </em><br><em>Special thanks to Evgeny Kuzyakov & DenysK for providing a state snapshot and general support.</em></p><hr>