Bitcoin Novatos

A la hora de reflejar los pools de liquidez dentro de Cointracking nos encontramos ante serios problemas dado que la herramienta lo hace de manera incorrecta y requerirá de nuestra pericia para subsanarlo.

Primero y antes que nada, repasemos lo más básico para que nos sea más sencillo comprender la problemática a la que nos enfrentamos.


¿Qué es un pool de liquidez?
Cuando hablamos de pools de liquidez, nos referimos a la delegación de fondos a un tercero o en un contrato inteligente con la intencionalidad de obtener rendimientos a cambio. El evento ocurre del siguiente modo:

Fase 1, delegación de criptoactivos

• Envío al pool de liquidez del criptoactivo 1.
  
• Envío al pool de liquidez del criptoactivo 2.
  
• Llegada de un token de resguardo a la billetera origen que atestigua la llegada de los criptoactivos al pool de liquidez.
  
• Recepción del criptoactivo 1 en el pool de liquidez.
  
• Recepción del criptoactivo 2 en el pool de liquidez.
  

Fase 2, obtención de rendimientos

• Cuando el usuario lo reclame, generara una llegada de rendimientos a la billetera que posea el token de resguardo.
  
  
  

Fase 3, recuperación de criptoactivos delegado

• Quema del token de resguardo.
  
• Salida del criptoactivo 1 del pool de liquidez.
  
• Salida del criptoactivo 2 del pool de liquidez.
  
• Llegada del criptoactivo 1 a la billetera que poseia el token de resguardo.
  
• Llegada del criptoactivo 2 a la billetera que poseia el token de resguardo.
  
• Entrega de los rendimientos pendientes no reclamados.
  

Adicionalmente, nos encontraremos que este producto tiene una particularidad extremadamente importante y es que, no volverán la misma cantidad de criptoactivos delegados a causa del impermanent-loss*.

*El impermament-loss es un suceso que ocurre dentro de los pools de liquidez. Al proveer liquidez es muy probable que uno de los dos activos delegados tenga mayor demanda que el otro, y, a causa de que se esté suceso, el proveedor de liquidez siempre se quedará con más cantidad del activo con baja demanda (generalmente en términos estadísticos el que menos se haya revaluado o el que más haya decrecido, según la situación de mercado), formando parte del riesgo de su inversión.



¿Cómo refleja este evento Cointracking?
Aquí es donde comienza el problema, dado que en la práctica nos facilita 3 métodos para reflejar lo anterior y que todos desde un punto de vista fiscal y contable son incorrectos, veamos uno a uno en que problemas incurre y que los causa:

1. Representación de liquidez tipo 1 "taxable"
   
2. Representación de liquidez tipo 2 "non-taxable"
   
3. Representación de liquidez tipo 3 "antigua"
   
4. Representación de liquidez tipo 4, "real"
   

¿Necesitas ayuda para realizar estos cambios? Puedo ayudarte personalmente, haz clic aquí para saber más.

¿Cómo se utiliza este método?
Para utilizar este método debemos simplemente sincronizar la billetera sin realizar ninguna acción adicional. Es la que Cointracking nos suministra por defecto.
 




¿Cómo se refleja en Cointracking la liquidez tipo 1 "taxable"?
Cointracking emplea el siguiente método para trasladar lo ocurrido utilizando este método:

Fase 1, delegación de activos

• Otros gastos del criptoactivo 1 delegado.
  
• Otros gastos del criptoactivo 2 delegado.
  
• Ingreso no imponible del token de resguardo.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses, cuando lleguen saldos a causa de que se haya hecho el reclamo manualmente por parte del usuario.
  
  

Fase 3, recuperación de activos delegados

• Gasto no imponible del token de resguardo.
  
• Ingreso no imponible del criptoactivo 1 delegado.
  
• Ingreso no imponible del criptoactivo 2 delegado.
  

Ejemplo:

