Saludos Hivers. Tomando las palabras de mi amigo @ecoinstant empezaré a redactar una serie de artículos titulados
Hive DEV Issues
Se trata de recopilar información relacionada a cuando estamos desarrollando para el ecosistema #HIVE. La idea es ir haciendo ruido para encontrar respuestas, soluciones e ideas cuando nos encontremos "atorados atrapados o confundidos" mientras tratamos de desarrollar aplicaciones en HIVE.
Comisiones de las piscinas de Liquidez. Fuentes de datos?
Aunque estemos desarrollando la web3, cuya base es y debería ser un sistema decentralizado, deberiamos contar con al menos fuentes de datos confiables. Mientras estoy desarrollando un par de aplicaciones relacionadas con las piscinas de liquidez de HIVE, me encuentro con un detallito:
Ese famoso dato llamado Fee Earned, traducido como "comisión ganada"
Es nada mas y nada menos que lo que se genera en comisiones cuando las monedas de una piscina se "mueven".
Un poco de investigación
Como siempre recomiendo:
En ambos servidores tenemos los canales de "developers" o desarrolladores. Y luego de pasar por allí haciendo pregunta, un buen desarrollador llamado @coininstant me dió un buen pedazo de código para explicarme como calcular las ganancias de una cuenta que tenga posicion en una piscina de liquidez.
El amigo habló de que el calculo seria: la diferencia entre 2 volumenes de transacciones multiplicado por el 0.2%
En teoría eso me llevó a probar la fórmula:
const vDelta = volumenActual - volumenHace24h;
const fees = vDelta * (0.2 / 100)
Mi sopresa es que ese dato no refleja la realidad mostrada en tribaldex.
Calcular, probar, investigar, preguntar y volver a iterar
Esto sería el "pan de cada día" para un desarrollador promedio en HIVE. Me dispuse a revisar los resultados que arroja tribaldex.com para efectos de una piscina de liquidez en un rango de 24h y descubrí dos valores:
0.11% & 0.14%
Esto lo calculas, casi manualmente y esto se leerá como queja casi:
casi manualmente porque tampoco tenemos una API para cosas como esta de las piscinas. Tribaldex tiene una API pero vaya usted a saber que se puede pedir alli además de los SETTINGS Asi que al calcular que ves en esa página, puedes obtener esos numeros.
Otro detalle: dichos valores varíab además si cambias el rango a 7 dias p 30 dias. Eso hace que aparezcan cosas como un fee = 0.7%, entre otros.
Fuente de verdad? Cómo? Cuando?
Si bien es cierto necesitamos empezar a encontrar maneras de tener a dispocisión mucha data que no está abierta a los desarrolladores o que, por algún motivo que desconozco "no tiene documentación apropiada"
Mi solución por ahora?
Pues para uso del index que estoy llevando a cabo, decidi habilitar una ruta o endpoint, para cuando un usuario quiera obtener los fees de una piscina:
http://localhost:3000/public/pool-fees?tokenPair=DEC:SPS&feePercentageBaseToken=0.1&feePercentageQuoteToken=0.15
Y para no comerme más la cabeza decidí dejar que el mismo usuario que pide esa data, pues coloque las Fees de cada token de dicho par.
Tip para descubrir las rutas o APIs que usa una página web
- Navega a la página, por ejemplo #peakd peakd.com.
- Clic derecho sobre cualquier lugar dentro de la página
- Se abre el inspector del navegador. Alli busca la pestaña Network y selecciona la opción "Fetch/XHR"
- Recarga la pagina y obtienes justo allí, las peticiones que la página hace
Esto te permite aprender cuales APIs o endpoints usa la pagina y así usarlos en tus projectos.
ENG:
Greetings Hivers. Taking my friend @ecoinstant's words as a starting point, I'll start writing a series of articles titled
Hive DEV Issues
This is about gathering information related to when we're developing for the #HIVE ecosystem. The idea is to make noise to find answers, solutions, and ideas when we find ourselves "stuck, trapped, or confused" while trying to develop applications in HIVE.
Liquidity Pool Fees. Data Sources?
Even though we're developing Web3, whose foundation is and should be a decentralized system, we should at least have reliable data sources. While developing a couple of applications related to HIVE's liquidity pools, I came across a small detail:
That famous piece of data called Fee Earned, translated as "earned commission."
It's nothing more and nothing less than the amount generated in commissions when coins in a pool are "moved."
A little research
As always, I recommend:
On both servers, we have "developers" channels. After going through them asking questions, a good developer named @coininstant gave me a nice piece of code to explain how to calculate the profits of an account that has a position in a liquidity pool.
The friend said the calculation would be: the difference between two trading volumes multiplied by 0.2%
In theory, this led me to try the formula:
const vDelta = currentVolume - volume24hAgo;
``` const fees = vDelta * (0.2 / 100)
My surprise is that this data doesn't reflect the reality shown in Tribaldex.
Calculate, test, research, ask, and iterate again
This would be the "bread and butter" for an average HIVE developer. I set out to review the results provided by tribaldex.com for the purposes of a liquidity pool over a 24-hour range and discovered two values:
0.11% & 0.14%
You calculate this, almost manually, and this will read as a complaint:
Almost manually because we don't have an API for things like this regarding pools. Tribaldex has an API, but who knows what you can request there besides the SETTINGS So, by calculating what you see on that page, you can get those numbers.
Another detail: these values also vary if you change the range from 7 days to 30 days. That causes things like a fee = 0.7%, among others, to appear.
Source of truth? How? When?
While it's true that we need to start finding ways to make a lot of data available that isn't open to developers or, for some reason unknown to me, "doesn't have proper documentation."
My solution for now?
Well, for the index I'm developing, I decided to enable a route or endpoint for when a user wants to get the fees for a pool:
http://localhost:3000/public/pool-fees?tokenPair=DEC:SPS&feePercentageBaseToken=0.1&feePercentageQuoteToken=0.15
And to avoid further headaches, I decided to let the user who requests that data enter the fees for each token in that pair.
Tip for discovering the routes or APIs used by a web page
- Navigate to the page, for example #peakd peakd.com.
- Right-click anywhere within the page
- The browser inspector opens. There, look for the Network tab and select the "Fetch/XHR" option.
- Reload the page and you'll see the requests the page makes right there.
This allows you to learn which APIs or endpoints use the page and thus use them in your projects.