# 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.

### <mark style="color:orange;">Possible Scenarios</mark>

#### 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.

### <mark style="color:orange;">Queryable Trade Data</mark>

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.optimex.com/optimex-revolutionizing-bitcoin-finance/optimex-swap/optimex-swap-how-it-work/trade-life-cycle/optimex-l2-network/stage-refund.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.