Feature/meteora integration

[bginsber]

Meteora DEX Integration

This PR integrates the Meteora DEX, allowing users to swap tokens, manage liquidity, and claim fees using Meteora's concentrated liquidity pools.

Changes

• Added src/meteora.rs module with Meteora DEX functionality:
  • Swap tokens
  • Add liquidity
  • Remove liquidity
  • Claim fees
• Added Meteora program ID constant
• Added official Meteora SDK dependency via commons crate
• Added comprehensive tests with minimal token amounts

Implementation Notes

• Uses the official Meteora repository: MeteoraAg/dlmm-sdk
• Minimized direct Solana dependencies, relying on commons interfaces where possible
• Follows similar patterns to existing DEX integrations
• Includes error handling and transaction confirmation
• Supports interactive confirmation for swaps
• Tests use real mainnet interactions with minimal amounts (~0.0006 SOL total)
  • Basic swap: 0.0001 SOL
  • Liquidity operations: 0.0001 SOL / 0.001 USDC
  • Fee testing: 0.0005 SOL / 0.005 USDC
• Tests include balance verification, error handling, and cleanup

Raydium Integration

Due to Solana version compatibility issues, dependency conflicts, and the fact that Jupiter can route through Raydium, a separate issue will be created to plan the deprecation of the direct Raydium integration. This PR will focus solely on the Meteora integration. Raydium changes will be handled in a future PR.

Known Issues

• Solana version compatibility with Raydium needs to be addressed. A plan for Raydium deprecation will be created in a separate issue.

Testing

• The implementation has been thoroughly tested locally with:
  • Basic swap operations
  • Liquidity management
  • Error handling
  • Transaction confirmation
  • Added realistic mainnet tests with minimal amounts

Future Work

1. Decide if we deprecate direct Raydium integration (tracked in a separate issue)
2. Add documentation for Meteora-specific features
3. Consider optimizing pool selection for better swap rates

Questions for Reviewers

1. Is the error handling approach appropriate?
2. Should we add more logging or metrics?
3. Are there any security considerations we should address?
4. Should we handle slippage differently?
5. What is the best approach for notifying users about the potential direct Raydium lib deprecation?

[piotrostr]

thank you for the PR @bginsber!

left some comments

one more thing - could we have some "realist" tests that run swaps by grabbing the env("FUND_KEYPAIR_PATH") with dust amounts? something like in

listen/src/pump.rs

Line 1094 in f77949e

#[tokio::test]

should be okay to run it with 100_000 lamports

[piotrostr]

could we swap this to the https://github.com/MeteoraAg/dlmm-sdk root repo?

[bginsber]

totally

[piotrostr]

Ill have to check out this branch and see if 2.0.3 is not going to cause shenanigans

the solana >=2 sdks were not compatible with the searcher client iirc, will lyk

[piotrostr]

yup

honestly i might be dropping the direct raydium lib dependency since it sucks big time, it takes like 4 account calls to do the swap, comes with a lot of peer deps and jupiter can easily allows swapping most raydium tokens with better slipapge prot

[dtmrc]

easier to monitor prices & pool events by using direct raydium though, yeh?

[piotrostr]

#16