Chia Network Transaction Fees Explained: Mempool Dynamics, Common Issues and Solutions

Blockchain technology seems to be forever evolving, so understanding the intricacies of transaction processing is crucial for both enthusiasts and newcomers. The Chia blockchain, known for its innovative approach to digital currency, presents a unique ecosystem where the mempool and transaction fees play pivotal roles. This article, delves into the heart of Chia’s network operations, offering insights into how transactions are managed and prioritized. It’s a journey into the core of Chia’s blockchain, where the mempool serves as a bustling hub, orchestrating the flow of transactions with efficiency and precision.

For the uninitiated, the concept of a mempool might seem daunting, but it’s essentially a waiting area for transactions before they are confirmed on the blockchain. Think of it as a digital lounge where transactions mingle, waiting for their turn to be included in a block. This article breaks down the complexities of the mempool and transaction fees into digestible segments, ensuring that even those new to Chia’s technical workings can grasp these fundamental concepts. It’s a blend of technical detail and accessible explanations, perfect for technology geeks eager to deepen their understanding and for beginners taking their first steps into the world of Chia blockchain.

Chia Network’s Mempool Size and Transaction Prioritization

The Chia blockchain is busy! But don’t worry – the network continues to function as designed. A natural fee market is emerging, demonstrating a positive trend of adoption, activity, and use on the Chia blockchain. The network is robust – blocks continue to be made at the same rate, even when the mempool is full. If you want your transaction to be included quickly while the network is busy, you will need to include a fee, which will be paid directly to the farmer who creates the block that includes your transaction.

This post should help to clarify how to think about fees.

This post is divided into four parts:

• Chia’s Mempool – a description of the mempool, what it does, and why it exists
• Chia’s Fees – a description of fees, how they work, and why they exist
• Recent blockchain activity – the current status of the mempool as of this writing, and how this affects fees
• Common issues and solutions – the primary issues that cause transactions process more slowly, and how to solve them

Chia’s Mempool

This will get pretty technical: 

• The mempool is a queue, which nodes use by default to prioritize transactions.
• The suggested transaction fee depends on how full the mempool is.
• The higher the fee, the more likely a transaction is to be included in the next block.

Each node on the network maintains its own queue of pending transactions called a mempool. When you submit a new transaction, your wallet sends it to a full node to be included in its mempool. Nodes are instructed to broadcast all mempool items to each of their peers, which in turn broadcasts the items to their peers, and so on. Thus, within a few seconds after you have submitted your transaction, it will propagate to every node on the network.

The mempool provides a list of suggested transactions for a node to include when it creates a block. This list is not part of Chia’s consensus – each node is free to ignore it. However, by default, nodes will include the transactions from the front of the queue – those that will result in the highest rewards. Blockchain fees are sent directly to the farmer that created the block, so farmers are incentivized to maintain the default behavior of prioritizing the highest-value transactions first.

Most farming software uses the reference farmer’s default size for its mempool. A few things to note:

• In versions 2.1.3 and earlier, the default mempool size was 50 blocks.
• Starting with version 2.1.4, the default mempool size will be 10 blocks. We chose the new size to maintain a balance between being large enough to allow most transactions to be included in a “pending” state, yet small enough for nodes to handle the logic of validation and prioritization.
• The mempool’s size is based on full blocks, which have a maximum CLVM cost of 11 billion. Currently, the block size is limited to 50% of the full size; the actual mempool size is double the default size while this limiter remains in place.

You can check the status of the mempool at dashboard.chia.net and can download 2.1.4 here

Chia’s Fees

Whenever you submit a transaction to the mempool (for example, to send XCH to another wallet or to transfer an NFT), you have the option of including a fee. The recommended fee depends on multiple factors, such as the transaction’s CLVM cost, as well as how full the mempool currently is.

CLVM cost

When a coin is spent, its puzzle (the CLVM program that makes up the coin) is run, along with a solution to the puzzle and an optional digital signature. Puzzles and their solutions come in a wide variety of sizes, depending on their functionality. A standard transaction, where a user sends XCH to another user, is one of the simpler puzzles to run. NFT puzzles, on the other hand, are at least ten times as large.

We measure the complexity of a puzzle by its CLVM “cost,” which roughly corresponds to the computing power required to run it. The CLVM cost of a standard transaction where one coin is being spent and one coin is being created is around 6 million. Standard transactions can also involve multiple coins, so their CLVM cost can be significantly higher.

With the aforementioned limiter in place, the maximum CLVM cost of a block is 5.5 billion. This means that nearly 1000 transactions with a CLVM cost of 6 million can fit into a block.

When prioritizing the mempool’s contents, nodes will calculate a transaction’s fee per cost, rather than just its fee. Let’s say two transactions are added to the mempool:

• A standard XCH spend
  • CLVM cost: 6 million
  • Included fee: 30 million mojos (5 fee per cost)
• An NFT transfer
  • CLVM cost: 67 million
  • Included fee: 100 million mojos (1.5 fee per cost)

In this case, the fee per cost of the XCH spend is 5 mojos, so it will be prioritized ahead of the NFT transfer, with a fee per cost of 1.5 mojos. The fact that the fee included with the NFT transfer is higher is unimportant with respect to how it is prioritized in the mempool.

This makes sense when put into a broader context. For each NFT transfer included in a block, around 11 XCH spends from this example could be included. To put it another way, a full block, with a maximum CLVM cost of 5.5 billion, could include nearly 1000 XCH spends similar to the one from this example, but it could only include 82 NFT transfers. This is why the software prioritizes transactions by fee per cost, rather than by fee alone.

