[BUG] Wrong declaration of URD address from return object about docs HOT 9 CLOSED

Please feel free to keep your code as suggested above. You can look into PR 751 (linked in the timeline above) to find out what will change in the docs/code: https://github.com/lukso-network/docs/pull/751/files

It should be fine as it is. Just waiting for approval from our SC team (in case there are further improvements to be made)

from docs.

UPDATE: URD address didn't work for some reason. Seems like whenever I deploy URD, the address is always an EOA.

Here's the code:

import LSP1UniversalReceiverDelegateVault from '@lukso/lsp-smart-contracts/artifacts/LSP1UniversalReceiverDelegateVault.json';

const vaultURDFactory = new ethers.ContractFactory(
      LSP1UniversalReceiverDelegateVault.abi,
      LSP1UniversalReceiverDelegateVault.bytecode,
    );

const vaultURD = await vaultURDFactory.connect(signer).deploy();
        console.log("vaultURD", vaultURD)
        // URD address
        const URDaddress = vaultURD.address;
        console.log("URDaddress", URDaddress)

This is return object:

Then when I lookup the address that's in in return object, in this case 0x21BE2f78D9B1A541D223a388df3C1d9d915996E0 - it's an EOA - https://explorer.execution.testnet.lukso.network/address/0x21BE2f78D9B1A541D223a388df3C1d9d915996E0.

So, reason why fetchData() is not working on my vault is because the address returned that I thought was URD is just an EOA. Not sure why this is the case.

from docs.

I also noticed same issue with vaults when deploying.

Transaction: https://explorer.execution.testnet.lukso.network/tx/0x06e4446c69aa5b6a0b59128f4f5c7c463067f82c38657fffc17905b883259262

Address from response obj: 0x227cF66484892bccf6ad81DD14E47311F9778FC3

from docs.

SOLUTION:

After taking a coffee break, I realized what's causing the issue.

In theory, whenever we deploy URD or Vault the return object should contain address of the deployed contract. Currently when deploying contracts in following manner:

Vault:

const vaultFactory = new ethers.ContractFactory(
      LSP9Vault.abi,
      LSP9Vault.bytecode,
    );

    const VAULT = await vaultFactory.connect(signer).deploy(address);
    
    console.log(VAULT.address)

URDv:

const universalProfileURDFactory = new ethers.ContractFactory(
      LSP1UniversalReceiverDelegateUP.abi,
      LSP1UniversalReceiverDelegateUP.bytecode,
    );

    const URD = await universalProfileURDFactory.connect(signer).deploy();
    
    console.log(URD.address)

the return object does contain an address, but it's not the deployed smart contract (see images below):

Instead I created 4 separate functions.

test1() > deploys vault specific URD
test2() > deploys vault itself
test3() > encodes data with addresses I manually retrieved from transaction hashes from previous two deployments (again, I had to manually extract deployed contract addresses from "internal transactions" section)
test4() > here we fetch assets held by vault with "LSP5ReceivedAssets[]".

After all of this it worked. I use ethers so "return vaultURD.target;" does not work as well, which was reason for this issue.

As @iber pointed out in Discord, you can simply await the deployment transaction like so:

const URD = await vaultURDFactory.connect(signer).deploy();

const contractAddress = await URD.deployTransaction.wait();

which then returns object with "contractAddress" field that's the actual address of deployed contract.

from docs.

This is great @Heisenburgirs , I'm Iber. This caused me a few hours to figure out

from docs.

Using ethers 5.7.2 btw

from docs.

Thanks @Heisenburgirs for the great report! Sorry to read you had issue. We are currently looking into it and will update these docs asap.

cc @biancabuzea200 @fhildeb

from docs.

Hey, thanks for your contribution and findings. 🙏🏻

I just created an update for our docs. This issue will be automatically closed once it's merged into main.

from docs.

Thanks!
Will there be a change in the code or will there be a change in the docs?
I'd like to know in case I have to change how I use it now ( the current work around pointed above)

from docs.