It is due to the different contract / internal transactions, and hard to decode the transactions because itās an unverified contract.
I think we might have to switch to indexing by contract events rather than transactions, since internal transactions do emit events on the official ENS registrar. But these events donāt include the secret, so weāll ultimately still have to get it from the transaction itself. I can think of a hacky way to do this just for ens.vision, but ideally we donāt have to handle each contract individually.
Iām talking to the sort.xyz team to see if they have ideas, or I can probably build a custom indexer and include it in the same open source repo.
4 Likes
No, the same approach would not work for setting text records (including avatar) because thereās no secret parameter, which is what weāre using to track registrations. The only reason the secret exists in registrations is to prevent front-running, which isnāt a problem with text records.
2 Likes
Hey everyone. We will release another bulkreg in the near future (will consider verifying it) so now is the time we can add some kind of āstandardizedā event if you guys think that is the way.
But that seems also like a lot of overhead to manage / know all contracts which act as registers on your end?
I can also share the existing ABI for you to decode our transaction if that helps. Iāve already added the ABI to dune long ago for example and the Secrets can be viewed with this data:
āensbulkreg_v5_ethereum.ENSVisionBulkv4_call_visionRegisterā
edit 2- of course i just re-read the thread and saw sort.xyz is using Dune in the back end ā¦ 
2 Likes
was thinking a little more and the Event might not even work for my next version ā¦ as im not passing individual params to my function in the new version per register callā¦ but instead its acting like a traditional multicaller working with a bytes[] ā¦ could just emit the whole bytes string and you decode that to get Register paramsā¦ but 
hmmm Iāll reach out in twitter dms to brainstorm this more