La puerta de los servicios de activos digitales, infraestructura de datos en cadena - Tiger Research

1. El muro que enfrentan los activos digitales: datos en cadena poco amigables {#rps-1}

El mercado de activos digitales está evolucionando rápidamente. Las stablecoins ya manejan transacciones por miles de millones de dólares anualmente, siendo utilizadas en áreas de pagos y remesas, y la tokenización de activos financieros tradicionales como acciones y bonos también está en marcha. Esto demuestra que el papel de la tecnología blockchain se está expandiendo a toda la cadena de valor financiera, desde la emisión y circulación de activos hasta los pagos y liquidaciones.

Ahora, la blockchain ha pasado de ser un tema de discusión sobre posibilidades a una etapa de construcción de infraestructura práctica. Por lo tanto, el enfoque de la discusión ha cambiado de demostrar la necesidad de adoptar la tecnología a cómo operar esto dentro del sistema financiero regulado. En particular, se trata de cómo integrar la infraestructura blockchain con los flujos de trabajo existentes en contabilidad, impuestos, auditoría y cumplimiento. A pesar de que la blockchain funciona como una nueva infraestructura básica, los procedimientos y estándares requeridos por el sistema financiero regulado aún deben mantenerse.

El problema es que el proceso de integrar la infraestructura blockchain en los flujos de trabajo financieros existentes es complicado. Los sistemas financieros heredados funcionan sobre datos estructurados estandarizados, mientras que los datos en cadena son más cercanos a datos en bruto que requieren indexación, decodificación y normalización. En otras palabras, es como un montón desordenado de recibos en lugar de un libro de contabilidad bien organizado.

Por lo tanto, para utilizar datos en cadena, se requiere una tubería de datos separada. Es necesario recopilar registros de transacciones de libros distribuidos y refinarlos para su propósito. Además, se debe contar con una infraestructura que pueda almacenar de manera confiable decenas de terabytes de datos y recuperarlos rápidamente cuando sea necesario. Al final, aunque los datos en cadena son públicos, no son datos que se puedan utilizar fácilmente por sí mismos.

2. La realidad y las limitaciones de construir infraestructura de datos en cadena {#rps-2}

Sin embargo, en las etapas iniciales, cuando el tamaño y el alcance del mercado de activos digitales eran limitados, este problema de accesibilidad a los datos no se destacó tanto. La mayoría de los servicios de activos digitales eran experimentos a pequeña escala dirigidos a un número limitado de participantes. Por ejemplo, el proyecto de token de depósito del banco de inversión global JP Morgan era un medio de pago limitado diseñado solo para unos pocos clientes institucionales. En un entorno donde los participantes y los propósitos de uso son claros, los tipos de transacciones a procesar también eran simples, y la inmediatez o precisión de los datos no era tan importante.

En ese momento, los criterios requeridos para los datos en cadena eran relativamente laxos. No había un gran problema operativo si todos los estados no coincidían estrictamente en tiempo real, siempre que, después de un tiempo, la consistencia final se mantuviera. Es decir, un enfoque basado en la consistencia eventual era suficientemente aceptable. En este entorno, era posible manejar la situación operando nodos de forma limitada o integrando puntos finales RPC externos o simplemente APIs de datos en cadena.

Sin embargo, a medida que el entorno en cadena se expandió, se volvió difícil manejarlo solo con los métodos existentes. La variedad de clases de activos y el rápido aumento en el volumen de transacciones hicieron que el alcance del procesamiento de datos creciera drásticamente. Como resultado, los requisitos técnicos que la infraestructura de datos debe cumplir han evolucionado más allá de un simple nivel de consulta a formas mucho más sofisticadas y que garantizan la inmediatez. Al entrar en una etapa de operación real, los estándares requeridos para la infraestructura han cambiado fundamentalmente.

3. Requisitos de infraestructura de datos en cadena para el sistema financiero regulado {#rps-3}

Para cumplir con este nivel de requisitos elevados, los criterios para evaluar la infraestructura también deben cambiar. Tiger Research presenta tres criterios clave para la infraestructura de datos en cadena que el sistema financiero regulado puede confiar y utilizar: completitud (Completeness), consistencia (Consistency) y estabilidad (Stability). Estos son requisitos esenciales que los datos en cadena deben cumplir para funcionar como el libro mayor de referencia de un servicio real.

3.1. Completitud (Completeness): ¿se incluyen todos los registros de transacciones? {#rps-4}

La completitud es el requisito más básico de la infraestructura de datos en cadena. Este criterio evalúa si todos los registros de transacciones registrados en el libro mayor de blockchain se han recopilado sin omisiones y si se han reflejado sin falta en el proceso posterior. En el sistema financiero regulado, la omisión de una sola transacción puede alterar el cálculo de saldos, el procesamiento contable y los resultados de liquidación.

Las omisiones de datos pueden ocurrir primero en la etapa de recopilación. La blockchain agrupa las transacciones ocurridas durante un período de tiempo en bloques y las registra en el libro mayor. La infraestructura de datos recopila y procesa estos bloques en orden. Sin embargo, si hay una interrupción en la recopilación de bloques de un intervalo específico debido a fallos en nodos o problemas de red, los registros de transacciones incluidos en ese intervalo también pueden omitirse. Sin embargo, las omisiones en la etapa de recopilación pueden ser verificadas y abordadas de manera relativamente clara. Se pueden llenar los datos mediante un trabajo de retroalimentación (Backfill) que recopila nuevamente el intervalo de bloques omitidos.

Otro problema es el proceso de procesamiento después de haber recopilado todos los datos de bloques originales. El indexador (Indexer) extrae los registros de transacciones necesarios de los datos originales y los convierte en una forma que se puede consultar. En este momento, si los datos no se analizan correctamente, algunos registros pueden perderse en el proceso de procesamiento. Por ejemplo, supongamos que se está indexando los datos de transferencia de tokens de Solana. Solana tiene estándares de tokens extendidos además de los estándares de tokens existentes. Si el indexador está diseñado para analizar solo el estándar existente, los registros de movimiento de tokens emitidos bajo el estándar extendido pueden omitirse.

En cadenas de alto rendimiento, la carga para mantener la completitud es aún mayor. Cuanto más corto es el ciclo de creación de bloques y mayor es el volumen de transacciones, más aumenta la cantidad de datos que la tubería de datos debe procesar en un corto período de tiempo. Incluso si no hay defectos en la lógica de recopilación y procesamiento, si el procesamiento en tiempo real no puede seguir el ritmo de la velocidad de la cadena, puede haber retrasos en la reflección de los registros de transacciones que ocurrieron en ese intervalo. En última instancia, la completitud debe ir más allá de simplemente obtener datos sin omisiones; debe ser capaz de responder continuamente a los cambios y la velocidad de la cadena.

3.2. Consistencia (Consistency): ¿son precisos los datos recopilados? {#rps-5}

Mientras que la completitud verifica la omisión de datos, la consistencia es el criterio que evalúa si los datos recopilados coinciden con el libro mayor de blockchain. En el sistema financiero regulado, la consistencia es tan importante como la completitud. Si un solo dato es incorrecto, todos los cálculos y juicios basados en él también pueden distorsionarse.

En blockchain, el proceso de confirmación del libro mayor puede llevar a que los datos cambien temporalmente. Mientras que los sistemas financieros tradicionales registran y gestionan datos basados en un servidor central, blockchain permite que múltiples participantes validen bloques y actualicen el libro mayor tras llegar a un consenso. En este proceso, pueden surgir situaciones en las que diferentes bloques parecen ser válidos simultáneamente debido a retrasos en la red o diferencias en los momentos de validación.

Durante este proceso, un bloque que inicialmente se consideró válido puede ser excluido del libro mayor final y ser reemplazado por otro bloque, lo que se conoce como reestructuración de bloques (Reorg). En este caso, las transacciones incluidas en el bloque pueden ser excluidas del libro mayor final o ser incluidas nuevamente en otro bloque. Esto puede dar lugar a problemas de consistencia, ya que los datos recopilados en un momento específico pueden diferir del estado del libro mayor confirmado posteriormente.

Los problemas de consistencia también pueden surgir en los nodos clientes. El nodo cliente es el software clave que opera los nodos de blockchain y, en términos simples, es similar al sistema operativo (OS) de blockchain. Si este software presenta fallas, pueden ocurrir errores en el proceso de interpretación y cálculo de los datos del libro mayor. De hecho, ha habido casos en los que los principales nodos clientes de Ethereum han presentado errores en el procesamiento de transacciones o en el cálculo de tarifas. Esto es similar a los incidentes en los servicios financieros donde los activos de los clientes se registran incorrectamente o las tarifas se liquidan de manera errónea.

Así, la consistencia de los datos en cadena no se garantiza simplemente recopilando datos. Los datos recopilados en un momento específico pueden diferir del libro mayor confirmado posteriormente, y las fallas en el nodo cliente pueden llevar a una interpretación incorrecta de los datos del libro mayor. Por lo tanto, para utilizar los datos en cadena como datos de referencia en el sistema financiero regulado, es necesario comparar y verificar continuamente que los datos recopilados coincidan con el libro mayor.

3.3. Estabilidad: ¿Es estable en un entorno operativo a gran escala? {#rps-6}

Si la integridad y la consistencia son criterios para verificar la calidad de los datos, la estabilidad es el criterio que determina si la recopilación, procesamiento y consulta de datos pueden continuar sin interrupciones en un entorno operativo a gran escala. Dado que incluso una sola falla o retraso puede tener consecuencias devastadoras en esta industria, este es un requisito innegociable. Especialmente, la infraestructura en cadena se basa en una red que no se detiene las 24 horas, por lo que los requisitos de estabilidad son aún más altos.

En un entorno operativo a gran escala, se deben procesar muchas solicitudes simultáneamente. En la infraestructura de servidores tradicional, se puede aumentar la capacidad mediante balanceo de carga (Load Balancing) distribuyendo las solicitudes entre varios servidores. Sin embargo, en la infraestructura de blockchain, operar múltiples nodos no necesariamente produce el mismo efecto. Los momentos de sincronización de bloques de cada nodo pueden diferir, lo que puede resultar en diferentes resultados para la misma solicitud de consulta.

Por ejemplo, supongamos que un usuario consulta el estado de procesamiento justo después de enviar una transacción. El nodo que recibió la primera solicitud puede haber verificado la transacción, pero otro nodo que recibió la solicitud de consulta puede no haberla reflejado aún. En este caso, aunque la infraestructura responde normalmente, el usuario puede ver diferentes estados para una misma transacción.

A medida que aumenta el volumen de datos, también se vuelve más difícil asegurar la estabilidad. En el sistema financiero regulado, no es suficiente simplemente verificar el estado más reciente. También es necesario evaluar el estado de los activos en un momento específico y verificar qué historial de transacciones llevó a ese estado. Para ello, se requieren nodos de archivo (Archive Node) que preserven registros históricos, pero según la cadena, su tamaño puede alcanzar decenas de terabytes. En un entorno donde se deben almacenar y consultar grandes volúmenes de datos, también aumenta la posibilidad de retrasos en las consultas y cuellos de botella en el sistema.

El mantenimiento continuo también es un requisito importante para la estabilidad. Blockchain sigue evolucionando incluso durante su operación, con hard forks (Hard Fork), actualizaciones de cadena y actualizaciones de nodos clientes. Si la tubería de recopilación y procesamiento de datos no puede adaptarse a estos cambios, incluso la infraestructura que funcionaba normalmente puede detenerse de inmediato. En última instancia, la estabilidad no se asegura solo con la construcción inicial, sino que debe mantenerse mediante la adaptación continua a los cambios en el entorno de la cadena.

4. Lambda256: Infraestructura de datos en cadena para el sistema financiero regulado {#rps-7}

Es raro que una empresa que prepara un negocio de activos digitales construya toda la infraestructura base de manera independiente. Generalmente, elige una infraestructura de cadena global con tecnología comprobada y concreta su modelo de negocio sobre ella. La infraestructura de datos en cadena también debe verse desde esta perspectiva. La infraestructura de datos en cadena que posee integridad, consistencia y estabilidad no es simplemente un desafío de construir una base de datos.

En un entorno complejo de múltiples cadenas, es necesario indexar en tiempo real las estructuras de datos diferentes de cada cadena y mantener una alta estabilidad y rendimiento de procesamiento incluso con un tráfico masivo. Además, se debe responder continuamente a la aparición de nuevos estándares y actualizaciones de cadena. En última instancia, la infraestructura de datos en cadena no es un proyecto de desarrollo que se complete en un corto período, sino un negocio de infraestructura a gran escala que requiere una enorme inversión de capital, tiempo y experiencia operativa práctica.

Por lo tanto, desde la perspectiva de la empresa, es más realista elegir un socio de infraestructura comprobado y concentrarse en su negocio principal en lugar de desarrollar toda la infraestructura de manera directa. Este es el contexto en el que Lambda256 se ha establecido como socio tecnológico de los principales operadores de activos digitales en Corea. Lambda256, una subsidiaria de tecnología blockchain de Dunamu, proporciona infraestructura de blockchain a intercambios, instituciones financieras y empresas web3, acumulando experiencia operativa en el mercado nacional.

Lambda256, basándose en esta experiencia, lanzó en 2024 la plataforma de desarrollo web3 'Nodit'. El 'DataShare', recientemente presentado, es un producto de infraestructura de datos en cadena de Nodit, diseñado teniendo en cuenta la calidad de los datos y el entorno operativo requeridos por el sistema financiero regulado. Antes de su lanzamiento oficial, se ha proporcionado un servicio en forma de almacén de datos a algunos socios durante más de dos años, lo que permite considerarlo como una infraestructura que ya ha pasado por un proceso de validación en un entorno práctico.

4.1. Diferenciación técnica: motor de indexación propio y pipeline de datos de alto rendimiento {#rps-8}

La diferenciación técnica de DataShare radica en proporcionar datos fragmentados del entorno de múltiples cadenas en un conjunto de datos que se ajusta a los flujos de trabajo existentes. En un entorno de múltiples cadenas, como cada cadena tiene una estructura de datos y un método de registro diferentes, los criterios de recopilación y procesamiento también deben diseñarse de acuerdo con las características de cada cadena. Además, dado que el entorno operativo de cada cadena cambia continuamente, como la introducción de nuevos estándares o actualizaciones de red, la dificultad de gestionar la infraestructura de datos aumenta aún más. DataShare cuenta con una estructura que puede responder continuamente a estas diferencias y cambios operativos, gracias a personal especializado con conocimientos de dominio, un motor de indexación propio y un pipeline de datos de alto rendimiento. Para obtener más detalles sobre la diferenciación técnica de DataShare, se puede consultar el artículo coescrito por Lambda256 y Disipher (la sociedad de tecnología blockchain de la Universidad Nacional de Seúl).

Para que esta estructura funcione de manera estable, también debe respaldarse un entorno de infraestructura de nodos que obtenga los datos de origen. DataShare se ofrece sobre la arquitectura de Hyper Node de Nodit, lo que permite responder de manera flexible incluso ante solicitudes masivas o fallos en los nodos. Se gestiona un umbral mínimo de nodos disponibles y se controla el umbral de latencia y recuperación para evitar que los problemas de un nodo se propaguen a todo el proceso de recolección. Además, la infraestructura está diseñada para responder sin interrupciones a cambios en el entorno, como actualizaciones de la mainnet o reemplazos de software de nodos.

Un aspecto importante que diferencia a DataShare es que los datos recolectados pasan por un proceso de verificación separado. DataShare verifica continuamente a través de un proceso de auto-verificación si los datos recolectados coinciden con el estado real de la cadena. Durante este proceso, se revisan las diferencias de datos que pueden surgir tras una reestructuración de bloques, errores en los clientes de nodos o actualizaciones de la cadena, y se verifica que los resultados del procesamiento de transacciones individuales se reflejen de manera coherente en los registros de eventos y cambios de saldo. Es decir, al cruzar los contenidos registrados en la cadena con los resultados procesados por DataShare, se reduce la posibilidad de omisiones de datos o errores de procesamiento, asegurando así la confiabilidad que puede ser utilizada como datos de referencia en los flujos de trabajo existentes.

Sin embargo, para utilizar los datos en cadena en las operaciones reales, no solo es necesaria la precisión de los datos, sino que también se debe poder proporcionar una amplia gama de tipos de cadenas y datos necesarios. DataShare actualmente admite 13 cadenas clave que tienen una alta demanda en el mercado y puede expandir conjuntos de datos personalizados basados en más de 50 cadenas múltiples operadas por Nodit. En el futuro, se planea proporcionar datos etiquetados que combinen direcciones de billeteras de intercambio, contratos inteligentes de DeFi y datos de precios, ampliando así el alcance de uso no solo para contabilidad y fiscalidad, sino también para la gestión de riesgos y el monitoreo de transacciones inusuales.

4.2. Diferenciación operativa: respuesta a la conformidad e integración de flujos de trabajo existentes

Para utilizar datos en cadena en el sistema financiero regulado, es necesario cumplir no solo con la calidad de los datos, sino también con los requisitos de conformidad. En particular, el sector financiero nacional tiene estándares estrictos que se aplican al introducir infraestructura de datos externos, como la separación de redes, control de acceso y estándares de operación de redes internas. DataShare apoya la construcción en las instalaciones (On-premise) dentro de IDC nacionales considerando este entorno, y ha asegurado la confiabilidad del sistema de gestión de seguridad a través de la certificación SOC2. Esto permite a las instituciones financieras introducir datos en cadena de acuerdo con sus políticas de seguridad internas y pautas regulatorias.

Es importante que las instituciones financieras puedan gestionar directamente la ubicación de almacenamiento de los datos y los permisos de acceso. DataShare admite una arquitectura que envía datos en cadena directamente a los almacenes en la nube utilizados por las instituciones financieras. Por ejemplo, al cargar datos en cadena en tiempo real en entornos de datos internos de las instituciones, como AWS S3, se puede mantener el control sobre la gestión de datos y el control de acceso, incluso al utilizar soluciones de infraestructura externas.

Además, DataShare planea seguir fortaleciendo la conectividad con los entornos de análisis de datos que las instituciones financieras ya utilizan. Al admitir la integración con principales plataformas de almacenamiento y análisis de datos como Snowflake, BigQuery y Databricks, el objetivo es que los datos en cadena se conecten orgánicamente con los flujos de trabajo existentes.

El sistema de soporte operativo de Lambda256 también es una fortaleza de DataShare. La infraestructura de datos en cadena se basa en una red blockchain que opera las 24 horas, por lo que es crucial tener la capacidad de detectar y responder rápidamente a fallos o retrasos. DataShare proporciona monitoreo constante y soporte técnico dedicado a través de personal especializado en el país, reduciendo la carga operativa que las instituciones financieras deben asumir directamente. Esto permite a las instituciones gestionar y utilizar datos en cadena de manera estable sin tener que expandir significativamente su organización de infraestructura blockchain.

5. Momentos en que se necesita infraestructura de datos en cadena

Escenario 1: Problema de rastrear con precisión el estado de los poseedores de acciones tokenizadas

En el sistema financiero regulado, está aumentando el número de casos en los que las acciones cotizadas se emiten simultáneamente en forma de tokens en la cadena. Un ejemplo representativo es el de la empresa de activos digitales global Galaxy Digital, que tokenizó sus acciones ordinarias ($GLXY) y las emitió en la blockchain de Solana. La empresa de tokenización de activos Securitize también emitió sus acciones ($SECZ) en Solana al mismo tiempo que se listó en la Bolsa de Nueva York (NYSE). Solana, que se destaca por su velocidad de procesamiento y bajos costos, se ha convertido en la infraestructura principal elegida por las instituciones financieras que buscan tokenizar acciones cotizadas de manera conforme a la regulación.

Las instituciones financieras que manejan tanto activos tradicionales como valores tokenizados en cadena enfrentan nuevos desafíos operativos. Las casas de valores deben rastrear con precisión el estado de los poseedores de tokens registrados en la blockchain y demostrarlo a las autoridades reguladoras y auditores. Esta es una tarea clave que se repite no solo en el momento de cierre, sino también en las fechas de referencia de dividendos y de cálculo de derechos de voto. Si los datos se omiten o si el saldo en un momento específico se calcula incorrectamente, puede llevar a riesgos críticos como pagos excesivos, errores de divulgación y fallos en la respuesta a auditorías.

El problema es que la estructura de datos única de Solana complica estas operaciones financieras. Aunque Solana es ventajosa en términos de costos y velocidad, su estructura de almacenamiento de registros de transacciones está distribuida en numerosas cuentas. Incluso una sola transacción DeFi fragmenta los datos en cuentas de tokens, grupos de liquidez y cuentas de tarifas. Además, dado que el tamaño acumulado de los datos en los nodos de archivo de Solana puede alcanzar varios cientos de terabytes, reconstruir el estado de los poseedores y el historial de transacciones en un momento específico del pasado se vuelve una tarea que es difícil de manejar para las instituciones individuales.

Por lo tanto, para integrar activos tokenizados basados en Solana en el sistema financiero regulado, es esencial contar con una infraestructura de datos que permita el análisis inmediato sin procesamiento. DataShare purifica los datos de origen fragmentados y los proporciona en una forma normalizada que puede ser consultada de inmediato en los almacenes de datos existentes de las instituciones financieras. En particular, se ha optimizado el pipeline para un entorno de alta velocidad con un ciclo de creación de bloques de menos de 0.4 segundos, asegurando la capacidad de procesar aproximadamente 20,000 transacciones por segundo en tiempo real por cadena y minimizando la latencia de indexación.

Escenario 2: Problemas de gestión de riesgos en pagos agenticos y pagos en cadena {#rps-12}

El mercado de pagos agenticos (Agentic Payment), donde los agentes de IA determinan y ejecutan pagos en lugar de los usuarios, está en auge. Desde el lanzamiento del protocolo de pago en cadena x402 por Coinbase, se ha comenzado a construir una infraestructura de pagos autónomos basada en stablecoins.

Sin embargo, para que los pagos autónomos entre agentes se consoliden como un servicio financiero comercial, la calidad de los datos en cadena que sirven como base para la toma de decisiones es de suma importancia. A medida que se reducen los procedimientos de verificación humana, el sistema debe determinar la disponibilidad de saldo, la confirmación de transacciones y la posibilidad de transacciones anómalas únicamente a través de datos. Si durante este proceso los datos en cadena se omiten o distorsionan, pueden ocurrir errores fatales en la aprobación y rechazo de pagos.

Entonces, ¿cuáles son los factores concretos que causan la omisión y distorsión de estos datos en un entorno de blockchain real? Una de las causas más representativas son las transacciones que fallan en su ejecución. Dependiendo de la congestión de la red, más del 20% de todas las transacciones pueden fallar, y en el caso de Solana, la tasa de fallos de las transacciones no votadas puede superar el 40%.

Si el sistema de pagos confunde estas transacciones fallidas como si hubieran sido procesadas correctamente, puede determinar que el saldo se ha deducido a pesar de que no se realizó el pago real, lo que provoca un error de discrepancia de saldo que rechaza pagos futuros. Además, el fenómeno de reestructuración de bloques (Reorg), donde una transacción que parecía haber sido aprobada en un momento dado es cancelada posteriormente, también actúa como un variable crítica que agrava la distorsión de datos.

DataShare busca resolver fundamentalmente estos problemas de confiabilidad de datos al seleccionar y suministrar solo aquellos datos cuya integridad (Finality) ha sido asegurada y cuyo éxito final ha sido confirmado al sistema de pagos. Verifica en tiempo real las transacciones no confirmadas o los registros de fallos incluidos en los datos de origen de blockchain en la etapa de pipeline, y proporciona únicamente conjuntos de datos refinados, eliminando así las preocupaciones sobre malfuncionamientos debido a distorsiones en cadena.

Además, está ampliando continuamente su alcance de soporte a importantes blockchains locales tanto nacionales como internacionales, como GIWA y Kaia, asegurando así la versatilidad comercial. Esto representa un valor clave al proporcionar una base de datos estable que permite que la infraestructura de pagos agenticos supere las limitaciones de depender de una red principal global específica y se diversifique de manera flexible de acuerdo con el entorno de servicio y los requisitos regulatorios de cada región.

6. Conclusión {#rps-13}

El éxito o fracaso de los negocios de activos digitales depende de cuán precisamente se manejen los datos. Todos los procesos financieros, desde la emisión de activos hasta los pagos y la liquidación, se están reorganizando en torno a datos en cadena. Por lo tanto, la omisión o error de datos puede no solo disminuir la confiabilidad del servicio, sino también provocar riesgos regulatorios fatales. DataShare actúa como una infraestructura de conexión que reduce estos riesgos operativos y permite que las instituciones financieras utilicen datos en cadena de acuerdo con sus estándares operativos.

Además, las instituciones financieras pueden utilizar diversas soluciones tecnológicas financieras de Lambda256, además de DataShare, para expandir las funciones necesarias de manera personalizada. Por ejemplo, es posible introducir SCOPE para la liquidación y operación de activos digitales, o CLAIR para el cumplimiento regulatorio, adaptándolas a las etapas de crecimiento del negocio, aumentando así la integridad del sistema. Es decir, se puede combinar gradualmente las funciones necesarias en el entorno existente sin la carga de reconstruir completamente la infraestructura desde el principio.

Como resultado, las instituciones financieras pueden liberarse completamente de la carga operativa de la gestión de infraestructuras complejas o el mantenimiento de sistemas, y concentrarse en el valor comercial inherente de la innovación de servicios y la diferenciación de productos. Se completa una estructura que, mientras reduce las barreras de entrada iniciales, permite asegurar de manera estable las funciones necesarias en cualquier momento, en línea con la expansión futura del negocio y los cambios regulatorios.

El presente artículo es un extracto del informe "La puerta de entrada a los servicios de activos digitales, infraestructura de datos en cadena" de Tiger Research, una institución de investigación especializada en Web3 asociada con Block Media. Este informe también está disponible en el sitio oficial de .