EIP-7531 Resolving Staked ERC-721 Ownership Recognition

I see.

Imo, you shouldn’t target the existing pools with this, or at least it shouldn’t be a concern for the event:
Pools that would take the time to update to implement this can easily also add a function that allows users to emit all the events for all their already staked items (and offer an “upgrade” button on their interface for users to call this function)

I’ll again come with the “Indexer POV”, but as an indexer, when I index and I do introspection, I cache the results in my DB. So the first time I see a pool I will introspect for the different interfaces I’m looking for, but not later. So I would miss this EIP if it was only added after the first time I encountered the contract.

1 Like

I didn’t think about this. It makes sense. If I want to take advantage of it, I call the function and pay the gas to emit the event. Still, the pool could emit the reverse event when the assets are unstaked.

@dievardump

I added an event in the interface after studying the problem to avoid unwanted effects (for example, fake events emitted by fraudulent contracts). Here is the updated doc in the pull request:

What do you think?

I like the addition of the event. Also great thinking on the timing.

What do you think of replacing mentions of “staked” to “held”. I think held is more broad, and in the use case I will use it for NFTs are not really staked. You are already using “hold” for the event and method so it seems appropriate.

1 Like

Good point, thanks.
I updated the EIP, leaving staked only where it was specifically talking about staking pools.

Bit of bikeshedding, but I’d recommend something like RightsHolderChange instead of HolderOfRightsFor for the event, to match the naming convention of other events in ERC-20.

1 Like

Good point.
Consistently, the function would sound better as rightsHolderOf instead of holderOfRightsFor.
I made a change in the PR at