Hello, I'm having trouble executing function calls with GSN.
I've deployed my GSNRecipient contract on Ropsten via Truffle, called initialize(), and funded the RelayHub for my contract. I'm using GSNProvider with web3 in my frontend to send transactions via MetaMask. When I attempt to send a transaction, I receive the following error:
Error estimating gas usage for transaction (gas required exceeds allowance (8000029) or always failing transaction). Make sure the transaction is valid, or set a fixed gas value.
If I specify the amount of gas to use in the web3 send function (less than 8000000), I will be able to sign the transaction through MetaMask. However, immediately after, this error will be thrown:
No relayer responded or accepted the transaction out of the 1 queried:
Error sending transaction via relayer 0x29749bca81c36835d6a49710a14aebc654bd3ec5: Unacceptable RelayMaxNonce
I'm not sure what this means. I'm unsure why the transaction would require so much gas in the first place, as my function call is simply changing the value of a mapping and should not be computationally expensive.
I'm fairly new to this space, so if anyone can provide some insight I'd appreciate it. Thanks!
I figured it out – my contract was using msg.sender rather than _msgSender() as the docs recommend. Works now!
1 Like
Hi @waypastmars,
Welcome to the community 
Glad you were able to resolve.
Building a GSN-powered DApp is good to use as a reference.
If you haven’t already, you should consider what GSN Strategy you may want to use to decide which relayed calls your dapp will accept.
1 Like
Thanks @abcoathup!
Yes, I’ve been giving some thought as to what GSN Strategy to use. Ideally I’d like to accept calls only if the function being relayed contains an argument that hashes to a certain value. Would I be correct in assuming I’d need to somehow extract this from the acceptRelayedCall’s encodedFunction parameter?
1 Like
Hi @waypastmars,
I am not sure how you could use hashes which would prevent an account that you didn’t want to authorize using either the same input or hash to have their relayed call approved. Though I would recommend having a play with different GSN Strategies to see how they work and what might be best for your use case.
I suggest having a look at the GSN Strategies already in OpenZeppelin Contracts to see how they work. Depending on your use case you may want to look at GSNRecipientSignature (or at least how it works with the approval data).
My plan was to check the hash (on chain) of some random data generated off chain and use it as a key in a mapping. If the value it maps to is nonzero, then I would approve the call and set the value in the mapping to zero, so it cannot be used again.
Still, I will check out GSNRecipientSignature and see if it can fit to my use case. Thanks!
1 Like