Reverse registrar not working on ENS Grants page; wrong address shown

I noticed that only a few of the applicants for ENS Small Grants have ENS names showing instead of hex addresses:

This seemed odd, until I tried to submit one and it happened to me too. For keeping an example consistent, clicking on the address for the third of those submissions shows this:

Note that hovering over the address shows it ends with a ‘9a’ after the end of what’s shown. Maybe there’s some issue with strings getting cut short due to failure to account for the ‘0x’ two characters at the beginning, and the reverse lookup works for folks who figured out how to submit their address without the leading 0x?

In the app, it certainly looks like the reverse registrar is correctly set up correctly for my address (no recent changes):

but maybe the ENS Small Grants system only recognizes and displays names if a .eth is used as the primary reverse record, even if other .eth names are associated with the address? This seems like a bug.

It’s also a bug that could make a signficant difference in affecting voting outcomes. One might reasonably give greater weight to proposals with an ENS name instead of just a hex address; using advanced features like DNS connection should be more of a plus than a minus in that aspect (or at least the .eth name already associated with the address could be shown). Therefore, there’s some value in fixing this before voting begins if possible.

1 Like

Maybe it was just a temporary issue? Looks fine to me:


1 Like

Hmm, odd that it’s viewer-dependent. I’m still seeing most of the addresses show up as hex, using Google Chrome, though I’ve just noticed that if I view the same URL in Firefox, my name and avatar show up there. Clicking the profile link also shows the name (in Firefox) instead of the address (as in Chrome) though neither browser shows the avatar on the profile page (just that blue-gradient circle).

In Chrome where these are present, I also tried disconnecting the MetaMask account, disabling MetaMask altogether, and opening devTools with “disable cache” checked (each followed by reload) but none of those steps addressed the issue (individually or in combination).


This seems to replicate for me. It’s being looked into.

Voting is five days away, which should be adequate time to resolve this.


Just pinging in to follow up; it looks like this did not get fixed.

Sorry about that. I updated something yesterday that I expected to solve this, but seems like it did not. My bad. I’ll be refactoring things tonight to take care of this. Thanks for following up!