Hosting a GSN relay that will not expect to get refunded by my contract

Hello,

I would like to run a GSN relay that will pay for the gas for my smart contract, without expecting a refund from the smart contract. I do not want to have to fund the smart contract at any point. And I do not want unauthorized contracts to use this relay. What is the best way to do this?

1 Like

Hi @DrySteel,

Welcome to the community :wave:

I am not sure what your asking is possible. I assume the dapps would request relayed calls with a gas price of zero, and a custom relayer would need to only relay calls to your contract, and for a recipient contract not to be funded.
I didn’t see anything obvious in the RelayHub contract that would prevent this but a quick test didn’t work in a local environment.

If you funded the recipient contract in the GSN, you could use any relayer, and you could use GSN Strategies to decide which relayed calls that your contract wanted to pay for.

Do you mind explaining why you don’t want to fund the recipient contract via the GSN?

Hi,

Yeah the reason we don’t want to fund the contract is that I will have many different contracts, each of which is an NFT. Could be like 100,000 different ones or more. And I don’t know which ones will be transferred or when they will be transferred. We could create a proxy contract that will be funded on the RelayHub and will relay transactions to the NFT contracts, but if this is not a supported use case of GSN, it may be better just to implement meta transactions in our NFT contracts, right?

1 Like

Hi @DrySteel,

Apparently this scheme is possible with the GSN, so you should be able to use the GSN for your use case:

  • Recipient contracts not to be funded
  • A custom relayer to only relay calls to your contracts

You may need to do some digging on requesting relayed calls with a gas price of zero and a zero transaction fee.

Let me know if you need more information.

Hi @DrySteel,

Have you had a chance to try setting this up?

Hi, we decided to use meta transactions instead. I think it is better for this case.

1 Like

Hi @DrySteel,

Out of interest, which MetaTransaction solution are you using?

I suggest having a look at the following article on Bounties Network implementation of MetaTransactions:

I also encourage you to appropriately test and audit (OpenZeppelin perform security audits) any solution that you use.