anchor.diff:  
   This is required to protect the contract from exploits (this is really similar to how ether is locked in Ethereum transactions).
   
  -Please not how the gas cost estimation is not 100% accurate, we may tweak it further down the road.
  +Please note how the gas cost estimation is not 100% accurate, we may tweak it further down the road.
   
   NOTE: `_preRelayedCall` and `_postRelayedCall` are used instead of preRelayedCall and postRelayedCall. This prevents them from being called by non-relayhub. Always use _pre and _post methods.
   
  -=== How to use it?
  +=== How to use it
   
   Create your contract using the following:
   
  
positive.code: 
  == GSNBouncerERC20Fee
  
  This bouncer is a bit more complex (but don't worry we've already wrote it for you!). Unlike `GSNBouncerSignature`, this Bouncer doesn't require any off-chain services.
  Instead of manually approving each transaction, you will give tokens to your users. These tokens are then used to pay for GSN calls to your recipient contract.
  Any user that has enough tokens is automatically approved and the recipient contract will cover his transaction costs!
  
  This bouncer charges users for the ether cost your recipient will incur. Each recipient contract has their own unique token, with a baked-in exchange rate of 1:1 to ether, since they act as an ether replacement when using the GSN.
  
  The recipient has an internal mint function. Firstly, you need to setup a way to call it (e.g. add a public function with onlyOwner or some other form of access control).
  Then issue tokens to users based on your business logic. For example, you could mint limited tokens to new users, mint tokens when they buy them off-chain, give tokens based on the user subscription etc.
  
  NOTE: *Users do not need call approve* on their tokens for your recipient to use them. They are a modified ERC20 variant that lets the recipient contract retrieve them.
  
  
negative.code: 
  The signature used to create the transaction must be added to the contract as a trusted signer. If it is not the same, this bouncer will not accept the transaction.
  
  This means that you need to set up a system where your trusted account signs call requests, as long as they are valid users.
  
  The definition of a valid user depends on your system, but an example is users that have completed their sign up via some kind of oauth and validation, e.g., gone through a captcha or validated their email address.
  You could restrict it further and let new users send a specific number of transactions (e.g., 5 requests via the GSN, at which point they need to create a wallet).
  Alternatively, you could charge them off-chain (e.g., via credit card) for credit on your system and let them run GSN calls until said credit runs out.
  
  The great thing about this setup is that *your contract doesn't need to change*. All you're doing is changing the backend logic conditions under which users call into your contract for free.
  On the other hand, you need to have a backend server, microservice, or lambda function to accomplish this.
  
  === How does it work?
  
  Here is the definition of acceptRelayedCall function.
  
  It decides whether or not to accept the call based on the signature. No further gsn-actions need to be taken.
  
  It only relies on the approvalData and does not use callData.
  
  