[Thread] Indexing Issues (Anonymous Profile/Empty Description)

[dusk depot]

If you experience issues searching for Universal Profiles on https://universalprofile.cloud and https://explorer.lukso.network/, or profiles and assets are showing as anonymous/with empty data, please comment the link/address below.

For Universal Profiles that are kept in the extension, please try to edit your profile data again first, as shown in this guide: https://support.lukso.network/general/profile-explorer/#why-does-my-profile-show-as-anonymous

We are constantly trying to improve stability for indexing. This thread will help us get back to you in one place, and resolve such issues quickly. 🙏🏻

FYI <@&820971103576129556>

LSP7 showing as empty for asset from @sharp scroll
Link: https://wallet.universalprofile.cloud/asset/0x8f7aecB612808703718aA76fB4752f930AB3487e?network=mainnet

[sharp scroll]

In the response from Algolia, LSP4Metadata is empty despite verifiableUri is present with https://debulls.cc/token/metadata.json

[south hornet]

On my end, i don't have an issue with my UP but with our LSP8 collection https://explorer.execution.mainnet.lukso.network/address/0x7c6118Ba719a62D40CE6c9580F96306a558CDA6F

This doesnt show neither the creator's UP nor at which txn it was created, i've looked at other projects and only our collection has this problem, not sure how to resolve it

0xaDD8E3947A934467afd9A6588e2c19ac89c1e15a this should be the creator UP of this LSP8

[scarlet musk]

Thanks for flagging, @sturdy crest LSP8 indexing issue

[sturdy crest]

I'll create a ticket so we can track this

Thanks

[sturdy crest]

I want to understand the issue a little better, when you say "This doesnt show neither the creator's UP nor at which txn it was created" what do you mean by this? The execution explorer or the wallet?

[south hornet]

In the explorer https://explorer.execution.mainnet.lukso.network/address/0x7c6118Ba719a62D40CE6c9580F96306a558CDA6F

This is our collection contract, if you compare this link with another lsp8 contract you’ll quickly see what I mean, it’s missing creator info

[south hornet]

So I guess to directly answer you, it would be the creator’s wallet and the creation hash

[timid lagoon]

I think we should not mix:

Creator as per "creator of the contract" (contract deployer)

and creator as per "creator of the "asset" like as written WITHIN the contract"

The reason it doesnt show up as "creator" (deployer : on blockscout) is because it was probably deployed by a UP, so it shows as an internal transaction).

[timid lagoon]

Please note that the blockscout explorer is sadly not yet supporting all the LSP perfectly.

It is a bit dumb

[sharp scroll]

@timid lagoon did you have time to check this?
#1219594025514963014 message

[timid lagoon]