• Hemos dispuesto de liquidez 50 BNB y 10000 USDT, siendo el valor de cada uno de los activos 10.000 €.
  
• Reclamemos una sola vez intereses por valor de 7 BNB.
  
• Al desmontar la liquidez recibimos 55 BNB y 9500 USDT, siendo el valor de cada uno de los activos a su vuelta 9500 €.
  

Fase 1, delegación de activos

• Otros gastos del 50 BNB.
  
• Otros gastos del 10000 USDT.
  
• Ingreso no imponible de 1 LP-1551.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses, 7 BNB.
  
  

Fase 3, recuperación de activos delegados

• Gasto no imponible de 1 LP-1551.
  
• Ingreso no imponible de 55 BNB.
  
• Ingreso no imponible 9500 USDT.
  

¿Cuáles son los errores de este método?
Este método incurre en los siguientes errores.
 

1. Esconde perdidas o beneficios latentes.
   Si revisamos los valores del ejemplo anterior, veremos como esconde perdidas patrimoniales que no han sido deducidas. Saquemos la calculadora:
   
   • A su delegación aportamos 50 BNB y 10.000 USDT, teniendo un valor conjunto de 20.000 €.
     
   • A su recuperación vuelven 55 BNB y 9500 USDT, teniendo un valor conjunto de 19.000 €
     
   • La perdida patrimonial incurrida de los 20.000 a los 19.000 € de 1.000 € de valuación nunca llega a ser consolidada, gasta los 20.000 con el atributo, otros gastos, pero al hacer nacer los 19.000 con ingreso no imponible queda en el limbo.
     El token de resguardo no ejecuta esta perdida al ser gastada con gasto no imponible y, adicionalmente, Cointracking en la mayor parte de casos, tampoco le atribuye el valor correcto automáticamente para en el caso de que tuviese el atributo gasto (y no "gasto no imponible") apareciese esa perdida.
     
     
     
2.  Interpreta como una operación de venta los activos delegados, provocando consolidación de la totalidad de los beneficios.
   Al gastar los dos activos mediante el uso del atributo "otros gastos", está consolidando beneficios o perdidas latentes. No está efectuando un tratamiento fiscal de delegación empleando retiradas y depósitos que no tendría gravamen fiscal, sino que, lo considera como una permuta de venta de los criptoactivos a cambio de la compra de un token de liquidez.
   
   
   
3. Puede afectar a la norma anti aplicación
   La normativa anti aplicación, conocida vulgarmente como norma "anti-recompra", tiene como finalidad prevenir la práctica de ejecutar una venta a perdidas y recomprar inmediatamente en tal de rebajar la factura fiscal manteniendo la misma cantidad de activos.
   
   Al aplicar la interpretación que realiza este método, tal y como hemos explicado en el apartado anterior que interpreta que existe una alteración patrimonial por transmisión por utilizar los dos criptoactivos como pago para la adquisición del token de resguardo, pudiendo ocasionar serios perjuicios a los declarantes a causa de que les aplique esta norma, cuando la intencionalidad en el uso del producto es manifiestamente otra.
   

¿Cómo se utiliza este método?
Para utilizar este método debemos simplemente sincronizar la billetera marcando la check de "non-taxable".
 




¿Cómo se refleja en Cointracking la liquidez tipo 2 "non-taxable"?
Cointracking emplea el siguiente método para trasladar lo ocurrido utilizando este método:

Fase 1, delegación de activos

• Gasto no imponible del criptoactivo 1 delegado.
  
• Gasto no imponible del criptoactivo 2 delegado.
  
• Ingreso no imponible del token de resguardo.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses, cuando lleguen saldos a causa de que se haya hecho el reclamo manualmente por parte del usuario.
  
  

Fase 3, recuperación de activos delegados

• Gasto no imponible del token de resguardo.
  
• Ingreso no imponible del criptoactivo 1 delegado.
  
• Ingreso no imponible del criptoactivo 1 delegado.
  

Ejemplo:

