Conversation
|
To move forward, we’d need the factory address so we can fetch and index all the tokens and pairs (either through events or via a read method). If the protocol has only a single pool instead of a factory setup, then we’d just need the tokens associated with that pool in order to proceed. Could you share whichever of these applies? |
Yes you can use our resolver's function getAllDexes() which will give you the list of dexKey's FluidDexLiteResolver - 0x26b696D0dfDAB6c894Aa9a6575fCD07BB25BbD2C DexKey is a struct which looks like this |
|
I can see everything is being decoded from dex_variables, but could you clarify where we should be fetching dex_variables from? Also, I passed the following input to fetch the dexState from the resolver contract and got an error. Could you share an example or the correct way to query it? Input: Error: |
| # Center price shift data | ||
| 'center_price_shift': 0x0000000000000000000000000000000000019d6228d9dcc28dfffffe688c1fe7, | ||
|
|
||
| # Range shift data (currently not active) |
There was a problem hiding this comment.
I noticed that range_shift and threshold_shift are currently set to inactive (0x00…00). They also don’t seem to be used anywhere in the AMM logic at the moment. Could you clarify if these variables will have any impact on the AMM once they’re activated in the future?
| lower_range_percent = unpacked_vars['lower_percent'] | ||
|
|
||
| if unpacked_vars['range_percent_shift_active']: | ||
| range_shift_data = pool_state['range_shift'] |
Our dex lite has a function called readFromStorage() which will help you read the state Dex Lite Address - 0xBbcb91440523216e2b87052A99F69c604A7b6e00 This code snippets from the resolver should give you context
Which function of the resolver were you trying to use? Btw these are our integration docs, you will find examples for everything here |
| # - Fee collection from trading volume | ||
| # - Stability of stablecoin pairs | ||
| # - Historical performance of similar pools | ||
| return Decimal('0.02') # 2% APY - reasonable for stablecoin pairs |
There was a problem hiding this comment.
Instead of hardcoding APY (e.g. 0.02), we need to calculate it dynamically using a generalized formula based on fees, rewards, and liquidity. Hardcoding won’t work across different pools.
There was a problem hiding this comment.
The APY depends on the volume the pool is getting, not sure how we can calculate it here without access to any historical data
|
We need a unique identifier to store pool info — generally, this is the pool address, but in Fluid DEX Lite there isn’t a pool address and currently the salt for both pools is the same. Could there be a possibility that, in the future, the same token pairs are added with different salts? This would help us understand what key to rely on for uniquely identifying pools in our DB. These are the dexes now. |
Yes its possible to have more than one pool for a pair, they will have different salts. You can use the dexId as the identifier, it is basically the hash of the dexKey bytes8 dexId = bytes8(keccak256(abi.encode(dexKey))); |
|
The quoted amounts and computed amounts are not matching. Here is the code we’re running (based on your implementation): We are using getDexState to fetch all the states, so I’ve removed the bits calculations from the AMM since we are already getting the direct data. Also attaching an image with a few cases where the amounts are deviating. Please review the code and outputs to help resolve the discrepancy. get_amount_out results: 
get_amount_in results: 
8" />
|
|
I think the issue is here 
The resolver returns expanded center price, hence we dont need to expand it again here |
|
get_amount_out is running fine but there are few cases in get_amount_in for which the quoted amounts are None but computed amount is returned from amm logic. Here are the results for your reference. 
Also while testing the actual txn(swapSingle) execution. In this particular case for get_amount_in, the computed get_amount_in is slightly off compared to the on-chain execution. Here is the tenderly simulation you can have a look. For example: In both the above cases, the issue seems to be with get_amount_in. Could you please recheck the logic there? get_amount_out is running fine for both. |
2 participants
Pull Request: Fluid Dex Lite Liquidity Module Integration
Protocol Information
Summary of Integration
Fluid Dex Lite is a sophisticated automated market maker (AMM) protocol that provides:
Unique Features for GlueX:
Implementation Details
Execution Functions Required
All functions interact with the FluidDexLite core contract:
swapSingle()andswapHop()for token exchangesreadFromStorage()for accessing packed dex variables_getPricesAndReserves()for current pricingFunctions Implemented
get_amount_out(): Implements exact constant product formula with:get_amount_in(): Reverse calculation using:amountIn = (amountOut * reserveIn) / (reserveOut - amountOut)fee = ((amountIn * SIX_DECIMALS) / (SIX_DECIMALS - feeBps)) - amountInget_amount_outget_apy(): Returns fixed 2% APY (hardcoded as external API unavailable)get_tvl(): Calculates total value locked by:Dynamic States Required for AMM Calculations
dex_variables: 256-bit packed state containing all pool parameterscenter_price_shift: Time-based price shifting data for rebalancingrange_shift: Dynamic range adjustment parameters (if active)threshold_shift: Threshold shifting data for rebalancing triggersDependencies
N/A - All calculations are self-contained using:
Other Requirements
Test Results
Comprehensive Test Suite: 15/15 Tests Passing ✅
Test Coverage:
Performance Verification (1000 USDC Swap):
Unpacked Dex State Verification:
Edge Cases Tested: