Function: redeemDeposit(uint32 _depositNonce, address _recipient)

The function allows for the redemption of a deposit. To facilitate this, several conditions must be met: the deposit corresponding to the _depositNonce must exist, the caller must be the owner of the deposit, and the retrieveDeposit function must be executed. This function must then be delivered to the Root chain, successfully executed there, and a response sent back to this chain to change the deposit's status to STATUS_FAILED. After successfully transferring tokens to the _recipient, the deposit object will be deleted to prevent the possibility of redeeming the same deposit twice.

Inputs

• _depositNonce

  • Control: The caller controls the _depositNonce.

  • Constraints: The caller must be the owner of the deposit object related to this _depositNonce.

  • Impact: Determines which deposit object is being accessed for redemption.

• _recipient

  • Control: Full control.

  • Constraints: N/A.

  • Impact: The address of the receiver of the deposited tokens.

Branches and code coverage

Intended branches

• Check that the deposit was deleted after redeeming.

  Test coverage

Negative behavior

• Double redeem is not possible.

  Negative test

Function call analysis

• this._clearToken(_recipient, deposit.hTokens[i], deposit.tokens[i], deposit.amounts[i], deposit.deposits[i]) -> IBranchPort(this.localPortAddress).bridgeIn(_recipient, _hToken, _amount - _deposit)

  • What is controllable? The _recipient is under the caller's control, while the rest of the data is sourced from an existing deposit owned by the caller.

  • If the return value is controllable, how is it used and how can it go wrong? There is no return value.

  • What happens if it reverts, reenters or does other unusual control flow? The function will revert if the BranchPort fails to mint _hToken tokens.

• this._clearToken(_recipient, deposit.hTokens[i], deposit.tokens[i], deposit.amounts[i], deposit.deposits[i]) -> IBranchPort(this.localPortAddress).withdraw(_recipient, _token, _deposit)

  • What is controllable? The _recipient is under the caller's control, while the rest of the data is sourced from an existing deposit owned by the caller.

  • If the return value is controllable, how is it used and how can it go wrong? There is no return value.

  • What happens if it reverts, reenters or does other unusual control flow? The function will revert if the BranchPort does not have a sufficient amount of the underlying _token.