Solana DvP exige que tanto el efectivo como los activos de una operación estén completamente disponibles antes de ejecutar el intercambio. El nuevo estándar institucional de la Solana Foundation bloquea ambas partes en cuentas de custodia separadas y las transfiere de forma simultánea, pero no aporta la liquidez ni la financiación necesarias para llegar a ese punto.
La fundación anunció el programa el 6 de octubre como un estándar de código abierto para la liquidación mediante entrega contra pago (DvP). Su objetivo es evitar el riesgo de que una de las partes entregue su activo o su dinero sin recibir a cambio la contraprestación acordada. La operación se completa entera o no se completa.
Liquidación bruta y sin compensación entre operaciones
El diseño publicado limita cada registro a un único intercambio entre dos partes. Las dos patas de la operación deben consistir en cuentas de tokens alojadas en Solana y no se permiten ejecuciones parciales. Un pago desde una cuenta bancaria a través de otro sistema queda fuera de este intercambio atómico.
Antes de liquidar, el comprador debe aportar el token que representa el efectivo y el vendedor debe depositar el activo correspondiente. El código comprueba que cada cuenta de custodia contiene, como mínimo, la cantidad pactada. Si una de las dos partes no está suficientemente financiada, la liquidación falla. Cualquier excedente se devuelve a la parte que lo depositó y no incrementa la cantidad que recibe la contraparte.
La financiación se realiza mediante transferencias de tokens convencionales y puede ejecutarse desde un sistema de custodia o tesorería. No requiere una llamada de financiación específica dentro del programa. Para completar el intercambio también es necesaria la firma de una autoridad de liquidación, una tercera dirección designada en el registro de la operación. Los destinos de los fondos quedan fijados al crearla.
Solana DvP tampoco incorpora compensación o netting entre operaciones. Las entidades que quieran agrupar obligaciones y liquidar únicamente el saldo neto deberán organizar esa función fuera del programa, antes de decidir cuánto efectivo y qué activos envían a las cuentas de custodia.
Menos espera, pero no necesariamente menos liquidez
La exigencia de financiar el importe bruto de cada operación puede aumentar las necesidades de liquidez frente a un sistema que compense varias obligaciones. A cambio, una entidad podría recuperar antes el efectivo o los activos recibidos y destinarlos a una operación posterior. Eso podría reducir el tiempo durante el que necesita financiación externa o la liquidez que mantiene reservada para una secuencia de pagos.
El resultado económico dependerá de cuándo deba inmovilizarse el dinero, cuándo puedan utilizarse los fondos recibidos y qué acuerdo de financiación tenga cada participante. La documentación del programa no ofrece datos medidos sobre ahorro de capital ni una comparación del coste total. La liquidación atómica protege frente al riesgo de entrega dentro del intercambio, pero no elimina las necesidades financieras que rodean la operación.
La protección tampoco cubre todos los riesgos asociados a los tokens. Un token de efectivo mantiene los riesgos de crédito y reembolso de su emisor, mientras que un token que represente un activo regulado puede estar sujeto a controles de transferencia. Las facultades de congelar, pausar o delegar permanentemente el control siguen siendo relevantes mientras los tokens permanecen depositados.
Las instrucciones de recuperación permiten a las partes reclamar sus propios fondos, rechazar la operación o solicitar su cancelación. Sin embargo, una orden del emisor que congele una cuenta o bloquee transferencias puede impedir que una operación totalmente financiada llegue a completarse o que los reembolsos se ejecuten. También debe estar disponible la autoridad autorizada para firmar la liquidación.
Despliegue y próximos datos necesarios
La documentación de la fundación identifica un programa actualizable en mainnet-beta y devnet. En la tabla de la red principal figura una autoridad con capacidad para modificar el programa, un elemento de gobernanza que las entidades deberán tener en cuenta. El cliente publicado apunta además a una revisión concreta del código, cuya última versión registrada está fechada el 30 de septiembre.
La firma de seguridad Cantina auditó entre el 21 y el 28 de mayo una versión anterior del repositorio. Sus cuatro hallazgos de riesgo medio aparecen como corregidos; otros tres de bajo riesgo y seis informativos constan como reconocidos. La Solana Foundation afirma que el programa está preparado para fondos reales y busca socios de diseño y primeros participantes antes de su lanzamiento en producción.
JPMorgan aportó comentarios sobre prácticas de liquidación de valores, pero el anuncio aclara que el banco no participó en el diseño, desarrollo, funcionamiento o aprobación del programa, ni lo respalda o garantiza. La evidencia decisiva para las instituciones será comprobar, en operaciones reales, cuánto capital deben inmovilizar, durante cuánto tiempo, cuál es el coste de financiación y cuándo pueden volver a utilizar los activos recibidos.
