Transaction commitment levels on Solana Explained
One of Solana's most prominent features is its ability to process transactions quickly and efficiently. When a transaction is sent to Solana, it goes through a process called "commitment". This is where the transaction is validated, recorded in the blockchain, and made permanent.
The commitment metric gives clients a standard measure of the network confirmation for the block. It describes how finalized a block is at that point in time and clients can then use this information to derive their own measures of commitment.
Here are the different commitment levels, in descending order (most finalized to least finalized) that exist in Solana:
finalized
- This is the highest level of commitment and transactions are irreversible. The RPC node will query the most recent block confirmed by the supermajority of the cluster as having reached maximum lockout, meaning the cluster has recognized this block as finalized. Transactions at this level also tend to have a higher transaction fee.
confirmed
- This commitment level is usually used for transactions that have been included in a block, but have not yet been confirmed by the network. The node will query the most recent block that has been voted on by the supermajority of the cluster (optimistic confirmation)
processed
- Here, the node will query its most recent block but the block may still be skipped by the cluster if the transaction fails. This is the least secure of all the three levels and transactions in this level are usually used for testing and development purposes and are not recommended for use in production environments.
As you can see, the natural state of progression for commitment levels on Solana is from processed
→ confirmed
→ finalized
.
In general, the higher the commitment level of a transaction, the more secure it is and the less likely it is to be reversed. However, it's worth noting that the time it takes for a transaction to reach a higher commitment level will depend on various factors such as the number of validators and the network's load.
Let's look at how Mirror World handles commitment levels.
How Mirror World uses commitment levels
By default, our API uses the confirmed
commitment because it provides a fairly quick response to the user and is optimistic.
However, most requests (especially POST
requests) accept the confirmation
parameter as an option. Some of these include:
- Mint NFT
- Mint Collection
- Mint New NFTs on Collection
- Update NFT Properties
- Transfer NFT
- List NFT
- Cancel NFT Listing
- Buy NFT
The choice of commitment level depends on the use case and the urgency of the transaction. There are some scenarios where you may want to change the default confirmed
commitment to finalized
. For example, if you're making a small transfer and it's not time-sensitive, you may choose to commit it at the confirmed
level. On the other hand, if you're making a large transfer or a trade, you may choose to commit it at the finalized
level to ensure that it's processed as soon as possible.
example HTTP Request to Buy NFT:
curl --location --request POST 'https://api.mirrorworld.fun/v1/devnet/solana/marketplace/transaction/buy' \--header 'Content-Type: application/json' \--header 'Accept: application/json' \--data-raw '{ "mint_address": "9pd6wUcfZpPBsrQFxqEkMjfbyaqraQRsiQtD8D4wqa6W", "price": 1.1, "confirmation": "finalized"}'
example HTTP Request to update NFT properties:
curl --location --request POST 'https://api.mirrorworld.fun/v1/devnet/solana/mint/update' \--header 'Content-Type: application/json' \--header 'Accept: application/json' \--data-raw '{ "mint_address": "FPiveD2LMFwDKPBGdEk6Ty7hf69hYbNHUuNicGUVy8PS", "name": "Dope NFT #1", "symbol": "DOPENFT", "update_authority": "9x1sRqFoZTkDtYVKwuVanE7s5LSA2hERZ8FRnU37S2L8", "url": "https://market-assets.mirrorworld.fun/gen1/631.json", "seller_fee_basis_points": 200, "confirmation": "confirmed"}'
Edit this page on GitHub