Onyx
Onyx Layer 1 fees depend on execution work and the XCN gas price
Onyx Layer 1 charges transaction fees in native XCN, with each estimate combining the transaction’s gas requirement and the current gas price. Use eth_estimateGas for the actual sender, recipient, value, and contract data, then read eth_gasPrice from Mainnet. A new destination can require extra gas for account creation. Keep the transfer amount separate from the gas budget, and confirm the recorded charge after execution. Bridge and application fees can add costs beyond this estimate.
An Onyx transfer to an unused address can require additional gas for account creation, which belongs in its transaction estimate.
Gas units, fee prices, and the XCN payment balance
Gas measures execution work, while the gas price converts each unit of that work into an XCN amount. Native transfers, token-contract calls, and deployments can require different work. Even transfers can differ when the destination needs account creation. The amount being sent is the principal; the network fee pays for processing. A self-funded native XCN transfer therefore requires a balance covering both.
Network resources are priced in USD terms, and the network converts the charge into XCN at its applicable conversion rate. A USD-based resource price does not make the XCN quantity permanent. Read the live gas price when preparing a transaction. A historical average cannot establish the charge for a different payload and ledger state.
How do you calculate an estimated fee in XCN?
The estimated execution fee combines the estimated gas requirement with the current gas price, converted from RPC units into XCN.
eth_estimateGas returns a gas quantity, while eth_gasPrice returns a price per gas unit. Keep those quantities separate during calculation. Integer arithmetic preserves precision until the application formats the XCN amount for display.
Estimated cost and funding allowance
The gas estimate and selected gas limit represent different quantities. A limit leaves room for execution; the receipt reports what the transaction consumed.
Expected execution charge
Let G represent estimated gas and P the returned price in 18-decimal RPC units per gas. The estimate in XCN is G × P ÷ 10^18.
Gas-limit allowance
For a transaction using gasPrice, a selected gas limit L gives an execution allowance of L × P ÷ 10^18 XCN. Native value sent belongs alongside that allowance in the funding calculation. The allowance is a budget boundary; the recorded execution charge needs its own reconciliation.
Network identity and native precision
Mainnet fee calculations use native XCN units on chain ID 327, returned as 0x147. JSON-RPC represents native XCN with 18-decimal scaling.
The native ledger settles XCN at eight decimal places.
Native transfer values must therefore align to multiples of 10^10 RPC units. Extra display digits do not create extra transferable precision. ERC-20 token amounts follow their own token units.
Destination creation changes transfer estimates
A first qualifying transfer can require additional gas because its destination needs a native ledger account. An EVM address can exist syntactically before that ledger account exists.
Transfers to unused addresses
A fixed 21,000 gas setting can be inadequate when the transfer creates its recipient account. The estimation request needs the actual sender, recipient, value, and data. A previous transfer to an established account describes different execution work, so its gas quantity cannot substitute for the new recipient’s estimate.
State changes and failed estimates
The estimate applies to the state the node evaluates. Recipient account creation can change between attempts, so an address’s previous estimate should not become a permanently cached gas limit. The selected limit should preserve reasonable execution headroom. Reducing that limit solely to lower a displayed budget can leave the transaction unable to complete.
An estimation error leaves no dependable gas quantity to multiply. Preserve the RPC error and resolve the affected input or compatibility issue before signing. Increasing the gas limit does not repair a contract call whose conditions reject execution. Only send to a recipient-controlled address; valid address syntax alone does not establish control.
Transfer and contract operations require different estimates
Transaction type determines the work an estimate must cover and the state a successful operation should change. Each operation needs its actual transaction payload.
| Operation | Estimate inputs | Execution work | Success evidence |
|---|---|---|---|
| Native XCN transfer to an existing non-contract account | Sender, recipient, and native value | Native transfer | Successful receipt and recipient balance |
| First qualifying native transfer to an unused address | Sender, actual destination, and native value | Transfer with account creation | Successful receipt and credited native balance |
| ERC-20 transfer | Token contract and encoded transfer arguments | Token-contract execution | Receipt and expected token balance change |
| ERC-20 allowance update | Token contract, spender, and approval amount | Allowance update | Receipt and allowance read |
| Swap | Router call, selected path, and attached native XCN value when XCN is the input | Execution of the selected swap | Receipt and received asset amount |
| Liquid staking deposit | Staking call and native XCN value | Staking-contract execution | Receipt and stXCN position |
| Contract deployment | Bytecode and constructor arguments | Deployment execution | Receipt and non-empty deployed code |
A direct ERC-20 transfer targets the token contract, with the amount encoded in its call data. That token amount remains separate from the native XCN fee budget.
Receipts distinguish execution from submission
Transaction receipts report execution, while submission identifiers let applications track a transaction before its outcome is known. Signing authorizes the payload; the network still needs to accept and execute it. A returned transaction hash alone does not confirm success or establish the final fee.
Where a receipt supplies gasUsed and effectiveGasPrice, their product expresses the RPC execution charge before conversion to XCN. Divide by 10^18 for XCN display units. Use the transaction’s gasUsed; cumulativeGasUsed describes accumulated block gas use through that transaction. Reconcile this calculation with the recorded native charge.
Receipt status and application state answer different questions. A token implementation can return false, so a successful transaction status alone need not establish the intended token transfer. A sender’s balance decrease can also combine fees with native value sent. Concurrent activity makes a single balance difference harder to attribute.
Bridge and application charges extend the cost budget
A Layer 1 gas estimate covers its transaction’s execution, while application quotes can include additional charges. Bridge fees are application-level charges separate from Onyx network gas. Their direction, asset, percentage charges, and minimums can affect the quote. Those parameters can change. Transactions submitted on Ethereum incur Ethereum network gas separately; the Onyx estimate does not price that execution.
Liquid staking can involve a protocol fee controlled by the staking contract’s owner. Its fee parameters can change independently of network gas. A governance action also needs its own gas estimate when it submits an on-chain transaction. Use the actual call to distinguish execution costs from any application-level charges.
Fresh fee inputs and supported RPC methods
Repeat transactions need fresh gas inputs when their payload, relevant ledger state, or network pricing has changed. Keep stable network identity separate from cached fee responses. The relay supports common fee methods, without promising every Ethereum client extension. An unsupported method leaves that tool’s estimate unavailable; it does not establish a zero fee.
A wallet or provider supporting the required methods on the same Mainnet is the appropriate compatibility fallback. An explorer or mirror can lag while consensus continues operating. Fee preparation therefore needs a responsive RPC read path, and post-execution reconciliation needs sufficiently fresh records. A current eth_blockNumber response reports RPC progress, not the freshness of every explorer view.
Questions worth asking
Does a larger XCN transfer require a proportionally larger network fee?
A native XCN transfer’s network fee is not a percentage of the amount sent. Gas measures execution work, and the applicable price determines its XCN cost. Recipient account creation and transaction data can affect that work. Application fees, including some bridge charges, can use percentage-based calculations, so an application’s total quote may behave differently from the Layer 1 gas estimate.
Will requesting eth_estimateGas spend XCN?
An eth_estimateGas request estimates execution without submitting the transaction to the ledger. It does not itself transfer assets or create an on-chain execution charge. Signing and submission are separate actions. A wallet may display an estimated budget during preparation, but displaying that amount does not mean the network has debited it.
Are Testnet gas readings valid as Mainnet fee quotes?
Testnet gas readings do not establish the fee for a Mainnet transaction. The networks have separate identities, states, and fee inputs. Testnet XCN has no Mainnet value. Testing can check whether an integration handles estimation and units correctly, but the live Mainnet transaction still needs Mainnet gas and price responses.
Why does wrapped XCN not satisfy a native gas balance requirement?
Wrapped XCN is an ERC-20 representation, while the ordinary Layer 1 gas balance uses native XCN. A token-contract balance therefore does not add to the account’s native balance automatically. Holdings elsewhere in the ecosystem also do not establish native funds on Mainnet. Check the representation and network when interpreting a wallet’s available fee balance.
What charge remains when an executed contract call fails?
A contract call that executes on-chain and fails can still incur a network charge. Failure does not erase the computation already performed. Read the failed transaction’s receipt and recorded fee rather than assuming the attempted operation was free. An estimation error has a different meaning: that request alone has not submitted an execution transaction.
When does an approval add to a token operation’s gas cost?
An allowance change adds execution cost when the wallet submits it as an on-chain transaction. A suitable existing allowance may remove the need for a new approval. Estimate each transaction the application submits, including any approval call it contains. Approval changes spending permission, so its receipt alone does not establish the later asset movement.
Updated ·