Migrating Lootboxes (Crates, UCR) contract on Harmony

Progress and updates
1

Hey guys!

Unfortunately we need to migrate Lootboxes contract on Harmony network – we don’t have some needed functionality for opening them (my bad – a small mistake).

image
image700×514 41.2 KB

Several minutes ago we stopped minting for new lootboxes, and now we are migrating them to a new contract. I will describe here, what is happening and how.

Users shouldn’t notice anything as an address for lootboxes will be changed, and the app will fetch data from the new contract.

@Lyagushka is in contact with Nftkey to give them all the information on the new contract (they will probably delist old and add a new collection)

New information soon ->>>>>>

1 Like
2

How Lootboxes mint works?

  • There is a GameManager role in the Lootboxes contract – only address which is GameManager can mint new lootboxes
  • Our GameManager.sol contract has finishMission method – a method for claiming mission rewards. If a user got a crate, this method calls mint method in Lootboxes.sol contract. New crates are minted only this way
  • There is burn method in lootboxes contract which is only accessible by GameManager role. It is needed to “open” crates in nearest future – to burn crate NFT and mint some new cool stuff
3

old contract on Harmony: 0x94E20843CFdB77379B13704469C4388aba15Cc75
new contract on Harmony: 0xd88980c139f0267A0Af9eaA21DD3062f79515D74

old contract on Fuji: 0x09689031eB0dcaFFf602C05055f00E09FeE7c6E6
new contract on Fuji: 0xB1789d09129617B77B6efFe36496CB48D1b09d7E

there are 61 crates on Fuji testnet and we’ll migrate them first

4

While migrating we need not to lose any token, any rarity, any information.

First we thought to make a snapshot and create same tokens on a new contract - but.
But while keeping a snapshot and migrating there could be some transfers, sells of crates - and we can lose this information.

So we need to do migrations in one transaction.

I created Migradoor contract for this (0x3A6CbD3Db97185DE6B4758abcf7AAd73f3DE066C on Fuji):

contract Migradoor {
    address constant oldLootboxes = 0x09689031eB0dcaFFf602C05055f00E09FeE7c6E6;
    address constant newLootboxes = 0xB1789d09129617B77B6efFe36496CB48D1b09d7E;

    function migrate(uint256 count) external {
        uint256 totalSupply = TokenInterface(oldLootboxes).totalSupply();
        uint256 realCount = count < totalSupply ? count : totalSupply;
        require (realCount > 0, 'no NFTs');
        for (uint256 i = 0; i < realCount; i++) {
            uint256 tokenId = TokenInterface(oldLootboxes).tokenByIndex(i);
            address owner = TokenInterface(oldLootboxes).ownerOf(tokenId);
            ILootboxes.Rarity rarity = ILootboxes(oldLootboxes).rarities(tokenId);

            ILootboxes(oldLootboxes).burn(tokenId);
            ILootboxes(newLootboxes).mint(owner, rarity);
        }
    }
}

And currently I test it on Fuji – here is the first migration transaction

5 tokens burned and 5 minted in the same transaction

Same tokenIds, same owners, same rarities

5

Just after rechecking I see a problem that after one burn tokenByIndex (from ERC721Enumerable extension) gives not first ids in the beginning.

It isn’t critical if token ids aren’t same, by it’s better for them to be.

So the new Migradoor (Fuji 0x16bDC39EAE6BA2e73788dd929D83ee0755E1fB89):

contract Migradoor {
    address constant oldLootboxes = 0x09689031eB0dcaFFf602C05055f00E09FeE7c6E6;
    address constant newLootboxes = 0xB1789d09129617B77B6efFe36496CB48D1b09d7E;

    function migrate(uint256[] memory tokenIds) external {
        for (uint256 i = 0; i < tokenIds.length; i++) {
            uint256 tokenId = tokenIds[i];
            address owner = TokenInterface(oldLootboxes).ownerOf(tokenId);
            ILootboxes.Rarity rarity = ILootboxes(oldLootboxes).rarities(tokenId);

            ILootboxes(oldLootboxes).burn(tokenId);
            ILootboxes(newLootboxes).mint(owner, rarity);
        }
    }
}

Transaction: Avalanche Transaction Hash (Txhash) Details | SnowTrace

6

Migration on Fuji successful, Harmony soon

7

Harmony Migradoor: 0x93017407ACAeF8f30ea62A67dD3d6C856073D0A7

in process

8

Migration complete