The Rosetta layer is not yet generating the synthetic unlock operations for the block associated with pox_v1_unlock_height. This one is tricky, because for each account, I need to infer which of the pox events are from pox-v1 vs pox-v2. Right now it requires first querying state from the existing stx_lock_event set, but that contains events from both pox-v1 and pox-v2, so the pox-v2 events need to be excluded by querying the new pox2_print_event set.
...
For only the single block associated with v1_unlock_height, determine all accounts that would still be locked from pox-v1 and generate a synthetic unlocks. This seems to require querying the stx_lock_event set, then inferring which entries are from pox-v1 by then excluding results that also exist in the new pox2_print_event set?
...
This could be made easier if there was a change to the stx_lock_event payload so that it included a property indicating if it was from pox-v1 vs pox-v2.
Originally posted by @zone117x in https://github.com/stacks-network/stacks-blockchain/issues/3318#issuecomment-1322097463
The Rosetta layer is not yet generating the synthetic unlock operations for the block associated with
pox_v1_unlock_height
. This one is tricky, because for each account, I need to infer which of the pox events are from pox-v1 vs pox-v2. Right now it requires first querying state from the existingstx_lock_event
set, but that contains events from both pox-v1 and pox-v2, so the pox-v2 events need to be excluded by querying the newpox2_print_event
set....
For only the single block associated with
v1_unlock_height
, determine all accounts that would still be locked from pox-v1 and generate a synthetic unlocks. This seems to require querying thestx_lock_event
set, then inferring which entries are from pox-v1 by then excluding results that also exist in the newpox2_print_event
set?...
This could be made easier if there was a change to the
stx_lock_event
payload so that it included a property indicating if it was from pox-v1 vs pox-v2.