openzeppelin/openzeppelin-subgraphs

Subgraph schema and templates to index the activity of OpenZeppelin Contracts.

openzeppelin-subgraphs's Issues

✖ Failed to upload subgraph to IPFS: Failed to upload file to IPFS: HTTPError: Forbidden Only certain IPFS methods are allowed

When following the sample deployment, subgraph errors out when calling npx graph deploy

This is using the config file shown in the example

Bug with EIP721 Token URI updates

Hi all (or @Amxx),

I've found a bug in the EIP721 code, related to token URI's not being updated when they should be.

On each transfer() and approval() event, the subgraph calls the following function to retrieve the token from the graph-node's GraphQL store: here

However, this function only queries and saves the token URI in the event that the token entity is not already found. In many cases, however, a token's URI can change; as the code currently stands, only the originally set token URI will ever be returned.

This should be as simple as always bind()ing and checking the token URI when loading the token, so that the updated URI always gets saved back to the store.

I can create a PR to merge this change in and will attach it to this issue.

Add support for `ConsecutiveTransfer` indexing for EIP-2309 compliant tokens

Description

Since the introduction of ERC721Consecutive in OpenZeppelin contracts, there's now a variant of transfer that's not indexed by OpenZeppelin subgraphs:

event ConsecutiveTransfer(uint256 indexed fromTokenId, uint256 toTokenId, address indexed fromAddress, address indexed toAddress);

Additional config to include in generated subgraph.yaml

I want to add additional configuration in subgraph.yaml ie.

graft:  base: Qm... # Subgraph ID of base subgraph  
block: 7345624 # Block number

One way to do this is to offer a cli arg that points to a yaml that will be inherited by yaml created with generated graph code.

Issue of using Bytes as entity IDs

Hi,

It seems right now there's a problem of using Bytes as IDs with the graph node, I've filed an issue here.

I don't think this is a problem of openzeppelin-subgraphs but I'm curious if anyone is seeing similar problems.

Also, I'm curious why one might favor using Bytes as opposed to ID when representing addresses, better performance?

Problem during compilation

When I attempt to compile with npx graph-compiler I get the following error in regard to the first entry in the datasources array in the sample.json. However, the .gql.json files exist in that directory.

Cannot find module 'erc721.gql.json'
Require stack:
- /home/maverick/Code/eth/openzeppelin-subgraphs/node_modules/@amxx/graphprotocol-utils/scripts/graph-compiler/config.js
- /home/maverick/Code/eth/openzeppelin-subgraphs/node_modules/@amxx/graphprotocol-utils/scripts/graph-compiler/cli.js

npx: 6.14.13
Ubuntu 20.04

Missing Dependencies

Overview

When attempting to run npm i, the prepare.sh script requires jq & winston, while just globally installing jq worked, the latest version of winston throws an error.

These dependencies and any other that might be needed, should be included in the package.json

Publish list of predeployed subgraphs

I believe some of these subgraphs have been predeployed. (Is that right?) Can we list them in the README? This would be a great way to introduce developers to the subgraphs and for quicker prototyping.

gitignore and generated/

Hey there! I've been doing some hacking related to adding new custom modules for my contracts, and noticed this. Most of the f*.schema.graphql file for each module are explicitly tracked per the .gitignore, with the exception of erc1967upgrade. Is there a particular reason for this? I see that on npm i and publishing that these files, alongside the yaml files are re-generated from source anyways.

EIP721 Token URI Bug

Hi all (or @Amxx),

I've found a bug in the EIP721 code, related to token URI's not being updated when they should be.

On each transfer() and approval() event, the subgraph calls the following function to retrieve the token from the graph-node's GraphQL store: here

However, this function only queries and saves the token URI in the event that the token entity is not already found. In many cases, however, a token's URI can change; as the code currently stands, only the originally set token URI will ever be returned.

This should be as simple as always bind()ing and checking the token URI when loading the token, so that the updated URI always gets saved back to the store.

I can create a PR to merge this change in and will attach it to this issue.

Duplicate key value violates unique constraint for `AccessControl`

Even after #36, this still happens for AccessControl

Use EIP-4906 for NFT metadata updates

EIP-4906: EIP-721 Metadata Update Extension

Cannot access derived fields of ERC-721

Attempting to access any derived fields inside functions will result in failure.

Subgraph instance failed to run: Mapping aborted at ../node_modules/@openzeppelin/subgraphs/generated/schema.ts, line 2426, column 12, with message: unexpected null wasm backtrace: 0: 0x3f30 - <unknown>!../node_modules/@openzeppelin/subgraphs/src/datasources/erc721/handleTransfer in handler `handleTransfer` at block #14456901 (cd04b81af2bf4c1057c5455097d0b2cdd5b7a3601ab1834316175d07f0c05843), code: SubgraphSyncingFailure

