Confirm Deposit Transaction

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.

Enhanced security: This endpoint validates that the transaction hasn’t been modified after creation, preventing tampering attacks.

curl -X POST https://api.zcombinator.io/damm/deposit/confirm \
  -H "Content-Type: application/json" \
  -d '{
    "signedTransaction": "4MzR7dxJNJRVP1Q6k7Y3j8X...",
    "requestId": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
  }'

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();

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()

Request Parameters

string

required

Base58 encoded signed transaction from the manager wallet (must match the transaction from /damm/deposit/build)

string

required

Unique identifier returned from the /damm/deposit/build endpoint

Response

boolean

Indicates if the transaction was submitted successfully

string

Transaction signature (transaction ID) on Solana

string

Address of the Meteora DAMM v2 pool

string

Mint address of Token A in the pool

string

Mint address of Token B in the pool

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

string

Success message

Success Response

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

Error Responses

400 - Missing Parameters

{
  "error": "Missing required fields: signedTransaction and requestId"
}

400 - Request Not Found

{
  "error": "Deposit request not found or expired. Please call /damm/deposit/build first."
}

The requestId is invalid, expired, or already used.

400 - Request Expired

{
  "error": "Deposit request expired. Please create a new request."
}

More than 10 minutes have passed since the deposit request was created.

400 - Transaction Deserialization Failed

{
  "error": "Failed to deserialize transaction: Invalid transaction format"
}

The provided signedTransaction cannot be decoded.

400 - Missing Blockhash

{
  "error": "Invalid transaction: missing blockhash"
}

400 - Expired Blockhash

{
  "error": "Invalid transaction: blockhash is expired. Please create a new transaction."
}

The transaction’s blockhash is older than 150 slots (~60 seconds).

400 - Fee Payer Mismatch

{
  "error": "Transaction fee payer must be manager wallet"
}

The transaction’s fee payer doesn’t match the configured manager wallet.

400 - Manager Not Signed

{
  "error": "Transaction verification failed: Manager wallet has not signed"
}

The manager wallet’s signature is missing from the transaction.

400 - Invalid Manager Signature

{
  "error": "Transaction verification failed: Invalid manager wallet signature"
}

The manager wallet’s signature is invalid or doesn’t match.

400 - Transaction Tampered

{
  "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.

400 - Unauthorized Program

{
  "error": "Invalid transaction: unauthorized program instruction detected",
  "details": "Instruction 3 uses unauthorized program: 11111111111111111111111111111112"
}

The transaction contains instructions from programs that aren’t allowed.

400 - Unauthorized Token Instruction

{
  "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.

400 - Invalid Transfer Authority

{
  "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.

400 - Unauthorized Manager Transfer

{
  "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.

400 - Unauthorized LP Owner Transfer

{
  "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.

400 - Amount Exceeds Expected

{
  "error": "Invalid transaction: Token A transfer amount exceeds expected",
  "details": "Instruction 8 amount too large"
}

Transfer amounts cannot exceed the specified deposit amounts.

400 - Invalid Manager SOL Transfer

{
  "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.

400 - Unauthorized LP Owner SOL Transfer

{
  "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.

500 - Configuration Error

{
  "error": "Server configuration incomplete"
}

Required environment variables are not configured.

500 - Transaction Submission Failed

{
  "error": "Failed to confirm deposit"
}

Process Flow

This endpoint performs extensive validation before submitting the transaction:

Validate Parameters

Ensures signedTransaction and requestId are provided

Retrieve Request Data

Looks up the deposit request data using the requestId

Queue Request

Ensures only one operation processes at a time for this pool (additional requests wait in queue)

Check Request Expiry

Verifies the request is not older than 10 minutes

Deserialize Transaction

Decodes the Base58 encoded transaction

Validate Blockhash

Checks that the transaction’s blockhash is recent and valid (within last 150 slots)

Verify Manager Wallet

Ensures the fee payer is the manager wallet and has signed the transaction

Verify Manager Signature

Cryptographically validates the manager wallet’s signature using nacl

Verify Transaction Integrity

Calculates SHA-256 hash and compares with stored hash to detect tampering

Validate Transaction Structure

Comprehensive security validation (see Security Validations section below)

Complete Transaction

Adds the required signatures to finalize the transaction

Submit Transaction

Broadcasts the fully-signed transaction to Solana with preflight checks

Wait for Confirmation

Attempts to wait for transaction confirmation (continues if timeout)

Cleanup

Removes the request data from memory and releases the pool lock

Security Validations

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

1. Request Queueing

Only one liquidity operation can be processed per pool at a time. Concurrent requests are automatically queued and processed sequentially.

2. Tampering Detection

Cryptographic validation detects any modification to the transaction structure before submission. This prevents malicious changes to instructions.

3. Blockhash Validation

Prevents replay attacks by verifying the blockhash is recent (within last 150 slots / ~60 seconds).

4. Manager Wallet Verification

Only the configured manager wallet can submit deposit transactions. Both fee payer and signature are verified cryptographically.

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)

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

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.

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.

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

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.

11. ATA Instruction Validation

Only CreateAssociatedTokenAccountIdempotent (opcode 1) is allowed for ATA program.

12. Amount Validation

All transfer amounts are compared against stored expected deposit amounts to prevent over-deposit or fund drainage.

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.

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

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.

One-Time Use

After successful submission:

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

Best Practices

Check Blockhash Age

Submit the signed transaction quickly after receiving it from /damm/deposit/build. Blockhashes expire after ~60 seconds.

Do Not Modify Transaction

Do not modify the transaction after receiving it from the build endpoint. Any modification will be detected and rejected.

Handle Expiry

If more than 10 minutes pass, create a new deposit request instead of retrying with the old requestId.

Verify Balances

Ensure your manager wallet has sufficient token balances before building the transaction.

Monitor Transaction

Use the returned signature to check transaction status on Solana explorers or via RPC.

Handle Queueing

If you receive a timeout or slow response, another request may be processing. Wait and retry.

Fund Flow

Understanding the fund flow during deposit:

Manager → LP Owner

Manager wallet transfers tokens to LP owner’s token accounts (or native SOL to LP owner address)

LP Owner → Pool Vaults

LP owner’s tokens are transferred to the pool and liquidity position is updated

LP Tokens Minted

LP position NFT is updated with increased liquidity amount

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

/damm/deposit/build - Create the unsigned deposit transaction
/damm/withdraw/build - Build withdrawal transaction

Launch

Claim token emissions (dev)

Claim LP fees

Manage AMM liquidity

Utility

Overview

Request Parameters

Response

Success Response

Error Responses

Process Flow

Security Validations

Rate Limiting

Transaction Confirmation

Concurrent Request Handling

One-Time Use

Best Practices

Fund Flow

​Overview

​Request Parameters

​Response

​Success Response

​Error Responses

​Process Flow

​Security Validations

​Rate Limiting

​Transaction Confirmation

​Concurrent Request Handling

​One-Time Use

​Best Practices

​Fund Flow

​Related Endpoints

Overview

Request Parameters

Response

Success Response

Error Responses

Process Flow

Security Validations

Rate Limiting

Transaction Confirmation

Concurrent Request Handling

One-Time Use

Best Practices

Fund Flow

Related Endpoints