I’m attempting to create a resolver for dynamic address lookup. My users (dApps and contracts) know to refresh the address frequently and not to save long lasting sessions. So I have good confidence that my client code will not cache addresses for too long - However, there is a requirement to emit AddrChanged events (EIPs/eip-137.md at master · ethereum/EIPs · GitHub) which I cannot easily meet. The contracts which determine the actual addresses do not have hooks whereby I can notify my resolver of these changes when they happen. So the resolver is not easily notified of the change.
If I want to satisfy this requirement to emit AddrChanged events I would have to monitor the network constantly and send transactions to my resolver contract whenever the mappings change. which is expensive. I’d like to avoid that.
I suppose this could be a problem for indexing services which rely on these events (thegraph?) however, Since I’m using the default TTL (0), I was hoping it might be ok. I need advice on this.
- If I cannot emit AddrChanged events, what else might break?
- Are there other commonly used resolvers which violate this requirement? Is it otherwise common to avoid emitting AddrChanged or practical?
- should I set TTL to some positive small number (e.g. 10) to signal indexing services they should not rely on cached values? Or is 0 actually “never cache” rather than “always cache”?
Thanks in advance!