Implement cross chain swaps#3364
Conversation
Implement initial Binance API integration in the cross-chain executor
Add RemoteSigner implementation that connects to the pumpx signer service for securely signing Solana transactions.
Update RemoteSigner implementation to receive a tokio runtime Handle through constructor rather than retrieving it internally.
Extract Solana functionality into a dedicated module
Add SolanaClient implementation that provides functionality for: - Transferring SOL to specified addresses - Transferring SPL tokens between wallets - Managing transaction signing and confirmations - Error handling and logging for transaction failures This extends the Solana module with client capabilities needed for cross-chain swaps and other DeFi operations.
…ng-cross-chain-swap
Add integration with Binance spot trading API for cross-chain swaps: - Expose Binance API types needed for order creation - Implement market order creation with appropriate trading pairs - Add status monitoring to verify order execution - Implement error handling with failure notifications - Support USDC, USDT and SOL pairs with BNB
Add Ethereum accounting contract integration to cross-chain swaps: - Add AccountingContractClient as a dependency to relevant crates - Initialize accounting contract client with Ethereum RPC provider - Set up contract address in executor initialization - Update cross-chain executor to use accounting client - Implement proper type parameters for RPC providers
4625636 to
bc336ae
Compare
Kailai-Wang
left a comment
There was a problem hiding this comment.
Thank you - I think the flow is fine - I have a few details to discuss
| let ethereum_rpc_provider = ethereum_rpc::AlloyRpcProvider::new(&args.ethereum_url); | ||
| let accounting_contract_client = AccountingContractClient::new( | ||
| ethereum_rpc_provider, | ||
| "TODO:get contract address".parse().unwrap(), |
There was a problem hiding this comment.
We have the contract address now:
0xb0830ef478a215ed393c20a0c97aa69869a0beea on bsc
| SubxtMetadataProvider<CustomConfig>, | ||
| >; | ||
|
|
||
| // TODO: temporary solution |
There was a problem hiding this comment.
Just curious: why is it temporary? I thought this was the solution 😂
There was a problem hiding this comment.
I was just thinking that on test networks for example the contract/mint addresses could be different so we may want to have a config for this
| for fill in trade_order.fills.unwrap() { | ||
| let fill_price: u128 = fill.price.parse().unwrap(); | ||
| let fill_amount: u128 = fill.qty.parse().unwrap(); | ||
| to_amount += fill_price * fill_amount; |
There was a problem hiding this comment.
Just to double-check that it's what we want - to_amount is the amount of BNBs to pay out? I just don't know if fill_price * fill_amount get it right. Like should it multiple it by fill_price?
Did it take decimal into consideration?
So if it's 0.01 BNB, to_amount will be (0.01 * 10^18), right?
There was a problem hiding this comment.
These values are decimals i'll change it
There was a problem hiding this comment.
Binance amount received will be multiplied by 10^8 because native BNB has a smalles unit Jager
There was a problem hiding this comment.
That's a good catch - i wasn't sure about it. Thanks.
There was a problem hiding this comment.
We actually need decimals in pumpx-api
It just has to match the binance api (what fill_price and fill_amount stand for)
Maybe you could write a comment naming an example for it - so that everyone that reads the code knows the intention at least
| }, | ||
| }, | ||
| // amount received from binance should be used... | ||
| amount_in: to_amount.to_string(), |
There was a problem hiding this comment.
Here we need to consider decimal, from previous example, backend expects 0.01 here, not 0.01 * (10^18)
There was a problem hiding this comment.
Conversion to bnb unit (Jager) is done later. I expect current impl will result in 0.01 not 0.01 * 10^8
| })?; | ||
|
|
||
| match trade_order.status { | ||
| BinanceOrderStatus::FILLED => { |
There was a problem hiding this comment.
So it means it's fully "filled", right? No partial trade could happen
There was a problem hiding this comment.
Now I assume we will get FILLED status with all fills (100% completion)
PARTIALLY_FILLED,
FILLED,
PARTIALLY_FILLED status is ignored and we poll untill it's FILLED
There was a problem hiding this comment.
I see - will we reach it eventually? Like can it be an endless loop?
Kailai-Wang
left a comment
There was a problem hiding this comment.
Let's merge it and I'll raise another PR to address the binance-api problem
TODO:
Note: the following trades are the only ones supported.
USDT@solana -> BNB
USDC@solana -> BNB
SOL@solana -> BNB