Conversation
nintynick
left a comment
There was a problem hiding this comment.
LGTM. some highlights from our discussion of this:
Why not emit eligible as part of the event?
the source of truth for eligibility is not transaction records, its the eligibility contract itself. so data indexed from events is not going to be the source of truth, and apps are going to have to read directly from the contract to check whether a wearer is eligible. but since we explicitly store badStandings, and storage can only change as a result of a tx, data indexed based on an event can be the source of truth
we take the other approach for wearing, which is based on both eligibility and hat status. But that’s because the 1155 standard forces us to emit events when hats are minted/transfered. Apps will need to confirm hat wearer status by reading from the contract, even if the subgraph tells them an address is wearing a hat.
if they don't, they could show out-of-date information about whether an account is eligible for or wearing a given hat. token gates will always explicitly check the contract, so no issues there. but more informational / visualization front ends will need to use a mix of subgraph and explicit on-chain reads
dev documentation will definitely be important here. When we build an SDK we can have the SDK handle that more seamlessly, too
This PR adds a
WearerStandingChangedevent emitted any time a wearer's standing for a given hat is changed.It also adds a check within
_processHatWearerStatusto ensure that burning a non-existent hat is not attempted. This is important because its possible for botheligibleandstandingvalues to change for a given wearer even if they are not actually wearing the hat in question.