Does a training video exist for ER721 with UUPS selected

The best example I could find so far was this but it seems to be a bit outdated.

Not sure why you think the video is outdated. It's very recent. If you have questions about it feel free to ask.

We do not have a video about ERC721 and UUPS combined. You can use Contracts Wizard to set it up.

Thank you for your response. I will ask specific questions.

If I wanted to create an upgradable PaymentSplitter contract what should I be using in terms of making it upgradable since it's not ERC720 or ERC721?

Please check out the documentation for using OpenZeppelin Contracts with Upgrades. For UUPS, you just need to add UUPSUpgradeable in the inheritance list.

1 Like

This question is probably more Remix but hopefully you an help.
If i've deployed SplitterPayment on Javascript VM (London) and then created a new contract to use for upgrade. How will the code below every compile in remix? DeclarationError: Identifier not found or not unique. contract SplitterPaymentUpgrade is SplitterPayment { and i'm assuming that's because it can't find SplitterPayment.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SplitterPaymentUpgrade is SplitterPayment {

function version() pure public returns (string memory) {
    return "v2!";
}

}

Yes, you're referencing SplitterPayment and it needs to be in scope.

Remix doesn't play well with upgrades. Recommendatoin is to use Hardhat with our Upgrades plugin.

Within defending the SplitterPayment contract doesn't show as upgradeable is that expected?

"Defender Admin could not determine whether this contract is upgradeable. Currently only EIP-1967 compliant contracts are supported.

You can still add this contract to Defender Admin and run admin operations on it."

I assume you deployed the contract through Remix, which does not result in an upgradeable deployment.

Can you share the repository for your video please. I need to setup the hardhat parts and a bit hard to follow in the video.

Thank you!

Also since a constructor can't be used can you show how params would be sent to an initializer function?

I had used this but hardhat gave errors.

constructor(address memory _payees, uint256 memory _shares)
initializer
{}

These questions are answered in the documentation. See Writing Upgradeable Contracts. The arguments are then given to deployProxy.

Any suggestions for when upgradeProxy times out?

const mars2 = await upgrades.upgradeProxy('0xa5e81a67666835684e9FcA90aE7A503f160F2689', MarsV2)
Uncaught:
TransactionMinedTimeout [Error]: Timed out waiting for transaction 0xd14817e2c43b5c5903111771ae40772bd69f33e3a800a247314485faa3595b5a
at Proxy.upgradeProxy (/Users/jtwomley/Dev/digibudzsmartcontract/hardhat/SplitterPayment/node_modules/@openzeppelin/hardhat-upgrades/src/upgrade-proxy.ts:26:32)
at deployImpl (/Users/jtwomley/Dev/digibudzsmartcontract/hardhat/SplitterPayment/node_modules/@openzeppelin/hardhat-upgrades/src/utils/deploy-impl.ts:60:16)
at fetchOrDeployGeneric (/Users/jtwomley/Dev/digibudzsmartcontract/hardhat/SplitterPayment/node_modules/@openzeppelin/upgrades-core/src/impl-store.ts:43:5)
at waitAndValidateDeployment (/Users/jtwomley/Dev/digibudzsmartcontract/hardhat/SplitterPayment/node_modules/@openzeppelin/upgrades-core/src/deployment.ts:70:15) {
deployment: {
address: '0x40FBcE3Fcf6A06C6fb7176967708556c34E6D6ae',
txHash: '0xd14817e2c43b5c5903111771ae40772bd69f33e3a800a247314485faa3595b5a',
layout: { storage: [Array], types: [Object] }

When an operation times out, resume the same operation and it will pick up where it left off, i.e. continue waiting for the transaction to mine.

When you say resume how would I do that in the console?

Also how do you verify a contract on etherscan so that you can see the read/write funcitons in etherscan?
npx hardhat verify --network rinkeby 0xa5e81a67666835684e9FcA90aE7A503f160F2689
Error HH303: Unrecognized task verify

Just re-run the function call with the same arguments.


If i'm using Gnosis Safe I would first
const mars2 = await MarsV2.attach(CONTRACT_ADDRESS)
await mars2.transferOwnership(GNOSIS_ADDRESS)

Then if in the future I want to do an upgrade would this have to be done through
const proxyAddress = '0xFF60fd044dDed0E40B813DC7CE11Bed2CCEa501F';

const BoxV2 = await ethers.getContractFactory("BoxV2");
console.log("Preparing upgrade...");
const boxV2Address = await upgrades.prepareUpgrade(proxyAddress, BoxV2);
console.log("BoxV2 at:", boxV2Address);

GNOSIS UI OpenZeppelin Upgrades: Step by Step Tutorial for Hardhat

rather than doing this?

const MarsV2 = await ethers.getContractFactory("Mars1V2");
const mars2 = await upgrades.upgradeProxy(CONTRACT_ADDRESS, MarsV2);

@frangio

Yeah when I try to do an upgrade within GNOSIS for the Mars contract I receive.
Only EIP1967-compatible proxies are supported

I've tried to use the proxy address

And the contract address

Both show the same error when trying to use for upgrade within GNOSIS