• Hemos dispuesto de liquidez 50 BNB y 10000 USDT, siendo el valor de cada uno de los activos 10.000 €.
  
• Reclamemos una sola vez intereses por valor de 7 BNB.
  
• Al desmontar la liquidez recibimos 55 BNB y 9500 USDT, siendo el valor de cada uno de los activos a su vuelta 9500 €.
  

Fase 1, delegación de activos

• Gasto no imponible del 50 BNB.
  
• Gasto no imponible del 10000 USDT.
  
• Ingreso no imponible de 1 LP-1551.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses, 7 BNB.
  
  

Fase 3, recuperación de activos delegados

• Gasto no imponible de 1 LP-1551.
  
• Ingreso no imponible de 55 BNB.
  
• Ingreso no imponible 9500 USDT.
  

¿Cuáles son los errores de este método?
Este método incurre en los siguientes errores.

1. Altera el valor histórico de los activos
   Al gastarlos mediante eventos no imponibles, se desvirtúa y modifica el FIFO de manera notoria, escondiendo de nuevo perdidas y beneficios, como sucede en el ejemplo del tipo 1.
   
   
   
2.  Afecta a la norma anti aplicación
   De nuevo, afecta a la norma anti aplicación y utilizándolo, desvirtúa la naturaleza de la norma, pero en este caso, pudiendo afectar de manera mucho más notoria en términos económicos.
   

 

¿Cómo se utiliza este método?
Desde marzo de 2022, Cointracking no nos facilita opción alguna para hacer uso de esta representación del pool de liquidez. Queda reservado solo para usuarios que tengan una billetera sincronizada a fecha anterior a marzo de 2022 y que si la eliminan, no volverán a disponer del método.

Es importante destacar que, es necesario mantener la línea de coherencia a lo largo del tiempo en los tratamientos de representación de pools de liquidez en un informe, por lo que si tienes recursos antiguos como este, tendrás que actualizarlos en algún momento y realizar declaraciones complementarias si hay variación en los resultados.



¿Cómo se refleja en Cointracking la liquidez tipo 3 "antigua"?
Cointracking emplea el siguiente método para trasladar lo ocurrido utilizando este método

Fase 1, delegación de criptoactivos

• Retirada de la moneda 1 de la billetera.
  
• Retirada de la moneda 2 de la billetera.
  
• Depósito de la moneda 1 en el pool de liquidez.
  
• Depósito de la moneda 2 en el pool de liquidez.
  
• Ingreso no imponible del token de liquidez en billetera.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses en billetera.
  

Fase 3, recuperación de criptoactivos delegados

• Gasto no imponible del token de liquidez de billetera.
  
• Operación de consolidación del "impermanent loss" que se haya producido.
  
• Retirada de la moneda 1 del pool de liquidez.
  
• Retirada de la moneda 2 del pool de liquidez.
  
• Depósito de la moneda 1 en la billetera.
  
• Depósito de la moneda 2 en la billetera.
  

Ejemplo:
Imaginemos que:

• Hemos dispuesto de liquidez 50 BNB y 10000 USDT en Pancake Swap desde Metamask.
  
• Ganemos 7 Cake en un solo harvest.
  
• Al desmontar la liquidez a causa del impermanent loss recibimos 48 BNB y 10500 USDT.
  

Lo reflejaríamos de la siguiente manera:
 

Fase 1, delegación de criptoactivos

• Retirada de 50 BNB de Metamask.
  
• Retirada de 10000 USDT de Metamask.
  
• Depósito de 50 BNB en "Liquidity: BNB-USDT"
  
• Depósito de 10000 USDT en "Liquidity: BNB-USDT"
  
• Ingreso no imponible del token 100 Cake-LP en Metamask.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses de 7 Cake en Metamask.
  
  

Fase 3, recuperación de criptoactivos delegados

• Gasto no imponible del 100 Cake-LP de Metamask.
  
