Un sistema de apoyo al arbitraje de criptomonedas

UNSISTEMA DE APOYO AL ARBITRAJE DE CRIPTOMONEDAS TRABAJO FIN DE GRADO CURSO 2021-2022 AUTORES ALBERTO BAÑEGIL DÍAZ FRANCISCO JAVIER VEGA MILLET DIRECTOR MANUEL NUÑEZ GRADO EN INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA DE COMPUTADORES FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID Resumen En la actualidad, las criptomonedas son un activo cada vez más frecuente a la hora de comprar y vender, con una gran capitalización de mercado. Las plataformas que ofertan estas criptomonedas, que han aumentado notablemente, ofrecen en ocasiones el mismo activo con diferentes cotizaciones. Es por ello que encontramos interesante aprovechar esta situación para desarrollar un software que de manera automática y empleando técnicas de arbitraje, logre generar un rendimiento económico. Palabras clave Criptomonedas, Blockchain, Arbitraje, Market Making, Aplicación I Abstract Currently, cryptocurrencies are becoming more and more frequently assets in the matter of trading, with a huge market capitalization. Platforms which offer those cryptocurrencies have grown notoriously, and sometimes they offer the same asset with different values. For that, we find it interesting to take advantage of this situation and develop a software which, automatically and using arbitrage techniques, makes profit. Keywords Cryptocurrencies, Blockchain, Arbitrage, Market Making, Application II Índice de contenidos Resumen I Abstract II Índice de contenidos III Índice de figuras V Introducción 1 Motivación 1 Objetivos 1 Plan de trabajo 2 Estructura del proyecto 2 Introduction 5 Motivation 5 Goals 5 Workplan 6 Structure of the project 6 Estado del arte 7 Blockchain 7 Criptomonedas 7 Arbitraje 9 Market Making 10 HummingBot 11 Cctx 14 Metodologías y Tecnologías 15 Metodologías 15 Tecnologías 17 Websockets 17 cURL 17 AWS 17 C++ 17 API Exchange 17 Github 18 III Implementación 19 Algoritmo Principal 19 Estructura del código 21 Experimentación 27 Evaluación 27 Testing 28 Ejemplo de ejecución 28 Contribuciones 31 Contribuciones de Alberto Bañegil Díaz 31 Contribuciones de Javier Vega Millet 32 Conclusiones y Trabajo Futuro 33 Conclusiones 33 Trabajo Futuro 34 Conclusions and future work 37 Conclusions 37 Future Work 38 Bibliografía 41 IV Índice de figuras Figura 3.1 Ejemplo de blockchain 7 Figura 3.2 Cotización del Bitcoin desde su inclusión en Coinmarketcap hasta agosto 8 de 2022 Figura 3.3 Arbitraje a tres puntos 10 Figura 3.4 Diagrama de flujo de arbitraje en HummingBot 12 Figura 3.5 Ejemplo ejecución comando create en Hummingbot 13 Figura 3.6 Ejemplo ejecución comando start en Hummingbot 14 Figura 4.1 Tablero Kanban 16 Figura 5.1 Diagrama de la clase padre Exchange 23 Figura 5.2 Diagrama de las clase hijas de Exchange 24 Figura 6.1 Ejemplo de Orden Simple 29 Figura 6.2 Ejemplo de Orden Compuesta 29 V Capítulo 1 - Introducción Este capítulo sirve como presentación de nuestro trabajo final de grado. Comienza explicando el contexto que motiva la elaboración del proyecto. Posteriormente, enumera los objetivos que se persiguen y la planificación del trabajo. Finalmente, se recoge una breve descripción de la memoria por capítulos. 1.1 Motivación En la actualidad las criptomonedas ocupan un lugar principal entre los activos de compraventa. La cantidad de plataformas online que las ofertan, conocidas como exchanges, no para de crecer. Sin embargo, este crecimiento no ha sido proporcional al número de proveedores de liquidez (o market makers) para estos mercados. Este factor, sumado a que el mercado cripto no cesa su actividad y a su carácter extremadamente volátil, propicia que se puedan encontrar diferentes precios del mismo activo en distintas exchanges. Por ello, hemos detectado la necesidad de una herramienta sencilla y accesible, que genere un rendimiento económico mientras aporta liquidez a los mercados. 1.2 Objetivos El objetivo de este proyecto es desarrollar un software capaz de aprovechar las diferentes cotizaciones de las criptomonedas en las principales exchanges, y por medio de estrategias de arbitraje, conseguir un beneficio económico. Para ello nos centraremos en las monedas con una capitalización suficiente para que tengan liquidez en diferentes plataformas, pero ninguna de las principales (bitcoin, ethereum…) ya que la competencia es mucho mayor y es más complicado encontrar oportunidades. Para conseguir el objetivo inicial, nos hemos propuesto los siguientes subobjetivos: 1 CAPÍTULO 1.Introducción 2 ●Entender el funcionamiento de la tecnología blockchain en las criptomonedas. ●Estudiar arbitraje financiero y sus posibles aplicaciones al mundo cripto. ●Comparar las opciones que existen actualmente en el mercado cercanas a nuestra idea. ●Implementar la solución y comprobar su correcto funcionamiento. 1.3 Plan de trabajo Este proyecto ha sido desarrollado por dos personas a lo largo del curso 2021/2022. Tras las primeras reuniones con el tutor de TFG, se acordó cambiar el tema inicial, “Backtesting de estrategias de inversión creativas”, dándole un enfoque orientado totalmente a las criptomonedas. Pensamos que son tecnologías novedosas que en un futuro pueden tener una adopción masiva, y nos resultó interesante tener la oportunidad de formarnos en este campo durante nuestro TFG. Este proceso comenzó con la labor de investigación y documentación de los diferentes temas a tratar (criptomonedas, arbitraje, market making…), fase que abarcó desde octubre hasta enero. Desde entonces hasta mayo, desarrollamos diferentes funcionalidades de la aplicación, realizando iteraciones progresivas. Finalmente llevamos a cabo la escritura de esta memoria, de manera paralela al testeo final de la aplicación, durante los meses de junio, julio y agosto. Para el reparto de tareas utilizamos la web Trello, adoptando metodologías ágiles como se comenta en la sección 4.1 1.4 Estructura del proyecto Este trabajo está compuesto por 9 capítulos. ●Capítulo 1 Introducción. Se define la motivación del proyecto y los objetivos a alcanzar. ●Capítulo 2 Introduction. Traducción al inglés del Capítulo 1. ●Capítulo 3 Estado del arte. Presenta el contexto tecnológico y el estado del arte. ●Capítulo 4 Metodologías y Tecnologías. Trata las metodologías de desarrollo y las herramientas usadas en el proyecto. CAPÍTULO 1.Introducción 3 ●Capítulo 5 Implementación. Se describe cómo se ha implementado el proyecto en sus diferentes fases de trabajo. ●Capítulo 6 Experimentación. Detalla las pruebas de testing y experimentación llevadas a cabo. ●Capítulo 7 Aportaciones. Aportaciones individuales al proyecto por cada uno de los miembros del equipo. ●Capítulo 8 Conclusiones y trabajo futuro. Cierra el trabajo con las conclusiones obtenidas, además del plan de trabajo para continuar el desarrollo del proyecto. ●Capítulo 9 Conclusions and future work. Traducción al inglés del Capítulo 8. CAPÍTULO 3. Estado del Arte 10 Figura 3.3 Arbitraje a tres puntos Aplicado a nuestro proyecto, utilizaremos un arbitraje a dos puntos para simplificar el desarrollo de la aplicación. Funcionará tal y como se ha explicado: buscaremos la diferencia de cotización de la misma moneda frente al dólar en diferentes exchanges. Nos centraremos en las conocidas como CEX, es decir, exchanges centralizadas [4]. 3.4 Market Making Un market maker es un proveedor de liquidez en mercados financieros. Juega un papel importante ya que ofrece simultáneamente órdenes de compra y de venta para el mismo activo en una exchange. Una analogía para entender el concepto de Market making, adaptada a partir de la documentación de HummingBot, es la siguiente: imaginemos que Juan tiene una guitarra en casa que no usa, y le vendría bien un dinero extra. Por otro lado, María lleva tiempo practicando con la guitarra de un amigo, y ahora cree que conoce lo suficiente para invertir en comprarse una, pero no quiere gastarse demasiado en una nueva. En este contexto, una casa de empeño podría ofrecer un servicio entre Juan y María; ofrece una manera de comprar/vender el activo a un precio justo (genera liquidez). La casa de empeño recibe la diferencia de precio (spread) entre el precio al que vende Juan y al que compra María, y lo reduce. CAPÍTULO 3. Estado del Arte 11 Por otro lado, el market maker necesita de variedad de activos en una exchange para funcionar, ya que están continuamente realizando operaciones de compraventa. Los activos de medio-baja capitalización de mercado no tienen la liquidez necesaria para que los bots regulen el spread y por lo tanto no se reduce ni aumenta el volumen de mercado. Por ello, hay que encontrar el equilibrio en las monedas con el suficiente volumen de mercado para poder emplear técnicas de arbitraje, pero alejados de las principales criptomonedas que predominan en el mercado, ya que la competencia para encontrar oportunidades es mucho mayor. Una vez analizados tanto el arbitraje como el market making de criptomonedas, destacamos dos opciones que actualmente realizan algo similar a nuestro software: el software HummingBot y la librería CCTX. 3.5 HummingBot Hummingbot [5] es un cliente software que permite al usuario crear y personalizar negociaciones de criptoactivos. Para ello, ofrece una interfaz en línea de comandos, donde el usuario puede programar bots de arbitraje que funcionen tanto en CEX (e.g. Binance), como en exchanges descentralizadas o DEX (e.g. Uniswap). El arbitraje en HummingBot sigue cuatro fases diferenciadas, que son las siguientes: 1. Lo primero es realizar tres comprobaciones para garantizar el correcto funcionamiento del sistema. Estas son: a. Comprobar que el sistema se encuentra conectado a los dos mercados en los que se va a comprar y vender. b. Comprobar que no hay órdenes pendientes de venta en el mercado en el que queremos realizar la operación. c. Comprobar que no ha habido un trade de arbitraje recientemente. Es necesario porque en ocasiones los exchanges tardan en refrescar el precio al que cotizan los activos. 2. Tras estas comprobaciones, se procede a buscar la oportunidad de arbitraje, que se producirá si en dos exchanges diferentes el mismo par tiene precios diferentes. CAPÍTULO 3. Estado del Arte 12 3. A continuación debemos calcular el tamaño óptimo de la orden de arbitraje. Estas oportunidades siempre tienen un tamaño limitado, porque según compres en el libro de ventas, el precio aumentará. De igual forma, según vendas en el libro de compras, cada vez venderás a un precio más bajo. Así, llegará un punto en el que el arbitraje no será posible. La estrategia de arbitraje analizará las órdenes de ambos libros para calcular el tamaño óptimo de arbitraje. Por último, se comprobará que se tienen fondos suficientes para ejecutar las órdenes seleccionadas. 4. El paso final es ejecutar ambas órdenes a la vez. Esto es así porque estas oportunidades no son fáciles de encontrar y son rápidamente explotadas por los traders. Este proceso se resume en la figura 3.3, un diagrama de flujo del funcionamiento del arbitraje en HummingBot. Figura 3.4 Diagrama de flujo de arbitraje en HummingBot CAPÍTULO 3. Estado del Arte 13 En la figura 3.4 se observa un ejemplo de ejecución del comando create, con el cual se crea un bot de arbitraje. Para ello se indica la estrategia que se quiere utilizar, en nuestro caso arbitraje, las exchanges y los pares que utilizará, así como el mínimo beneficio requerido para ejecutar una orden. Finalmente, la configuración se guarda en un archivo .yml. Figura 3.5 Ejemplo ejecución comando create en Hummingbot Al ejecutar el comando start, las órdenes se crearán en ambas exchanges, y el bot estará preparado para cuando encuentre la oportunidad de arbitraje con los parámetros que incluimos en la configuración (Figura 3.5). CAPÍTULO 3. Estado del Arte 14 Figura 3.6 Ejemplo ejecución comando start en Hummingbot 3.6 Cctx CCXT [6] es una de las bibliotecas de código abierto más avanzadas para realizar trading con criptomonedas, y fue diseñada pensando en un perfil de trader con conocimientos técnicos y con habilidades para el desarrollo de código. Su desarrollo inicial fue en JavaScript,y posteriormente se compatibilizó para PHP y Python. La biblioteca ofrece a los desarrolladores una base sólida para construir y emplear algoritmos de trading de acuerdo con sus objetivos, necesidades y deseos. [7]. Actualmente soporta ciento dieciséis exchanges, estando 13 de ellas certificadas para su uso en CCTX por la propia entidad Capítulo 4 - Metodologías y Tecnologías En este capítulo analizaremos la metodología Kanban, que ha sido la elegida para el desarrollo de nuestro proyecto, así como las diferentes tecnologías que hemos utilizado. 4.1 Metodologías Siendo un proyecto realizado por dos personas, hemos creído conveniente utilizar una metodología ágil. En nuestro caso hemos optado por Kanban que está basada en una filosofía de mejora continua. Las tareas se seleccionan de una lista de acciones pendientes en un flujo de trabajo constante. [8] El uso de una metodología ágil como Kanban fomenta una planificación flexible y la mejora continua del proyecto ya que el desarrollo es evolutivo. De esta manera, hemos podido adaptar nuestros objetivos y metas de manera más sencilla. Ha sido útil a la hora de planificar nuestro trabajo, ya que permite paralelizar tareas del desarrollo del código, del testing y de la escritura de la memoria. 15 CAPÍTULO 4. Metodologías y Tecnologías 16 Figura 4.1 Tablero Kanban Como se aprecia en la figura 4.1, nuestro tablero Kanban tiene 5 columnas: ●To Do: muestra las tareas pendientes que no se han iniciado. ●In Progress: son aquellas tareas en las que nos encontramos trabajando en el momento. ●Ready For Testing: las tareas listas para comprobar su correcto funcionamiento. ●Testing: aquellas tareas que estamos probando. ●Done: son las tareas ya finalizadas. Además, también se puede apreciar el código de colores que tienen las etiquetas: ●Tareas que requieren de investigación, previas al desarrollo ●Tareas relacionadas con el desarrollo del código ●Tareas relacionadas con la escritura de la memoria CAPÍTULO 4. Metodologías y Tecnologías 17 4.2 Tecnologías Para el desarrollo de la aplicación han sido necesarias tecnologías de diferente índole. La suma de todas ellas hacen funcionar el software. 4.2.1 Websockets WebSockets, hace posible abrir una sesión de comunicación interactiva entre el navegador del usuario y un servidor. La ventaja de las conexiones bidireccionales, es su rapidez. Con esta API, se puede enviar mensajes a un servidor y recibir respuestas controladas por eventos sin tener que consultar al servidor para una respuesta. [9] 4.2.2 cURL cURL es un proyecto de software consistente en una biblioteca (libcurl) y un intérprete de comandos (curl) orientado a la transferencia de archivos. Soporta diferentes protocolos, entre ellos HTTPS, el que hemos utilizado[10] La principal utilidad de cURL es automatizar el envío de archivos y concatenar acciones sin supervisión. 4.2.3 AWS Amazon Web Services (AWS) es un conjunto de herramientas y servicios de cloud computing de Amazon. Los más de 200 servicios de centros de datos que ofrece globalmente, sumado a la madurez del servicio en comparación con su competencia, hacen de AWS la opción mayoritaria del mercado [11]. 4.2.4 C++ Ha sido uno de los lenguajes de programación con los que más hemos trabajado a lo largo del grado, y es por eso que hemos decidido utilizarlo para implementar nuestra aplicación. 4.2.5 API Exchange Una API es una interfaz que reúne un conjunto de funciones y métodos, accesibles para otras aplicaciones. En nuestro caso, hemos utilizado las API de CAPÍTULO 4. Metodologías y Tecnologías 18 diferentes CEX, en total 19. Entre ellas destacan Binance, Kucoin, Gate.io o Ascendex. Tras su estudio, las hemos conectado a nuestra aplicación para llevar a cabo las órdenes de compraventa automáticamente 4.2.6 Github Es una plataforma de alojamiento que posibilita crear repositorios de código y mantenerlos en la nube, ya sea con visibilidad privada o pública, de manera segura. Es la principal plataforma del tipo que hemos usado a lo largo de la carrera, y por ello hemos decidido utilizarla para subir nuestra versión final del proyecto. Capítulo 5 - Implementación Este capítulo explica cómo se ha llevado a cabo la implementación de nuestro proyecto, analizando para ello el algoritmo principal y la estructura del código y sus principales clases. Al comienzo de la implementación se decidió usar un fichero, donde venía cada par(por ejemplo BTC-USDT), y a continuación, se indicaba en qué exchanges estaba ese par. Dicho método no era demasiado efectivo, ya que el programa solo funcionaba con los pares que estaban en el fichero, y el fichero estaba escrito y actualizado a mano; en definitiva, poco eficiente. Se decidió cambiar esta parte, por algo más dinámico y en tiempo real, reemplazándolo por un programa que primero pregunta con qué par quieres operar, y a continuación envía una petición HTTP a cada exchange en ese mismo momento. Estas responden si ese par está o no. A continuación, explicamos el funcionamiento del algoritmo principal. 5.1 Algoritmo Principal El algoritmo principal funciona de la siguiente manera: en primer lugar, se comprueba que el exchange que tiene el mínimo ask es menor que el exchange que tiene el máximo bid. Con un valor constante de diferencia de 0.01%, aunque este valor podría ser de nuestra elección. Se simula, para esos dos exchanges, la máxima cantidad que se podría negociar, siendo la diferencia entre sus precios mayor que 0.01%. Si el proceso acaba aquí tendríamos una “single order”. Una vez simulados, si todavía hay dos exchanges cuya diferencia de precios es mayor que 0.01%, se vuelve a repetir el proceso con el mínimo ask de el siguiente exchange, con el máximo bid del siguiente exchange, o con ambos. Tendríamos una “multiple order”. 19 CAPÍTULO 5. Implementación 26 ●Exmo: https://documenter.getpostman.com/view/10287440/SzYXWKPi ●FMFV https://api.fmfw.io/ ●FTX: https://docs.ftx.com/#overview ●Gate.io: https://www.gate.io/docs/developers/apiv4/en/ ●Hitbtc: https://api.hitbtc.com/ ●Huobi: https://huobiapi.github.io/docs/spot/v1/en/#change-log ●Kucoin: https://docs.kucoin.com/#general ●Lbank: https://github.com/LBank-exchange/lbank-official-api-docs/blob/master/ API-For-Spot-EN/Trading%20REST%20API.md ●Nominex: https://developer.nominex.io/#general-api-information ●OKX: https://www.okx.com/docs-v5/en/#overview ●Poloniex: https://docs.poloniex.com/#introduction ●Whitebit: https://github.com/whitebit-exchange/api-docs Capítulo 6 - Experimentación Tras tener una versión funcional de nuestra aplicación por línea de comandos, este capítulo explica las diferentes pruebas que llevamos a cabo para verificar su correcto funcionamiento. 6.1 Evaluación La estrategia elegida e implementada se basa en la baja latencia. En la evaluación de nuestro software influyen factores expuestos a continuación: La ubicación en la que el programa es ejecutado es crucial. Se sabe que la mayoría de los exchanges de criptomonedas están actualmente en Asia. Esto provoca que si el programa se ejecuta desde España, el websocket se desconecta más fácilmente (por ejemplo una conexión en Asia puede durar de 12 a 24 horas, en España, de 1 a 24 h). Cada mensaje enviado por websocket es un “paquete”, y si la ubicación es muy lejana hay más probabilidades de una pérdida de paquetes, con resultados potencialmente catastróficos para nuestros intereses. Potencia procesador: este programa en concreto, utiliza un thread por cada exchange, por lo que requiere potencia de procesador. Se puede ejecutar perfectamente en ordenadores que sólo tengan 1Core-1Thread concurrentemente, pero podría ralentizar la recogida de datos en tiempo real. El software: se ha procurado que la potencia de este software sea lo más rápida posible, usando websockets de Boost, estructuras de datos de la STL, y el algoritmo principal del main. Simples detalles como compilar con la opción -O3 en gcc también son importantes. Se ha optado por gcc en vez de Clang u otros compiladores simplemente por familiarización con el debugger de gcc, pero se puede compilar con el compilador que desee el usuario. Estos 3 factores son determinantes a la hora de testear y evitar situaciones perjudiciales como la pérdida de paquetes o una latencia alta. Este último caso podría ocasionar que otra persona se adelantara en la oportunidad de arbitraje, o que el orderbook no estuviera correctamente actualizado. 27 CAPÍTULO 6. Experimentación 28 6.2 Testing Hemos analizado nuestro software en multitud de escenarios, probando en distintas ubicaciones y utilizando diferentes procesadores. Dado que hay infinitas combinaciones, mencionaremos las más óptimas. El sistema ha sido testeado en los servidores de Amazon AWS con instancias EC2, en ubicaciones como Tokyo, Osaka, Singapur, o Corea del Sur, también en China, pero esta última ubicación conlleva muchos inconvenientes que hace que no sea óptima en ningún caso. Se ha probado con procesadores de 1 a 4 cores, siendo suficiente usar 2 cores de última generación, aunque se recomiendan 4. Con las condiciones expuestas, el sistema puede generar en torno a un 70% de aciertos, teniendo cada acierto una media de profit de 0.10€ y cada pérdida una media de -0.10€. Esta estadística es de datos diarios, no se ha probado más de un día seguido por temas económicos. El sistema tiene dos variantes, Single Order, el más básico y fiable y Multiple Order, más arriesgado y a la vez proporciona más beneficio. El riesgo es debido a que es común que los orderbooks de cada exchange sean mezclas a su vez de orderbooks de otros exchanges. Por ejemplo, el orderbook de Kucoin es un conjunto de orderbooks de Binance, Ftx, Gateio y su propio orderbook, y cuando mandas una orden de compra a Kucoin, Kucoin puede hacer de intermediario, mandando esa orden a Binance. Dicho fenómeno requiere un research de optimización más amplio que excede este TFG. 6.3 Ejemplo de ejecución Con esta sección se pretende ilustrar la funcionalidad principal de nuestra aplicación. Tras ejecutar el programa, el cliente introduce la criptomoneda con la que va a operar y a continuación se muestran las exchanges en las que el par con USD está activo de dicha criptomoneda. En el siguiente link se puede ver un ejemplo de ejecución con la opción de DEBUG activada, en la que se pueden ver la menor diferencia de precio entre exchanges, teniendo en cuenta las comisiones. Tras cada orden ejecutada, se muestra por pantalla en qué exchange se ha comprado y vendido además del profit de la operación, del total, del volumen movido por el software y el contador de aciertos CAPÍTULO 6. Experimentación 29 (operaciones en las que el profit es positivo) y pérdidas (operaciones en las que el profit es negativo) https://drive.google.com/file/d/196-KrAptWkWNxWOX1-WLKwBDK77STMYC/view?usp=s haring Figura 6.1 Ejemplo de Orden Simple Figura 6.2 Ejemplo de Orden Compuesta CAPÍTULO 6. Experimentación 30 Capítulo 7 - Contribuciones 7.1 Contribuciones de Alberto Bañegil Díaz En un principio este TFG era demasiado ambicioso. Como no sabíamos demasiado sobre el tema, queríamos incluir las DeFi(Finanzas Descentralizadas), no sólo como tema sino para añadirlo a nuestro programa de ejecución. Una vez hecho, me di cuenta que era un tema demasiado extenso, y un campo en actual desarrollo, quizás poco maduro como para crear una aplicación en condiciones, además de que requiere aprender nuevos paradigmas y lenguajes de programación como Solidity, Vyper o Rust. Empecé a crear el esqueleto y la base de lo que sería el código de la aplicación, la parte de conectividad a los exchanges en el fichero exchange.h, el algoritmo principal de ejecución, en el fichero main.cpp y la estructura de datos general. Los capítulos 5 Implementación, 6 Experimentación y 8 Conclusiones y Trabajo Futuros fueron escritos de manera conjunta. Empecé implementando cada exchange, para más tarde hacerlo de manera conjunta. 31 CAPÍTULO 7. Contribuciones 32 7.2 Contribuciones de Javier Vega Millet Durante las primeras semanas del proyecto, tuve que familiarizarme con conceptos de economía como el arbitraje y sus diferentes tipos, y market making. Posteriormente, cuando decidimos que el proyecto estaría dedicado exclusivamente al arbitraje de criptomonedas, investigué acerca del tema. Cursar la asignatura optativa Introducción a la tecnología blockchain resultó de gran utilidad, así como la documentación de Hummingbot para terminar de entender cómo funciona el arbitraje de criptomonedas. Tras tener la primera versión funcional del software (mediante el fichero para los pares), colaboré en las pruebas de testing. Después decidimos cambiar el proceso de selección de pares para automatizarlo, donde programé las peticiones https correspondientes y ayudé a programar algunos exchanges y su conectividad. Por último, en cuanto a la memoria he escrito los capítulos 1 de Introducción, con su correspondiente traducción en el capítulo 2, 3 del Estado del arte, 4 de Metodologías y Tecnologías. Los capítulos 5 Implementación, 6 Experimentación y 8 Conclusiones y Trabajo Futuros fueron escritos de manera conjunta. Capítulo 8 - Conclusiones y Trabajo Futuro En este capítulo final, se revisarán las conclusiones obtenidas a lo largo del desarrollo del proyecto, así como los posibles aspectos a mejorar en los próximos años. 8.1 Conclusiones Este trabajo de fin de grado tenía como objetivo principal el desarrollo de un software capaz de generar un rendimiento económico en el trading de criptomonedas mediante el uso de técnicas de arbitraje. Una vez finalizada su implementación y en vista de las diferentes pruebas realizadas, no podemos concluir que nuestro proyecto sea rentable a largo plazo. Sí hemos observado que la proporción de acierto es cercana al 70%, pero a pesar de ello hay que tener en cuenta más factores como: Comisiones exchanges: esta parte es un pilar fundamental ya que cuanto más volumen generes en el exchange, menores serán tus comisiones. A medida que tus comisiones bajen, no necesitarás llegar el primero, por lo que es proporcional a la latencia que necesitas(cuanto menos dinero tienes, más rápido tienes que ser) Maker o Taker?: Este TFG se basa en una estrategia de Taker. El Taker lanza órden a mercado directamente, el Maker lanza una “limit order” al orderbook, por lo que no se ejecuta necesariamente al instante, pueden pasar incluso días si la órden está muy alejada del precio actual. Las estrategias Taker son las más simples, pero a la vez incurren en más costos de comisión, mientras que las estrategias maker (market-making) son más complejas pero incurren en menos costos de comisión. Withdrawal fee: Este es el principal problema por el que se necesita una gran cantidad inicial para cada par en cada exchange. Si en un futuro mejorase, mejoraría proporcionalmente la cantidad requerida inicial. Para ilustrar este factor, proponemos el siguiente ejemplo. En primer lugar, se necesita el requisito de tener las mismas cantidades del par a operar en cada exchange que se opere. Para simplificar usaremos solo 2 exchanges y supondremos 1 ETH=2500€. Tenemos 5000€ y 2ETH en 33 CAPÍTULO 8. Conclusiones y Trabajo Futuro 34 Exchange1, tenemos 5000€ y 2ETH en Exchange2 (se podría tener €10K en Exchange1 y 4ETH en exchange2, en caso de tener una estadística que indique que siempre se compra en Exchange1 y siempre se vende en Exchange2). Siguiendo con el ejemplo, si el bot ejecuta una operación de arbitraje en la que compra con 5000€ en Exchange1 y vende con 2ETH en Exchange2, el balance sería el siguiente: 4ETH en Exchange1 y 10.000€ en Exchange2. El bot ya no es capaz de ejecutar la misma operación, ya que en Exchange1 no quedan € y en Exchange2 no quedan ETH, hay que hacer un withdrawal para volver al estado anterior. Esta operación ha generado 5€ de beneficio(10.000€ * mediaDifPrecio, donde mediaDifPrecio es 0.05%). El problema es que hacer una transferencia en la red Ethereum actualmente cuesta entre 10€ y 40€, por lo que el withdrawal se come el beneficio obtenido. Hay chains como BSC, Solana y muchas otras en las que el withdrawal está entre 1€ y 5€, lo que haría que el balance feeWithdrawal/beneficio acabase en positivo. Por otro lado, durante el proceso hemos aprendido y profundizado en conceptos de economía como el arbitraje y el market making. Además, hemos ampliado nuestros conocimientos acerca de las criptomonedas, e investigado herramientas como Hummingbot que nos han aportado mucho tanto en aspectos estructurales como técnicos. En el desarrollo propiamente dicho del software, hemos puesto en práctica los contenidos adquiridos en las asignaturas de Fundamentos de la Programación, al programar en C++ nuestro código, Tecnología de la Programación para la jerarquía de clases y el uso de herencia e Ingeniería del Software, adoptando metodologías ágiles para el desarrollo. Hemos utilizado cerrojos en la implementación de las clases de las exchanges, vistos en Sistemas Operativos, y también nos fue de ayuda la asignatura de Ampliación de Sistemas Operativos y Redes para la programación de Sockets y conocer los diferentes protocolos. 8.2 Trabajo Futuro El proyecto cuenta con varios frentes de trabajo por los que se podría ampliar y mejorar el software. El trabajo realizado se corresponde con un esqueleto del proyecto final, pero no es una aplicación completamente funcional. Para lograrla, se trabajará en los próximos años en los siguientes aspectos: CAPÍTULO 8. Conclusiones y Trabajo Futuro 35 Estrategia Maker. Sería interesante ampliar dicho sistema con estrategias maker, con limit orders en vez de market orders, o hacer una mezcla de ambas, para así incurrir en menos comisiones. Añadir exchanges descentralizadas. Siguiendo la filosofía descentralizadora del blockchain, añadir exchanges descentralizadas podría ser una opción interesante. Para lograrlo, sería necesario aprender lenguajes de programación como Solidity, Go o Rust. Solidity para la red Ethereum y diferentes EthereumVirtualMachines como Avalanche o BinanceSmartChain, Go y Rust para nuevos conceptos de DeFi como Cosmos y Polkadot, que pretenden ser una Chain que englobe a todas. Actualmente en el mundo DeFi y en las exchanges descentralizadas en general, están habiendo muchas oportunidades de arbitraje creativas como FrontRunning de operaciones o liquidaciones, flash loans, Maximal extractable Value y muchos otros conceptos. Todos ellos requieren de un estudio profundo, además de habilidad para levantar tu propio nodo en cada chain. En definitiva, es otro concepto totalmente distinto de arbitraje al que estamos acostumbrados a ver en CEXs o finanzas tradicionales. Wikipedia URL: https://es.wikipedia.org/wiki/Arbitraje_(econom%C3%ADa) Pole, A. (2021) Statistical Arbitraje: Algorithmic Trading Insights and Techniques Ehrman, Douglas S. (2006) The Handbook Of Pairs Trading. Strategies Using Equities, Options, and Futures Ernest P. Chan (2013) Algorithmic Trading