This does not only happen with contract.tokens, but with all other derived fields in ERC-721 too.

Reproduction:
https://github.com/the-emerald/oz-subgraph-tokens

npm i

and then go to node_modules/@openzeppelin/subgraphs/src/datasources/erc721.ts, in handleTransfer:

export function handleTransfer(event: TransferEvent): void {
	let contract = fetchERC721(event.address)
	if (contract != null) {
		let token = fetchERC721Token(contract, event.params.tokenId)
		let from  = fetchAccount(event.params.from)
		let to    = fetchAccount(event.params.to)

		token.owner    = to.id
		token.approval = fetchAccount(Address.zero()).id // implicit approval reset on transfer

		contract.save()
		token.save()

		let ev         = new ERC721Transfer(events.id(event))
		ev.emitter     = contract.id
		ev.transaction = transactions.log(event).id
		ev.timestamp   = event.block.timestamp
		ev.contract    = contract.id
		ev.token       = token.id
		ev.from        = from.id
		ev.to          = to.id
		ev.save()
+		let foobar = contract.tokens;
	}
}

Now deploy according to instructions in README.md.

ERC721 error: unexpected null - @openzeppelin/subgraphs/src/fetch/erc721.ts, line 64, column 9

Due to the fetchERC721 function having the return statement null as ERC721Contract, once deploying the subgraph, the subgraph fails with the following message: it can be viewed here

Error: Mapping aborted at node_modules/@openzeppelin/subgraphs/src/fetch/erc721.ts, line 64, column 9, with message: unexpected null wasm backtrace: 0: 0x20c3 - <unknown>!node_modules/@openzeppelin/subgraphs/src/fetch/erc721/fetchERC721 1: 0x2474 - <unknown>!node_modules/@openzeppelin/subgraphs/src/datasources/erc721/handleTransfer in handler `handleTransfer` at block #9000018 (4b7dedc5e85a1ce20f6f33cbba93b272c2464fa481c2cd51998c4127f8bf6cb4)

This graph was done very simply with the following configuration:
v0.0.1:

{
  "output": "generated/test.",
  "chain": "rinkeby",
  "datasources": [
    { "module": "erc721" }
  ]
}

v0.0.8

{
  "output": "generated/test.",
  "chain": "rinkeby",
  "datasources": [
    { "startBlock":  9000000, "module": "erc721" }
  ]
}

[Vanta] Remediate "Medium vulnerabilities identified in packages are addressed (Github Repo)" for npm-follow-redirects/CVE-2023-26159

What's wrong?
You have open medium severity vulnerabilities.

Github Vulnerability

• npm-follow-redirects/CVE-2023-26159

How to fix?

1. Visit the Vulnerabilities page to learn more about the unresolved vulnerabilities.
2. Remediate or deactivate monitoring for each unresolved vulnerability.
3. Optional] If the vulnerability was resolved outside of the SLA you’ve defined, explain the reason to your auditor on the [SLA violations page.

This issue was automatically created from Vanta. View test in Vanta

Issue of query the nested derivedFrom field after change from ID to byte

Hi everyone

I don't know if another guy has the same problem as me.
I got this issue when using @openzeppelin/[email protected], It is working fine in @openzeppelin/[email protected]

Suppose you create a subgraph for ERC20 tokens by graph-compiler. The below query will NOT work correctly.

 {
  erc20Balances {
    id
    account {
      id
      ERC20balances {
        id
      }
    }
  }
}

the nested fields ERC20balances will be empty. The same query with the same address is working fine in version @0.1.7-1

@graphprotocol/[email protected]

@graphprotocol/[email protected] has been updated to @graphprotocol/[email protected]
A lot of syntax needs to be updated
please help!!!!!

Prepare script deletes files, then throws due to empty files

> @openzeppelin/[email protected] prepublish
> rimraf artifacts build cache generated


> @openzeppelin/[email protected] prepare
> bash scripts/prepare.sh

node:internal/modules/cjs/loader:1176
    throw err;
    ^

SyntaxError: /openzeppelin-subgraphs/configs/accesscontrol.json: Unexpected end of JSON input

Upgrade graph dependencies for performance updates

Not an issue, but there was a new article from edge and node regarding updates to their packages graph-cli and graph-ts for indexing improvments

• Using immutable entities
• Using Bytes as the id

Would be great if this repo implemented these changes to improve indexing speed. I'll see if I can get around to it this week as we need these improvements for our production subgraph indexing bsc contract events (it's painfully slow - see this recent issue and this one)

No link to this repository from external documentation site

While going over https://docs.openzeppelin.com/subgraphs/0.1.x, I noticed there's no reference that links back to this repository. So I couldn't easily figure out that this is the repository where we keep the actual code that I should use to follow the docs.

What do you think of adding a link to this repository in the main page at https://docs.openzeppelin.com/subgraphs/0.1.x/ ?

