Hey, thank you for a great subgraph 👍
I wonder if you plan to support transactions' log (if it is possible ofc)

I was trying to query the EIP721 subgraph on The Graph playground for all the NFTs managed by a contract, such as 0x06012c8cf97BEaD5deAe237070F9587f8E7A266d. I did some googling and following this comment, I came up with this query:

{
  tokenRegistry(id: "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d") {
    tokens {
      identifier
      owner {
        id
      }
    }
  }
}

However I got a null result:

{
  "data": {
    "tokenRegistry": null
  }
}

The same query with some different contract address such as this works. So I was wondering whether there was some contract allowlist somewhere, but the closest I could find in the code base was this https://github.com/Amxx/subgraphs/blob/master/subgraphs/common/config/eip721.json, which doesn't look to me like it's filtering out any contract address.

@Amxx could you please advise if I am missing something from the query? Also, is this subgraph supposed to work for all ERC721 contracts on Ethereum or whether there's an allowlist somewhere? Thank you.

Here is the complete error

wasm trap: out of bounds memory access wasm backtrace: 0: 0x1d42 - !~lib/util/memory/memcpy 1: 0x1e8b - !~lib/memory/memory.copy 2: 0x36e2 - !~lib/string/String#replaceAll 3: 0x387e - !../node_modules/@openzeppelin/subgraphs/src/fetch/erc1155/replaceURI 4: 0x3c3e - !../node_modules/@openzeppelin/subgraphs/src/fetch/erc1155/fetchERC1155Token 5: 0x3db3 - !../node_modules/@openzeppelin/subgraphs/src/datasources/erc1155/registerTransfer 6: 0x4843 - !../node_modules/@openzeppelin/subgraphs/src/datasources/erc1155/handleTransferBatch in handler handleTransferBatch at block #16899351 (b1e020fd883a5a65f091fe52c275fcdcde1fabbb1a6b48a33bcd941e2e8ade19)

@Amxx can you help in figuring out the issue?

Hi,

I'm new to subgraph & my goal is to fork the eip721 subgraph for difference chains.

I try to run yarn in the common folder and it fails because it can't find some open-zeppelin dependencies.
I fix a wrong dependency: "@amxx/graphprotocol-utils": "^1.1.0-alpha.2", should be "@amxx/graphprotocol-utils": "^1.1.0",
It still doesn't work. yarn puts all packages in the main node_modules folder.

I removed the main packages.json file and run again yarn from inside the common folder. This time all packages + the @amxx/graphprotocol-utils (previously missing) are saved in common/node_modules

Still I get an error when I run yarn in the common folder.

$ scripts/prepare.sh
/myhome/subgraphs/subgraphs/common/node_modules/@amxx/graphprotocol-utils/scripts/graph-compiler/utils.js:14
    throw new Error(error);
    ^

Error: Error merging schema entries: incompatible fields found for Account
    at assert (/myhome/subgraphs/subgraphs/common/node_modules/@amxx/graphprotocol-utils/scripts/graph-compiler/utils.js:14:11)

I was hoping to be able to somehow prepare the dependencies needed, then change "chain": "mainnet", to "chain": "avalanche", in the config/eip721.json file (and then try to deploy from there)... but I'm stuck and I'd like some help.

OS: Fedora Linux (i case anyone needs this, I had to install libsecret-devel: sudo dnf install libsecret-devel)
Node version: v16.17.0

Any help/hint is appreciated. Thank you

Hi, the eip721 subgraph seems to works fine, but for collections that do a reveal (which are most nowadays), the metadata is stale compared to what you can get from the contract.

Example, query NFTs from this contract:

{
  contract(id: "0x345974220a845ddeceed011e8e6106b59724b661") {
    asERC721 {
      tokens {
        identifier
        id
        uri
      }
    }
  }
}

Let's take 0x345974220a845ddeceed011e8e6106b59724b661, which has identifier 257 and uri ipfs://QmWckz84W5GPBjyoyCiDWsbwcGjUDWmBGPURmpZ9639tvm/257. If you follow it you will see there are no traits in the JSON.

If you go on Etherscan and read the contract, put the identifier as tokenId for the tokenURI function, you get another URL: ipfs://QmQCA6Hfr7357MrQskqsPmcBfGre8WDUUcH4qur15s4ELt/257.
This has the full metadata.

Now the subgraph shows as fully synced, so maybe there's some black magic I'm not understanding? Is this a type of data that we cannot get from The Graph, because we have to run the contract each time?

I know that the name of the subgraph is 721, but I wanted to know if there were any plans to also support the new 721A standard as part of this?

In fetchRegistry you check that a token is compatible with ERC721 interface 80ac58cd, but some NFTs for some reason return false for that interface and true for ERC721Metadata 5b5e139f and then they are not inedexed.

For example: https://etherscan.io/token/0x2a46f2ffd99e19a89476e2f62270e0a35bbf0756

Edit: Sorry, closed issue. For some reason the example doesn't support any of 3 (Erc721, metadata or enumerable)