Fees and payment costs

Identify the charge you are approving

A purchase amount and its network execution cost are separate terms. A merchant cart total is the sum of catalog prices and quantities; it does not define the protocol schedule. There is no universal merchant processing or ramp percentage to apply across every route. Review the specific quote and provider terms for the mechanism you select.

EVM gas

EVM transactions use Ethereum-style gas accounting. Dynamic-fee transactions carry maximum fee and priority fee fields; execution receipts report gas used and effective gas price. The EVM base fee adjusts against target gas usage and is bounded by configured minimum and maximum parameters. Query the current network settings when preparing a transaction.

Use the EVM RPC and wallet fee controls for an EVM transfer or contract call. Native LayerX activity fee estimates apply to canonical activities rather than arbitrary EVM transactions. A workflow spanning both execution planes should expose the costs and evidence of its individual legs.

The native committed schedule

Native activity fees are deterministic functions of committed schedule bytes and execution meters. Parameters include base_fee, per_activity_type_unit, per_encoded_byte, per_execution_unit, per_storage_unit, multiplier_basis_points, Asset prices, and module prices.

Schedule versions select an encoding and pricing contract; they are distinct from an individual estimate's observed state. The withdrawal price slot is encoded as an unsigned 64-bit value even though other price slots use unsigned 128-bit values. An available schedule slot does not by itself determine which activity encodings a particular submission interface accepts.

How the fee is calculated

1. For a Programs CALL carrying an exact program fee, use the declared exact fee units under the applicable program fee schedule.
2. Otherwise begin with base_fee.
3. For an Asset activity under schedule version 2 or later, add its named flat Asset price. For other activity types, add per_activity_type_unit × activity_type.
4. Under version 4, add the named module price for escrow, budget, stream, service, perpetuals, governance, or bridge activities.
5. Add the encoded-byte, execution-unit, and storage-unit coefficients multiplied by their corresponding meters.
6. Multiply the total by multiplier_basis_points, divide by 10,000, and round upward.

ordinary_fee = ceil(
  (base_fee
   + activity_component
   + applicable_module_price
   + per_encoded_byte * canonical_encoded_bytes
   + per_execution_unit * execution_units
   + per_storage_unit * storage_units)
  * multiplier_basis_points / 10000
)

The exact Programs fee path is valid for Programs module 9, CALL ordinal 3, with a nonzero program fee schedule version. Unknown Asset ordinals fail as LXP_ERR_UNKNOWN_ACTIVITY; unsupported schedule versions fail as LXP_ERR_VERSION_UNSUPPORTED. Integer arithmetic and canonical encodings keep independent execution and replay calculations consistent.

Asset and module prices

Version 4 module parameters are fee.module.escrow, fee.module.budget, fee.module.stream, fee.module.service, fee.module.perps, fee.module.governance, and fee.module.bridge. Programs uses its own exact CALL pricing path rather than a slot in this seven-module table.

Estimate before signing

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "lx_estimateFee",
  "params": ["<canonical activity hex>"]
}

The estimate returns fee as a decimal string, parameter_version, hexadecimal canonical_schedule, canonical_bytes, observed_head_sequence, state_root, and verification: "authenticated_committed_snapshot". Keep this context with the proposed payment so the approved estimate can be associated with the state and schedule that produced it.

An estimate reserves no balance, locks no schedule, and proves no execution. When the schedule needs execution or storage meters that estimation cannot establish, the estimator refuses instead of treating the missing meters as zero. LNI fee_estimate and session_fee_state expose the committed schedule projection with the same non-reservation semantics.

Set and fund the fee ceiling

1. Prepare the exact canonical activity and estimate its fee.
2. Choose a maximum in integer base units and disclose that fee_limit with the other payment terms.
3. Ensure the actor's spendable fee balance covers the full limit, even when the estimate is lower.
4. Sign and submit the approved bytes, preserving their activity identifier and idempotency key.
5. Verify the final receipt, charged fee, result code, and requested commitment.

Protocol fee charges settle as 402LXP transfer legs with reason LXP_REASON_PROTOCOL_FEE to treasury account system:fees. Replay verifies the recorded charge, actor debit, treasury credit, schedule version, and resulting state. A failed payment can therefore have a fee-bearing receipt even when its requested transfer did not apply.

Programs occupancy and persistent storage

Occupancy charges for namespace bytes held across protocol batches. Its time unit is the batch number, not elapsed wall-clock time. The CALL flow prices its execution budget and carves authorized occupancy out of the signed fee limit. Due maintenance transfers settle as ordinary 402LXP legs.

Occupancy is a separate batch settlement. A CALL that writes persistent storage is not fully settled until occupancy settlement for its containing batch completes. Program outcomes carry occupancy byte-batches, fee units, Asset identifier, evidence digest, and transfer root. Preserve the outcome and batch evidence when reconciling persistent storage costs; simulation alone does not perform batch occupancy settlement.

Merchant, metered, and subscription pricing

A merchant quote binds cart lines, integer totals, Asset, recipient, scheme, network, and timeout into a request digest. One cart uses one payment Asset and recipient. Catalog changes create new quote digests. In x402, accept the offered requirement without editing its amount or recipient, and distinguish that resource price from the network fee needed to settle it.

Metered and subscription grants authorize bounded future draws with explicit purpose, expiry, and billing windows. Each draw or renewal remains a separately authorized receive and settlement. Price a complete workflow by its actual activities and storage obligations, rather than assuming that an initial grant covers every future network charge.

Governance and parameter changes

Governance controls fee.base, fee.activity, fee.byte, fee.exec, fee.storage, fee.multiplier_bps, and fee.encoding, together with the named Asset and module prices. Committed schedule bytes are stored under fee.schedule; version 4 also uses fee.module-prices. Read the active committed schedule when estimating instead of copying fixed prices into application code.

Related guides

• Payments and settlement
• First payment walkthrough
• EVM execution and gas
• Programs and occupancy
• Public payment API
• Governance