Gas Relayer

This release supports relayed transactions via Open GSN.

Fund managers can leverage this support to pay for gas costs of allowed transactions with the VaultProxy 's WETH balance.

From a high level, this works by deploying a GSN-compliant "paymaster" contract per-fund that is allowed to withdraw WETH from its associated VaultProxy to top up a deposit balance for that fund.

Architecture

The gas relayer architecture is specific to this release (i.e., it is not "persistent" between releases).

The main contracts involved are:

• GasRelayPaymasterLib - the canonical library contract for all "paymaster" instances, providing the logic for interacting with GSN contracts, maintaining a healthy WETH deposit, and defining the rules for calls that can be relayed

• GasRelayPaymasterFactory - deploys new "paymaster" (BeaconProxy) instances, and is the reference for the current beacon library (i.e., GasRelayPaymasterLib)

• GasRelayRecipientMixin - shared logic that is inherited by all gateway contracts for relayable transactions

Usage

To use gas relaying:

1. There must be enough WETH in the VaultProxy to cover the deposit amount specified by the current GasRelayPaymasterLib .

2. The fund owner calls deployGasRelayPaymaster() on the ComptrollerProxy

3. The ComptrollerProxy deploys a new "paymaster" ( BeaconProxy instance) via the GasRelayPaymasterFactory and deposits WETH into the newly-deployed paymaster.

4. The fund should maintain enough WETH balance in the VaultProxy to top up the deposit before it runs out.

To turn off the gas relayer, the fund owner can call shutdownGasRelayPaymaster() on the ComptrollerProxy, which withdraws the WETH deposit back to the VaultProxy.

When a fund migrates to a new release, the fund owner can call withdrawBalance() on the "paymaster" to withdraw the WETH deposit back to the VaultProxy.

Allowed calls

Any account with a permissioned role (owner, migrator, or asset manager) on the fund can use the internal gas relayer architecture. Additionally, the fund owner can specify additional arbitrary users (e.g., the executors of deposit and redemption queues).

Any calls by these users is allowed to be relayed. The fund owner is responsible for monitoring for any abuse.