Gas settings per network

A DALP InstanceA DALP Instance is one self-contained copy of the platform, deployed inside a boundary you choose and connected to ledger networks you approve.Read the concept prices work before it does it. When a wallet cannot pay for the transaction the platform is about to send, the platform pauses that work, names the wallet, and asks for a deposit rather than letting the write fail at the node. Every figure in that decision comes from a per-network gas block: how much to ask for, how long the ask stays open, how large an ask is too large to be believable, and whether the chain charges anything at all.

Each network carries its own block, because the same figure is right on one chain and absurd on another. A chain whose token trades in thousands and a chain whose token trades in cents need the same gas allowance, not the same native amount, which is why most of these settings are measured in gas rather than in tokens.

Where a value can be setCopy Anchor Link

A gas setting can arrive from four places, and the first one that names the field decides it:

1. The network's own saved settings. A platform administrator writes these through the platform-admin network catalogue. They take effect without a redeploy.
2. The deployment's network entry. The gas block on the network in the values you pass to the Helm chart, which mirror config.yml. Changing it is a release event.
3. The per-chain-id defaults. The chainGasDefaults section, keyed by chain ID, carrying calibrated figures for chains the platform has already measured. See Chains that ship calibrated.
4. The built-in defaults. The figures in the table below, used when nothing above names the field.

Resolution is per field, not per block. A network that saves only pauseWindowSeconds keeps every other figure live against the layer beneath it, so a later change to the deployment entry or to the shipped chain defaults still reaches that network. The reverse is also true: a figure saved on the network freezes at the value you saved, and no later calibration change moves it until you clear it.

The two sponsorship bounds fall through differently at the bottom. When no layer names them, they take the deployment's global paymaster.maxGasCostCeiling and paymaster.autoSponsorshipMaxGasCost rather than a gas-block default, so a chain that never mentions sponsorship behaves exactly as it did before per-network gas settings existed.

How to read a key nameCopy Anchor Link

The names are predictable, so you can tell a key's unit from its spelling:

No key names a chain-specific unit. A gas amount is priced at the fee of the transaction being sized, at the moment of the ask, so one figure holds its meaning as the fee market moves and across chains whose tokens are worth very different amounts. A native amount is a raw integer in the chain's smallest unit and travels as a string of digits, because the values involved are larger than a JavaScript number represents exactly.

The settingsCopy Anchor Link

A network whose resolved sponsorshipAutoMaxGasCost sits above its resolved sponsorshipMaxGasCostCeiling is refused rather than silently clamped, because every sponsored operation on it would fail validation anyway.

Choosing the values that matterCopy Anchor Link

Three of these decide most of the behaviour an operator notices.

pauseWindowSeconds is a claim about attention, not about the chain. The default of half an hour suits a deployment where someone is watching and can top a wallet up. A chain funded by hand from a treasury, or a public testnet whose token comes from a faucet an operator has to go and visit, needs a day. Set it too short and work that was only waiting for money fails instead.

maxReasonableGas exists because a bad estimate is worse than no estimate. An estimator fault or a base-fee spike can produce a request many times the real cost, and an operator who pays it has lost the difference. The default catches an estimate roughly six times too large for a big deployment. Set it only after measuring the chain, and set it to 0 only on a chain whose fee behaviour is deliberately extreme.

feeCapBaseFeeMultiplier has to anticipate the market, because the cap is fixed when the transaction is signed and the base fee keeps moving. The default of 2 absorbs five consecutive maximally full blocks. A chain whose fee market climbs faster than that needs a larger number: a signed transaction whose cap the market outruns can never be mined, and it holds the head of its sender's queue while every later transaction from that sender waits behind it. Raising it also raises what an operator is asked to deposit, because the request is sized from the same cap. The headroom itself is never charged, since the sender pays the base fee plus the tip and the cap is only a ceiling.

feeCapBaseFeeFloor keeps a near-zero base fee from producing a cap with no room to move. The cap uses the base fee times the multiplier or this floor, whichever is larger, and then adds the tip. The default of 1 gwei suits a chain that charges a few gwei or more. On a chain whose base fee is far below 1 gwei, the floor alone sets the cap, and every funding request is sized against a price the chain never charges: against base fees measured in September 2026, about 200 times too much on Base and about 1.8 million times on OP Mainnet. Set it on such a chain to a value close to what the chain charges in a busy hour. The field is read from the deployment's values only; the network catalogue does not write it.

Where the gas price comes fromCopy Anchor Link

The platform does not sign with a fixed price. Every signature, cancellation, wallet reserve, and funding request on a chain reads one price source, and that source tries these in order:

1. A chain that charges nothing prices every transaction at zero.
2. The price read from the chain now: the pending base fee and the tip the node suggests. A read is reused for twelve seconds, so a funding request and the signature that follows it see the same price.
3. The newest price seen before, of any age, when the chain cannot be read right now.
4. fallbackGasPrice from the deployment's network entry, when the chain cannot be read and no price was ever seen for it.

When none of these exists, the platform signs nothing and the work waits with a gas-price-unknown error until the chain answers. It never guesses a price. The fee cap is the base fee times feeCapBaseFeeMultiplier, never less than feeCapBaseFeeFloor, plus the tip. A chain without a base fee is signed with a legacy gasPrice equal to the price read from the chain, with no headroom, because a legacy price is paid in full rather than capped.

Set fallbackGasPrice only for a chain whose endpoint may be unreachable when the platform first starts. A value set too low produces transactions that the chain refuses until a real price is read, so pick a base fee at or above what the chain has charged recently. The field is read from the deployment's values only; the network catalogue does not write it.

Whether the chain charges gasCopy Anchor Link

zeroGas is the one setting that answers itself. Left unset, the platform probes the chain once and caches the answer, and the effective value is reported as measured rather than configured. Set it only to overrule a probe you know to be wrong.

When the probe cannot get an answer, because the endpoint is unreachable or the node offers neither fee history nor a gas price, the platform treats the chain as one that charges gas. That direction is deliberate. A chain wrongly marked as charging nothing puts every write back on the silent path, where a drained wallet's transaction dies at the node with no request raised, no wallet named, and no resumption once the wallet is funded. A chain wrongly treated as charging gas costs at most one funding request an operator declines.

Chains that ship calibratedCopy Anchor Link

The chainGasDefaults section carries measured figures for chains the platform already knows, keyed by chain ID. A deployment that adds one of these chains, with only an ID, a name, and an RPC endpoint, gets those figures with no entry of its own and no code change.

A chain ID that is absent from this section is not a special case: it resolves to the built-in defaults. Adding an entry here is a values change, so a recalibration ships without a code release, and the platform records which layer supplied every figure it used.

Adding a chainCopy Anchor Link

Work down the layers, and stop as soon as the answer is good enough.

1. Check whether the chain is already calibrated. If its chain ID appears in the table above, add the network with its ID, name, and RPC endpoint, and set nothing else. The shipped figures apply.
2. Otherwise start on the built-in defaults. They cover a chain within roughly a factor of two of every chain measured so far. Add the network, leave the whole gas block empty, and let the platform probe whether the chain charges gas.
3. Adjust what the deployment's own circumstances change, not what the chain changes. pauseWindowSeconds is the usual one, because it describes who funds the wallets and how fast they respond.
4. Measure before you set a gas amount. Run a deployment on the chain, read the effective figures and the layer each came from on the network's edit sheet, and set only the ones the measurement contradicts.
5. Set the sponsorship bounds only if the chain's fee level differs from the rest of the deployment. They default to the deployment's global paymaster bounds, which already cover a typical operation at a moderate fee.

Frequently asked questionsCopy Anchor Link