Gas Model

Understanding Gas Refund and Gas Limit in Pharos Transactions

Overview

When sending a transaction on Ethereum or an EVM-compatible blockchain, it is essential to set an appropriate gas limit to ensure successful execution. One common issue arises when the gas limit is set exactly equal to the gas used, particularly when the transaction involves a gas refund mechanism.

Summary Table

Feature	Details
Opcode pricing	Fully aligned with Ethereum EVM opcode gas table
EIP-1559 support	✅ Compatible (base fee + priority fee)
Base fee	Dynamic (recalculated per epoch)
Transaction fee model	Charged by gas_limit at inclusion time
Fee distribution	Base fee is burned; priority fee is credited to the validator
Refund logic	Full EVM-style refund tracking supported, but refund does not affect charge

Transaction Fee Distribution

Following the EIP-1559 model, every transaction fee on Pharos is split into two components:

• Base Fee — the base fee is burned directly, permanently removing the corresponding tokens from circulation.
• Priority Fee — the priority fee (tip) is credited to the validator that produces the block, as a reward for including the transaction.

This fee-distribution mechanism is already implemented on Pharos.

Difference from Ethereum

On Ethereum, the priority fee is credited to the block producer's address immediately after each transaction is executed. Pharos differs because of two core design choices:

• Parallel execution & pipelined architecture — to maximize performance, transactions are executed in parallel rather than sequentially.
• Multi Concurrent Proposer (MCP) model — multiple proposers can contribute to a single block.

Because transactions execute in parallel, priority fees cannot be settled at the granularity of individual transactions in real time. Instead, they are accumulated and credited to the corresponding validators in a batch at epoch boundaries.

Best Practices for Developers

• Set a slightly higher gas limit: Allow extra gas beyond the expected execution cost.

  • Example: If you expect 100,000 gas used before refund, set the gas limit to 120,000 to avoid failures.
• Use Estimation APIs:

  • When sending transactions via Web3 libraries (ethers.js, web3.js), always use estimateGas() and add a buffer.
  • Example (ethers.js):

const estimatedGas = await contract.estimateGas.someFunction();
const gasLimit = estimatedGas.mul(12).div(10); // Adding a 20% buffer
await contract.someFunction({ gasLimit });

• Monitor Gas Refund Logic:

  • If your contract relies heavily on gas refunds (e.g., clearing storage or SELFDESTRUCT), test transactions with different gas limits to find an optimal value.
• Check for Out-of-Gas Failures:

  • If a transaction fails unexpectedly despite having enough gas, check whether gas refunds are affecting execution.
  • Debug with debug_traceTransaction or EVM logs.

Conclusion

To prevent transactions from failing due to gas refund issues, always set a gas limit slightly higher than the expected gas usage. This ensures smooth execution and prevents out-of-gas errors caused by refund mechanisms.

By following these best practices, developers can avoid failed transactions and improve the reliability of smart contract interactions.