Benjamin Samuels

i was able to repro this with another program with a similar configuration with a latency delay of 0s

I'm looking for the opposite though; I think it will make more sense if I describe a naive implementation of the feature; ``` Add new opcode "MUSTCOVER". This opcode is...

im 99% sure this was fixed by https://github.com/yearn/yearn-vaults-v2-subgraph/pull/119/files currently unable to repro on main. when the subgraph version is incremented, need to retest to validate the fix

looks like this was implemented: https://github.com/yearn/yearn-vaults-v2-subgraph/blob/main/src/mappings/registryMappings.ts#L13-L45 Is that what you had in mind @salazarguille?

I'm fairly certain this bug is caused by the following logic that's used to calculate the burnt share amount; https://github.com/yearn/yearn-vaults-v2-subgraph/blob/main/src/mappings/vaultMappings.ts#L360-L362 The total shares burnt are not exposed through the event...

@0xbok https://github.com/yearn/yearn-vaults-v2-subgraph/blob/main/schema.graphql#L509-L510

@salazarguille how about we clone yearn-exporter's apy calcs? https://github.com/yearn/yearn-exporter/blob/master/yearn/apy/v2.py#L114-L199 I'm working on a branch that should bring a lot of the subgraph's data fields in line with what yearn-exporter provides,...

I think this issue is fixed on main