As discussed with @cde8 the timelock sync between chains occurs at the blockheight level, not the timestamp level.
Currently the atomic_bridge.move(counterparty) module uses timestamp, whereas the eth (initiator) uses blockheight. This was merged optimistically as an issue to fix later.
I initially tried to use blockheight in the tests but this broke the tests wouldn't run withe compiler reporting some errors within aptos-framework code. Now that we have the upstream sync, this issue may be resolved.
Update the atomic_bridge.move to use blockheight as its timelock val.
Submit the PR to the feature branch eng-546-atomic-bridge
No tests need to be added, but the current move tests should still pass.
As discussed with @cde8 the timelock sync between chains occurs at the blockheight level, not the timestamp level.
Currently the
atomic_bridge.move
(counterparty) module uses timestamp, whereas the eth (initiator) uses blockheight. This was merged optimistically as an issue to fix later.You can see us setting the timestamp in motion here https://github.com/movementlabsxyz/movement/pull/205/files#diff-a56b20379dbef0e9742fd9a9e7fe5512e645e339176a27bbbe4774bfa0aabe5a
I initially tried to use blockheight in the tests but this broke the tests wouldn't run withe compiler reporting some errors within
aptos-framework
code. Now that we have the upstream sync, this issue may be resolved.atomic_bridge.move
to use blockheight as its timelock val.eng-546-atomic-bridge