I think there is some discrepancy between the behavior of the code, the documentation of the code, and the documentation of the spec re: verification of contract status/updates on Tezos. (e.g. verify that the contract was originated correctly, verify that the contract was funded correctly).
The actual behavior of the code is that it looks at the current state of the contract and fails if the status is not what is expected.
I think some of the documentation refers to an outdated plan in which the API would check the state of the contract at intervals until either the status is met or a timeout elapses. This was meant to be an approximation of the notification service (in which the verifying party would receive a notification when the updated occurs) and was abandoned because of deadline pressure (the current implementation was much easier).
See also: #250 could be mitigated by adding waiting behavior.
I think there is some discrepancy between the behavior of the code, the documentation of the code, and the documentation of the spec re: verification of contract status/updates on Tezos. (e.g. verify that the contract was originated correctly, verify that the contract was funded correctly).
The actual behavior of the code is that it looks at the current state of the contract and fails if the status is not what is expected.
I think some of the documentation refers to an outdated plan in which the API would check the state of the contract at intervals until either the status is met or a timeout elapses. This was meant to be an approximation of the notification service (in which the verifying party would receive a notification when the updated occurs) and was abandoned because of deadline pressure (the current implementation was much easier).
See also: #250 could be mitigated by adding waiting behavior.