But why do you need to check trading transactions? What kind of info do you read from the onchain transaction?
(itâs just to know if the txid is enough)
But why do you need to check trading transactions? What kind of info do you read from the onchain transaction?
(itâs just to know if the txid is enough)
I cannot understand why my trade request is rejected/accepted easily anymore since there are many arb bots are working and pDEX has random nature thanks to its implementation and sharding.
@abduraman thank you!
So Iâll add txid to trades but you would be interested too if I show all failed trades somewhere?
Failed trading transactions are already tracked on my side but not displayed in the UI.
select count(*) from failedtradingtransactions;
count
------
41271
I didnât want it not to increase your workload. In fact, that would be good.
To start, https://incscan.io/pdex/trades : click on the link icon, youâll see the corresponding response trade.
1.8.6 version released
New features:
Show failed trades: Failed trades are now available, use the âfailed tradesâ checkbox in the trades list to show them.
Transactions linked to trades: Use the link icon available on each trade line to go to the corresponding trade response transaction.
Transactions linked to shielded coins: Use the link icon available on each shielded coin line to go to the corresponding shielded response transaction.
Removed feature
cc @abduraman
Thank you so much.
If possible, could you put an icon/backColor or something else to distinguish failed ones from accepted ones? Thanks. @inccry
added
Sorry @inccry. I misunderstood the page. Since I thought that failed and accepted ones were merged, I suggested such a feature. However, they are discrete. When the box is checked, only failed trades are displayed. So, in that case, my suggestion was meaningless
Well, if you can implement the merged display, it would be better I mean that all trade requests are displayed when the box is checked.
Thatâs exactly how I thought the new feature worked too. Was confused until I realized that the check mark acted more as a toggle between successful and failed transactions, instead of a merge/filter. Agree merge/filter would be a better view.
Oof!
I would have done it if it was simple But itâs two different Influx measurements, so impossible to merge while keeping pagination.
Iâll try to move this option elsewhere so it doesnât look like a search filter.
@inccry, could you also add the linked pDEX response to the tx info page, such as https://incscan.io/tx/a9b6f9ece3727600d863ce4bf7b33389adb3dce0a9fe36ef58b2c33dcd659335? It would be helpful. Thanks.
Hello @J053,
Itâs possible but itâs not trivial. When you see a âlinked transactionâ like here thatâs because metadata of this transaction contains a âRequestedTxIDâ value.
I know. Youâll need to make a query to your DB for a trade response with RequestedTxID = TxID. Also, if it was unsuccessful, the query will return 2 TxIDs, because of the tradingFee and sellAmount refund, right?
I donât run this kind of queries on a table with 1.5+M of rows . Thatâs why I build a specific projection for this kind of use cases.
Yep, example:
No disappointment here. Your contributions to the ecosystem are always superb.
In order to be ready for Privacy V2, I just deployed a test version of Incscan:
This version uses testnet-2 Incognito network and all USD calculations are disabled or faked.
Feel free to use it for all your tests!
Wen ICO?