> ## Documentation Index
> Fetch the complete documentation index at: https://v1-docs.zcombinator.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Confirm Deposit Transaction

> POST /damm/deposit/confirm - Submit signed deposit transaction to the blockchain

## Overview

Confirms and submits a signed liquidity deposit transaction to the Solana blockchain. This endpoint validates the transaction structure comprehensively, verifies the transaction hasn't been tampered with, and broadcasts it to the network. The transaction transfers tokens from the manager wallet and adds liquidity to a Meteora DAMM v2 pool.

<Warning>
  **Enhanced security**: This endpoint validates that the transaction hasn't been modified after creation, preventing tampering attacks.
</Warning>

<CodeGroup>
  ```bash curl theme={null}
  curl -X POST https://api.zcombinator.io/damm/deposit/confirm \
    -H "Content-Type: application/json" \
    -d '{
      "signedTransaction": "4MzR7dxJNJRVP1Q6k7Y3j8X...",
      "requestId": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
    }'
  ```

  ```javascript fetch theme={null}
  const response = await fetch('https://api.zcombinator.io/damm/deposit/confirm', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      signedTransaction: "4MzR7dxJNJRVP1Q6k7Y3j8X...",
      requestId: "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
    })
  });

  const result = await response.json();
  ```

  ```python requests theme={null}
  import requests

  data = {
      "signedTransaction": "4MzR7dxJNJRVP1Q6k7Y3j8X...",
      "requestId": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
  }

  response = requests.post(
      'https://api.zcombinator.io/damm/deposit/confirm',
      json=data,
      headers={'Content-Type': 'application/json'}
  )

  result = response.json()
  ```
</CodeGroup>

## Request Parameters

<ParamField body="signedTransaction" type="string" required>
  Base58 encoded signed transaction from the manager wallet (must match the transaction from `/damm/deposit/build`)
</ParamField>

<ParamField body="requestId" type="string" required>
  Unique identifier returned from the `/damm/deposit/build` endpoint
</ParamField>

## Response

<ResponseField name="success" type="boolean">
  Indicates if the transaction was submitted successfully
</ResponseField>

<ResponseField name="signature" type="string">
  Transaction signature (transaction ID) on Solana
</ResponseField>

<ResponseField name="poolAddress" type="string">
  Address of the Meteora DAMM v2 pool
</ResponseField>

<ResponseField name="tokenAMint" type="string">
  Mint address of Token A in the pool
</ResponseField>

<ResponseField name="tokenBMint" type="string">
  Mint address of Token B in the pool
</ResponseField>

<ResponseField name="amounts" type="object">
  Object containing the deposited amounts (in raw token units):

  * `tokenA` (string): Token A amount deposited
  * `tokenB` (string): Token B amount deposited
  * `liquidityDelta` (string): Liquidity amount added
</ResponseField>

<ResponseField name="message" type="string">
  Success message
</ResponseField>

### Success Response

```json theme={null}
{
  "success": true,
  "signature": "5J8Z9xKqH4nL2pR7vT3mB1cW6dF8yG4aS9jK2xM5nP8hQ3rV7wE1",
  "poolAddress": "CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C",
  "tokenAMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
  "tokenBMint": "So11111111111111111111111111111111111111112",
  "amounts": {
    "tokenA": "1000000000",
    "tokenB": "500000000",
    "liquidityDelta": "707106781"
  },
  "message": "Deposit transaction submitted successfully"
}
```

## Error Responses

<AccordionGroup>
  <Accordion title="400 - Missing Parameters">
    ```json theme={null}
    {
      "error": "Missing required fields: signedTransaction and requestId"
    }
    ```
  </Accordion>

  <Accordion title="400 - Request Not Found">
    ```json theme={null}
    {
      "error": "Deposit request not found or expired. Please call /damm/deposit/build first."
    }
    ```

    The requestId is invalid, expired, or already used.
  </Accordion>

  <Accordion title="400 - Request Expired">
    ```json theme={null}
    {
      "error": "Deposit request expired. Please create a new request."
    }
    ```

    More than 10 minutes have passed since the deposit request was created.
  </Accordion>

  <Accordion title="400 - Transaction Deserialization Failed">
    ```json theme={null}
    {
      "error": "Failed to deserialize transaction: Invalid transaction format"
    }
    ```

    The provided signedTransaction cannot be decoded.
  </Accordion>

  <Accordion title="400 - Missing Blockhash">
    ```json theme={null}
    {
      "error": "Invalid transaction: missing blockhash"
    }
    ```
  </Accordion>

  <Accordion title="400 - Expired Blockhash">
    ```json theme={null}
    {
      "error": "Invalid transaction: blockhash is expired. Please create a new transaction."
    }
    ```

    The transaction's blockhash is older than 150 slots (\~60 seconds).
  </Accordion>

  <Accordion title="400 - Fee Payer Mismatch">
    ```json theme={null}
    {
      "error": "Transaction fee payer must be manager wallet"
    }
    ```

    The transaction's fee payer doesn't match the configured manager wallet.
  </Accordion>

  <Accordion title="400 - Manager Not Signed">
    ```json theme={null}
    {
      "error": "Transaction verification failed: Manager wallet has not signed"
    }
    ```

    The manager wallet's signature is missing from the transaction.
  </Accordion>

  <Accordion title="400 - Invalid Manager Signature">
    ```json theme={null}
    {
      "error": "Transaction verification failed: Invalid manager wallet signature"
    }
    ```

    The manager wallet's signature is invalid or doesn't match.
  </Accordion>

  <Accordion title="400 - Transaction Tampered">
    ```json theme={null}
    {
      "error": "Transaction verification failed: transaction has been modified",
      "details": "Transaction structure does not match the original unsigned transaction"
    }
    ```

    The transaction structure was modified after it was built. The SHA-256 hash doesn't match.
  </Accordion>

  <Accordion title="400 - Unauthorized Program">
    ```json theme={null}
    {
      "error": "Invalid transaction: unauthorized program instruction detected",
      "details": "Instruction 3 uses unauthorized program: 11111111111111111111111111111112"
    }
    ```

    The transaction contains instructions from programs that aren't allowed.
  </Accordion>

  <Accordion title="400 - Unauthorized Token Instruction">
    ```json theme={null}
    {
      "error": "Invalid transaction: unauthorized token instruction detected",
      "details": "Instruction 2 has invalid opcode: 7"
    }
    ```

    Token program instructions must be Transfer (3), InitializeAccount (9), TransferChecked (12), or SyncNative (17) only. SyncNative is required for wrapping SOL to WSOL.
  </Accordion>

  <Accordion title="400 - Invalid Transfer Authority">
    ```json theme={null}
    {
      "error": "Invalid transaction: transfer authority must be manager or LP owner",
      "details": "Instruction 5 authority mismatch"
    }
    ```

    Token transfers must be signed by either the manager wallet or LP owner.
  </Accordion>

  <Accordion title="400 - Unauthorized Manager Transfer">
    ```json theme={null}
    {
      "error": "Invalid transaction: transfer from manager must go to LP owner",
      "details": "Instruction 6 invalid destination"
    }
    ```

    Manager wallet transfers can only go to the LP owner's token accounts.
  </Accordion>

  <Accordion title="400 - Unauthorized LP Owner Transfer">
    ```json theme={null}
    {
      "error": "Invalid transaction: LP owner transfers must go to pool vaults only",
      "details": "Instruction 7 unauthorized destination for LP owner transfer"
    }
    ```

    CRITICAL SECURITY: LP owner transfers can only go to pool vaults, preventing fund drainage attacks.
  </Accordion>

  <Accordion title="400 - Amount Exceeds Expected">
    ```json theme={null}
    {
      "error": "Invalid transaction: Token A transfer amount exceeds expected",
      "details": "Instruction 8 amount too large"
    }
    ```

    Transfer amounts cannot exceed the specified deposit amounts.
  </Accordion>

  <Accordion title="400 - Invalid Manager SOL Transfer">
    ```json theme={null}
    {
      "error": "Invalid transaction: manager SOL transfer must be to LP owner",
      "details": "Instruction 9 to mismatch"
    }
    ```

    Native SOL transfers from manager must go to LP owner.
  </Accordion>

  <Accordion title="400 - Unauthorized LP Owner SOL Transfer">
    ```json theme={null}
    {
      "error": "Invalid transaction: LP owner SOL transfers must be to WSOL account only",
      "details": "Instruction 10 unauthorized destination for LP owner SOL transfer"
    }
    ```

    SECURITY: LP owner SOL transfers are only allowed to whitelisted destinations (LP owner's WSOL account for wrapping SOL, or self-transfers for account creation). This prevents fund drainage attacks while allowing legitimate SOL wrapping operations.
  </Accordion>

  <Accordion title="500 - Configuration Error">
    ```json theme={null}
    {
      "error": "Server configuration incomplete"
    }
    ```

    Required environment variables are not configured.
  </Accordion>

  <Accordion title="500 - Transaction Submission Failed">
    ```json theme={null}
    {
      "error": "Failed to confirm deposit"
    }
    ```
  </Accordion>
</AccordionGroup>

## Process Flow

This endpoint performs extensive validation before submitting the transaction:

<Steps>
  <Step title="Validate Parameters">
    Ensures signedTransaction and requestId are provided
  </Step>

  <Step title="Retrieve Request Data">
    Looks up the deposit request data using the requestId
  </Step>

  <Step title="Queue Request">
    Ensures only one operation processes at a time for this pool (additional requests wait in queue)
  </Step>

  <Step title="Check Request Expiry">
    Verifies the request is not older than 10 minutes
  </Step>

  <Step title="Deserialize Transaction">
    Decodes the Base58 encoded transaction
  </Step>

  <Step title="Validate Blockhash">
    Checks that the transaction's blockhash is recent and valid (within last 150 slots)
  </Step>

  <Step title="Verify Manager Wallet">
    Ensures the fee payer is the manager wallet and has signed the transaction
  </Step>

  <Step title="Verify Manager Signature">
    Cryptographically validates the manager wallet's signature using nacl
  </Step>

  <Step title="Verify Transaction Integrity">
    Calculates SHA-256 hash and compares with stored hash to detect tampering
  </Step>

  <Step title="Validate Transaction Structure">
    Comprehensive security validation (see Security Validations section below)
  </Step>

  <Step title="Complete Transaction">
    Adds the required signatures to finalize the transaction
  </Step>

  <Step title="Submit Transaction">
    Broadcasts the fully-signed transaction to Solana with preflight checks
  </Step>

  <Step title="Wait for Confirmation">
    Attempts to wait for transaction confirmation (continues if timeout)
  </Step>

  <Step title="Cleanup">
    Removes the request data from memory and releases the pool lock
  </Step>
</Steps>

## Security Validations

This endpoint implements the most comprehensive transaction validation to prevent attacks:

<AccordionGroup>
  <Accordion title="1. Request Queueing">
    Only one liquidity operation can be processed per pool at a time. Concurrent requests are automatically queued and processed sequentially.
  </Accordion>

  <Accordion title="2. Tampering Detection">
    Cryptographic validation detects any modification to the transaction structure before submission. This prevents malicious changes to instructions.
  </Accordion>

  <Accordion title="3. Blockhash Validation">
    Prevents replay attacks by verifying the blockhash is recent (within last 150 slots / \~60 seconds).
  </Accordion>

  <Accordion title="4. Manager Wallet Verification">
    Only the configured manager wallet can submit deposit transactions. Both fee payer and signature are verified cryptographically.
  </Accordion>

  <Accordion title="5. Allowed Programs">
    Only permits instructions from:

    * Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA)
    * Associated Token Program (ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL)
    * Compute Budget Program
    * Lighthouse Program (for optimization)
    * Meteora CP-AMM Program (CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C)
    * Meteora DAMM v2 Program (cpamdpZCGKy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG)
    * System Program (for native SOL transfers)
  </Accordion>

  <Accordion title="6. Token Instruction Validation">
    * Only Transfer (opcode 3), InitializeAccount (opcode 9), TransferChecked (opcode 12), and SyncNative (opcode 17) are allowed
    * SyncNative is required for wrapping SOL to WSOL in native SOL deposits
    * Validates transfer authority (manager wallet or LP owner)
    * Transfer amounts cannot exceed specified deposit amounts
  </Accordion>

  <Accordion title="7. Destination Validation - Manager Transfers">
    Manager wallet transfers can ONLY go to:

    * LP owner's Token A account
    * LP owner's Token B account (or LP owner address for native SOL)
      Any other destination is rejected.
  </Accordion>

  <Accordion title="8. Destination Validation - LP Owner Transfers">
    **CRITICAL SECURITY**: LP owner transfers can ONLY go to:

    * Pool Token A vault (for adding liquidity)
    * Pool Token B vault (for adding liquidity)
    * LP owner's own token accounts

    This prevents malicious clients from draining LP owner funds to arbitrary addresses.
  </Accordion>

  <Accordion title="9. System Transfer Validation - Manager">
    For native SOL transfers from manager wallet:

    * Only SystemProgram.transfer (instruction type 2) allowed
    * Must be from manager wallet to LP owner
    * Amount cannot exceed Token B deposit amount
  </Accordion>

  <Accordion title="10. System Transfer Validation - LP Owner">
    **SECURITY**: LP owner SOL transfers are whitelisted to specific destinations only:

    * LP owner's WSOL associated token account (required for wrapping SOL)
    * LP owner's own address (for self-transfers needed for account creation)

    This prevents fund drainage while allowing legitimate SOL wrapping operations required for native SOL deposits. Any transfers to other addresses are rejected.
  </Accordion>

  <Accordion title="11. ATA Instruction Validation">
    Only CreateAssociatedTokenAccountIdempotent (opcode 1) is allowed for ATA program.
  </Accordion>

  <Accordion title="12. Amount Validation">
    All transfer amounts are compared against stored expected deposit amounts to prevent over-deposit or fund drainage.
  </Accordion>
