# Depositing Funds

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

#### Native Coin Deposit

```solidity
function deposit(address ephemeralL2Address, TradeInput calldata input, TradeDetail calldata data) external payable;
```

🔐 Permissionless Execution

* Callable by any user initiating a native coin trade.
* Requires `msg.value` to match the expected deposit amount.

🔎 Trade Validation

* Ensures the caller matches the expected sender in `TradeInput`.
* Checks whether the `tradeId` derived from the input has already been used.
* Prevents replay attacks or duplicate trade submissions.

🔁 Trade State Transition

* Records the hash of `TradeDetail` for future verification and process continuity.

📢 Event Emission

* Emits a `Deposited` event with metadata required for off-chain monitoring and processing.

#### ERC-20 Token Deposit

```solidity
function deposit(address ephemeralL2Address, TradeInput calldata input, TradeDetail calldata data) external;
```

🔐 Permissionless Execution

* Callable by any user initiating an ERC-20 token trade.

🔎 Trade Validation

* Ensures the deposited token matches the configured `LOCKING_TOKEN`.
* Ensures the caller matches the expected sender in `TradeInput`.
* Checks whether the `tradeId` derived from the input has already been used.
* Prevents replay or re-submission of the same trade.

💸 Token Transfer

* Uses `safeTransferFrom` to securely transfer tokens into the Vault contract.
* The caller must approve the Vault to spend tokens prior to calling.

🔁 Trade State Transition

* Records the hash of `TradeDetail` for future verification and process continuity.

📢 Event Emission

* Emits a `Deposited` event with metadata required for off-chain monitoring and processing.

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

Unlike EVM and Solana networks which use smart contracts, Bitcoin utilizes the **Native Bitcoin Vault**—a non-custodial escrow built with Bitcoin's native scripting.

Users deposit BTC into a P2TR (Pay-to-Taproot) address controlled by a 2-of-2 multisig between the user and the Settlement Committee. Trades are settled when both parties sign, or users can reclaim funds after timelock expiry using only their own key.

For technical details on vault construction, spending paths, and security model, see [Native Bitcoin Vault.](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault.md)

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

#### Native SOL and SPL-token deposit

Unlike EVM networks, we use a single function for depositing both native SOL and SPL tokens. The distinction between them is made using arguments and the list of accounts.

```rust
pub struct TradeInput {
    /// The sessionId, unique identifier for the trade.
    pub session_id: [u8; 32],  
    /// The solver address, the address of the solver.
    pub solver: [u8; 20],      
    /// The trade information, contains the information about the origin and destination of the trade.
    pub trade_info: TradeInfo, 
}

pub struct TradeDetailInput {
    pub timeout: i64,
    pub mpc_pubkey: Pubkey,
    pub refund_pubkey: Pubkey,
}
pub struct DepositArgs {
    /// Input trade information.
    pub input: TradeInput,
    /// Detailed trade data.
    pub data: TradeDetailInput,
    /// The tradeId, unique identifier for the trade.
    pub trade_id: [u8; 32],
}
pub fn handler_deposit<'c: 'info, 'info>(
    ctx: Context<'_, '_, 'c, 'info, DepositAccounts<'info>>,
    deposit_args: DepositArgs,
) -> Result<()>
```

🔐 Permissionless Execution

* Callable by any user initiating a trade.

🔎 Trade Validation

* Ensures that the `ephemeral_account` is not associated with any active trades.
* Ensures signer matches the expected spender in `TradeInput` .
* Ensures the asset matches the expected value in the TradeInput. For native SOL, the asset is marked as native; otherwise, it is the public key of the SPL token.
* Ensures the deposited amount is at least equal to the whitelisted minimum set by the operators.
* Checks whether the `tradeId` derived from the input has already been used.
* Check whether the asset was whitelisted by the operators beforehand.
* Prevents replay attacks or duplicate trade submissions.
* Ensures the deposited vault address matches the expected vault PDA uniquely derived for the trade.

💸 Token Transfer

* Use `spl_token::transfer_checked` instruction to securely transfer SPL-token with the correct accounts.
* Use `system_program::transfer` instruction to transfer native SOL with the correct accounts.

🔁 Trade State Transition

* Creates a `TradeDetail PDA` account to store trade information for future verification and process continuity, state of the `TradeDetail` will be `Deposited`&#x20;


---

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