• Operación de venta de 2 BNB por compra de 500USDT en "Liquidity: BNB-USDT".
  
• Retirada de 48 BNB de PancakeSwap.
  
• Retirada de 10500 USDT de PancakeSwap.
  
• Depósito de 48 BNB en Metamask.
  
• Depósito de 10500 USDT en Metamask
  

¿Cuáles son los errores de este método?
A causa de que consolida una venta no real de un activo por otro en el impermanent-loss, no se consolidan en su totalidad las minusvalías (perdidas) y plusvalías (beneficios) totales, quedando mejor que los anteriores métodos, pero sin dar solución total al problema de esconder errores.

¿Cómo se utiliza este método?
Este método es el que personalmente utilizaría dado que considero que es el que mejor refleja los eventos ocurridos y que menores problemas incurriría frente a normativas como las de anti aplicación.

Recordad que a falta de normativa, es solo una interpretación que hacemos, pero, que será necesario una consulta vinculante para asegurarnos de que es seguro el empleo del mismo.

Este método requiere de intervención manual y es tremendamente complejo. Hay que interpretar cada uno de los pools de liquidez y añadir correctamente las entradas, úsalo con mucha precaución, es fácil equivocarse.



¿Cómo se refleja en Cointracking la liquidez tipo 4 "real"?
Cointracking emplea el siguiente método para trasladar lo ocurrido utilizando este método:
 

Fase 1, delegación de criptoactivos

• Retirada del criptoactivo 1 de la billetera.
  
• Retirada del criptoactivo 2 de la billetera.
  
• Depósito del criptoactivo 1 a la llegada al pool.
  
• Depósito del criptoactivo 2 a la llegada al pool.
  
• Ingreso no imponible del token de resguardo a la billetera.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses, cuando se reclamen, en la billetera.
  

Fase 3, recuperación de criptoactivos delegado

• Gasto no imponible del token de resguardo en la billetera.
  
• Perdida por apalancamiento del criptoactivo que al desmontar en pool vuelva en menor cantidad.
  
• Beneficio por apalancamiento del criptoactivo que al desmontar el pool vuelva en mayor cantidad.
  
• Retirada del criptoactivo 1 a la salida del pool.
  
• Retirada del criptoactivo 2 a la salida del pool.
  
• Depósito del criptoactivo 1 a la llegada a la billetera.
  
• Depósito del criptoactivo 2 a la llegada a la billetera.
  

Ejemplo:
Imaginemos que:

• Hemos dispuesto de liquidez 50 BNB y 10000 USDT en Pancake Swap desde Metamask.
  
• Ganemos 7 CAKE en una sola reclamación de intereses.
  
• Al desmontar la liquidez a causa del impermanent-loss recibimos 48 BNB y 10500 USDT.
  

Lo reflejaríamos de la siguiente manera:
 

Fase 1, delegación de criptoactivos

• Retirada de 50 BNB de la billetera.
  
• Retirada de 10000 USDT de la billetera.
  
• Depósito de 50 BNB a la llegada al pool.
  
• Depósito de 10000 USDT a la llegada al pool.
  
• Ingreso no imponible del token de resguardo a la billetera.
  

Fase 2, obtención de rendimientos

• Ingreso por intereses de 7 Cake en la billetera.
  
  

Fase 3, recuperación de criptoactivos delegado

• Gasto no imponible del 100 Cake-LP en la billetera.
  
• Perdida por apalancamiento de 2 BNB al desmontar en pool.
  
• Beneficio por apalancamiento de 500 USDT al desmontar en pool.
  
• Retirada de 48 BNB a la salida del pool.
  
• Retirada de 10500 a la salida del pool.
  
• Depósito de 48 BNB a la llegada a la billetera.
  
• Depósito de 10500 USDT a la llegada a la billetera.
  

¿Cuáles son los errores de este método?
Este método consideramos que no incurriría en ningún problema fiscal y es el que más se adecua a lo acontecido.