Defender UI stuck on Querying contract and pausability state after accepting Arbitrum-rinkeby upgrade proposal

I was able to view the contract's state and pausability in defender, but after making an upgrade proposal (via hardhat script), and accepting the proposal in the defender web interface, it is frozen at Querying contact state and pausability.

:computer: Environment

On ubuntu using chrome browser, and contract is on arbitrum-rinkeby test chain.


please see the picture, it should have all the other IDs you need. The abbreviated contract address is 0x048e18b79bEB1dEcbB6F44b7395c9638D5e69DD1
The proposal approval seemed to be processed fine. Nothing happens on refresh of the brower or re-login, still stuck in this querying state.

:1234: Code to reproduce

See the picture of the issue.

ALSO notice how strange the screen looks when hovering on the addess box

Hi @jsgphd welcome to the forum, thanks for reaching out.

After looking at it it seem the contract's Abi was not save during loading the contract in Defender I updated the contract with Abi found on the Arbitrum-rinkeby scan, it should be good to go now.

But a missing ABi should not have freeze the UI we will investigate this further.

Have a good day

Hi, I have the same problem. How can I solve it please?

Thank you

Thanks for looking into this so quickly! My other contracts have the same issue, but I can't update them as the UI is frozen.

Hi @gigi thanks for reaching out, I updated the ABI of your contract.

Sorry for the inconvenience, a fix for the Ui will be released this week or the next.
Maybe you could use addContract in defender-client before creating a related proposal?

Ok I will try that. Thanks.

Thank you @bjmrq .

To not have the problem should I have to verify the new contract before latest approval? Thank you

I had the same issue for some contracts, looks like the ABI is not there anymore.

I could do a workaround by directly navigating to the edit section of the contract:

There just paste the ABI and after the UI will not be frozen anymore

I tried addcontract first, and it didn't seem to make a difference. Same lock up after, and can't seem to get the ABI to populate in defender.

Also I tried this URL solution with the /edit at the end, it just loads with no return.

For example, this link just spins with no return:

Hello everyone,

A missing ABI should not freeze the UI anymore on the contract page.

Note that to be able to interact with the contract on the UI you will need to update the contract with it's ABI as the UI uses it to call different query methods on the contract and also display the list of possible action methods to call on the contract for a new proposal.

Hi @bjmrq . I am still having issues. My first deploy goes well and the Abi shows up. I am using addContract for that. After I do an upgrade and approve/execute it, it doesn't show up and the UI keeps spinning... I have tried both sending and not sending the abi on the proposeUpgrade call:

await defender.proposeUpgrade( address , CONT, {
title: name,
description: Upgrade ${timeStr},
abi: abiStr

what am I doing wrong? is this not the proper way to send the revised abi or is it a bug where defender is ignoring it? Once again this is on arbitrum-rinkeby.

a UI spinning example would be

The "checking pausability...." never returns. The " Contract state" returns but with nothing listed as it is missing the abi on the upgrade.

One other detail.... if I go to the url (2 lines above) with /edit appended and then update the abi manually, it seems to then work fine, so that is the work around.

ALSO when I try to do a simulate before accepting, it gives me an error:
Transaction reverted: simulate failed: Unknown transaction type 106

This is probably due to the missing abi....

Good day @jsgphd thanks again for reaching out.

Having a closer look at the structures of the objects you pass to the function call I think they are not correct.
For example, the new implementation ABI key name is not right, so the new ABI is not saved in the contract, so the UI is then unable to query the contract state properly as the contract has no ABI anymore.

Here are 2 examples for proposeUpgrade and createProposal

await adminClient.proposeUpgrade(
      title: "Upgrade",
      description: "...",
      via: "0x...",
      viaType: "EOA",
      newImplementation: "0x...",
      newImplementationAbi: "[...]",
      network: "arbitrum-rinkeby",
      address: "0x...",

  await adminClient.createProposal({
    title: "Upgrade",
    description: "...",
    via: "0x...",
    viaType: "EOA",
    type: "upgrade",

    metadata: {
      newImplementationAddress: "0x...",
      newImplementationAbi: "[...]",

    contract: {
      network: "arbitrum-rinkeby",
      address: "0x...",

We are going to include more validations at the endpoint level but in the meantime you could have some help looking at the types ./node_modules/defender-admin-client/lib/api.d.ts

I hope it helps!

I will try that, but most of my confusion is coming from your npmjs page, here is the example on the defender-admin-client's page, which doesn't actually work properly. If you guys could make that defender-admin-client documentation better it would be very helpful. Thanks again.

const newImplementation = '0x3E5e9111Ae8eB78Fe1CC3bb8915d5D461F3Ef9A9';
const contract = { network: 'rinkeby', address: '0x28a8746e75304c0780E011BEd21C72cD78cd535E' };
await client.proposeUpgrade({ newImplementation }, contract);

Hi @bjmrq

Some good news... I was able to get the abi to update when using the adminClient.createProposal function. However, adminClient.proposeUpgrade gives me an error telling me that metadata.newImplementationAddress is not set, even though it is set... I even tried as just newImplementation (without the "Address") as you had it above, but that gave the same error as well.

The strange thing is the simulate always give me the following error, even though everything seems to work properly when Executed:

Transaction reverted: HTTP post /contracts/arbitrum-rinkeby-0x45058374a3Af7D7DD170EA5E28B7930d77796D54/proposals/28963a79-4d5a-4cb7-965f-be3228936267/simulate failed: Unknown transaction type 106

I re-upgraded the contract so you can re-create the simulation fail:

Thanks so much for all your help,

Hi @jsgphd thanks for your response,

We will be updating the documentation for it to be more clear and include the new implementation ABI in the example, nice catch!
Unfortunately, I am unable to reproduce your issue, could you paste the snippet of code you are using to create the proposal?

(Also note that both proposeUpgrade and createProposal have different arguments structures (one have the newimplementation finfo nested in metadata the other not, one have a contract key the other one do not etc..)