Add Minswap DEX transaction and DEX Utility calculation #7
Conversation
|
Have you had any success? Even after submitting an order and calling the graphql endpoint logTx (which was only endpoint I was able to see that is called after a tx is submitted), I haven't had any success with the order being batched successfully. |
I've actually had great success with this. No problems thus far. |
|
Just looked my tx closer and for my script I was attaching the datum as inline. Works now after removing that. |
h2physics
changed the title
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
Signed-off-by: Nguyen Le Vu Long <vulongvn98@gmail.com>
| async function getPoolById( | ||
| network: Network, | ||
| blockfrostAdapter: BlockfrostAdapter, | ||
| poolId: string | ||
| ): Promise<{ poolState: PoolState; poolDatum: PoolDatum }> { | ||
| const pool = await blockfrostAdapter.getPoolById({ | ||
| id: poolId, | ||
| }); | ||
| if (!pool) { | ||
| throw new Error(`Not found PoolState of ID: ${poolId}`); | ||
| } | ||
|
|
||
| const rawRoolDatum = await blockfrostAdapter.getDatumByDatumHash( | ||
| pool.datumHash | ||
| ); | ||
| const poolDatum = PoolDatum.fromPlutusData( | ||
| network === "Mainnet" ? NetworkId.MAINNET : NetworkId.TESTNET, | ||
| Data.from(rawRoolDatum) as Constr<Data> | ||
| ); | ||
| return { | ||
| poolState: pool, | ||
| poolDatum: poolDatum, | ||
| }; | ||
| } |
There was a problem hiding this comment.
tl; dr
On preprod testnet, the total liquidity acquired from this poolDatum seems to be incorrect. Can you confirm that the getPoolById info sent into the calculateZapIn is giving a correct estimate?
Example
When accessing the ADA/MIN datum, I get a total liquidity value of 262828735.
When I use this number for calculating the Zap In expected LP with 50 ADA, I get 237,556. That seems correct, but when I submit the zap in order I get back 2,143,510 LP, an order of magnitude difference.
When I look at the datum of the order contract, it's telling me a completely different number for the total liquidity: 8,197,014.
Looking at the datum more closely, it looks like it is operating as a pool with ADA on one side and LP on the other according to the assets in the datum.
It seems to me that the datum is either incorrect for the ADA/MIN pool or a different address needs to be used for the datum. Or theres a bug in how the order contract is storing datum in the pool UTxO.
My main concern is that if the total liquidity is incorrect here, then I won't be able to properly calculate how much I should expect to receive. I could always set the expected liquidity to 1 to ensure my transaction goes thorugh, but I don't like it.
There was a problem hiding this comment.
Heres the completed order transaction for reference:
https://preprod.cardanoscan.io/transaction/75c0646d5879bc3a4318eb4b36582c8b1a6180c2125e12c27fb6cc8d3fc019ce?tab=utxo
Ignore what I have in the datum with an 8 in the minimum receive part. I found a bug in my code that inverted a set of numbers.
There was a problem hiding this comment.
Ah, this also reminds me...
The total_liquidity in the pool datum seems to roughly match the quantity returned when you get the asset info from the asset endpoing:
https://docs.blockfrost.io/#tag/Cardano-Assets/paths/~1assets~1{asset}/get
However, the datum in the pool UTxO doesn't match it at all.
There was a problem hiding this comment.
@theeldermillenial To avoid empty pool, in creating pool transaction, we burned 10 LP Asset of Pool Creator. So the Total Liquidity Pool in the datum is always larger than quantity of LP Asset 10
There was a problem hiding this comment.
@h2physics That accounts for 10LP. What about the order of magnitude difference in LP?
262,828,735 is a big difference compared to 8,197,014.
That seems to be leading to an order of magnitude difference in the estimated zap in deposit.
Testcases: