Stage: Refund

After a trade is marked as FAILURE and the scriptTimeout is expired, the final step is for the MPC to refund the locked funds to the user. Once the refund transaction is executed, the MPC finalizes the process by calling the refund() function, submitting the refundTxId to log the transaction on-chain and transition the trade to the REFUNDED stage.

If the user has already claimed the refund through an external mechanism, the MPC is responsible for detecting this and submitting the related transaction ID. Key responsibilities of the MPC during this phase include:

• Executing the refund transaction to return funds to the user.

• Confirming the refund on-chain via refund().

• Detecting and reporting externally claimed refunds by submitting the related transaction ID.

⚠️ Important: The refund() function finalizes a failed trade, ensuring proper refund distribution and syncing off-chain data with on-chain state.

Possible Scenarios

Scenario 1: Refund Execution After Failure

• Trade marked as FAILURE and scriptTimeout has elapsed.

• MPC initiates the refund transaction to return funds to the user.

• Upon success, MPC calls refund(), providing refundTxId.

• Trade advances to REFUNDED stage, emitting a Refunded event for record-keeping.

Scenario 2: Refund Already Claimed by User

• Trade in FAILURE stage and timed out.

• User independently claims the refund.

• MPC detects the refund and calls refund() with refundTxId.

• Trade is finalized as REFUNDED, emitting a Refunded event for logging.

Successful Refund Process

• refund() Function:

  • Signature: refund(bytes32 tradeId, bytes calldata refundTxId, bytes calldata signature) external;

  • Permissioned execution through the Router contract by authorized MPC Node.

• Trade Stage Validation:

  • Ensures trade is in FAILURE stage.

  • scriptTimeout must have passed.

• Signature Verification:

  • Utilizes EIP-712 signing to ensure data integrity.

  • Confirms the signer is an MPC signer for the source chain.

• Trade State Transition:

  • Updates trade stage to REFUNDED.

  • Records refundTxId in finalization metadata.

  • Removes trade from pending list.

• Event Emission:

  • Emits a Refunded event indicating trade refund and finalization.

Queryable Trade Data

After fulfilling a refund, several public view functions are available to query related data and track trade progress, essential for frontend rendering, auditability, and off-chain monitoring.

• Get Current Stage:

  • Function: getCurrentStage(bytes32 tradeId) external view returns (uint256);

  • Returns the current trade stage (e.g., REFUNDED).

• Get Trade Finalization:

  • Function: getTradeFinalization(bytes32 tradeId) external view returns (TradeFinalization memory);

  • Provides finalization details, including refundTxId, for future audits.