Error during codegen

Hello together,

i am receiving the following error on codegen:

The code is available in https://github.com/amrap030/subgraph

Node version: v14.17.0
Npm version: 6.14.13

I would be glad if you can have a look at it. Thank you in advance!

the blocks cannot be synchronized!

The subgraph's version support for AssemblyScript has reached v0.19.0. After the current code is deployed, the blocks cannot be synchronized!

Missing LICENSE

Hey there, this repo is missing a license, so it's not free to modify or edit by default. Can we please get clarification on the licensing for this repo? Cheers!

[Vanta] Remediate "Medium vulnerabilities identified in packages are addressed (Github Repo)" for npm-axios/CVE-2023-45857

What's wrong?
You have open medium severity vulnerabilities.

Github Vulnerability

• npm-axios/CVE-2023-45857

How to fix?

1. Visit the Vulnerabilities page to learn more about the unresolved vulnerabilities.
2. Remediate or deactivate monitoring for each unresolved vulnerability.
3. Optional] If the vulnerability was resolved outside of the SLA you’ve defined, explain the reason to your auditor on the [SLA violations page.

This issue was automatically created from Vanta. View test in Vanta

Issue resolving addresses in erc721 transfers

Do you want to request a feature or report a bug?

• bug

What is the current behavior?

• all addresses (contract, from, to) in the erc721transfer are not correctly indexed and return null

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

• I followed the steps described here to index erc721 contracts on the aurora chain
• i changed nothing in the generated .yaml and .graphql files
• my config.json looks like this:
  { "output": "generated/sample.", "chain": "aurora", "datasources": [ {"address": "0xea5cc56b180d1a845bd86cba6711868a9763f461", "startBlock": 57466411, "module": [ "erc721" ] } ] }
• after deploying to the graphs hosted service I found the following behavior/bug:
  • when querying for multiple transfers all ids/addresses return null
    
    
  • the same behavior happens when I query for transactions for a particular token
  • but when I request a specific transfer it works
    
    

There's a similar issue already open but he uses Bytes instead of IDs, after inspecting the generated schema.graphql i saw that it uses both ids and bytes, could that be the problem?

What is the expected behavior?

• transfers returning the addresses correctly

Transfers don't reduce an accounts spenders approval amount (using the oz erc20 contract)

If an approved spender makes a transfer the accounts mapping to that spender approval amount won't reduce if the current openzeppelin template is in use without modifications.

In this transfer handler the approval amount isn't reduced based on the transferred amount

openzeppelin-subgraphs/src/datasources/erc20.ts

Line 30 in 5c55b2e

export function handleTransfer(event: TransferEvent): void {

The transferFrom function updates the spenders approval but doesnt emit a new approval event
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/5ed5a86d1d22f387ce69ab4e0ace405de8bc888d/contracts/token/ERC20/ERC20.sol#L305

In order to index the approval amount this override in the erc20 implementation would need to be implemented
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/5ed5a86d1d22f387ce69ab4e0ace405de8bc888d/contracts/token/ERC20/ERC20.sol#L277

This is not an issue if you were indexing a different erc20 implementation such as the uni token which emits an approval event when a transfer is made
https://etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984#code

Some questions and proposal

First of all Happy New Year to all and thanks for this repo, it is helping me to learn a lot, the second thing is that I would like to propose to make a default fetch URI in token creation ERC1155 for those contracts that does not implement the IMETADATAURI Interface because the replacement of the ID is done by the client, on the other hand, I like the system and I have created a fork of this repo because I would like to extend the templates, but I can not make it work, I can not even install the dependencies. Greetings to all and happy 2022.

Duplicate key value violates unique constraint after #25

Description

After #25, some entities were moved to immutable: true, which is reasonable and shouldn't be a problem. However, there are some entities that are being saved twice (with the same data), so there was no issue previous to the migration to immutable, but now it flags them as duplicated.

Overall, this issue is not happening to all of the immutable entities, but here are some examples

Proposed solution

Just check that any immutable entity that already exists doesn't get saved again.

Duplicate key value violates unique constraint "erc721_transfer_id_key"

Hi guys, I was deployed a subgraph which's index NFTs (ERC721 + ERC1155) on goerli-testnet. Everything seems working fine, but until recent block, it show the following error:

A non-deterministic fatal error occured at block 8656060: Failed to transact block operations: store error: duplicate key value violates unique constraint "erc721_transfer_id_key"

I think it can cause by event.id(block) function, which is concatenate block number to log index.

Cannot retrieve data by wallet address for erc721

Hello !

Does account entity in schema https://github.com/OpenZeppelin/openzeppelin-subgraphs/blob/main/generated/erc721.schema.graphql correspond to the wallet ? If so I can't query using id as the wallet address at least on aurora and moonbeam ?

Thank you