And in there, the creator is meant to be the "deployer" of the contract. (not creator in the sense of "Intellectual property" let's say)

[timid lagoon]

@dusk depot - for some reasons, also this asset doesn't show as LSP7 in the inspector:

https://erc725-inspect.lukso.tech/inspector?address=0x8f7aecB612808703718aA76fB4752f930AB3487e&network=mainnet

So either it comes from the contract or from our frontend idk

[sharp scroll]

It uses LSP7 v0.15.0-rc.0

and ERC725 Inspect Tools still uses v0.14.0 with older LSP7 interfaceID

[timid lagoon]

ok ty nice catch

yeah we didnt implement 15 rc yet

Im thinking maybe it might be because the hash verification of the json file is not correct

but i need to decode

0x00006f357c6a002040d7d5391fe721ca6a57aec0ad65897b66a948ec17bba7a8c41f12bdfef0024a68747470733a2f2f646562756c6c732e63632f746f6b656e2f6d657461646174612e6a736f6e

this is the VerifiableURI - i dont have anyting to decode it fast rn

[sharp scroll]

https://github.com/lukso-network/LIPs/blob/main/LSPs/LSP-2-ERC725YJSONSchema.md#verifiableuri

0000 — VerifiableURI identifier
6f357c6a — Verification method keccak256(utf8)
0020 — Verification data length
40d7d5391fe721ca6a57aec0ad65897b66a948ec17bba7a8c41f12bdfef0024a — keccak256 of the contents of https://debulls.cc/token/metadata.json
68747470733a2f2f646562756c6c732e63632f746f6b656e2f6d657461646174612e6a736f6e — HEX-encoded URI https://debulls.cc/token/metadata.json

👇
I believe the problem is at the Indexer side. It also stuck @ "updatedAtBlockMetadata": 2105439 despite I did update the LSP4Metadata at a later block...

[sharp scroll]

@timid lagoon also, the UP extension parses LSP4 metadata properly and displays the token icon! but UP Cloud doesn't...

[south hornet]

I think we’re having a misunderstanding

1st image is BurnPunx LSP8 and 2nd image is DWOOBz LSP8 both were deployed using universal.page

Ours is missing creator info and creation txn

@stuck bough is the issue on your end?

I didn’t say it should show as creator, I said it’s missing creator/creation info like every other lsp8 on blockscout, so it’s not a compatibility issue since DWOOBz lsp8 is the only one where that is missing

txn.app shows the creator UP without issue so I’m pretty sure this is an indexing issue, maybe I’m completely misunderstanding what is happening, but if it isn’t then issue lies at universal.page I guess?

The main question is why would one lsp8 among others on blockscout only not show the creator info of that lsp8. This is an issue only present on blockscout so if it isn’t an indexing issue what is it?

Hopefully I was more clear this time

[south hornet]

Yes I understood that, I think we’re going in a completely different direction here, I’m simply pointing a difference present only on DWOOBz lsp8 among every other lsp8 launched from upage and only blockscout (wallet explorer and txn.app have no issue identifying the creator’s up)

[timid lagoon]

@surreal owl - do you have any ideas why the contract creator (deployer) doenst show up in blockscout?

My assumption is that it might be in internal transactions bc of some UP execute deployment and that blockscout doesnt detect it so well. Wdyt?

[timid lagoon]

Txs.app uses LUKSO blocscout as a backend. So that data are the same.

Plan is to go with own separate backend but this needs some time to be done

Other assumption could be an issue in blockscout indexer, which is weird. Let's see what Matt thinks.

[sharp scroll]

@timid lagoon I just updated the LSP4 metadata once again. The indexer has caught it and updated the verifiableUri, but not LSP4Metadata

[timid lagoon]

@sturdy crest coudl you take a look at this?

[south hornet]

I think the indexer was updated after we deployed it, this contract being one of the oldest lsp8 deployed from upage, I think a reindexing of blockscout would fix this personally

[timid lagoon]

So we have 2 backend systems:

1. Blockscout backend -> which simply indexes blocks and tx but has very little knowledge of LSP
2. Our custom made indexer - entirely made for LSP

Maybe blockscout is missing some info but this would be weird - waiting on @surreal owl s input here

[sharp scroll]

Is your custom made indexer open source?
If yes, share a link to it, please, so we can also investigate ourselves 🙂

[surreal owl]

Hey @south hornet, could you share the links for both explorers LSP8? From what I understand, the Execution Explorer doesn't display the creator of the LSP8 contract, while another explorer does show it, correct?

[surreal owl]

Blockscout (execution explorer backend) is 1:1 with Ethereum. Backend indexer doesn't support LSPs. Integration is made on the FE layer with internal LUKSO LSP indexer and storage. But I'll need to compare both (explorer LSP links), and then I can say more.

[sturdy crest]

Will take a look

[timid lagoon]

yeah but LSP aside, why would Blockscout NOT show the deployer of the contract?

[timid lagoon]

as per here ^

[surreal owl]

Hard to say... I need to check DB, backend flow and compare those 2 LSP

[sturdy crest]

Found the issue and produced a fix. We'll need to re index to fix this record on mainnet.

it was related to the content-type check being too strict

[sharp scroll]

I guess it didn’t expect ;charset=UTF-8 part to be present? 👀

[south hornet]

DWOOBz
https://explorer.execution.mainnet.lukso.network/address/0x7c6118Ba719a62D40CE6c9580F96306a558CDA6F

BurnPunX
https://explorer.execution.mainnet.lukso.network/address/0x66b738baea30243bfe4c168a11e79dd1f930e59c?ref=txsapp

Chillwhales
https://explorer.execution.mainnet.lukso.network/address/0x86E817172b5c07f7036Bf8aA46e2db9063743A83

Just examples really but I haven’t seen another lsp8 contract with that issue outside DWOOBz I really think a reindexing would fix this

@surreal owl

[surreal owl]

Ok, thanks. I'll get back to you when I check all things on the blockscout side (backend, DB for https://explorer.execution.mainnet.lukso.network/address/0x7c6118Ba719a62D40CE6c9580F96306a558CDA6F)

[surreal owl]

I really think a reindexing would fix this - Blockscout already includes a sanitizer and other Elixir components to ensure thorough indexing in the database, but let me check

[surreal owl]

I was really busy today... sorry. Looking at it now guys 👍

[surreal owl]

From Blockscout perspective, to present Creator title it is required to: data.is_contract && data.creation_tx_hash && data.creator_address_hash, now I'll check what's in Blockscout DB

[stuck bough]

1. what

[south hornet]

Matt is on it, I think the DWOOBz lsp8 contract was made on upage before the explorer had creator tags

[sharp scroll]

Have you started the re-indexing process yet?

[sturdy crest]

Hey Marv1n, we are fixing another issue and will trigger the re index.
We are also working on a way to be able to fix these occurences faster

Sorry for the inconvenience

[surreal owl]

Hey 👋 This case is very strange and unique... I reached out to the Blockscout dev team for help. I see Deployed ByteCode only, but not the Contract creation code for 0x7c6118Ba719a62D40CE6c9580F96306a558CDA6F and it's hard to understand why. It also seems that the only way is to try with https://github.com/blockscout/blockscout/pull/6582 to force Blockscout Elixir backend to reindex TXs for blocks range - just need to confirm with BS team now.

[surreal owl]

Hey, what we've found with BS team is https://explorer.execution.mainnet.lukso.network/tx/0x786114fce66f9b93b7ff4e76b0d2725ddba4a5e1c4f3acf334c44b08e5a792ce and it's TX trace shows (https://explorer.execution.mainnet.lukso.network/address/0x7c6118Ba719a62D40CE6c9580F96306a558CDA6F creation):

"calls": [ 
  { 
    "from": "0xadd8e3947a934467afd9a6588e2c19ac89c1e15a", 
    "gas": "0x3e3f61", 
    "gasUsed": "0x39f30c", 
    "to": "0x7c6118ba719a62d40ce6c9580f96306a558cda6f", 
    "input": "0x61010060...", 
    "output": "0x60806040...", 
    "calls": [{ ... }], 
    "value": "0x0", 
    "type": "CREATE" 
  } 
]

We are trying to figure out how it was created and when (technically, with trace logs etc). I have some few steps to check now in BS DB, but it seems that I could trigger block re-fetch UPDATE blocks SET consensus=false WHERE number=1573308;

[surreal owl]

@south hornet Fixed. We'll update BS backend and frotend to the latest upstream version next week. It seems that was an indexer issue... but BS don't know the exact reason - I can't find any error logs or root case of this missing Creator at 😦

[south hornet]

Great, all good then

[olive orbit]

@south hornet I have a PR open on erc725-inspect, so that you can decode and view the metadat of any assets
0.15.0 or older
https://github.com/lukso-network/tools-erc725-inspect/pull/103

[olive orbit]

@sturdy crest was this fixed?

Metadata looks good

@sharp scroll I think I have found the issue for DeBulls CC image not showing in the wallet: contract 0x8f7aecB612808703718aA76fB4752f930AB3487e

If you compare the LSP4 Metadata of Universal.Page for instance (first screenshot) and yours (second screenshot), you JSON file only has the icon field, but no fields like image or backgroundImage.
The wallet shows the image. So you might want to include these properties as well 🙂