Mempool Contents

The other primary factor which affects the suggested fee is how busy the mempool currently is, demonstrated in three scenarios.

Scenario 1: Mempool is not busy

• Minimum fee to enter the mempool: zero
• Minimum fee to be included in the next block: zero

The mempool is considered “not busy” when its entire contents will fit into one block. In this scenario, nodes that use the default mempool logic will include every pending transaction when building a new block. They do this because there is no incentive for picking only certain transactions – they might as well include everything. When the mempool is in this state, your transaction is likely to be included in the next transaction block, regardless of whether you included a fee.

Scenario 2: Mempool is busy, but not full

• Minimum fee to enter the mempool: zero
• Minimum fee to be included in the next block: depends on mempool’s contents

The mempool is considered “busy” when it contains more transactions than will fit in a single block. When the mempool is in this state, nodes will need to prioritize which transactions to include. By default, the logic used will maximize profits for the farmer. If you don’t include a fee with your transaction, it will be added to the end of the queue. If you instead include a fee of one mojo, your transaction will be prioritized ahead of those with zero fees, and so on.

Scenario 3: Mempool is full

• Minimum fee to enter the mempool: five mojos per cost
• Minimum fee to be included in the next block: depends on mempool’s contents

The final situation to consider is when the mempool is full. In this state, a new transaction cannot be added to the mempool without kicking another transaction out. By default, if the new transaction has a fee of less than five mojos per cost, the node will prioritize it the same as a transaction with zero fee. Such a transaction likely will not even make it into the mempool.

A transaction that meets the five-fee-per-cost threshold will be prioritized accordingly; one or more of the lowest priority transactions will be kicked out of the mempool in order to make room for the new transaction.

Recent Activity

As of this writing, the mempool is usually full. This means that Scenario 3 applies. Your transactions will need to include a fee of at least five mojos per cost in order to be included in the mempool.

A basic XCH spend (CLVM cost: 6 million) will therefore require a fee of at least 30 million mojos. Chia’s documentation lists the CLVM cost for various other transaction types.

The exact costs can be difficult to figure out by hand. However, the reference wallet includes a fee estimator that should provide an accurate fee. Simply select the appropriate fee to prioritize your transaction, as shown above.

*Note that as of version 2.1.4, there is a bug in the fee estimator. While it typically provides an accurate fee (as in the image above), it occasionally provides an underestimate. If you want to be more certain that your transaction will be processed quickly, you may want to enter a custom fee of 100 million mojos (0.4 US cents as of this writing) for standard XCH spends, or 1 billion mojos for more complex spends, such as those involving Offers, CATs, or NFTs. For the exact fee recommendations for various types of transactions, see Chia’s documentation.

Common Issues and Solutions

Problem: Transaction pending for a long time

If your transaction is in a “pending” state for more than a few minutes, it has entered the mempool, but has yet to make it to the front of the queue. As mentioned above, a transaction in this state is not guaranteed to be included in a future block. For example, transactions with higher fees could continuously enter the queue ahead of your transaction.

Solution: RBF

If you want your transaction to be given a higher priority, one option is to use Replace By Fee (RBF). The first step is to select “Delete Unconfirmed Transactions” in your wallet. This is only applied locally – your wallet will no longer reserve the coin(s) that had been used for the transaction, but your transaction will still be stuck in mempools throughout the network.

The next step is to use RBF against your pending transaction. In order for RBF to be applied, you must submit a new transaction, following these rules:

1. Include at least all of the coin spends from the original transaction.
2. Pay a fee that meets each of the following criteria:
   1. The new fee must be at least ten million mojos higher than the original fee.
   2. The new fee per cost must be higher than that of the original transaction.
   3. The new fee per cost must be at least five mojos.
3. Include the same time-locks as the original transaction (if there were any).

As long as you follow each of these rules, your new transaction will replace your original one throughout the network.

Note: We’re aware that this is an advanced feature. We plan to make it much easier to use RBF in a future release.

Problem: INVALID_FEE_TOO_CLOSE_TO_ZERO or INVALID_FEE_LOW_FEE

If you receive either of these errors when submitting a transaction, the included fee was not large enough for inclusion into the mempool.

Solution: Wait or resubmit

By default, your wallet will retry the transaction after 30 minutes. It may therefore go through if you simply wait. However, this is not guaranteed (it depends on the mempool’s status after 30 minutes). You can also resubmit the transaction and include a fee of at least five mojos per cost, which will give it a better chance of being added to the mempool.

Problem: MEMPOOL_CONFLICT or DOUBLE_SPEND

These errors generally indicate that at least one of the RBF rules was not followed. The most common reason: at least one of the coin spends from the original transaction was not included in the RBF attempt. When sending less than 70% of your funds, there is a high probability that your wallet will select at least one different coin than what was originally selected.

Solution: Redo RBF

If you see either of these errors, you can attempt a new RBF spend. However, if you simply send the same amount again, you will likely run into the same issue. Imagine reaching into a coin jar and pulling out a handful of coins. If you put the coins back into the jar and take out some new coins, it is likely that at least one of the coins from your first handful will be missing from your second handful.

One way to ensure that this will work is by sending your entire balance to yourself, minus an appropriate fee. This is like removing every coin from the jar on your second attempt. In this case, you are guaranteed to have chosen all of the original coins.

After you have sent your entire balance to yourself, you can redo the original transaction. Be sure to include a sufficient fee.