Stage: Confirm Deposit & Failure Handling

📝 Overview This phase occurs after a trade has been submitted and the user has deposited funds into a designated Vault on the source asset-chain. At this point, the MPC (Multi-Party Computation) nodes are responsible for validating the trade's legitimacy before allowing it to proceed.

Key responsibilities of the MPC during this phase:

  • Verifying the deposited amount and source addresses match the submitted trade data.

  • Validating pre-signatures (presigns) for both settlement and refund paths.

  • Ensuring all trade-related data and signatures are consistent and untampered.

Possible Scenarios

✅ Successful Deposit Match: If the MPC confirms that the deposited amount and sources match expectations, it calls confirmDeposit, advancing the trade to the SELECT_PMM stage.

❌ Failure or Timeout:

  • If a mismatch occurs (e.g., incorrect amount or unverified sources), the MPC can mark the trade as Failure.

  • Trades marked as Failure are permanently halted and will not proceed to settlement or payout.

  • After a grace period (scriptTimeout), the MPC finalizes the trade and triggers an automatic refund of the user’s deposited funds.

✅ Valid Deposit: confirmDeposit()

function confirmDeposit(bytes32 tradeId, bytes memory signature, bytes[] memory depositFromList) external;

🔐 Permissioned Execution

  • Can only be called through the Router contract.

  • The requester must be an authorized MPC Node.

🔎 Trade Stage Validation

  • Ensures the trade is currently at the CONFIRM_DEPOSIT stage.

  • Prevents re-submission or out-of-order execution

🔑 Signature Verification

  • Uses EIP-712 signing with a domain separator to ensure data integrity.

  • Validates that the signer is an MPC signer for the specified source chain.

🔁 Trade State Transition

  • Upon successful validation, the trade progresses to the SELECT_PMM stage.

  • The validated depositFromList is persisted on-chain for audit and traceability.

📢 Event Emission

  • Emits DepositConfirmed event which signals that the trade can now proceed to the next step - SELECT_PMM.

‼️ MPC Validation Logic

  • Verifies that the deposited amount and fromChain match the expected amountIn.

  • Confirms the list of sender addresses (depositFromList) who actually funded the Vault.

  • Validates all deposit-related encoded data within scriptInfo.

  • Verifies the pre-signatures for both settlement and refund, ensuring they are cryptographically valid and usable later.

  • Any inconsistency in the data (amounts, addresses, scripts, signatures) may later be marked as a failure via report.

    ⚠️ Any mismatch, inconsistency, or tampering can later be reported and halted using report().

❌ Invalid Deposit or Error: report()

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

📝 Note If the MPC detects invalid or unexpected data during the CONFIRM_DEPOSIT stage (e.g., incorrect amounts, invalid presigns, or malformed scripts), it can halt the trade permanently by reporting the failure.

🔐 Permissioned Execution

  • Can only be called through the Router contract.

  • The requester must be an authorized MPC Node.

🔎 Constraints & Behavior

  • The trade must not already be finalized (COMPLETED, FAILURE, or REFUNDED).

  • This is the stage where reporting does not require a timeout delay (scriptTimeout).

⚠️ Valid Reasons to Report Failure

  • Mismatch between amountIn and actual deposit.

  • Invalid pre-signatures for settlement/refund.

  • Unexpected, malformed, or tampered data in scriptInfo (e.g. timeout).

🔑 Signature Verification

  • The failure message is signed using EIP-712 format to ensure authenticity.

  • The signer must be a valid MPC signer for the relevant source chain.

🔁 Trade State Transition

  • Stores failure details, including msgError and the failed stage (CONFIRM_DEPOSIT).

  • The trade is immediately marked as FAILURE, halting any further progression.

🧾 Refund Behavior

  • Once the scriptTimeout elapses, the user’s funds are eligible for automatic refund.

📢 Event Emission

  • Emits a FailureReported event, including failed stage, error reference, which enables public inspection and monitoring of failed trades.

Queryable Trade Data

📝 Note After the deposit confirmation phase—whether the trade advances to SELECT_PMM or transitions to FAILURE—several public view functions become available to query validated deposit information and track trade progress. These are essential for frontend rendering, auditability, and off-chain monitoring.

✅ On Successful Deposit Confirmation

🔍 Get Trade Stage

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

Returns the current stage of the trade (e.g., SELECT_PMM).

🔍 Get deposit address list

function getDepositAddressList(bytes32 tradeId) external view returns (bytes[] memory);

Returns an array of addresses confirmed to have deposited funds into the Vault.

❌ On Invalid Deposit or Timeout

🔍 Get Trade Stage

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

Returns the current stage of the trade (e.g., FAILURE).

🔍 Get failure details

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

Returns the error metadata associated with the failed trade, including the stage and reason for failure.

PreviousStage: Trade InitializationNextStage: PMM Selection & Failure Handling