Does GSNRecipient invalidate all other Zeppelin contracts?

From the docs on GSN:

Third-party contracts you inherit from may not use these replacement functions, making them unsafe to use when mixed with GSNRecipient .

This is of course related to the new _msgSender() and _msgData() which must be used in place of msg.sender and msg.data when accepting GSN meta transactions.

Does this mean that all Zeppelin contracts, upgradeable or not, cannot be inherited from anymore?

1 Like

Not at all! We’ve of course thought of this :slight_smile: and all OpenZeppelin contracts are now written in such a way that if GSNRecipient is present in the inheritance tree, they’ll automatically start using the GSN _msgSender, with no extra overhead on non-GSN contracts.

This means however that you must use the contracts from the package: copy-pasted contracts from older versions will not work.

3 Likes

Fantastic!

Yeah the copy-paste might cause troubles for some tools. I remember I once had issues with contracts imported from node_modules. I think that was with MythX.

1 Like

I think to clarify we mean contracts from openzeppelin contracts-ethereum-package correct? @nventuro https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package

1 Like

Both @openzeppelin/contracts and @openzeppelin/contracts-ethereum-package have GSN support, but ethereum-package is the one to use if you’re using the SDK, yes.

3 Likes