-
Notifications
You must be signed in to change notification settings - Fork 18
Implement cross chain swaps #3364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have the contract address now:
0xb0830ef478a215ed393c20a0c97aa69869a0beea
on bsc
tee-worker/omni-executor/rpc-server/src/methods/pumpx/submit_swap_order.rs
Outdated
Show resolved
Hide resolved
@@ -76,35 +101,48 @@ pub type ParentchainTxSigner = TxSigner< | |||
SubxtMetadataProvider<CustomConfig>, | |||
>; | |||
|
|||
// TODO: temporary solution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious: why is it temporary? I thought this was the solution 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
tee-worker/omni-executor/intent/executors/cross-chain/src/lib.rs
Outdated
Show resolved
Hide resolved
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These values are decimals i'll change it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Binance amount received will be multiplied by 10^8 because native BNB has a smalles unit Jager
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good catch - i wasn't sure about it. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
tee-worker/omni-executor/intent/executors/cross-chain/src/lib.rs
Outdated
Show resolved
Hide resolved
tee-worker/omni-executor/intent/executors/cross-chain/src/lib.rs
Outdated
Show resolved
Hide resolved
}, | ||
}, | ||
// amount received from binance should be used... | ||
amount_in: to_amount.to_string(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it means it's fully "filled", right? No partial trade could happen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see - will we reach it eventually? Like can it be an endless loop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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