Interop Fees

Fees for interop transactions are charged in two ways:

• Sending Fees
• Settlement Fees

Sending Fees

This fee is taken from senders (users) of interop calls or bundles.

• Users are charged on a per-call basis.
• Users must pay a fee for each call they send via interop (If there are X calls in the bundle they send → they have to pay X * fee.)
• Sending fees are paid in the same transaction where the user initiates sending a bundle.
• Sending fees are charged by the InteropCenter contract (an entry-point for initiating interop in v31)

Users can choose between two ways of paying sending fees. The choice is made per-bundle via the ERC-7786 bundle attribute useFixedFee(bool).

Option 1: Dynamic Base Token Fee (Default)

This is considered the go-to option for paying fees.

• The exact per-call value is read from the state variable interopProtocolFee on InteropCenter.
• The fee is denominated and paid in the base token of the sending chain, together with msg.value.
• The per-bundle charge is interopProtocolFee * numberOfCalls.
• Users pay the sending fee in the same transaction where they initiate the interop bundle.
• The fee value is set via setInteropFee(uint256), which is restricted to the bootloader (onlyCallFromBootloader). In practice this means it is updated by the chain’s operator via a system transaction.

Option 2: Fixed ZK Fee

This is considered a Stage 1 aligned way of paying fees.

• The fee value is hardcoded and independent of the chain operator. It’s only updateable on protocol upgrades, meaning the Operator is unable to change the fee amount by itself.
• The fee is denominated and paid in the ZK token on the sending chain.
• The ZK token must be bridged to the chain before users can use this option.

Sending Fee Handling

• Sending fees, regardless of the option chosen by the user, are accumulated inside the InteropCenter contract, keyed by block.coinbase (the block producer of the block in which the bundle was sent):
  • Both base token and ZK fees accumulate in InteropCenter.
• Fees are withdrawable by the coinbase that earned them, via claimProtocolFees(receiver) and claimZKFees(receiver):
  • The caller must be the coinbase that accrued the balance (checked via msg.sender). The caller can direct the withdrawal to any receiver address.

Settlement Fees

This fee is taken from an address specified by operators of the chains settling on Gateway when they execute batches on Gateway.

• Settlement fees are charged on a per-call basis.
• The operator supplies the payer address (settlementFeePayer) inside the execute-batches calldata.
• The payer address must have, ahead of time:
  • called setSettlementFeePayerAgreement(chainId, true) on the GWAssetTracker opting in to pay for that specific chainId, and
  • approved the GWAssetTracker to spend its wrapped ZK (WZK) tokens in the usual ERC-20 way. The per-chain agreement exists to prevent a malicious operator of chain A from specifying a payer address that only intended to pay for chain B. Without an explicit agreement for chain A, the batch execution reverts with SettlementFeePayerNotAgreed(payer, chainId). An agreement can be revoked at any time with setSettlementFeePayerAgreement(chainId, false).
• The fee is pulled from the payer in the same transaction where the operator settles the batch. If fee collection fails (no agreement, insufficient balance, or missing approval), the whole batch execution reverts. This makes fee collection atomic with settlement.

Fee Properties

• The fee is denominated in ZK, which is the base token on GW.
  • In the current implementation it is taken in WZK (wrapped ZK) via safeTransferFrom, to reuse standard ERC-20 approvals/accounting.
• The per-call value is stored in gatewaySettlementFee on GWAssetTracker.
• The value is controlled by the owner of GWAssetTracker (Decentralized governance)
• Collected settlement fees stay on the GWAssetTracker contract (as WZK balance) and are withdrawable by the owner of GWAssetTracker via withdrawGatewayFees(recipient) (Decentralized Governance).