Identify Incentive in Events where incentive matters about v3-staker

[omarish]

Hmm good question. So specifically we're talking about:

TokenStaked, TokenUnstaked, and ClaimRewardFromCurrentStake (if we end up going that way).

I agree that we should be doing at least one of these two so that it's possible to re-create history from events. If we do bytes32, we'll still need to also include tokenId as a separate param since it doesn't get encoded into the id.

It sounds like the decision is:

a) event TokenStaked(address rewardToken, address pool, uint32 startTime, uint32 endTime, uint32 claimDeadline, uint128 totalReward, uint256 tokenId) or
b) event TokenStaked(bytes32 incentiveId, uint256 tokenId)

I think this would also apply for TokenUnstaked and ClaimRewardFromCurrentStake. And of course some of these would be indexed.

Some considerations:

1. space/gas efficiency
2. user experience: @nickblt I saw you're working on a tool that would plug in to this. Do you have a preference? And is there a standard way other staking contracts do this?

[nickblt]

Catching up on things, this is obviously already closed but since I was pinged...

As the code stands we will be going with using bytes32 incentiveId With that, for me, as long as all the delete incentives[key]; match up with emit IncentiveEnded events; we don't seem to be losing anything to history and any recreation can occur. LGTM