# Staking and Transaction Timing ### Overview Proof of Stake allows coin holders to earn rewards by keeping their wallet online and staking their coins to help secure the network. When your wallet successfully stakes a block, you receive newly minted coins as a reward plus any transaction fees included in that block. (In a traditional sense, think of it like your savings account is earning interest. The more money you have, the more interest you earn.) However, these staking rewards come with a maturity period requirement that can affect your ability to send transactions immediately. This document explains how staking works, why it can delay transactions, and how to manage your staking settings to avoid complications. ### How Staking Affects Transactions When you earn a staking reward, those newly minted coins and collected transaction fees cannot be spent immediately. The network enforces a thirty-block maturity period before staked coins become spendable. This security measure ensures that if a staking block becomes orphaned due to a chain reorganization, the coins that would have been created by that block never enter circulation. Without this maturity requirement, users could spend coins that might later disappear from the blockchain, creating serious accounting problems. With five-minute block times, the thirty-block maturity period translates to 150 minutes or approximately two and a half hours. During this window, any coins you earned from staking remain locked and cannot be included in outgoing transactions. If you attempt to send coins while a portion of your balance consists of immature staking rewards, you may encounter transaction delays or complications. ### Checking for Immature Coins Before attempting to send a transaction, you can verify whether you have recently earned staking rewards by examining your debug log. The debug log records all Proof of Stake blocks your wallet has successfully staked. If you have not won any stakes in the previous thirty blocks (approximately 150 minutes), all your coins should be mature and available for immediate spending. To check your staking activity, locate your debug log file at `~/.[daemon]/debug.log` and search for recent Proof of Stake entries. If you see staking activity within the last two and a half hours, you should wait for the maturity period to complete or temporarily disable staking before sending coins. **Example for Lynx users:** Your debug log would be located at `~/.lynx/debug.log`. Search for entries indicating "New proof-of-stake block found" or "CheckStake()" to identify recent staking activity. ### Option 1: Send Without Disabling Staking If your debug log shows no staking activity in the previous thirty blocks, you can send transactions immediately without changing any settings. Your coins are already mature and the staking process will not interfere with your transaction. This is the simplest approach when you have not recently earned staking rewards. Simply execute your standard send command and your transaction will process normally. The staking thread continues running in the background but will not affect your transaction since all coins in your wallet have already matured. ### Option 2: Disable Staking Temporarily If you need to send coins immediately but recently earned staking rewards, you can temporarily disable staking without restarting your wallet using the `setstaking` RPC command. This approach provides immediate control over the staking function and is ideal for one-time transactions. To disable staking immediately, execute this command: ``` [daemon]-cli setstaking false ``` **Example for Lynx:** `lynx-cli setstaking false` Once staking is disabled, wait for any immature coins to mature. You can monitor the maturity progress by checking the block height. Once thirty blocks have passed since your last stake, all coins become spendable and you can safely send your transaction. To re-enable staking after completing your transaction, execute this command: ``` [daemon]-cli setstaking true ``` **Example for Lynx:** `lynx-cli setstaking true` The `setstaking` command takes effect immediately without requiring a daemon restart. However, this setting is temporary and will revert to whatever is configured in your `[daemon].conf` file the next time you restart the wallet. Use this method when you need immediate control but don't want to permanently change your staking behavior. To determine if the staker is enabled, you can execute the following command (with no argument). The response will be true (the staking thread is enabled and running) or false (staking is off and no staking effort is taking place). ``` [daemon]-cli setstaking ``` **Example for Lynx:** `lynx-cli setstaking` ### Option 3: Disable Staking Permanently For users who frequently send transactions and want to avoid maturity delays altogether, you can permanently disable staking through the configuration file. This approach requires a daemon restart but provides a persistent setting that survives wallet restarts. Open your configuration file located at `~/.[daemon]/[daemon].conf` and add or modify the `disablestaking` parameter: ``` disablestaking=1 ``` **Example for Lynx:** Edit `~/.lynx/lynx.conf` and set `disablestaking=1` After saving the configuration file, restart your daemon for the change to take effect. Staking will remain disabled until you change this setting back to `disablestaking=0` and restart again. To re-enable staking permanently, change the parameter to: ``` disablestaking=0 ``` Then restart the daemon. This configuration provides long-term control over staking behavior and is the recommended approach if you have a consistent preference for whether staking should be enabled or disabled. ### Understanding Transaction Delays and Stuck Transactions When you attempt to send coins while a portion of your balance consists of immature staking rewards, your transaction may become stuck. This happens because the wallet attempts to construct a transaction using all available coins, including those that have not yet matured. The network rejects these transactions because immature coins cannot be spent, leaving your transaction unconfirmed in the mempool. A stuck transaction can be alarming because it appears that your coins have been sent but the recipient never receives them. The transaction shows as pending in your wallet, reducing your available balance, but never confirms on the blockchain. This state can persist for up to twenty-four hours as network nodes simply hold it in their mempools until it expires. Eventually, all nodes drop the unconfirmed transaction from their mempools and your coins return to your spendable balance. **Important:** Your coins are never lost during this process. The transaction failure is purely temporary and your full balance will be restored once the stuck transaction is abandoned or dropped by the network. However, the experience can cause significant confusion and concern, which is why following the proper procedure for managing staking and maturity is important. ### Resolving Stuck Transactions If you have already sent a transaction that has become stuck due to immature coins, you can immediately resolve the issue using the `abandontransaction` command. This command tells your wallet to stop tracking the stuck transaction and return the coins to your available balance (this only applies to unconfirmed transactions). To abandon a stuck transaction, you need the transaction ID (txid). You can find this in your wallet's transaction list or by checking recent transactions in your debug log. Once you have the txid, execute: ``` [daemon]-cli abandontransaction "txid" ``` **Example for Lynx:** `lynx-cli abandontransaction "a1b2c3d4e5f6..."` Replace the quoted txid with your actual transaction identifier. After executing this command, your coins immediately become available again in your wallet. You can then follow the proper procedure of disabling staking, waiting for maturity, and sending your transaction again. The `abandontransaction` command only affects your local wallet's tracking of the transaction. If the transaction was broadcast to the network, some nodes may still have it in their mempools, but it will eventually be dropped as unconfirmable. Your wallet will no longer attempt to rebroadcast it after you execute the abandon command. ### Best Practices for Managing Staking and Transactions For users who actively stake and regularly send transactions, consider these approaches to minimize complications: **For frequent senders:** Keep `disablestaking=1` in your configuration file and only enable staking during periods when you do not need to send transactions. This ensures your full balance is always immediately available for spending. **For infrequent senders:** Leave staking enabled and check your debug log before sending transactions. If you have recently staked, wait the full 150-minute maturity period before sending, or temporarily disable staking using the `setstaking false` command. **For maximum rewards:** Keep staking enabled at all times and plan your outgoing transactions around the maturity cycle. Check your last stake time, add 150 minutes, and schedule your sends after that window completes. Understanding the relationship between staking, maturity, and transaction timing allows you to manage your wallet effectively while maximizing staking rewards and maintaining the ability to send coins when needed. The maturity requirement serves an important security function in Proof of Stake consensus, and working with this requirement rather than against it ensures smooth wallet operation. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.getlynx.io/lynx-administration/staking-and-transaction-timing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.