Cada recompensa por staking de ADA es un evento fiscal doble. El protocolo acredita la recompensa a la dirección de staking en un límite de época. El usuario retira la recompensa a una dirección de pago en una transacción de retiro en cadena separada. Diferentes jurisdicciones tratan uno o ambos como el momento imponible. Cualquiera que sea el que se aplique, el CSV que importa su motor de impuestos necesita ambas marcas de tiempo y el precio de ADA en cada una. Este artículo es el complemento fiscal y contable de la serie existente sobre custodia de Cardano. La guía complementaria sobre sondeo de saldos de staking y recompensas de Cardano a escala cubre la consulta de staking de Cardano subyacente y la economía de caché que hace que las lecturas repetidas sean gratuitas. La guía complementaria sobre detección de depósitos de Cardano sin ejecutar un nodo completo cubre el recorrido del rango de bloques que observa las transacciones de retiro en la cadena. Esta pieza es para el ingeniero que crea el estado de recompensa por usuario que alimenta las plataformas de impuestos de criptomonedas (Koinly, CoinTracker, Cryptio, ZenLedger) o la oficina administrativa de custodia que produce estados de cuenta de fin de año. Las mismas cinco columnas responden a ambas audiencias. Este artículo recorre las dos consultas que las producen, el cálculo de épocas, el paso de conversión fiduciaria, la forma CSV y las preocupaciones operativas específicas de la declaración de impuestos. ## Los dos eventos de impuestos por recompensa Hay dos eventos de recompensa en Cardano. La mayoría de los marcos de impuestos se preocupan por al menos uno. Muchos se preocupan por ambos. El primer evento es ganado. En cada límite de época, el cálculo de recompensas de Shelley acredita la dirección de participación con las recompensas de dos épocas anteriores. La recompensa llega sin ninguna acción del usuario. Algunas jurisdicciones tratan este crédito como ingreso ordinario. El precio de ADA en el momento del crédito se convierte en la base de costo para el nuevo ADA. El segundo evento es el retiro. El usuario firma una transacción en la cadena que transfiere las recompensas acumuladas de la cuenta de recompensas a una dirección de pago. Este es un evento distinto con su propio hash de transacción y marca de tiempo. Otras jurisdicciones tratan el retiro como el momento imponible. El precio de ADA en el retiro se convierte en el valor realizado. Un estado de recompensa por usuario justificable registra ambos. El flujo de ganancias proporciona la línea de tiempo de reconocimiento de ingresos.El flujo retirado proporciona la línea de tiempo de retiro de efectivo. Las plataformas de impuestos que aceptan cualquiera de los dos modelos los quieren como filas separadas. ## Campos de staking de Cardano en la API de Bitquery La API address de Cardano devuelve un bloque staking para cualquier dirección Shelley o dirección de stake (stake1...). Abra la consulta de instantánea de staking de Cardano en el IDE GraphQL de Bitquery para ejecutarla. Cinco campos impulsan la exportación de impuestos. rewardsAmount es el total de ADA de por vida acreditado como recompensas a esta clave de stake. rewardsAvailable es la porción acreditada pero aún no retirada. withdrawnAmount es el total de por vida movido fuera de la cuenta de recompensa. stakedAmount es el principal actualmente delegado, utilizado para validar períodos de delegación activos. stakedAmountWithRewards es la posición combinada. rewardsAmount y withdrawnAmount son ambos monótonos. Toma una instantánea hoy, toma otra en el siguiente límite de época, la diferencia es la actividad en esa ventana. Esta es la propiedad que hace que el enfoque de instantánea que se describe a continuación funcione. ## Patrón 1: Instantánea de recompensa por época usando lecturas en caché El protocolo Cardano acredita recompensas en cada límite de época. Las épocas de la red principal son de cinco días. La recompensa para la época N se calcula al final de la época N+1 y se acredita al comienzo de la época N+2. Una instantánea tomada justo después de cada límite de época captura el nuevo crédito. El procedimiento es sencillo. Instantánea rewardsAmount para cada clave de participación en cada límite de época. Resta la instantánea anterior de la nueva. El delta es la recompensa acreditada en esa época. Etiqueta cada delta con la hora de inicio de la época, que se convierte en la marca de tiempo del evento de ingresos en el extracto del usuario. El trabajo intensivo de lectura como este es para lo que se creó la caché de Bitquery. Las lecturas repetidas (stake_address, snapshot_time) se sirven desde la caché y no consumen puntos de API. El perfil de sondeo observado en custodios de producción en Bitquery lo confirma: miles de claves de participación sondeadas a lo largo de múltiples épocas se resuelven casi por completo desde la caché después de la primera pasada. Para los flujos de trabajo de impuestos esto importa dos veces. La ejecución del informe anual es barata. Volver a ejecutar el mismo período meses después para una auditoría o declaración enmendada reproduce exactamente las mismas instantáneas sin costo alguno. ## Patrón 2: Eventos de retiro en la cadena Los retiros son transacciones explícitas. La API transactions de Cardano expone withdrawalValue y withdrawalCount a nivel de transacción.Abra la consulta de transacciones de retiro de Cardano en el IDE GraphQL de Bitquery para ejecutarla. Para atribuir un retiro a una clave de participación específica, realice una unión en la dirección de participación utilizada en el certificado de retiro de la transacción. En la práctica, un custodio ya sabe qué clave de participación pertenece a qué usuario, por lo que la unión se realiza en el código de su aplicación a partir del hash de la transacción y la clave de participación archivada. Una plataforma de impuestos de criptomonedas generalmente recibe la dirección de participación del usuario durante la incorporación y ejecuta la misma unión. La salida es una fila por retiro: clave de participación, marca de tiempo, cantidad de ADA, hash de la transacción. Agregue el precio ADA/USD en la marca de tiempo y tendrá el evento de retiro de efectivo que el motor de impuestos desea. ## Patrón 3: Adjuntar precio de ADA para conversión de moneda fiduciaria Dos formas de obtener el precio. El enfoque más económico es usar inputValue(in: USD) o outputValue(in: USD) en la API de transacciones. Bitquery devuelve el valor convertido a USD en la marca de tiempo de la transacción dentro de la misma consulta. No hay una segunda llamada a la API, no hay un feed de precios separado que mantener. Si los requisitos de auditoría exigen una fuente de precio fija (un intercambio específico, un precio de liquidación diario, un oráculo interno), mantenga su propia tabla de precios indexada por la hora de inicio de la época. Únase en la marca de tiempo de la instantánea o la transacción de retiro. Los auditores generalmente prefieren una fuente de precio documentada que puedan verificar en lugar de una conversión incrustada que no puedan. ## Formato CSV para exportación de impuestos La mayoría de las plataformas de impuestos aceptan un CSV genérico con la forma que se muestra a continuación. Las columnas se asignan directamente a los campos producidos por los patrones 1 y 2. event_type separa los dos flujos para que el motor de impuestos pueda aplicar la regla correcta por fila. epoch está vacío en las filas de retiro porque los retiros no son eventos alineados con la época. tx_hash está vacío en las filas ganadas porque los eventos ganados son créditos a nivel de protocolo en el límite de la época y no tienen su propio hash de transacción. Koinly y Cryptio aceptan esta forma a través de su importador CSV genérico. CoinTracker la acepta después de un cambio de nombre de columna. El mismo archivo se abre limpiamente en Excel para una revisión del CFO. ## El retraso de la época N+2 y las recompensas de sincronización de estados de cuenta para la época N no se acreditan al final de la época N. Se acreditan al comienzo de la época N+2, aproximadamente diez días después. La marca de tiempo de ingresos en el estado de cuenta del usuario es el tiempo de crédito, no el tiempo de trabajo. Esto tiene dos consecuencias que vale la pena documentar en su política de informes.Para los usuarios que retiran su participación a mitad de época, la última recompensa llega dos épocas después de que dejan de delegar. La mayoría de las plataformas tributarias esperan la marca de tiempo del crédito como la fecha de ingresos. Manténgase fiel a eso y documente el razonamiento. Para los estados de cuenta de fin de año, las recompensas de la última época de diciembre llegan a principios de enero. Decida su política con anticipación. La posición al estilo del IRS es que el evento de ingresos es el momento del crédito, lo que coloca la recompensa en el siguiente año fiscal. Confirme con el contador del usuario. El enfoque de instantánea de Bitquery hace que cualquiera de las políticas sea sencilla de implementar porque la marca de tiempo de la instantánea es explícita en cada fila. ## Bitquery vs. cardano-db-sync autoalojado para informes de recompensas La alternativa natural es ejecutar cardano-db-sync contra un nodo de Cardano y consultar el esquema de recompensas directamente en Postgres. Esta es una opción legítima para algunos equipos. Es la opción incorrecta para la mayoría de los casos de uso de impuestos y contabilidad. El caso para db-sync es una latencia inferior a cincuenta milisegundos en consultas privadas y control total sobre el esquema de Postgres. El argumento en contra de db-sync para informes fiscales es que el flujo de trabajo está dominado por reejecuciones (revisiones de auditoría, declaraciones enmendadas, reexpresiones de períodos), y la caché de Bitquery convierte esas reejecuciones en lecturas gratuitas. ## Conectando esto a un backend fiscal o contable Una canalización típica de informes de recompensas tiene cuatro componentes. Un programador de instantáneas dispara la consulta de staking para cada clave de stake en cada límite de época y escribe el resultado en una tabla de instantáneas indexada por (stake_address, epoch). Un ordenador delta lee instantáneas consecutivas por clave de stake y emite una fila de evento ganado por delta distinto de cero. Un observador de retiros consulta la API de transacciones para withdrawalCount: {gt: 0} en ventanas deslizantes, une cada resultado al mapeo interno de clave de stake a usuario y emite una fila de evento retirado por retiro atribuido. Un generador de CSV lee las filas de ganancias y retiros para el período de estado solicitado, adjunta la columna de precio ADA/USD y produce el archivo CSV. Los cuatro componentes son independientes. El programador de instantáneas se ejecuta en el reloj de época. El observador de retiros se ejecuta en el reloj de cadena. El computador delta y el generador de CSV se ejecutan en el reloj de informes. Una falla en uno no corrompe a los demás, y una nueva ejecución de cualquier componente es barata porque las lecturas de la API subyacente están en caché. ## Resumen Un producto de custodia de Cardano o una plataforma de impuestos de criptomonedas que informa recompensas de staking de ADA por usuario tiene el mismo problema de datos independientemente de la audiencia.El archivo CSV necesita una marca de tiempo del evento, una cantidad de ADA, un precio de ADA en el momento del evento y una atribución de clave de participación, tanto para el momento de obtención como para el momento de retiro. Dos consultas GraphQL cubren ambos momentos. La instantánea de participación en la API de direcciones de Cardano proporciona la línea de tiempo de obtención. La API de transacciones de Cardano proporciona la línea de tiempo de retiro. El agregador (in: USD) proporciona la conversión a moneda fiduciaria. La caché convierte las reejecuciones de auditoría y las declaraciones modificadas en lecturas de punto cero. [Bitquery]