-
Notifications
You must be signed in to change notification settings - Fork 502
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
Protocol 18: Horizon path/strict-receive Bug #4014
Comments
I think the algorithm accidentally swapped the pair when it's fetching the liquidity pool balance data. Here is my step :
Result at my time : USDC : 81.7596979 YBX : 0.1288722{
"_links": {
"self": {
"href": "https://horizon-testnet.stellar.org/liquidity_pools/d600a004ecf7d07b4b2305ae9a7305e402bed3e0a16375ca948177c25798a65d"
},
"transactions": {
"href": "https://horizon-testnet.stellar.org/liquidity_pools/d600a004ecf7d07b4b2305ae9a7305e402bed3e0a16375ca948177c25798a65d/transactions{?cursor,limit,order}",
"templated": true
},
"operations": {
"href": "https://horizon-testnet.stellar.org/liquidity_pools/d600a004ecf7d07b4b2305ae9a7305e402bed3e0a16375ca948177c25798a65d/operations{?cursor,limit,order}",
"templated": true
}
},
"id": "d600a004ecf7d07b4b2305ae9a7305e402bed3e0a16375ca948177c25798a65d",
"paging_token": "d600a004ecf7d07b4b2305ae9a7305e402bed3e0a16375ca948177c25798a65d",
"fee_bp": 30,
"type": "constant_product",
"total_trustlines": "1",
"total_shares": "3.1622776",
"reserves": [
{
"asset": "USDC:GAEB3HSAWRVILER6T5NMX5VAPTK4PPO2BAL37HR2EOUIK567GJFEO437",
"amount": "81.7596979"
},
{
"asset": "YBX:GCIWMQHPST7LQ7V4LHAF2UP6ZSDCFRYYP7IM4BBAFSBZMVTR3BB4OQZ5",
"amount": "0.1288722"
}
],
"last_modified_ledger": 557365,
"last_modified_time": "2021-10-19T07:06:52Z"
}
USDC : 0.1288721 YBX : 81.7596978Fetch `paths/strict-receive` for USDC -> YBX and vice versa, look for the one without intermediary path, using binary search, this is what i found Response{
"_embedded": {
"records": [
{
"source_asset_type": "credit_alphanum4",
"source_asset_code": "USDC",
"source_asset_issuer": "GAEB3HSAWRVILER6T5NMX5VAPTK4PPO2BAL37HR2EOUIK567GJFEO437",
"source_amount": "0.2035282",
"destination_asset_type": "credit_alphanum4",
"destination_asset_code": "YBX",
"destination_asset_issuer": "GCIWMQHPST7LQ7V4LHAF2UP6ZSDCFRYYP7IM4BBAFSBZMVTR3BB4OQZ5",
"destination_amount": "81.7596978",
"path": [
{
"asset_type": "credit_alphanum4",
"asset_code": "EURT",
"asset_issuer": "GABHG6C7YL2WA2ZJSONPD6ZBWLPAWKYDPYMK6BQRFLZXPQE7IBSTMPNN"
}
]
},
{
"source_asset_type": "credit_alphanum4",
"source_asset_code": "USDC",
"source_asset_issuer": "GAEB3HSAWRVILER6T5NMX5VAPTK4PPO2BAL37HR2EOUIK567GJFEO437",
"source_amount": "105682568.9751371",
"destination_asset_type": "credit_alphanum4",
"destination_asset_code": "YBX",
"destination_asset_issuer": "GCIWMQHPST7LQ7V4LHAF2UP6ZSDCFRYYP7IM4BBAFSBZMVTR3BB4OQZ5",
"destination_amount": "81.7596978",
"path": []
}
]
}
} Response{
"_embedded": {
"records": [
{
"source_asset_type": "credit_alphanum4",
"source_asset_code": "YBX",
"source_asset_issuer": "GCIWMQHPST7LQ7V4LHAF2UP6ZSDCFRYYP7IM4BBAFSBZMVTR3BB4OQZ5",
"source_amount": "0.0000001",
"destination_asset_type": "credit_alphanum4",
"destination_asset_code": "USDC",
"destination_asset_issuer": "GAEB3HSAWRVILER6T5NMX5VAPTK4PPO2BAL37HR2EOUIK567GJFEO437",
"destination_amount": "0.1288721",
"path": [
{
"asset_type": "credit_alphanum4",
"asset_code": "BTC",
"asset_issuer": "GA2RETJWNREEUY4JHMZVXCE6EJG6MGBUEXK2QXXMNE5EYAQMG22XCXHA"
}
]
},
{
"source_asset_type": "credit_alphanum4",
"source_asset_code": "YBX",
"source_asset_issuer": "GCIWMQHPST7LQ7V4LHAF2UP6ZSDCFRYYP7IM4BBAFSBZMVTR3BB4OQZ5",
"source_amount": "0.0000010",
"destination_asset_type": "credit_alphanum4",
"destination_asset_code": "USDC",
"destination_asset_issuer": "GAEB3HSAWRVILER6T5NMX5VAPTK4PPO2BAL37HR2EOUIK567GJFEO437",
"destination_amount": "0.1288721",
"path": [
{
"asset_type": "credit_alphanum4",
"asset_code": "ETH",
"asset_issuer": "GATPY6X6OYTXKNRKVP6LEMUUQKFDUW5P7HL4XI3KWRCY52RAWYJ5FLMC"
}
]
},
{
"source_asset_type": "credit_alphanum4",
"source_asset_code": "YBX",
"source_asset_issuer": "GCIWMQHPST7LQ7V4LHAF2UP6ZSDCFRYYP7IM4BBAFSBZMVTR3BB4OQZ5",
"source_amount": "0.1933082",
"destination_asset_type": "credit_alphanum4",
"destination_asset_code": "USDC",
"destination_asset_issuer": "GAEB3HSAWRVILER6T5NMX5VAPTK4PPO2BAL37HR2EOUIK567GJFEO437",
"destination_amount": "0.1288721",
"path": [
{
"asset_type": "credit_alphanum4",
"asset_code": "XLM",
"asset_issuer": "GBYKCGLHDZBI32XPO2Z6T76CSYMN2RDZ5L25EK2CHBGWSGEJJUMQ4QKI"
}
]
},
{
"source_asset_type": "credit_alphanum4",
"source_asset_code": "YBX",
"source_asset_issuer": "GCIWMQHPST7LQ7V4LHAF2UP6ZSDCFRYYP7IM4BBAFSBZMVTR3BB4OQZ5",
"source_amount": "105682487.0986820",
"destination_asset_type": "credit_alphanum4",
"destination_asset_code": "USDC",
"destination_asset_issuer": "GAEB3HSAWRVILER6T5NMX5VAPTK4PPO2BAL37HR2EOUIK567GJFEO437",
"destination_amount": "0.1288721",
"path": []
}
]
}
} Notice something weird? The Liquidity Pool balance swapped. This skew the exchange rate and avaible liquidity and fucks up the calculation. In your request, the error compounded and resulted in a very weird response Edit : fixing markdown |
Very clear report, thanks. We're checking this out as a matter of urgency. |
Closed in #4018? |
Hopefully! Please reopen if it's not the case. |
The fix for this issue will be released on Monday as part of Horizon 2.10.0 if no unexpected problems are found. |
The fix has been deployed to testnet https://horizon-testnet.stellar.org/ @mootz12 @Firdausfarul could you please confirm you cannot reproduce the problem any more? |
Confirmed, the problem cannot be reproduced anymore. |
Fantastic, thanks again for the great bug report!!! |
What version are you using?
Currently deployed Horizon API @
https://horizon-testnet.stellar.org
Time of writing:
2021-10-18T21:41:29Z
What did you do?
The
paths/strict-receive
endpoint is returning paths through liquidity pools that are impossible. Note: Due to the risk of the paths / offers / liquidity pools changing, I will attach the API results returned at the time of writing this to the bug.Setup
The Testnet is currently setup with a simple price wall bot, that issues 4 assets, ETH, EURT, USDC, and BTC, that follow the Coinbase / Binance price for each asset. It does this by setting a single deep Buy/Sell wall for each asset to USDC.
We also issue a testnet version of YBX.
All of this is actively traded on and used with the YieldBlox Beta, on the testnet.
User LP Construction
Users of our Beta have been playing around with AMM's / LP. Some users have setup YBX -> ETH / EURT / USDC / BTC pools in hopes to capture users selling the testnet YBX.
See Response
Incorrect Path
A few paths appear to be broken. Here is an ETH -> USDC
Path Strict Receive
example that is returning an invalid path:See Response
If I attempt to submit against this path using a
PathPaymentStrictReceive
, it fails to submit. This transaction contains a tiny amount, to showcase the path we are taking, and then an operation for the quoted amount.Example XDR:
Tx Result XDR:
If you check out the result XDR, the first operation succeeds and you can see the path is taking us through the liquidity pools for Testnet YBX. Then, the second operation with the same path and quoted volume from
path/strict-receive
is failing withtoo_few_offers
.I also attached the relevant offer that the path takes at the end to convert BTC -> USDC, to show that there is enough liquidity in that offer to convert the final Path Payment.
See Response
What did you expect to see?
I expect the Path endpoints to correctly calculate possible paths through liquidity pools.
What did you see instead?
The path endpoint returned a path that we were not able to traverse.
The text was updated successfully, but these errors were encountered: