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]

#16

[piotrostr]

@bginsber lets resolve the Cargo.toml conflict and we are good to merge:)

[piotrostr]

ill take it from here, @bginsber, thank you so much!

[bginsber]

ill take it from here, @bginsber, thank you so much!

Sorry for missing the resolve comment. Happy to continue helping on other to-dos. Honestly, as soon as I read and laughed at your twitter bio I knew I had to find a way to contribute