Skip to main content

​
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"
  }'

​
Request Parameters

​
signedTransaction
string
required
Base58 encoded signed transaction from the manager wallet (must match the transaction from /damm/deposit/build)
​
requestId
string
required
Unique identifier returned from the /damm/deposit/build endpoint

​
Response

​
success
boolean
Indicates if the transaction was submitted successfully
​
signature
string
Transaction signature (transaction ID) on Solana
​
poolAddress
string
Address of the Meteora DAMM v2 pool
​
tokenAMint
string
Mint address of Token A in the pool
​
tokenBMint
string
Mint address of Token B in the pool
​
amounts
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
​
message
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

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

{
  "error": "Deposit request not found or expired. Please call /damm/deposit/build first."
}
The requestId is invalid, expired, or already used.
{
  "error": "Deposit request expired. Please create a new request."
}
More than 10 minutes have passed since the deposit request was created.
{
  "error": "Failed to deserialize transaction: Invalid transaction format"
}
The provided signedTransaction cannot be decoded.
{
  "error": "Invalid transaction: missing blockhash"
}

{
  "error": "Invalid transaction: blockhash is expired. Please create a new transaction."
}
The transaction’s blockhash is older than 150 slots (~60 seconds).
{
  "error": "Transaction fee payer must be manager wallet"
}
The transaction’s fee payer doesn’t match the configured manager wallet.
{
  "error": "Transaction verification failed: Manager wallet has not signed"
}
The manager wallet’s signature is missing from the transaction.
{
  "error": "Transaction verification failed: Invalid manager wallet signature"
}
The manager wallet’s signature is invalid or doesn’t match.
{
  "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.
{
  "error": "Invalid transaction: unauthorized program instruction detected",
  "details": "Instruction 3 uses unauthorized program: 11111111111111111111111111111112"
}
The transaction contains instructions from programs that aren’t allowed.
{
  "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.
{
  "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.
{
  "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.
{
  "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.
{
  "error": "Invalid transaction: Token A transfer amount exceeds expected",
  "details": "Instruction 8 amount too large"
}
Transfer amounts cannot exceed the specified deposit amounts.
{
  "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.
{
  "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.
{
  "error": "Server configuration incomplete"
}
Required environment variables are not configured.
{
  "error": "Failed to confirm deposit"
}

​
Process Flow

This endpoint performs extensive validation before submitting the transaction:
1

Validate Parameters

Ensures signedTransaction and requestId are provided
2

Retrieve Request Data

Looks up the deposit request data using the requestId
3

Queue Request

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

Check Request Expiry

Verifies the request is not older than 10 minutes
5

Deserialize Transaction

Decodes the Base58 encoded transaction
6

Validate Blockhash

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

Verify Manager Wallet

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

Verify Manager Signature

Cryptographically validates the manager wallet’s signature using nacl
9

Verify Transaction Integrity

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

Validate Transaction Structure

Comprehensive security validation (see Security Validations section below)
11

Complete Transaction

Adds the required signatures to finalize the transaction
12

Submit Transaction

Broadcasts the fully-signed transaction to Solana with preflight checks
13

Wait for Confirmation

Attempts to wait for transaction confirmation (continues if timeout)
14

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:
Only one liquidity operation can be processed per pool at a time. Concurrent requests are automatically queued and processed sequentially.
Cryptographic validation detects any modification to the transaction structure before submission. This prevents malicious changes to instructions.
Prevents replay attacks by verifying the blockhash is recent (within last 150 slots / ~60 seconds).
Only the configured manager wallet can submit deposit transactions. Both fee payer and signature are verified cryptographically.
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)
  • 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
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.
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.
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
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.
Only CreateAssociatedTokenAccountIdempotent (opcode 1) is allowed for ATA program.
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

1

Check Blockhash Age

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

Do Not Modify Transaction

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

Handle Expiry

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

Verify Balances

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

Monitor Transaction

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

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:
1

Manager → LP Owner

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

LP Owner → Pool Vaults

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

LP Tokens Minted

LP position NFT is updated with increased liquidity amount
All security validations ensure this exact flow is followed with no deviations.