Es habitual leer que una blockchain «lo registra todo para siempre». Es una descripción incompleta. Un registro distribuido anota transacciones según sus propias reglas y hace muy difícil alterarlas después, pero el valor jurídico de lo anotado depende de hechos que ocurren fuera de la cadena: quién firmó, con qué facultades, sobre qué activo y con qué documento. Este artículo repasa qué puede probar un registro de este tipo, qué no puede saber por sí mismo y cómo debería encajar en un sistema que gestione activos reales y los derechos sobre ellos.
Qué aporta un registro distribuido
- Un orden verificable de los eventos anotados: qué ocurrió antes y qué después.
- Integridad: alterar una anotación pasada sin que se note es muy difícil mientras la red funcione según sus reglas.
- Una referencia común entre participantes que no comparten sistema ni tienen por qué confiar plenamente entre sí.
- Trazabilidad: cada movimiento de una representación digital queda vinculado a la dirección que lo originó.
- Automatización de reglas sencillas, como restricciones de transferencia, cuando el código se ha diseñado y revisado para ello.
Son propiedades valiosas, pero conviene leerlas con precisión: la cadena prueba que una operación se anotó y cuándo, no que la operación fuera válida.
Lo que la cadena no puede saber
Una red registra lo que recibe firmado con una clave válida. No tiene forma de comprobar, por sí sola, lo que ocurre en el mundo físico o en el jurídico. En particular, no sabe:
- Quién es la persona que controla una clave. Una dirección no es una identidad.
- Si quien firmó tenía facultades suficientes para hacerlo, como representante de una sociedad o en virtud de un poder.
- Si el activo subyacente existe, está libre de cargas o pertenece a quien dice.
- Si el contrato o el instrumento que la anotación representa es válido y está correctamente documentado.
- Si una clave se usó sin permiso. Si se pierde o se sustrae, la red anotará igualmente las operaciones que se firmen con ella.
Por eso una blockchain no sustituye a los registros que la ley considera de autoridad, como el Registro de la Propiedad para los inmuebles, ni a los procesos de verificación de identidad que deben realizar las entidades obligadas a ello.
Autoridad por hecho: quién manda en cada dato
Un sistema serio no pregunta «qué dice la blockchain», sino «quién es la autoridad sobre este hecho concreto». La respuesta cambia según el dato. La titularidad de un inmueble la acredita el registro público correspondiente. La identidad de una persona, el proceso de verificación de la entidad obligada a realizarlo. El cobro efectivo de un pago, el proveedor de servicios de pago autorizado que lo ejecuta. Y la titularidad de un instrumento, el registro que designe su régimen jurídico.
En España, la Ley 6/2023 de los Mercados de Valores y de los Servicios de Inversión admite que determinados valores se representen mediante sistemas basados en tecnología de registros distribuidos, con una entidad responsable de su registro. En el ámbito europeo, el Reglamento (UE) 2022/858 establece un régimen piloto para infraestructuras de mercado basadas en esta tecnología. En ambos casos la tecnología se integra en un marco con responsables identificados; no los sustituye.
La pregunta decisiva no es qué dice la cadena, sino qué registro manda cuando dos registros no coinciden y quién está autorizado a corregirlo.
Observar la cadena, no obedecerla
Si el registro de autoridad está fuera de la cadena, lo que se lee de ella pasa a ser una observación: un dato que se recibe, se comprueba y se contrasta con lo que debería haber ocurrido. Este enfoque protege frente a errores conocidos: un nodo que devuelve información incorrecta, una reorganización de la red que deshace bloques recientes o una transferencia que no tiene respaldo en ninguna operación autorizada. Un evento observado en la cadena no debería crear, por sí solo, un derecho nuevo; debería desencadenar una conciliación.
Reconciliar, no duplicar
Mantener dos registros que dicen lo mismo sin un criterio de prevalencia es una fuente habitual de conflictos. La alternativa es una arquitectura con responsabilidades claras:
- Un registro de autoridad que refleja la situación jurídica de cada instrumento y de cada titular.
- Una representación digital en la cadena que se trata como reflejo de ese registro, no como su origen.
- Un libro contable de doble partida para los movimientos económicos, en el que cada asiento tiene su contrapartida y no se borra: se corrige con otro asiento.
- Una conciliación periódica entre el registro, la cadena y los extractos de los proveedores de pago.
- Un rastro documentado de cada diferencia detectada: quién la resolvió, con qué autorización y por qué.
Con esta estructura, si la cadena y el registro discrepan, existe un procedimiento conocido para resolverlo, y la discrepancia queda a la vista en lugar de esconderse.
Datos personales fuera de la cadena
Lo que se anota en un registro distribuido es, en la práctica, muy difícil de rectificar o de suprimir. Eso choca con derechos que reconoce el Reglamento General de Protección de Datos, como la rectificación o la supresión. Por eso un diseño prudente mantiene los datos personales fuera de la cadena y, como mucho, anota referencias técnicas o huellas criptográficas de documentos. Incluso esas huellas pueden llegar a considerarse datos personales en algunos contextos, de modo que qué se anota debe decidirse tras analizar cada caso.
Contratos inteligentes, EVM y estándares de tokens
Un contrato inteligente es código que se ejecuta en una red y aplica reglas programadas: quién puede recibir un token, cuántas unidades existen o cuándo puede pausarse una operación. EVM (Ethereum Virtual Machine) es el entorno de ejecución que comparten Ethereum y muchas otras redes, y Solidity es el lenguaje habitual para escribir esos contratos, con herramientas de prueba y librerías revisadas como Foundry u OpenZeppelin.
Los estándares definen cómo se comporta un token. Un token fungible simple (ERC-20) no incorpora por sí solo restricciones de identidad. Para valores con restricciones se estudian estándares como ERC-3643, que añade identidad y cumplimiento en cadena, y ERC-721 o ERC-1155 para unidades no fungibles o de varias clases cuando las condiciones jurídicas lo justifican. Usar un estándar o una librería conocida no sustituye la auditoría del contrato final ni el análisis jurídico del instrumento.
Un contrato inteligente ejecuta reglas, pero no sustituye al contrato jurídico: lo que vincula a las partes sigue siendo la documentación del instrumento.
XRP Ledger y la elección de red
XRP Ledger (XRPL) es un registro distribuido distinto de las redes EVM: dispone de mecanismos nativos para emitir y transferir activos digitales sin recurrir a contratos escritos en Solidity. XRPL nativo no ejecuta contratos Solidity. El ecosistema XRPL cuenta además con una sidechain compatible con EVM, que sí permite desplegar contratos Solidity en una red distinta del XRP Ledger principal.
Elegir una red u otra depende del instrumento: de los permisos y restricciones que necesita, de los costes, de la custodia y recuperación de claves y de la capacidad de integración. Y cambiar la representación de un instrumento de una red a otra exige un procedimiento controlado —congelar movimientos, conciliar unidades y posiciones, emitir la nueva representación y desactivar la anterior—, porque replicar tokens vivos en dos redes duplicaría el derecho económico.
El enfoque de Bridge Positive
Bridge Positive desarrolla su plataforma con estos principios. El activo y el instrumento jurídico van antes que el token. El registro de autoridad y el libro contable son la referencia, y la cadena se trata como un medio de representación y trazabilidad que debe conciliarse con ellos. La plataforma está diseñada para que los datos personales no se registren en la cadena. Y el núcleo es independiente de una red concreta, para que un cambio de tecnología o de régimen jurídico no obligue a rehacer los derechos ya registrados. El núcleo aplica ya estas reglas en su entorno de laboratorio; la conexión con redes reales se incorporará instrumento a instrumento, con auditoría y con las autorizaciones aplicables.
Nota editorial: Información general sobre conceptos técnicos y jurídicos, no asesoramiento. Describe principios de diseño de la plataforma, no servicios disponibles hoy. Lo que una norma permita o exija en un caso concreto requiere un análisis profesional.
Fuentes y referencias
- Reglamento (UE) 2022/858 del Parlamento Europeo y del Consejo, de 30 de mayo de 2022, sobre un régimen piloto de infraestructuras del mercado basadas en la tecnología de registro descentralizadoRégimen piloto europeo para infraestructuras de mercado basadas en DLT.
- Ley 6/2023, de 17 de marzo, de los Mercados de Valores y de los Servicios de InversiónRepresentación de valores mediante sistemas basados en tecnología de registros distribuidos.
- Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales (RGPD)Derechos de rectificación y supresión frente a registros difíciles de modificar.
- Tecnología Bridge: identidad, derechos y tecnología
Las referencias normativas se citan como marco general. Su aplicación a un caso concreto requiere revisión profesional.


