dexscreener
1.0.0
| Fecha redactada | 9 de mayo de 2024 |
| Implementación | 13 de mayo de 2024 - 12 de julio de 2024 |
| Descripción | Desarrollar la integración de DEXScreener de código abierto |
| Autores | Sourabh Niyogi y Matthias Funke |
Dexscreener es una interfaz de usuario líder para comerciantes activos, que resume la actividad reciente de DEX. Actualmente, DEXScreener representa a Stellaswap (en Moonbeam), pero por lo demás tiene una cobertura deficiente del ecosistema de Polkadot. Esta propuesta se refiere al desarrollo de Dexscreener en los próximos 60 días para:
Se espera que otras paracaídas defi Polkadot puedan utilizar el punto final de esto para implementar una indexación DEX similar para su cadena.
La implementación se realizará con un contenedor Docker completamente autónomo, con un indexador basado en Node.js utilizando un backend MySQL, siguiendo la especificación Dexscreener. Se utilizará una pequeña cantidad de tablas, block , asset , pair y event para la indexación y admitirá los siguientes 4 puntos finales
GET /latest-block Devuelve el último bloque donde estarán disponibles los datos de /events
{
"block": {
"blockNumber": 12341234,
"blockTimestamp": 1698126147
}
}
blockTimestamp es de set.timestampGET /asset?id=:string Devuelve información sobre un activo en la parachain específica. Usamos la id de la paleta assets en AssetHub (por ejemplo, 1984 para USDT) o la paleta assetRegistry en HydraDX (por ejemplo, 26 para NODL).
¿Cómo le decimos a dexscreener qué activos tenemos? ¿Es ese un punto final separado?
{
"asset": {
"id": "1000019",
"name": "DED",
"symbol": "DED",
"totalSupply": 10000000,
"circulatingSupply": 900000,
"coinGeckoId": "moonbeam"
}
}
assetRegistry.assets y xyk.poolAssets (necesitamos unir algunos metadatos fuera de la cadena, por ejemplo, símbolo y coinGeckoId)¿Qué campos son opcionales? Es posible que no haya un coinGeckoId para todos los activos o que no se conozca el suministro circulante.
assets.asset y poolassets.asset GET /pair?id=:string Aceptamos que los ID siempre se ordenarán en orden ascendente (usando números, no cadenas), por lo que podemos usar una cadena como 5-100019 para el par de activos con ID 5 y 100019.
El otro par no existe.
{
"pair": {
"id": "5-100019",
"dexKey": "hydradx",
"asset0Id": "5",
"asset1Id": "100019",
"feeBps": 30
}
}
id será de xyk.poolAssets o poolassets.asset , con asset0Id y asset1ID resolubles.feeBps de Hydradx? GET /events?fromBlock=:number&toBlock=:numberDevuelve eventos de swap (eventType = swap) y eventos de liquidez para agregar/eliminar pool
{
"events": [
{
"block": {
"blockNumber": 12344321,
"blockTimestamp": 1673319600
},
"eventType": "swap",
"txnId": "0x1118d6bde171a4df1238f5eb69c4b9fff4d4e0169c91268dfa3661d6571faea9",
"txnIndex": 3,
"eventIndex": "12344321-5",
"maker": "7KjNuVyjY5Jv3znWGXSBBHt7Ls6Uwm1LmhswrGGDSYNUAwKW",
"pairId": "5-100019",
"asset0In": 10000,
"asset1Out": 20000,
"priceNative": 2,
"reserves": { "asset0": 100, "asset1": 50 }
},
...
]
}
txnID es el ExtrinsicHashtxnIndex es el ID extrínsecomaker es la dirección ss58 del firmante del extrínseco (DISCUSIÓN: técnicamente el firmante es el tomador)pairId coincide con el pairasset0In y asset1Out se toman directamente del evento. (NO: necesitamos asignar el intercambio enrutado al par)reserves y eventos de agregar/eliminar grupos en Hydradx omnipool? Nuestra expectativa es que Dexscreener vincule a los usuarios directamente a una interfaz de intercambio:
y para piscinas:
Pregunta : ¿Es correcto este punto de contacto? Creemos que esto tiene implicaciones sobre cuál debería ser el activeid y el pairid, y limita directamente la siguiente pregunta.
Se supone que la mayoría de las personas que utilizan dexScreener son degens o arbitrajistas. No pueden comprar LRNA, por lo tanto, ¿podemos fingir que LRNA no existe? El único problema es que algunas transacciones serán censuradas, pero hay situaciones en las que los LP se pagan en LRNA y luego el LRNA se cambia por otra cosa.
Pregunta: ¿Cómo se deben asignar las operaciones complejas a los eventos?
Necesitamos calcular el mapeo de un intercambio enrutado a uno o más pares, implementado en el indexador dexscreener. Matthias recomienda que creemos los pares dinámicamente en función de algún umbral de volumen, en cuyo caso es una cuestión de qué pares crear "virtualmente".
iBTC a USDT podría quedar así:
... Si alguien realmente tiene tokens de 2 o 4 grupos, los asignamos de la siguiente manera:
Ejemplos de HydraDX:
https://hydradx.subscan.io/extrinsic/5081726-2
Debe ingerir como: 450.391786 USDT -> 0.15 WETH
https://hydradx.subscan.io/extrinsic/5081141-2
Debe ingerir como: 500 USDT -> 0.00808666 WBTC
https://hydradx.subscan.io/extrinsic/5080488-0
80.9981538781 vDOT > 51616.002281331759 HDX
https://hydradx.subscan.io/extrinsic/4589219-2?event=4589219-13
Debería mostrar: 10799.9040616235 INTR -> 772.6816006249018 4-Pool (fuerza asignada a USDT*)
Comentario: en este caso el usuario realmente quería tener 4-pool.
https://hydradx.subscan.io/extrinsic/4705161-3?event=4705161-37
Debería mostrar: 8899.9696696365 INTR -> 38.8922321335 vDOT
