# Claim Locked Funds

### <mark style="color:orange;">EVM-Compatible Networks</mark>

#### Permissionless Token Refund

```solidity
function claim(bytes32 tradeId, TradeDetail calldata detail) external;
```

🔐 Permissionless Execution

* Callable by anyone. Funds are always transferred to the `refundAddress`, ensuring there is no risk of unauthorized access or fund diversion.
* Allows third parties (e.g., bots or monitoring services) to trigger refunds on behalf of users.

🔎 Trade Validation

* Can only be executed after the specified timeout (`block.timestamp > detail.timeout`) has passed.
* Verifies that the provided `TradeDetail` matches the recorded hash for the given `tradeId`.
* Prevents unauthorized or malicious claim attempts by enforcing input authenticity.

🛡️ Replay Protection

* Deletes the stored hash for the `tradeId` before transferring funds.
* Protects against replay attacks and reentrancy exploits.

💸 Fund Transfer

* Transfers the locked funds to the `refundAddress` specified in the original trade.
* The method of transfer depends on the Vault type (either native coin or ERC-20 token).

📢 Event Emission

* Emits a `Claimed` event upon successful execution.

## [<mark style="color:orange;">Bitcoin Network</mark>](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault.md)

#### Permissionless Token Refund <a href="#toc_4" id="toc_4"></a>

```bitcoin
// User-controlled withdrawal after timelock
<TimelockBlocks> OP_CHECKSEQUENCEVERIFY OP_DROP <UserPK> OP_CHECKSIG

// Multi-sig spending path (before timeout)  
<SettlementCommitteePK> OP_CHECKSIG <UserPK> OP_CHECKSIGADD OP_2 OP_NUMEQUAL
```

**🔐 Permissionless Execution** \* Callable by the user after 144 blocks (\~24 hours). Funds are always transferred to the user's specified address, ensuring no risk of unauthorized access or fund diversion. \* Allows third parties (e.g., bots or monitoring services) to trigger refunds on behalf of users after timeout expiration.

**🔎 Trade Validation**&#x20;

* Can only be executed after the specified timeout (144 Bitcoin blocks ≈ 24 hours) has passed using `OP_CHECKSEQUENCEVERIFY`.&#x20;
* &#x20;Script validates that the timeout condition is met before allowing fund withdrawal.&#x20;
* Prevents unauthorized or malicious claim attempts by enforcing Bitcoin's consensus-level timelock mechanism.

**🛡️ Replay Protection**&#x20;

* Bitcoin's UTXO model inherently prevents replay attacks - once a UTXO is spent, it cannot be spent again.&#x20;
* Each vault creates a unique P2TR address with specific script conditions that can only be executed once.

**💸 Fund Transfer**&#x20;

* Transfers the locked Bitcoin to the user's specified refund address via native Bitcoin transactions.&#x20;
* The method depends on which script path is executed (timelock for user claims, multisig for trade settlements).

**📡 Transaction Confirmation**&#x20;

* Bitcoin transaction is broadcast to the network and confirmed through the standard Bitcoin mining process.&#x20;
* Transaction details are permanently recorded on the Bitcoin blockchain for full transparency.

***

**For complete technical specifications and implementation details, refer to the** [**Bitcoin Vault Script documentation**](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault.md)**.**

### <mark style="color:orange;">Solana Network</mark>

#### Permissionless Token Refund

```rust
pub struct ClaimArgs {
    /// The tradeId, unique identifier for the trade.
    pub trade_id: [u8; 32],
}
pub fn handler_claim<'c: 'info, 'info>(
    ctx: Context<'_, '_, 'c, 'info, Claim<'info>>,
    claim_args: ClaimArgs,
) -> Result<()>
```

🔐 Permissionless Execution

* Callable by anyone. Funds are always transferred to the `refund_pubkey`, ensuring there is no risk of unauthorized access or fund diversion.
* Allows third parties (e.g., bots or monitoring services) to trigger refunds on behalf of users.

🔎 Trade Validation

* Can only be executed after the specified timeout (Clock()::get.unix\_timestamp`> trade_detail.timeout`) has passed.
* Can only be executed for the `TradeDatail` in the `Deposited` state.
* Verifies that the provided `TradeDetail` matches the recorded hash for the given `tradeId`.
* Prevents unauthorized or malicious claim attempts by enforcing input authenticity.

🛡️ Replay Protection

* Update the status of corresponding TradeDetail account from `Deposited`  to `Claimed`
* Transfer the asset stored in the corresponding vault and ONLY that vault to `refund_pubkey`&#x20;

💸 Fund Transfer

* Transfers the locked funds to the `refund_pubkey` specified in the original trade.
* The method of transfer depends on the Vault type (either native coin or SPL token).


---

# 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/asset-chain/claim-locked-funds.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.