Bug: The unstake txn does not respect the cooldown period and credits the owner before the cooldown has passed.
Currently, there is no real way to specify a "delay" in an operation as reconciliations happen. In blockchain-node, a "callback" is triggered to update the ledger at the specified cooldown height, so there is no on-chain representation of the ledger change at that height.
For the purposes of check:data, the operation needs to be "processed" at the cooldown height in order for reconciliation to succeed. My best guess for a solution is to have a rosetta-side db that stores "unstake" cooldowns and each block request will poll the db to see if there is an "unstake" cooldown at that block and apply the operation in a "ghost" transaction that supplies the required op to calculate the balance change.
Bug: The unstake txn does not respect the cooldown period and credits the owner before the cooldown has passed.
Currently, there is no real way to specify a "delay" in an operation as reconciliations happen. In blockchain-node, a "callback" is triggered to update the ledger at the specified cooldown height, so there is no on-chain representation of the ledger change at that height.
For the purposes of
check:data, the operation needs to be "processed" at the cooldown height in order for reconciliation to succeed. My best guess for a solution is to have a rosetta-side db that stores "unstake" cooldowns and each block request will poll the db to see if there is an "unstake" cooldown at that block and apply the operation in a "ghost" transaction that supplies the required op to calculate the balance change.Open to other suggestions