dexscreener
1.0.0
| Date de rédaction | 9 mai 2024 |
| Mise en œuvre | 13 mai 2024 - 12 juillet 2024 |
| Description | Développer l’intégration open source DEXScreener |
| Auteurs | Sourabh Niyogi et Matthias Funke |
Dexscreener est une interface utilisateur de premier plan pour les traders actifs, résumant l'activité DEX récente. Actuellement, DEXScreener représente Stellaswap (sur Moonbeam) mais a par ailleurs une mauvaise couverture de l'écosystème Polkadot. Cette proposition concerne le développement de Dexscreener dans les 60 prochains jours pour :
On s'attend à ce que d'autres parachains Defi Polkadot puissent utiliser le point final de ceci pour implémenter une indexation DEX similaire pour leur chaîne.
L'implémentation se fera avec un conteneur Docker complètement autonome, avec un indexeur basé sur Node.js utilisant un backend MySQL, suivant la spécification Dexscreener. Un petit nombre de tables block , asset , pair , event seront utilisées pour l'indexation et prendront en charge les 4 points de terminaison suivants
GET /latest-block Renvoie le dernier bloc où les données de /events seront disponibles
{
"block": {
"blockNumber": 12341234,
"blockTimestamp": 1698126147
}
}
blockTimestamp provient de set.timestampGET /asset?id=:string Renvoie des informations sur un actif sur la parachain spécifique. Nous utilisons l' id de la palette assets dans AssetHub (par exemple 1984 pour USDT) ou de la palette assetRegistry dans HydraDX (par exemple 26 pour NODL)
Comment pouvons-nous indiquer à dexscreener quels actifs nous possédons ? Est-ce un point final distinct ?
{
"asset": {
"id": "1000019",
"name": "DED",
"symbol": "DED",
"totalSupply": 10000000,
"circulatingSupply": 900000,
"coinGeckoId": "moonbeam"
}
}
assetRegistry.assets et xyk.poolAssets (nous devons joindre certaines métadonnées hors chaîne, par exemple symbol et coinGeckoId)Quels champs sont facultatifs ? Il se peut qu’il n’y ait pas de coinGeckoId pour tous les actifs, ou que l’offre en circulation ne soit pas connue.
assets.asset et poolassets.asset GET /pair?id=:string Nous convenons que les identifiants seront toujours triés par ordre croissant (en utilisant des nombres et non des chaînes), nous pouvons donc utiliser une chaîne telle que 5-100019 pour la paire d'actifs avec les identifiants 5 et 100019.
L'autre paire n'existe pas.
{
"pair": {
"id": "5-100019",
"dexKey": "hydradx",
"asset0Id": "5",
"asset1Id": "100019",
"feeBps": 30
}
}
id proviendra de xyk.poolAssets ou poolassets.asset , avec asset0Id et asset1ID résolvablesfeeBps pour Hydradx GET /events?fromBlock=:number&toBlock=:numberRenvoie les événements Swap (eventType = swap) et les événements d'ajout/suppression de liquidité au 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 est le ExtrinsicHashtxnIndex est l'ExtrinsicIDmaker est l'adresse SS58 du signataire de l'extrinsèque (DISCUTER : techniquement, le signataire est le preneur)pairId correspond à la pairasset0In et asset1Out sont extraits directement de l'événement. (NON : nous devons mapper le swap routé à la paire)reserves et les événements d'ajout/suppression de pool dans Hydradx omnipool ? Nous nous attendons à ce que Dexscreener relie les utilisateurs directement à une interface d'échange :
et pour les piscines :
Question : Ce point de contact est-il correct ? Nous pensons que cela a des implications sur ce que devraient être l'assetid et le pairid, et contraint directement la question suivante.
L'hypothèse est que la plupart des personnes utilisant dexScreener sont des dégens ou des arbitragistes. Ils ne peuvent pas acheter d’ARNL, donc pouvons-nous prétendre que l’ARNL n’existe pas ? Le seul problème est que certaines transactions seront censurées, mais il existe des situations où les LP sont payés en LRNA, et le LRNA est ensuite échangé contre autre chose.
Question : Comment les métiers complexes doivent-ils être mappés aux événements ?
Nous devons calculer le mappage d'un swap routé vers une ou plusieurs paires, implémenté dans l'indexeur dexscreener. Matthias recommande de créer les paires de manière dynamique en fonction d'un certain seuil de volume, auquel cas il s'agit de savoir quelles paires créer « virtuellement ».
iBTC en USDT pourrait ressembler à ceci :
... Si quelqu'un possède réellement des jetons à 2 ou 4 pools, nous les mappons comme suit :
Exemples HydraDX :
https://hydradx.subscan.io/extrinsic/5081726-2
Devrait ingérer comme : 450,391786 USDT -> 0,15 WETH
https://hydradx.subscan.io/extrinsic/5081141-2
Doit être ingéré sous la forme : 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
Doit afficher : 10799.9040616235 INTR -> 772.6816006249018 4-Pool (force mappée sur USDT*)
Commentaire : dans ce cas, l'utilisateur voulait vraiment posséder 4 pools.
https://hydradx.subscan.io/extrinsic/4705161-3?event=4705161-37
Doit afficher : 8899.9696696365 INTR -> 38.8922321335 vDOT
