Closed owocki closed 3 years ago
@kvrnc does this look ok?
I assume they will not be able to handle the IPFS hashes? I'd prolly suggest that we need to generate a API call for them (as the nft.com/id example) so they can fetch the data...
@kuhnchris is right since the contract is not verified, we are unable to determine the function and field available to pair the token id with the ipfs hash. @owocki by any chance you have the ABI for the contract? Here is a sample of an un-verifiable contract with ABI, Read and Write function works. https://etherscan.io/address/0x2e642b8d59b45a1d8c5aef716a84ff44ea665914#code
It's basically a ERC721, minimal ABI provided here: https://github.com/kuhnchris/KudosDisplayCards-dApp/blob/master/src/web3wrapper.ts
Alternative the 'official' ABI available but not matching up the contract(s) 1:1 is here: https://github.com/OpenKudos/python_client/blob/master/abi/kudos.json
i dont understand why this is so complicated. we use ERC721 standards in the Kudos. it should be easy to integrate the kudos data; verified or not (Kudos is not verified on OpenSea for example).
well, the main issue is that you have deployed a contract that is simply not verifiable, and hence not trustworthy... since nobody can check what you actually got in the contract. for all purposes and for the history that had happened before, your token could have an exit scheme/exit function that allows you to empty the contract. that's the reason why some things require verified contracts.
...not sure why we'd need that for displaying images with the tokenURI function tho, but, yeah...