near · matiasbenary · Dec 15, 2025 · Dec 15, 2025 · Dec 16, 2025 · Dec 18, 2025
@@ -0,0 +1,87 @@
+---
+title: Benchmarking Blockchain
+authors: [matiasbenary]
+slug: blockchain-finality-benchmark
+tags: [benchmark, performance, finality]
+---
+
+*While each has its own theoretical finality, an important question for devs is "how long does it *actually* take for my app that a transaction is final". In this post, we send transactions across 6 different chains and waited for them to be final to compare them empirically*
+
+
+<!-- truncate -->
+
+## Understanding Finality in Blockchain
+
+When you send a transaction on a blockchain, how long does it take to be truly final? This question is critical for developers building applications, especially those requiring fast confirmations like payments, gaming, or DeFi.
+
+There are two main types of finality:
+
+- **Soft Finality (Optimistic)**: The transaction is included in a block and is *unlikely* to be reversed, but there's still a small chance of reorganization
+- **Hard Finality**: The transaction is irreversibly committed to the blockchain with cryptographic guarantees
+
+
+For example, here are the **theoretical finality times** for 6 popular blockchains:
+
+| Blockchain       | Optimistic Finality | Hard Finality | Validators/Nodes | Hardware Requirements |
+|------------------|---------------------|---------------|------------------|-----------------------|
+| NEAR Protocol    | 600ms | [1.2 seconds](https://pages.near.org/blog/blink-and-its-final-near-launches-600ms-blocks-and-1-2s-finality/) | [~350](https://nearblocks.io/node-explorer) | [8 cores, 8GB RAM, 1TB SSD](https://near-nodes.io/validator/hardware-validator) |
+| Aptos            | 130ms | [650ms](https://blockchain.news/flashnews/aptos-sets-industry-record-with-130ms-block-times-and-650ms-finality-implications-for-crypto-traders) | [~135](https://explorer.aptoslabs.com/analytics?network=mainnet) | [32 cores, 64GB RAM, 3TB SSD](https://aptos.dev/network/nodes/validator-node/node-requirements) |
+| Arbitrum         | [250ms](https://docs.arbitrum.io/launch-arbitrum-chain/faq-troubleshooting/troubleshooting-building-arbitrum-chain#what-is-the-max-theoretical-tps-for-an-arbitrum-chain) | [~15 minutes](https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#step-4-finality) | [1 sequencer](https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer) | [4 cores, 16GB RAM, NVMe SSD](https://docs.arbitrum.io/run-arbitrum-node/run-full-node) |
+| Ethereum Sepolia | [2.4 minutes (12 blocks)](https://ethereum.stackexchange.com/questions/319/what-number-of-confirmations-is-considered-secure-in-ethereum) | [~15 minutes](https://ethereum.org/roadmap/single-slot-finality/) | [~12.000-10.000](https://etherscan.io/nodetracker) | [4 cores, 16GB RAM, 2TB SSD](https://geth.ethereum.org/docs/getting-started/hardware-requirements) |
+| Solana           | 400-600ms | [13 seconds](https://solana.com/developers/guides/advanced/confirmation) | [~820](https://solscan.io/analytics) | [12 cores, 256GB RAM, 2TB SSD, 1Gbps](https://docs.solanalabs.com/operations/requirements) |
+| Sui              | 500ms | [500ms](https://docs.sui.io/concepts/sui-architecture/consensus#transaction-throughput) | [~125](https://suiscan.xyz/mainnet/validators) | [24 cores, 128GB RAM, 4TB NVMe](https://docs.sui.io/guides/operator/validator/validator-config) |
+
+## Real-World Performance Benchmark
+
+Despite what the theoretical numbers say, real-world performance can differ due to network conditions, node performance, and other factors. To get a clearer picture, we conducted a benchmark test across six different blockchains.
+
+To put this to the test, we built simple benchmarking scripts which make 30 transactions on each network, and look to see how long it takes for both optimistic and hard finality.
+
+To be as fair as possible, we:
+
+- used testnet networks on all chains
+- made a simple transfer of native tokens to avoid complexities of smart contracts
+- used free and public RPC endpoints
+
+## What Does Optimistic Finality Actually Mean?
+
+It is important to remark that there is not a single definition on what optimistic finality means, and it can vary between blockchains. Here's how each blockchain in our benchmark defines optimistic finality:
+
+### NEAR Protocol
+On NEAR, we measure [`EXECUTED_OPTIMISTIC`](https://docs.near.org/api/rpc/transactions) which is reached when the transaction is [included in a block and all non-refund receipts have finished their execution](https://docs.near.org/protocol/transaction-execution). According to the official documentation, at this stage "the transaction is included into the block + all non-refund transaction receipts finished their execution," though the corresponding blocks may not yet be finalized. This represents an optimistic state where execution is complete but blocks are still being finalized by the network.
+
+### Aptos
+For Aptos, optimistic finality is measured as the time when the transaction is submitted and the transaction hash is returned, without waiting for confirmation. This represents the fastest possible response but with the least guarantees. For hard finality, we use [`waitForTransaction`](https://aptos.dev/build/sdks/ts-sdk/building-transactions) which waits until the transaction is committed to the blockchain and execution succeeds.
+
+### Solana
+Solana uses the [`confirmed` commitment level](https://docs.solanalabs.com/consensus/commitments) for optimistic finality, which means 66%+ of the validator stake has voted on the block. For hard finality, the [`finalized` commitment level](https://solana.com/docs/advanced/confirmation) requires 31+ confirmed blocks to be built on top of the transaction's block, making it economically irreversible.
+
+### Sui
+On Sui, optimistic finality uses `WaitForLocalExecution` which waits for the local node to execute the transaction. For hard finality, [`WaitForEffectsCert`](https://docs.sui.io/concepts/sui-architecture/transaction-lifecycle) waits for an effects certificate, which is a guarantee that the transaction will be included in a checkpoint and cannot be reverted.
+
+### Ethereum Sepolia & Arbitrum
+For EVM chains, optimistic finality is measured using block confirmations - 12 confirmations for Sepolia and 1 confirmation for Arbitrum. Hard finality uses Ethereum's [`finalized` block tag](https://ethereum.org/developers/docs/blocks/), which indicates the block has been accepted as canonical by more than 2/3 of validators, typically occurring after two epochs (~12-13 minutes for Ethereum).
+
+## Results
+
+Here is a summary of the average finality times observed during our benchmark:
+
+| Blockchain       | Optimistic Finality   | Hard Finality           |
+|------------------|-----------------------|-------------------------|
+| NEAR Protocol    | 2352ms ± 305ms        | 3499ms ± 244ms          |
+| Aptos            | 200ms ± 5ms           | 618ms ± 40ms            |
+| Arbitrum         | 2213ms ± 312ms        | 1440021ms ± 161901ms    |
+| Ethereum Sepolia | 151618ms ± 15050ms    | 1150564ms ± 5918ms      |
+| Solana           | 938ms ± 252ms         | 12973ms ± 279ms         |
+| Sui              | 1493ms ± 77ms         | 3152ms ± 30ms           |
+
+## Resources
+
+The complete benchmark data and analysis tools are open source and available on GitHub:
+
+- **Benchmark Data**: [matiasbenary/benchmarks](https://github.com/matiasbenary/benchmarks) - Raw benchmark results and histograms
+- **Network Analyzer**: [matiasbenary/networksAnalizer](https://github.com/matiasbenary/networksAnalizer) - Tool used to measure and analyze finality across different networks
+
+---
+
+*Want to build on NEAR? Check out our [developer documentation](/smart-contracts/what-is) to get started.*
@@ -0,0 +1,138 @@
+---
+title: Transaction Fee Analysis
+authors: [matiasbenary]
+slug: fee-analysis
+tags: [benchmark, fees, cost-efficiency]
+---
+
+*In this post, we analyze actual transaction fees across 6 different chains to help developers understand the real costs of running their applications*
+
+<!-- truncate -->
+
+## Understanding Transaction Fees
+
+When building applications on blockchain, transaction fees can significantly impact both user experience and operational costs. Whether you're building a payment system, a gaming platform, or a DeFi protocol, understanding the true cost of transactions is essential.
+
+Transaction fees are payments made to execute operations on a blockchain network. These fees compensate validators and miners for:
+
+- **Computational resources**: Processing and executing your transaction
+- **Storage**: Recording transaction data permanently on the blockchain
+- **Network bandwidth**: Broadcasting your transaction across the network
+- **Security**: Preventing spam and abuse by making operations cost something
+
+Transaction fees vary widely across blockchains due to:
+
+- **Network Congestion**: Higher demand typically leads to higher fees
+- **Consensus Mechanism**: Different mechanisms have different computational costs
+- **Token Economics**: The native token price directly affects USD-denominated fees
+- **Fee Models**: Fixed fees vs. gas-based pricing
+
+## How Transaction Fees Are Calculated
+
+Each blockchain has its own fee calculation mechanism:
+
+### NEAR Protocol
+NEAR uses a [gas-based system](https://docs.near.org/protocol/gas#cost-for-common-actions) where fees are calculated as:
+```
+Fee = Gas Units Used × Gas Price (in NEAR)
+```
+Gas units are determined by the computational complexity of operations (transaction processing, function calls, storage). The gas price is fixed at 0.0001 NEAR per gas unit, making fees predictable and stable.
+
+### Aptos
+Aptos implements a [gas system similar to Ethereum](https://aptos.dev/network/blockchain/gas-txn-fee) where:
+```
+Fee = Gas Units × Gas Price (in Octas, where 1 APT = 100,000,000 Octas)
+```
+The gas price is dynamic and adjusts based on network demand, with a minimum gas price to prevent spam.
+
+### Arbitrum
+As an Ethereum Layer 2, Arbitrum's [fees](https://docs.arbitrum.io/how-arbitrum-works/gas-fees) consist of:
+```
+Fee = L2 Gas Used × L2 Gas Price + L1 Data Fee
+```
+The L2 component covers Arbitrum computation, while the L1 data fee covers the cost of posting transaction data to Ethereum mainnet.
+
+### Ethereum
+Ethereum uses [EIP-1559 gas model](https://ethereum.org/en/developers/docs/gas/):
+```
+Fee = Gas Units × (Base Fee + Priority Fee)
+```
+The base fee is burned and adjusts based on network congestion. The priority fee (tip) goes to validators and incentivizes transaction inclusion.
+
+### Solana
+Solana uses a [simple fee structure](https://solana.com/docs/core/fees) with:
+```
+Fee = Number of Signatures × Lamports per Signature (5,000 lamports)
+```
+Where 1 SOL = 1,000,000,000 lamports. Most transactions have one signature, resulting in a fixed ~0.000005 SOL fee.
+
+### Sui
+Sui uses a [gas-based system](https://docs.sui.io/concepts/tokenomics/gas-in-sui) where:
+```
+Fee = Computation Units × Gas Price (in MIST, where 1 SUI = 1,000,000,000 MIST)
+```
+The gas price fluctuates based on network load, with validators setting minimum prices through a gas price mechanism.
+
+## What Actions Affect Transaction Fees?
+
+While our benchmark focuses on simple token transfers, transaction fees can vary significantly based on the operations performed:
+
+### Computational Complexity
+- **Simple transfers**: Minimal computation, lowest fees
+- **Smart contract calls**: Higher fees based on function complexity
+- **Cross-contract calls**: Multiple contract interactions increase fees
+- **Complex calculations**: More CPU-intensive operations cost more gas
+
+### Storage Operations
+- **Reading data**: Generally cheaper or free
+- **Writing data**: Storing new data on-chain is expensive
+- **Updating state**: Modifying existing storage incurs fees
+- **Deleting data**: Some chains offer gas refunds for freeing storage
+
+### Transaction Size
+- **Data payload**: Larger transaction data increases fees
+- **Function arguments**: More parameters = higher costs
+- **Return values**: Larger outputs can affect fees
+
+### Network-Specific Factors
+- **NEAR**: Storage staking requires locking tokens proportional to data stored
+- **Ethereum/Arbitrum**: Contract deployment costs significantly more than transfers
+- **Solana**: Additional signatures (multi-sig) multiply the base fee
+- **Aptos/Sui**: Complex Move bytecode execution increases gas consumption
+
+The fees measured in our benchmark represent the **baseline cost** for the simplest possible operation. Real-world application transactions typically cost 2-100x more depending on complexity.
+
+## Real-World Fee Analysis
+To ensure fair comparison, we:
+
+- Used testnet networks on all chains
+- Performed simple native token transfers to avoid smart contract complexity variations
+- Used public RPC endpoints
+- Collected 28-30 transactions per blockchain
+- Calculated transaction fees using: `transactionFee = balanceBefore - balanceAfter - amount`
+- Converted fees to USD at current market prices
+
+## Results
+
+Here is a summary of the average transaction fees observed:
+
+| Blockchain       | Transactions | Avg Fee (Native) | Avg Fee (USD) | Token Price | Fee Documentation |
+|------------------|--------------|------------------|---------------|-------------|-------------------|
+| Arbitrum         | 30           | 0.00000042       | $0.000000084  | $0.20       | [Docs](https://docs.arbitrum.io/how-arbitrum-works/gas-fees) |
+| Aptos            | 28           | 0.000012         | $0.000019     | $1.59       | [Docs](https://aptos.dev/network/blockchain/gas-txn-fee) |
+| Ethereum Sepolia | 30           | 0.000000021      | $0.000062     | $2,944.00   | [Docs](https://ethereum.org/en/developers/docs/gas/) |
+| NEAR             | 30           | 0.000045         | $0.000070     | $1.56       | [Docs](https://docs.near.org/protocol/gas#cost-for-common-actions) |
+| Solana           | 30           | 0.0000050        | $0.000645     | $129.00     | [Docs](https://solana.com/docs/core/fees) |
+| Sui              | 30           | 0.001965         | $0.002928     | $1.49       | [Docs](https://docs.sui.io/concepts/tokenomics/gas-in-sui) |
+
+
+## Resources
+
+The complete fee analysis data and tools are open source and available on GitHub:
+
+- **Benchmark Data**: [matiasbenary/benchmarks](https://github.com/matiasbenary/benchmarks) - Raw fee data and analysis
+- **Network Analyzer**: [matiasbenary/networksAnalizer](https://github.com/matiasbenary/networksAnalizer) - Tool used to measure and analyze fees across different networks
+
+---
+
+*Want to build on NEAR with low transaction costs? Check out our [developer documentation](/smart-contracts/what-is) to get started.*
@@ -59,3 +59,11 @@ pivortex:
   socials:
     x: ThePiVortex
     github: PiVortex
+
+matiasbenary:
+  name: Matias Benary
+  title: Developer
+  url: https://github.com/matiasbenary
+  image_url: https://github.com/matiasbenary.png
+  socials:
+    github: matiasbenary