Stage: Confirm Settlement & Failure Handling

Following a confirmed payment through confirmPayment(), the trade moves to the CONFIRM_SETTLEMENT phase. In this stage, the MPC is tasked with settling the trade by releasing funds to the designated PMM on the source chain. Upon executing the release transaction, the MPC calls confirmSettlement(), submits the releaseTxId, and transitions the trade to the COMPLETED stage.

If issues arise, such as network failures, and if the user has claimed a refund, the MPC must call the report() function, marking the trade as FAILURE and stopping further progress. Here are the core responsibilities of the MPC at this stage:

• Release Funds: Initiates settlement by sending funds to the PMM.

• Confirm Settlement: Calls confirmSettlement().

• Report Failures: Uses report() to log a failure if necessary.

⚠️ Important: Reporting a failure means the MPC is held accountable for compensating the PMM’s loss.

Possible Scenarios

✅ Successful Settlement

• MPC releases funds to the PMM.

• Confirms settlement with confirmSettlement(), using releaseTxId.

• Trade reaches the COMPLETED stage.

• SettlementConfirmed event logs the final transaction.

• Trade is final and unmodifiable.

❌ Settlement Failure

• If incapable of settling, possibly due to a network issue, and a refund is claimed, MPC reports via report().

• Trade is marked FAILURE.

• FailureReported event is logged for transparency.

• Audit records detail the failed transaction.

Functions

On Successful Settlement: confirmSettlement()

function confirmSettlement(bytes32 tradeId, bytes calldata releaseTxId, bytes calldata signature) external;

• Permissioned Execution: Only through the Router contract by an authorized MPC Node.

• Stage Validation: Trade must be in CONFIRM_SETTLEMENT.

• Signature Validation: Ensures signer validity using EIP-712.

• State Transition: Updates trade to COMPLETED, records releaseTxId.

• Event Emission: Emits SettlementConfirmed.

On Unexpected Incidents: report()

function report(bytes32 tradeId, bytes calldata msgError, bytes calldata signature) external;

• Permissioned Execution: Via Router, authorized MPC Node.

• Constraints: Trade must not be final (not COMPLETED, FAILURE, or REFUNDED).

• Reasons for Failure:

  • Chain-level or MPC issues.

  • User refund claimed.

• Signature Verification: Uses EIP-712 for authenticity.

• State Transition: Logs failure reason, marks trade as FAILURE.

• Event Emission: Emits FailureReported.

Queryable Trade Data

After settlement, regardless if the trade is COMPLETED or FAILURE, public view functions are available:

On Successful Settlement

• Get Trade Stage:

  function getCurrentStage(bytes32 tradeId) external view returns (uint256);

• Get Trade Finalization:

  function getTradeFinalization(bytes32 tradeId) external view returns (TradeFinalization memory);

On Unexpected Incidents

• Get Trade Stage:

  function getCurrentStage(bytes32 tradeId) external view returns (uint256);

• Get Failure Details:

  function getFailureInfo(bytes32 tradeId) external view returns (FailureDetails memory);