A DALP Instance prices a write before it sends it. When a wallet cannot pay for the transaction the platform is about to send, the platform pauses that work, names the wallet and requests a deposit, so the write does not fail at the node. Every figure in that decision comes from a per-network gas block: how much to request, how long the request stays open, how large a request the platform accepts as plausible, and whether the chain charges for gas. Most chains need no gas keys, and Adding a chain says which to check first.
Each network carries its own block, because a native amount that suits one chain is wrong on another. Most settings are measured in gas, so one value keeps its meaning on a chain whose token trades in thousands and on one whose token trades in cents.
Each gas field resolves through the layers on its own, so one value set on a network leaves every other field live against the layer below.
Where a value can be set
A gas setting can arrive from four places, and the first one that names the field decides it:
- The network's own saved settings. A platform administrator writes these through the platform-admin network catalogue. They take effect without a redeploy.
- The deployment's network entry. The
gasblock on the network in the values you pass to the Helm chart. Changing it is a release event. - The per-chain-id defaults. The
chainGasDefaultssection, keyed by chain ID, carrying calibrated figures for chains the platform has already measured. See Chains that ship calibrated. - The built-in defaults. The figures in the table below, used when nothing above names the field.
Each field resolves on its own. A figure saved on the network freezes at the value you saved, and no later calibration change moves it until you clear it. A field you leave unset keeps following the layer below, so a later calibration change still reaches that network.
The two sponsorship bounds fall through differently at the bottom. When no layer names them, they take the deployment's global paymaster. and paymaster. rather than a gas-block default, so a chain that never mentions sponsorship uses the deployment's global bounds.
How to read a key name
The suffix of a key gives its unit:
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 settings
A network whose resolved sponsorship sits above its resolved sponsorship is refused rather than silently clamped, because every sponsored operation on it would fail validation anyway.
Choosing the values that matter
Four of these decide most of the behaviour an operator notices.
pauseWindowSeconds depends on how fast someone tops up a wallet, and the chain does not change it. 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 protects the operator from a bad 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. With the default, a request worth more than 200,000,000 gas at the fee cap is refused. Set it only after measuring the chain, and set it to 0 only on a chain whose fee behaviour is deliberately extreme.
feeCapBaseFeeMultiplier sets the headroom for base-fee growth, because the cap is fixed when the transaction is signed and the base fee keeps moving. On a chain with Ethereum's fee rules, where the base fee rises by at most 12.5 percent a block, 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 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. 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 from
Every signature, cancellation, wallet reserve, and funding request on a chain reads one price source, and that source tries these in order:
- A chain that charges nothing prices every transaction at zero.
- The price read from the chain now: the pending base fee and the tip the node suggests. A read is reused for twelve seconds while the chain head does not move, so a funding request and the signature that follows it see the same price. A read that takes twelve seconds or longer is refused with a
gas-price-unknownerror. - The newest price seen before, when the chain cannot be read right now and that price is less than 60 seconds old.
fallbackGasPricefrom the deployment's network entry, when the chain cannot be read, no price was ever seen for it, and the chain has been unreadable for less than 60 seconds.
When none of these exists, the platform signs nothing and the work waits with a gas-price-unknown error until the chain answers. A price seen more than 60 seconds ago is never used, and neither is fallbackGasPrice once a price has been seen for the chain. 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.
On a chain with a feePolicy, the tip comes from the chain's recent fee history instead of the node's suggestion, and is held between tipFloorWei and tipCeilingWei.
The tip ceiling also sizes what Ripple Custody may charge. Ripple prices each transaction at its own Priority High rate, and the platform sets the order's maximum fee at four times the gas limit times the fee cap with the tip at tipCeilingWei. On a chain without a fee policy the maximum fee uses the fee cap as quoted.
The policy's other fields govern resending a stuck write or bundle at a higher fee: publicMempool turns those resends on, transactionBudgetWei caps the native amount one transaction may cost, and blockTimeSeconds tells the platform how old a chain head may be before a resend is unsafe.
The platform ships a policy for Ethereum mainnet and Sepolia (chain IDs 1 and 11155111) and for chain IDs 17000 and 560048: a tip from 0.01 to 2 gwei, a budget of 0.01 of the native currency, resends on, and a 12-second block time. On those chains feeCapBaseFeeFloor defaults to 0.
The multiplier is always the configured value or the default of 2. The platform does not measure it from the chain. The fee cap uses the multiplier to three decimal places, so 1.2345 prices as 1.235. Each network card on the Networks page shows the newest base fee the platform recorded on that network and when it last changed. That figure is for information only and does not change the fee cap.
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 gas
The platform measures zeroGas 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, because 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 a funding request that an operator can decline.
Chains that ship calibrated
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.
Sepolia runs the Amsterdam fork, which prices a code deposit at 1,530 gas per byte of deployed code. Its deployment floor, deployFallbackGas, is 40,000,000 gas for that reason: the largest contract DALP deploys is 24,494 bytes of runtime code, and with 120 bytes of overhead its code deposit costs 24,614 × 1,530 = 37,659,420 gas before the constructor runs, so the built-in deployFallbackGas of 25,000,000 underfunds it. A chain absent from this section resolves to the built-in defaults, so a chain that adopts the fork needs the same figure.
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 chain
Follow these steps in order, and stop at the first one that gives the behaviour you need.
- 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.
- Otherwise start on the built-in defaults. Add the network, leave the whole gas block empty, and let the platform probe whether the chain charges gas.
- Adjust the figures that depend on how your deployment operates.
pauseWindowSecondsis the usual one, because it describes who funds the wallets and how fast they respond. - 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.
- 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.
Questions about gas settings
Which layer supplied the value my network runs on?
Open the network in the platform-admin catalogue and edit it. Every gas field shows the figure it resolves to as its placeholder, with a line underneath naming the layer that supplied it: this network, the deployment values, the chain default, the platform default, or a measurement of the chain. An empty field with a placeholder is inheriting. A filled field is set on this network.
How do I stop inheriting and pin a value?
Type the value into the field on the network's edit sheet and save. From then on that one field is fixed on this network and no change to the layers beneath it moves the value. Clearing the field again restores inheritance for that field alone.
Do these settings apply to a chain that charges nothing?
Almost none apply. On a chain resolved as charging no gas, the platform sizes no funding requirement at all: the requirement comes back as zero, so the allowances, the deployment fallback, and the reasonable-size ceiling never produce a figure, and no request is raised for the window or the settle delay to govern. zeroGas is the setting doing the work on such a chain, which is why leaving it for the platform to measure matters more there than anywhere else.
Why is the request I am asked to approve larger than the transaction costs?
A request covers the work being done plus an ongoing-operations allowance, so the same wallet does not pause again on its next operation, and it is sized at the fee cap rather than at the fee the transaction pays. The cap is a ceiling: on a chain with a base fee and a tip, the sender pays the base fee plus the tip, and the headroom between that and the cap is never charged.
A request many times larger than that is what maxReasonableGas refuses outright. A wallet whose transactions Fireblocks broadcasts (provider-native mode) is asked for three times the gas cost at the cap, because Fireblocks holds back its own fee reserve before it broadcasts and refuses a transaction the wallet cannot cover with that reserve included.
Like every request sized from a refusal, that amount then gets a 25 percent margin, so the request is at least 3.75 times the gas cost before the ongoing-operations allowance is added.
That applies to the first request a deployment or a write raises, before anything is sent to Fireblocks, and to the request the funding pause raises when Fireblocks refuses a transaction for its fee: the pause then asks for the reserve Fireblocks reported, or for more than the wallet holds when Fireblocks reported none.
A wallet whose transactions Ripple broadcasts is sized the same way at four times the gas cost at the cap. Ripple holds the whole maximum fee of each open order, four times the gas cost at the fee cap with the tip at the fee policy's ceiling. When the wallet cannot cover that, Ripple holds the order and the funding pause asks for the reserve Ripple reports. Wallets signed through any other custody provider, and Fireblocks or Ripple wallets whose signed transactions DALP broadcasts itself, are asked for the gas cost alone.
Two requests hold their minimum to a ceiling: the one for the wallet that creates the organisation's contracts, and the one for the wallet that sends queued writes. The minimum the work waits for is at most twice the gas cost at the cap, times the provider's multiple, plus any currency the transaction itself sends, so the 25 percent margin never lifts it past that.
When the node or the provider reports a larger reserve than the estimate, the ceiling grows by twice the difference, and the minimum never drops below what they report. The recommended amount keeps the ongoing-operations allowance, so it can be larger than the ceiling. Its size comes from the network's opsAllowanceGas settings, which an administrator can lower for each network.
Can a gas setting be changed without a redeploy?
Yes. The network's own saved settings are written through the platform-admin catalogue. A save notifies the running services, which reload that network without a restart. Only the deployment's network entry and the shipped chain defaults need a release.