ERC1155, ERC2771 and Upgradable Contracts discrepancies

Hi guys,

I know the question may seem a bit vague, but I would be very grateful if someone could share his experiences - warnings, hints or advise - making SCs upgradable using OZ ERC1155, ER2771 implementations on Mumbai & Polygon?
I'm using solc 0.8+ but some contracts still need 0.6.

I have noticed some strange behavior with the initialiser:

function __Token_init_unchained(string memory _name, string memory _uri) internal initializer {
__ERC1155_init(_uri);
name = _name;
_setupRole(DEFAULT_ADMIN_ROLE, _msgSender());
_setupRole(CREATOR_ROLE, _msgSender());
_setupRole(PAUSER_ROLE, _msgSender());
}

When I checked with OZ Defender Admin, I have 3 different addresses for each role none of them are the EOA who is used in the deploy script of Hardhat and the default admin role is the 0x0 address.
What are the recommendations with msgSender() when using Upgradeable contracts please?
Thanks.

Hey @Toufik! I’m assuming you’re seeing something similar to this on Defender Admin:

Screenshot from 2021-05-26 15-41-29

If so, that does not mean that the zero address is the default admin and that 0x9f2… is the minter. It means that those are the identifiers of the roles. For security reasons, each role has a bytes32 hexadecimal identifier, and that’s what you see there.

To check if the deployer of your contract has that role, you can use the “Query other functions” button in Admin (shown at the bottom of the Contract state panel when creating an Admin Action), and query hasRole with the role identifier you want and the address you want to check for that role. For instance, here I’m checking if my EOA has DEFAULT_ADMIN_ROLE (identified by zero):

Screenshot from 2021-05-26 15-43-45

Hope this helps!

Hi @spalladino and thanks for your quick answer.
It's true that I didn't it was a bytes32 identifier, my bad. Yet, when I call the hasRole() getter in Defender it returns false for each of the roles defined in my first post an even if I pass an argument explicitly using the 0xd....1D for setting up the roles. For example, I get:

hasRole(0x8..888f, 0xd....1D)
false

I have checked on tenderly.co that the 0xd....1D is the Caller Address of the contract's creation. It's the ${deployer.address} of my deployProxy() function.
Am I missing something?

thanks,

Is there a chance you haven’t called the initializer maybe? Or you’ve called the initialize method in your contract, but have not called the parent’s __Token__init method in it?

Can you share the contract address so I can take a look at it, and verify the implementation’s code on etherscan?

Well there was probably some issue with the initializer. It’s fixed now thanks!

1 Like