hboon
commented
3 years ago contractURI()
function contractURI() returns(string metaData)Ok, but note that this is at the contract level so name and image are for the contract, not for the individual token types or token instances. (ie. we can use this to show that single row in the Wallet tab only), so if decimals is included here, we can't use it since there would be more than 1 token type (with 0 or more decimals value) in this same ERC1155 token-holding contract. [1]
Sometimes the URL (maybe just from Rarible?) have an {address} variable embedded. We'll need to substitute it with the contract address:
https://api-mainnet.rarible.com/contractMetadata/{address}uri()
function uri(1) returns(string token Description Metadata for token index 1)While the contracts I came across use uri(), the ERC1155 standard defines tokenURI(), so we'll have to support both.
Telling the difference between fungibles and non-fungibles
Like I mentioned separately, I couldn't find a way to tell them apart, given an _id. (maybe if decimals is included in the uri()/tokenURI() data? But I haven't found any fungible to verify against yet).
Fetching balances
We'll have to use event logs to figure this out. But blockscout.com (at least for xDai) supports getting ERC1155 transfers.
Couple of unknowns:
- I've only tried on xDai. Not sure about others, eg. classic on blockscout.com
- I don't know if
safeBatchTransferFrom()are included and if they are, how they are included in the results. So this approach might not work - Not sure about blockscout white-labels
Sample contract: https://blockscout.com/xdai/mainnet/tokens/0x93d0c9a35c43f6BC999416A06aaDF21E68B29EBA/read-contract Transfers: https://blockscout.com/xdai/mainnet/tokens/0x93d0c9a35c43f6BC999416A06aaDF21E68B29EBA/token-transfers One of them: https://blockscout.com/xdai/mainnet/tx/0xb5d96a979406faff272cc68b9a143575dcc79f462bcaa38b6edb8b2b5a1ab7a3
GET(s):
Sender:
curl 'https://blockscout.com/xdai/mainnet/api?&module=account&action=tokentx&address=0x2a58ab26538a905f08ac7838b83c1c160430e744&sort=desc' | json_pp | clipReceipient:
curl 'https://blockscout.com/xdai/mainnet/api?&module=account&action=tokentx&address=0x61cd76d2dab94cbf81ad45a8451f1467cead23fe&sort=desc' | json_pp | clip(they both includes transaction 0xa5c15de2c4bff26810ebc3dd7df64d2c4a7afdff9ffb255c7905f501c7e80b86)
Event logs
{
"name" : "TransferSingle",
"inputs" : [
{
"type" : "address",
"indexed" : true,
"name" : "_operator"
},
{
"type" : "address",
"indexed" : true,
"name" : "_from"
},
{
"type" : "address",
"indexed" : true,
"name" : "_to"
},
{
"type" : "uint256",
"name" : "_id",
"indexed" : false
},
{
"type" : "uint256",
"name" : "_value",
"indexed" : false
}
],
"type" : "event",
"anonymous" : false
},
{
"name" : "TransferBatch",
"inputs" : [
{
"type" : "address",
"indexed" : true,
"name" : "_operator"
},
{
"type" : "address",
"indexed" : true,
"name" : "_from"
},
{
"type" : "address",
"indexed" : true,
"name" : "_to"
},
{
"type" : "uint256[]",
"name" : "_ids",
"indexed" : false
},
{
"type" : "uint256[]",
"name" : "_values",
"indexed" : false
}
],
"type" : "event",
"anonymous" : false
}JavaScript code
TransferSingle:
contractInstance1.getPastEvents('TransferSingle', {
filter: {
_to: owner,
},
fromBlock: 0,
toBlock: 'latest'
}, function(error, events){ console.log(error, events); })TransferBatch:
contractInstance1.getPastEvents('TransferBatch', {
filter: {
_to: owner,
},
fromBlock: 0,
toBlock: 'latest'
}, function(error, events){ console.log(error, events); })Will need to filter for _from for both events too.
Getting Collection/Token type name
Referring to Tomek's designs where "Mathilde Cretier" the collection name is displayed. We wouldn't get such a representative name, it'll be something like "Enjin" or "Rarible" instead, because it is at the contract level, not at the collection/token type level.
[1] So if there's a fungible representing fiat (fractional dollars) instead of gold (discrete pieces), I don't know how to get/provide decimals for the fiat type... maybe it is included uri() or tokenURI()
Variables in URLs
- contractURI() might have the variable {address} which needs to be replaced with the contract address
- uri()/tokenURI might have the vararible {id} which needs to be replaced withtokenId/_id (and similarly for any URL inside the JSON served by this URL)
Effect on UI
So based on the collection, collection name and contractURI() things we talked about, and referring to Tomek's design https://projects.invisionapp.com/share/HD10WWZ5JXA5#/screens, the UI flow would be the same, but the data displayed is slightly different because we can't tell multi-collections/multi-verse from collections. We have to treat each ERC1155 as a single multi-collection like that:
- Wallet tab display 1 row per ERC1155 contract (if "0xfaafdc07907ff5120a76b34b731b278c38d6043c", hardcode "Enjin", otherwise get from
contractURI(), otherwise tryname()(ouch Enjin doesn't have that too!), otherwise display the contract name. - Tap on the row in Wallet tab (eg. Mathilde Cretier Art, which will actually display as "Enjin")
- Under Assets, it will show all the _id/token IDs under this contract. For "Enjin", it will show the tokens from "Mathilde Cretier" as well as "The Vault" and "Lost Relics" (for Tomek's wallet). If we had tapped on "GenSys.X" in the Wallet tab (which is another ERC1155 contract), the "Assets" tab will show a list of tokens from this contract.
JamesSmartCell
@hboon Some notes on ERC1155 specifically for tracking balances and URI I made:
Check the Ethereum standard https://eips.ethereum.org/EIPS/eip-1155
Token name and symbol are usually the same as ERC20/ERC721:
However the ERC1155 spec in openzeppelin doesn't indicate these are required. Name is also supplied in the contractURI:
Here is an example of an overall contract URI metadata, however this route may or may not be present.
-->
From the Ethereum standard:
Note the
decimalsfield above!Note that
imageis the equivalent of the token image in ERC721, so in the example of a print run of 50, theimageis the actual print.Here is an example of specific tokenUri
-->
Balance events:
_operator: the sender of the transaction_from,_to: as expected_id: token Identifier_value: as expectedAs above, but note the array fields for
_idsand_valuesIs emitted when the URI for a token changes. TODO: Find out if the unindexed string gives the actual string or is the hash value. If it's the actual string then it can be used to re-load the metadata.
Interface spec