Skip to content

Network Specific Behavior

Didi edited this page Sep 20, 2022 · 1 revision

Network Specific Behavior

This page is about EVM network specific characteristics which in some way affect the Superfluid protocol and/or the UX when interacting with it.

Fee mechanics

Optimism

Transactions incur L2 execution fees and L1 data fees.
The gas price and gas limit provided refer to the L2 fees, which are usually negligible. Example tx: 0x75c18321fbea0d9cfad44f05ea83383fc381ed0fd104e3606b31e09181c0cf6f - has gas price set to 0.001 gwei.
If setting the gas price up to 1 gwei (3 orders of magnitude), that only marginally affects the overall tx cost, see 0x818a89ff8a721cea2664db8d8f730ad3f2ebc3a89afc9c1d5d270f06de3367cf. Note however that this are txs consuming only the minimum 21k L2 gas.
The L1 gas price is set automatically and depends on the L1 base fee at the time of execution.

The L2 gas price works like the Ethereum gas price pre EIP-1559 (fee market).
There is a floor price of 0.001 gwei which so far is usually enough because of the chain not being saturated.
Note that unlike Ethereum, Optimism does not have a mempool, meaning that underpriced transactions are outright rejected.

More details: https://community.optimism.io/docs/developers/build/transaction-fees/

Polygon

Polygon has enabled EIP-1559, but it behaves quite differently for 2 reasons:

  1. The parameters BASE_FEE_MAX_CHANGE_DENOMINATOR and ELASTICITY_MULTIPLIER were kept the same (8 and 2). This translates to a maximum base fee change of 1/8 = 12.5% per block.
    However the block time of Polygon PoS is 2 seconds vs. Ethereum's 12 seconds. This leads to the base fee to potentially change way faster than on Ethereum.
    Since Ethereum has 5 blocks per minute, that translates to a max base fee increase of 1.125^5 = ~80% in 1 minute or ~325% (~3x) in 2 minutes.
    On Polygon with its 30 blocks per minute, the base fee increase can reach 1.125^30 = ~3300% (~33x) in 1 minute or ~117100% (~1171x) in 2 minutes. A consequence of this is that the max_fee_per_gas transaction field should be set considerably higher than the last observed base fee, because if the broadcasting of the tx happens to occur during a moment of chain congestion, it can quickly become stale.
    Note that despite this, the ramp-up of the base fee is paradoxically often too slow, leading to txs getting stuck. Readn on for an explanation.
  2. When not explicitly setting gas price related parameters, Polygon txs tend to be rejected with Error: transaction underpriced (example).
    This happens mainly while the chain is not saturated and the base fee is close to 0 wei.
    web3.eth.getGasPrice() will return values like 30000000013 in such situation and sending a tx without manual gas price (or max fee / max priority fee) set will be rejected. Setting --miner.gasprice '31000000000' and --txpool.pricelimit 31000000000 didn't change that behavior.
    The only known mitigation so far is to always manually set a gas price or - in case of type2 transactions - max fee & max priority fee. If the chain isn't saturated, a value of 31 gwei should do, otherwise it's a bit of guesswork. Because the base fee often sits at single-digit wei values, it takes a while for it to ramp up to the 30 gwei floor set - despite the much higher possible rate of change compared to Ethereum, as described above. The result of that is that in the meantime it behaves like pre-EIP1559 Ethereum: one has to guess the appropriate price to be paid and may easily either overpay or have the tx stuck for a while - that's because one has to guess the right max_priority_fee_per_gas to be set for the tx to be selected.

An unfortunate consequence of this peculiarities is that there's no known way (even with self-hosted and freely configurable RPC node) for how to transact with Polygon without the need to explicitly set gas price parameters - something working quite well on all other supported networks.
When using protocol scripts, this can be achieved by setting the env var POLYGON_MAINNET_GAS_PRICE (value denominated in wei).

Verification

Arbitrum

Verification on Arbiscan sometimes fails for unknown reasons.

Clone this wiki locally