Open sichen1234 opened 2 years ago
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This issue now has a funding of 200.0 USD (199.92 USD @ $1.0/USD) attached to it.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Workers have applied to start work.
These users each claimed they can complete the work by 264 years, 3 months from now. Please review their action plans below:
1) 0x0-github has applied to start work _(Funders only: approve worker | reject worker)_.
Hi, I think I can fix this, regarding the issue with encoded data, this is normal as you display tem as UTF-8 if you put it back to raw or other modes you should see the difference 2) jjhesk has applied to start work _(Funders only: approve worker | reject worker)_.
I can help you with this problem. Try using one different tool to see it. I have the tool to help. 3) tgarm has applied to start work _(Funders only: approve worker | reject worker)_.
I can help to make the token transfer in explorer shows normal. As for the input data decoding, it determines on the kind of operation. I can help to make normal operations decode well.
FYI, I've developed NFTs like this: https://testnet.bscscan.com/tx/0xf245455030fc91192fe8fdb07240fe18206bfed9816807f1bbdef83b97cfd317
Learn more on the Gitcoin Issue Details page.
Hi, I got your answer on the feed. I will need some extra information, the two links you provided are the same tx (so I can't see any difference). Can you also describe me a little more precisely what you expect regarding the json data decoded. I also don't understand the why is there a scenario where there's no Transfer event emitted
The only difference between the two screenshots regarding the input data is that it is in default or original view in first one and in utf-8 in second one which is logical since data aren't decodable with utf-8, it just uses slots filled by function selector and arguments as an hex number.
@0x0-github Sorry I fixed the links and uploaded images of the 2 transactions. Now they are different.
For a point of comparison, look at what we deployed to goerli last year: https://goerli.etherscan.io/tx/0x6014fc62c05cd4670cb63e15f63123afcc64a39c802bf6238ac87b042954002d
It shows the Tokens Transferred info, and once you click on "Decode" for Input Data, you see the data there clearly. I'm not sure why Tokens Transferred info is missing. The Input Data may be messed up now that we have changed the manifest and metadata to JSON format.
I'm looking to use these field values so that we can synch the data with a database, to perform searches and queries. Does that sound like a reasonable use case?
@sichen1234 a solution to take this information and display in any kind of decoding is using a subgraph it works on almost all EVM networks (ethereum, binance smartchain, avalanche, harmony, fuse...)
@developerfred Are you suggesting graphql? We thought that it would not do so well if we tried to query a large number of tokens, so we implemented a token-query-server/ which sync's the tokens with a postgresql database. It is working now, though I thought it'd be better to get the on-chain data correct as well. Do you think so?
@sichen1234 I'm suggesting https://thegraph.com/en/, it uses graphQL depending on how the queries are consumed it is ideal for a large amount of information, if you use the mainnet then the synchronization is very fast and the storage is in ipfs, you can make a crown that takes the information from the subgraph and throws it in postgress so you will have two sources of asyncronous information
@developerfred Interesting. So then are the changes/fixes in this issue not necessary? Pls email me at sichen@opensourcestrategies.com - I'd like to discuss that further.
The difference you get on the decode is up to etherscan/bscscan and I don't think bsc scan development is that far. I alway had weird characters trying to decode with utf-8. For the Token transferred, this is displayed if you triggered your transfer event in your smart contract.
If you need to query large amount of data, consider using thegraph like developerfred suggested wich is pretty awesome even if not free, the advantage is that it is pretty fast. But since you're talking about BSC you could also build your own (bsc RPC url aren't limited like in ETH network) like you did. It will only depend on the amount of data you need but it's costless and have no limitations (x calls / x months). Parsing input data from ethersjs is no big deal
Add the Tokens Transferred Info to the tokens created by our NetEmissionsTokens.sol, so that it is more like this token on BSC testnet
Make it possible to decrypt the input data again. We've made the metadata JSON format, and it seems they are mixed together. You can switch between the different views and decode input - none of them are showing the correct decoded metadata.
Example of Tokens Transferred:![Screen Shot 2022-04-01 at 9 59 25 AM](https://user-images.githubusercontent.com/1706353/161309337-db2c1603-c1c6-4f0e-883b-1be24ac7c80a.png)
Our token without Tokens transferred and with input data not decryptable:![Screen Shot 2022-04-01 at 9 59 41 AM](https://user-images.githubusercontent.com/1706353/161309396-fc1f93ae-fef3-44bc-8052-1ffb4613b0c3.png)