La Cardano Foundation ha lanzado Cardano Rosetta Java v2.1.0, introduciendo funcionalidad de gobernanza completa de la era Conway a través de endpoints estandarizados de Mesh API, permitiendo a exchanges y desarrolladores interactuar con la infraestructura de gobernanza descentralizada de Cardano por primera vez a través de la interfaz Rosetta.
La era del ledger Conway, también conocida como la fase Voltaire, representa la transición de Cardano hacia la gobernanza en cadena donde los poseedores de ADA, los Operadores de Stake Pool y los Representantes Delegados participan directamente en las decisiones del protocolo. Hasta v2.1.0, esta capa de gobernanza no era accesible a través de la API Rosetta en la que los exchanges e integradores institucionales confían para la interacción estandarizada de blockchain.
El lanzamiento cierra esa brecha tanto en los endpoints de construcción como de datos.
Los SPOs ahora pueden emitir votos en cadena sobre acciones de gobernanza directamente a través de la API. Los usuarios pueden delegar su poder de voto a los DReps a través de la misma interfaz en lugar de requerir herramientas separadas. Se ha agregado soporte para CIP-129, permitiendo la inferencia automática del tipo de DRep a partir de identificadores con prefijo, lo que simplifica cómo se manejan las identidades de los participantes de gobernanza durante la construcción de transacciones. Las operaciones de gobernanza, incluyendo dRepVoteDelegation, ahora se identifican y devuelven correctamente en los endpoints de bloque, bloque/transacción y construcción/análisis.
Para los exchanges en particular, la cobertura estandarizada de endpoints significa que las transacciones relacionadas con la gobernanza pueden ser analizadas, validadas y mostradas utilizando la misma infraestructura ya implementada para transferencias estándar de ADA y operaciones de staking.
Más allá de la gobernanza, v2.1.0 incluye varios refinamientos de infraestructura. Las operaciones dentro de los endpoints de datos ahora están ordenadas por índice en orden ascendente, mejorando la consistencia para los desarrolladores que analizan datos de transacciones programáticamente. El manejo de códigos de estado HTTP se ha corregido para alinear los tipos de error con códigos de respuesta apropiados: los errores no reintenables ahora devuelven 400 Bad Request en lugar de 500 Internal Server Error, un cambio que hace que el manejo de errores sea más predecible para los integradores. Una interfaz de administración experimental para el indexador ahora es accesible en localhost para desarrolladores que ejecutan instancias locales.
Ninguno de esos cambios son características principales, pero la corrección del código de estado HTTP es el tipo de corrección que elimina una categoría de confusión de depuración que ha frustrado a los desarrolladores que integraban la versión anterior. Las pequeñas mejoras en el manejo de errores tienden a tener un impacto práctico desproporcionado.
La ruta de actualización desde v2.0.0 es totalmente compatible y no requiere resincronización de datos, lo que significa que los exchanges y operadores de infraestructura en la versión principal actual pueden aplicar la actualización sin tiempo de inactividad operativa. Para los operadores que aún ejecutan v1.x.x, se requiere una resincronización completa de génesis del yaci-indexer, aunque los datos existentes del Cardano Node pueden conservarse durante todo el proceso.
La distinción importa en la práctica. Los operadores que se trasladaron a v2.0.0 durante su lanzamiento en febrero de 2026 obtienen una actualización sin problemas. Aquellos que aún no han migrado desde v1.x.x enfrentan un proceso más complejo antes de acceder a las características de gobernanza en v2.1.0.
El lanzamiento de v2.0.0 a principios de febrero de 2026 fue la actualización significativa anterior, que redujo el tiempo de sincronización de red aproximadamente en un 30%, reduciendo la sincronización de 52 horas a aproximadamente 37 horas. Esa reducción fue significativa para los exchanges y desarrolladores que ejecutan infraestructura de nodo completo, reduciendo el tiempo hasta la preparación operativa en más de 15 horas para nuevas implementaciones.
v2.1.0 se basa en esa base agregando la capa de gobernanza en lugar de reemplazar o modificar las mejoras de sincronización. Los dos lanzamientos juntos representan una línea de tiempo razonablemente comprimida de avance de infraestructura: sincronización más rápida en febrero, integración de API de gobernanza en el mismo mes.
El modelo de gobernanza en cadena de Cardano es un componente relativamente nuevo y aún en maduración del protocolo. La capacidad para que los SPOs y poseedores de ADA participen en acciones de gobernanza existe a nivel de protocolo, pero las tasas de participación dependen en parte de qué tan accesibles sean las herramientas para las plataformas donde la mayoría de los usuarios interactúan con sus tenencias.
Un exchange que ahora puede mostrar la participación en gobernanza directamente a través de endpoints de API estandarizados elimina un paso del proceso para los usuarios que de otro modo necesitarían herramientas externas para votar o delegar. Si esa reducción de fricción se traduce en tasas de participación en gobernanza significativamente más altas es una pregunta que los datos en cadena posteriores al lanzamiento eventualmente responderán.
La publicación Cardano Foundation Updates Its Exchange API to Include Full Governance Support apareció primero en ETHNews.

