The **Recipient** contract can then extract the **Transaction Signer** address
by performing 3 operations:
1. Check that the **Forwarder** is trusted. How this is implemented is out of
the scope of this proposal.
2. Extract the **Transaction Signer** address from the last 20 bytes of the
call data and use that as the original `sender` of the transaction (instead of `msg.sender`)
3. If the `msg.sender` is not a trusted forwarder (or if the msg.data is
shorter than 20 bytes), then return the original `msg.sender` as it is.
The **Recipient** MUST check that it trusts the Forwarder to prevent it from
extracting address data appended from an untrusted contract. This could result
in a forged address.
### Protocol Support Discovery Mechanism
Unless a **Recipient** contract is being used by a particular frontend that
knows that this contract has support for native meta transactions, it would not
be possible to offer the user the choice of using meta-transaction to interact
with the contract. We thus need a mechanism by which the **Recipient** can let
the world know that it supports meta transactions.
This is especially important for meta transactions to be supported at the Web3
wallet level. Such wallets may not necessarily know anything about the
**Recipient** contract users may wish to interact with.
As a **Recipient** could trust forwarders with different interfaces and
capabilities (e.g., transaction batching, different message signing formats),
we need to allow wallets to discover which Forwarder is trusted.
To provide this discovery mechanism a **Recipient** contract MUST implement
this function:
```solidity
function isTrustedForwarder(address forwarder) external returns(bool);
```
* That function MUST return true if the forwarder is trusted by the
Recipient.
* That function MUST return false if the forwarder is not trusted.
* That function MUST NOT throw a revert.
Internally, the **Recipient** MUST then accept a request from forwarder
That function can be called on-chain and as such gas restriction needs to be
put in place.
A Gas limit of 10k is enough for making the decision either inside the
contract, or delegating it to another contract and doing some memory access
calculations, like querying a mapping.
### Recipient example
```solidity
contract RecipientExample {
function purchaseItem(uint256 itemId) external {
address sender = _msgSender();
... perform the purchase for sender
}
address immutable _trustedForwarder;
constructor(address trustedForwarder) internal {
_trustedForwarder = trustedForwarder;
}
function isTrustedForwarder(address forwarder) external returns(bool) {
return forwarder == _trustedForwarder;
}
function _msgSender() internal view returns (address payable signer) {
signer = msg.sender;
if (isTrustedForwarder(signer)) {
bytes memory data = msg.data;
uint256 length = msg.data.length;
assembly { signer := mload(add(data, length))) }
}
}
}
```
## Rationale
* Make it easy for contract developers to add support for meta
transactions by standardizing the simplest viable contract interface.
* Without support for meta transactions in the recipient contract, an externally owned
account can not use meta transactions to interact with the recipient contract.
* Without a standard contract interface, there is no standard way for a client
to discover whether a recipient supports meta transactions.
* Without a standard contract interface, there is no standard way to send a
meta transaction to a recipient.
* Without the ability to leverage a trusted forwarder every recipient contract
has to internally implement the logic required to accept meta transactions securely.
* Without a discovery protocol, there is no mechanism for a client to discover
whether a recipient supports a specific forwarder.
* Making the contract interface agnostic to the internal implementation
details of the trusted forwarder, makes it possible for a recipient contract
to support multiple forwarders with no change to code.
## Security Considerations
A bad forwarder may allow forgery of the `msg.sender` returned from
`_msgSender()` and allow transactions to appear to be coming from any address.
This means a recipient contract should be very careful which forwarder it
trusts and whether this can be modified. The power to change the forwarder
trusted by a recipient is equivalent to giving full control over the contract.
If this kind of control over the recipient is acceptable, it is recommended
that only the owner of the recipient contract be able to modify which forwarder
is trusted. Otherwise best to leave it unmodifiable, as in the example above.
## Implementations
An implementation of a base class for a recipient: [BaseRelayRecipient.sol](https://github.com/opengsn/forwarder/blob/master/contracts/BaseRelayRecipient.sol)
