Transaction validation fails

Validation of proposal transaction fails with Multisig execution strategy

:computer: Environment

Admin / Contract / New proposal


The problem exists both in matic and in mumbai networks.

We created a multisig AdminAccount: 0x11fe914689525618c322fc9cd76333BA15a932a6
On deploy of our contracts, we set this account to have PAUSER role. Querying hasRole() on 0x6b33f92a7D4fD296274ecCBCe77c32BDB75A703E contract, we confirm that AdminAccount indeed got this role.
Trying to Create admin action to Pause the contract , we get an error about insufficient permissions.

Another related issue is with grantRole. The same contract has DEFAULT_ADMIN_ROLE and I was able to assign a EXTRACTOR role to some address but in half hour I could not assign another role to the same address because of permission problem:

but now it's impossible:

What can be an issue?


We also get many times the following error:


:1234: Code to reproduce

Hi, while trying to reproduce this issue, I did stumble upon the "does not correspond to..." message once, due to a failed RPC call. The rest seems to be working fine.

Mumbai and Matic seem to be a bit unstable at times, which looks like the source of your problem here (especially considering you did succeed in granting a role the first time).

We should make a better job of displaying proper error messages in these situations though. Now that a couple of hours passed since your report, please try again and let us know how it goes. If you're still stuck after that, please share with us a couple of proposal id's and we'll do our best to investigate.

Hi Martin,
Following up on my colleague message above.

We redeploy everything without multisig account and it works properly; therefor the root of the problem is with the multisig I assume.

We cannot share a proposal id as we fail to create one.
The issue persist.

We aren't able to reproduce it either.
Its now resolved by itself. We gave your system about 24h to rest and tried again, and now it works. Redeployed the same contracts a few more times without encountering the issue again.
But as you can see from my colleague initial description this issue in on/off without any rational explanation.