</AccordionGroup>

<Warning>
  **Enhanced security for deposits**: Deposit transactions undergo the most rigorous validation to prevent fund drainage attacks. The combination of transaction hash validation, strict destination checks, and amount validation ensures that only legitimate deposits can be processed.
</Warning>

## Rate Limiting

This endpoint is subject to rate limiting:

* **10 requests** per 5-minute window per IP
* Returns HTTP 429 when limit exceeded

## Transaction Confirmation

The API attempts to wait for transaction confirmation but continues even if confirmation times out:

* **Confirmation Commitment**: confirmed
* **Timeout Handling**: Logs warning but returns success
* **User Responsibility**: Check transaction status on Solana explorer

You can view the transaction on Solscan: `https://solscan.io/tx/{signature}`

## Concurrent Request Handling

<Warning>
  **Request queueing**:

  When a liquidity operation is being processed for a pool, subsequent requests for the same pool will wait in queue. This prevents:

  * Concurrent deposit conflicts
  * Transaction race conditions
  * Double-processing

  Requests are automatically processed in order when the current operation completes.
</Warning>

## One-Time Use

After successful submission:

* The requestId cannot be reused
* You must create a new request for additional operations

## Best Practices

<Steps>
  <Step title="Check Blockhash Age">
    Submit the signed transaction quickly after receiving it from `/damm/deposit/build`. Blockhashes expire after \~60 seconds.
  </Step>

  <Step title="Do Not Modify Transaction">
    Do not modify the transaction after receiving it from the build endpoint. Any modification will be detected and rejected.
  </Step>

  <Step title="Handle Expiry">
    If more than 10 minutes pass, create a new deposit request instead of retrying with the old requestId.
  </Step>

  <Step title="Verify Balances">
    Ensure your manager wallet has sufficient token balances before building the transaction.
  </Step>

  <Step title="Monitor Transaction">
    Use the returned signature to check transaction status on Solana explorers or via RPC.
  </Step>

  <Step title="Handle Queueing">
    If you receive a timeout or slow response, another request may be processing. Wait and retry.
  </Step>
</Steps>

## Fund Flow

Understanding the fund flow during deposit:

<Steps>
  <Step title="Manager → LP Owner">
    Manager wallet transfers tokens to LP owner's token accounts (or native SOL to LP owner address)
  </Step>

  <Step title="LP Owner → Pool Vaults">
    LP owner's tokens are transferred to the pool and liquidity position is updated
  </Step>

  <Step title="LP Tokens Minted">
    LP position NFT is updated with increased liquidity amount
  </Step>
</Steps>

All security validations ensure this exact flow is followed with no deviations.

## Related Endpoints

* [`/damm/deposit/build`](/api-reference/damm-liquidity/deposit-build) - Create the unsigned deposit transaction
* [`/damm/withdraw/build`](/api-reference/damm-liquidity/withdraw-build) - Build withdrawal transaction