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.
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.
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:
edit 2- of course i just re-read the thread and saw sort.xyz is using Dune in the back end …
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