XRC-GAS: Gas Price Behavior
Version: 1.0
Last updated: 2025-01-06
This document specifies the gas price behavior on the XGR Network for developers integrating applications.
It explains how gas pricing works, how to estimate transaction costs, and what to expect compared to standard Ethereum-compatible networks.
Table of contents
- Overview
- Key differences from standard EIP-1559
- Gas price behavior
- Transaction cost estimation
- RPC endpoint behavior
- Fee structure
- Best practices for integration
- FAQ
1. Overview
The XGR Network uses a modified EIP-1559 gas model optimized for predictable transaction costs.
Key characteristics:
- Gas price remains stable under normal network conditions
- A network-governed minimum base fee ensures price predictability
- Standard EIP-1559 transactions and tooling work without modification
- Spam protection activates automatically during high network load
For most integrations, XGR behaves like any EIP-1559-compatible chain. This document explains the specific behaviors that differ from Ethereum mainnet.
2. Key differences from standard EIP-1559
2.1 Compatibility
| Feature | Support |
|---|---|
| Transaction types | Legacy (Type 0) and EIP-1559 (Type 2) |
| Transaction fields | gasPrice, maxFeePerGas, maxPriorityFeePerGas |
| RPC endpoints | eth_gasPrice, eth_maxPriorityFeePerGas, eth_feeHistory |
| Tooling | All standard Ethereum tooling (wallets, libraries, frameworks) |
| Gas estimation | eth_estimateGas works as expected |
| Effective price calculation | min(maxFeePerGas, baseFee + maxPriorityFeePerGas) |
2.2 Behavioral differences
| Aspect | Standard EIP-1559 | XGR Enterprise Model |
|---|---|---|
| Base fee at low load | Decreases toward zero | Fixed at minimum |
| Base fee at normal load | Fluctuates around target | Fixed at minimum |
| Price floor | None | Network-governed minimum |
| Priority fee (tip) | Required (>0) for inclusion | Optional (suggested: 1 gwei) |
| Price increase trigger | Above 50% block utilization | Above 80% block utilization |
| Maximum increase rate | +12.5% per block | +25% per block (above 80% only) |
| Price decrease behavior | Gradual (-12.5% per block) | Immediate return to minimum |
| Minimum adjustment | Governed by protocol | Governed on-chain (no hard fork required) |
2.3 Visual comparison
Standard EIP-1559 XGR Enterprise Model
baseFee baseFee
↑ ↑
│ ╱╲ price │ ╱ emergency
│ ╱ ╲ fluctuates │ ╱ pricing
│ ╱ ╲ continuously │ ╱
│ ╱ ╲ │ ╱
│ ╱ ╲ │ ╱
│ ╱ ╲ │ ●
│ ╱ ╲ can │ stable │ minBaseFee
│╱ ╲ approach zero │ pricing │ (on-chain)
└─────────────────────→ load └─────────────────────→ load
80%
Key insight: On XGR, gas price equals the on-chain minimum under normal conditions, enabling reliable cost forecasting.
3. Gas price behavior
3.1 On-chain governance
The minimum base fee (minBaseFee) is stored in the EngineRegistry smart contract and can be adjusted through network governance without requiring a hard fork.
| Parameter | Source | Adjustable |
|---|---|---|
minBaseFee |
EngineRegistry contract | Yes (governance) |
| Congestion threshold | Protocol | Fixed at 80% |
| Maximum increase rate | Protocol | Fixed at 25%/block |
Developers should query the current minBaseFee via RPC rather than hardcoding values.
3.2 Normal operation (≤ 80% network utilization)
Under normal conditions:
baseFee = minBaseFee (from EngineRegistry)
The base fee remains constant regardless of whether utilization is 10%, 50%, or 80%.
3.3 High load operation (> 80% network utilization)
When network utilization exceeds 80%, the base fee increases progressively:
| Network Utilization | Base Fee Behavior |
|---|---|
| ≤ 80% | Stable at minBaseFee |
| 85% | Increases ~6.25% per block |
| 90% | Increases ~12.5% per block |
| 95% | Increases ~18.75% per block |
| 100% | Increases ~25% per block (maximum) |
3.4 Recovery behavior
When utilization drops below 80%, the base fee immediately returns to minBaseFee. There is no gradual decay period.
4. Transaction cost estimation
4.1 Cost formula
Transaction Cost = Gas Used × Effective Gas Price
Effective Gas Price = min(maxFeePerGas, baseFee + maxPriorityFeePerGas)
Under normal network conditions:
Effective Gas Price = minBaseFee
Note: XGR suggests a small non-zero priority fee by default (for wallet compatibility). Users can still set it to 0 manually.
4.2 Calculation examples
The following examples use hypothetical values for illustration. Actual network parameters are governed on-chain.
Assumption for examples: minBaseFee = 100 Gwei
| Operation | Typical Gas | Calculation | Example Cost |
|---|---|---|---|
| Native transfer | 21,000 | 21,000 × 100 Gwei | 2,100,000 Gwei |
| ERC-20 transfer | ~65,000 | 65,000 × 100 Gwei | 6,500,000 Gwei |
| ERC-20 approve | ~46,000 | 46,000 × 100 Gwei | 4,600,000 Gwei |
| NFT transfer | ~85,000 | 85,000 × 100 Gwei | 8,500,000 Gwei |
| Simple swap | ~150,000 | 150,000 × 100 Gwei | 15,000,000 Gwei |
| Complex DeFi operation | ~300,000 | 300,000 × 100 Gwei | 30,000,000 Gwei |
Note: Gas consumption varies by contract implementation. Use eth_estimateGas for accurate estimates.
4.3 Cost estimation approach
| Scenario | Recommended Approach |
|---|---|
| Real-time transactions | Query eth_gasPrice for current effective price |
| Budget forecasting | Query current minBaseFee + small buffer |
| Worst-case planning | Add 25-50% buffer for potential congestion periods |
4.4 Comparison: Cost predictability
| Network Type | Price Variability | Budget Reliability |
|---|---|---|
| Ethereum Mainnet | High (10x+ swings common) | Low |
| L2 Rollups | Medium | Medium |
| XGR Network | Low (stable at minimum) | High |
5. RPC endpoint behavior
5.1 Gas price endpoints
| Endpoint | Returns | Description |
|---|---|---|
eth_gasPrice |
baseFee |
Suggested price for legacy transactions |
eth_maxPriorityFeePerGas |
1 gwei |
Suggested priority fee (not required) |
eth_feeHistory |
Historical data | Base fees, gas ratios, and reward percentiles |
5.2 Expected values under normal load
| Field | Typical Value | Notes |
|---|---|---|
baseFeePerGas (block header) |
minBaseFee |
Governed on-chain |
eth_gasPrice response |
minBaseFee |
Ready-to-use for legacy TX |
eth_maxPriorityFeePerGas response |
1 gwei |
Suggested for wallet compatibility; not required |
Suggested maxFeePerGas |
~2× baseFee | Buffer for compatibility |
5.3 The maxFeePerGas buffer
Standard tooling typically suggests maxFeePerGas = 2 × baseFee as a safety buffer. On XGR this buffer is often unnecessary due to price stability, but does not cost extra—users only pay the effective price.
| You specify | Network baseFee | You pay |
|---|---|---|
maxFeePerGas = 200 Gwei |
100 Gwei | 100 Gwei (effective) |
maxFeePerGas = 150 Gwei |
100 Gwei | 100 Gwei (effective) |
maxFeePerGas = 110 Gwei |
100 Gwei | 100 Gwei (effective) |
6. Fee structure
6.1 Fee distribution
Transaction fees are distributed using a fixed formula, independent of EIP-1559 tip mechanics:
Total Fee = Gas Used × Gas Price
1. Burn (fixed): 1000 Gwei per transaction
2. Remaining: Total Fee − 1000 Gwei
3. Treasury: Remaining × donationPercent%
4. Validator: Remaining − Treasury
Important: On XGR, maxPriorityFeePerGas is not used as a dedicated “validator tip payout”.
If a user sets a non-zero priority fee, it can increase the effective gas price (and total fee),
but the resulting fee is still split by the fixed XGR formula (burn + donation + validator).
6.2 Distribution parameters
| Parameter | Default | Source | Adjustable |
|---|---|---|---|
| Burn amount | 1000 Gwei | Protocol | No |
| Donation percent | 15% | EngineRegistry | Yes (governance) |
| Donation address | On-chain | EngineRegistry | Yes (governance) |
6.3 Example distribution
Assumption: gasUsed = 21,000, gasPrice = 100 Gwei, donationPercent = 15%
| Step | Calculation | Amount |
|---|---|---|
| Total fee | 21,000 × 100 Gwei | 2,100,000 Gwei |
| Burn (fixed) | — | 1,000 Gwei |
| Remaining | 2,100,000 − 1,000 | 2,099,000 Gwei |
| Treasury (15%) | 2,099,000 × 0.15 | 314,850 Gwei |
| Validator | 2,099,000 − 314,850 | 1,784,150 Gwei |
6.4 Fee transparency
Each transaction emits an event documenting the fee split:
| Event | Contract | Data |
|---|---|---|
XGRFeeSplit |
0x...fEE1 |
(donationFee, validatorFee, burnedFee) |
This enables transparent tracking of fee distribution for auditing and analytics.
7. Best practices for integration
7.1 General recommendations
| Area | Recommendation |
|---|---|
| Fee estimation | Use RPC endpoints; avoid hardcoding gas prices |
| Transaction type | EIP-1559 (Type 2) preferred for better UX |
| Buffer strategy | 10-20% buffer typically sufficient (vs. 100%+ on volatile networks) |
| Retry logic | Standard retry patterns; fee bumping rarely needed |
7.2 For wallet integrations
| Aspect | Recommendation |
|---|---|
| Fee display | Show expected cost (effective price), not maximum |
| User messaging | Emphasize price stability as a feature |
| Advanced settings | Allow users to reduce maxFeePerGas buffer if desired |
| Stuck transactions | Rare under normal conditions; standard replacement works |
7.3 For dApp backends
| Aspect | Recommendation |
|---|---|
| Cost budgeting | Query current minBaseFee + 10% buffer |
| Batch operations | Combine operations where possible to reduce per-TX overhead |
| Monitoring | Alert if baseFeePerGas > 1.5× minBaseFee (indicates congestion) |
| SLA planning | Use minBaseFee as baseline for cost guarantees |
7.4 For smart contract developers
| Aspect | Recommendation |
|---|---|
| Gas optimization | Still valuable—reduces costs proportionally |
| Refund mechanisms | Work normally; unused gas refunded at effective price |
| Gas stipends | Standard 2300 gas stipend for .transfer() applies |
| Cost estimation | Stable pricing simplifies gas cost documentation |
8. FAQ
Pricing
Q: What is the minimum gas price?
A: Transactions must pay at least the current baseFee, which equals minBaseFee under normal conditions. This value is governed on-chain via the EngineRegistry contract.
Q: Can gas prices go to zero?
A: No. The network enforces a minimum base fee that is always greater than zero.
Q: Why does my wallet suggest a high maxFeePerGas?
A: Standard tooling uses a 2× buffer for volatile networks. On XGR this is usually unnecessary, but setting a high maximum does not increase actual costs.
Q: How do I get the current minimum base fee?
A: Query eth_gasPrice for a ready-to-use value, or read baseFeePerGas from the latest block header.
Network behavior
Q: What happens during high network load?
A: Above 80% utilization, base fee increases up to 25% per block. This is a spam protection mechanism and typically temporary.
Q: How quickly do prices recover after congestion?
A: Immediately. When utilization drops below 80%, base fee returns to minBaseFee in the next block.
Q: Is the 80% threshold configurable?
A: No, this is a protocol parameter. Only minBaseFee and fee distribution parameters are adjustable via on-chain governance.
Compatibility
Q: Do standard Ethereum tools work?
A: Yes. All EIP-1559-compatible tooling works without modification.
Q: Are there any breaking differences from Ethereum?
A: No breaking differences. The model is a superset of EIP-1559 with additional stability guarantees.
Q: How do priority fees (tips) work?
A: XGR returns a small suggested priority fee by default (e.g. 1 gwei) for wallet compatibility. Tips are not required under normal conditions.
If a non-zero tip is specified, it can increase the effective gas price (and total fee). Fee distribution still follows the fixed XGR split (not a dedicated tip payout).
Appendix: Quick reference
Model parameters
| Parameter | Value | Governance |
|---|---|---|
| Minimum base fee | On-chain (EngineRegistry) | Adjustable |
| Congestion threshold | 80% block utilization | Fixed |
| Maximum price increase | 25% per block | Fixed |
| Price decrease | Immediate to minimum | Fixed |
Calculation reference
Effective Gas Price = min(maxFeePerGas, baseFee + maxPriorityFeePerGas)
Transaction Cost = Gas Used × Effective Gas Price
Under normal load (default suggestion):
baseFee = minBaseFee (from EngineRegistry)
Effectiv eGas Price = minBaseFee + maxPriorityFeePerGas (if specified)
Fee distribution reference
Total Fee = Gas Used × Gas Price
Distribution (fixed formula):
→ Burn: 1000 Gwei (fixed per transaction)
→ Remaining: Total Fee − 1000 Gwei
→ Treasury: Remaining × donationPercent%
→ Validator: Remaining − Treasury
Note: EIP-1559 tip values do NOT affect this distribution.