Llevar un fondo a la cadena no es técnicamente difícil: contratos, participaciones, transferencias, listas blancas; en unas semanas puede estar funcionando. Lo difícil es tener que responder cada mes a la misma pregunta: ¿cuántos activos reales hay detrás de cada participación en la cadena?
Esta pregunta no se puede resolver solo con código, porque apunta al mundo fuera de la cadena: el saldo de las cuentas de custodia, el flujo de efectivo de los fondos de préstamos, el valor liquidativo de los fondos del mercado monetario, los pagos de las cuentas por cobrar. Esas cifras están en los sistemas de los bancos, en las hojas de cálculo de los auditores y en los modelos de valoración. Lo que ve el contrato en la cadena es una cifra que una dirección envía periódicamente; no tiene forma de saber cómo se calculó.
Así surge una situación extraña: se ha completado la «tokenización» de los activos, pero no la de la confianza. Las participaciones pueden circular en la cadena las 24 horas del día, los 7 días de la semana, pero el valor que las respalda sigue dependiendo de un informe mensual firmado por una persona.
@Space and Time aborda precisamente este paso. Su enfoque no consiste en llevar los activos a la cadena, sino en hacer que los «cálculos» sean verificables: los datos fuera de la cadena permanecen en las bases de datos que las empresas ya utilizan, se verifican mediante integración, se consultan conjuntamente con la actividad en la cadena y, por último, Proof of SQL emite una prueba. Se puede verificar de forma independiente cómo se calcula el valor liquidativo, qué cuentas se suman para determinar las reservas y cómo se filtran las listas de cumplimiento normativo, sin que quien realiza la verificación necesite ver los registros originales.
La importancia de esto se concentra en tres ámbitos.
El primero es la auditoría. Antes, los auditores solo podían hacer muestreos, porque verificar todos los datos resultaba demasiado costoso. Ahora pueden comprobar si «el resultado es correcto según este criterio de agregación», sin tener que llevarse una copia de los datos de los clientes. La auditoría pasa de «confío en que lo hayas calculado» a «he verificado tu algoritmo».
El segundo es la prueba de reservas. Tanto los exchanges como los emisores de stablecoins están ofreciendo pruebas de reservas, pero en la mayoría de los casos se trata de «una instantánea del saldo en un momento dado» y la información la divulga la propia entidad. El cálculo verificable permite convertirlo en un criterio que pueda verificarse continuamente: la correspondencia entre reservas y pasivos, el intervalo temporal y el método de agregación quedan fijados en una consulta reproducible que terceros pueden volver a ejecutar en cualquier momento.
El destino final de la tokenización no es llevar más activos a la cadena, sino lograr que se pueda confiar directamente en la cifra que aparece en ella. #sxt $SXT @SpaceandTime
Esta pregunta no se puede resolver solo con código, porque apunta al mundo fuera de la cadena: el saldo de las cuentas de custodia, el flujo de efectivo de los fondos de préstamos, el valor liquidativo de los fondos del mercado monetario, los pagos de las cuentas por cobrar. Esas cifras están en los sistemas de los bancos, en las hojas de cálculo de los auditores y en los modelos de valoración. Lo que ve el contrato en la cadena es una cifra que una dirección envía periódicamente; no tiene forma de saber cómo se calculó.
Así surge una situación extraña: se ha completado la «tokenización» de los activos, pero no la de la confianza. Las participaciones pueden circular en la cadena las 24 horas del día, los 7 días de la semana, pero el valor que las respalda sigue dependiendo de un informe mensual firmado por una persona.
@Space and Time aborda precisamente este paso. Su enfoque no consiste en llevar los activos a la cadena, sino en hacer que los «cálculos» sean verificables: los datos fuera de la cadena permanecen en las bases de datos que las empresas ya utilizan, se verifican mediante integración, se consultan conjuntamente con la actividad en la cadena y, por último, Proof of SQL emite una prueba. Se puede verificar de forma independiente cómo se calcula el valor liquidativo, qué cuentas se suman para determinar las reservas y cómo se filtran las listas de cumplimiento normativo, sin que quien realiza la verificación necesite ver los registros originales.
La importancia de esto se concentra en tres ámbitos.
El primero es la auditoría. Antes, los auditores solo podían hacer muestreos, porque verificar todos los datos resultaba demasiado costoso. Ahora pueden comprobar si «el resultado es correcto según este criterio de agregación», sin tener que llevarse una copia de los datos de los clientes. La auditoría pasa de «confío en que lo hayas calculado» a «he verificado tu algoritmo».
El segundo es la prueba de reservas. Tanto los exchanges como los emisores de stablecoins están ofreciendo pruebas de reservas, pero en la mayoría de los casos se trata de «una instantánea del saldo en un momento dado» y la información la divulga la propia entidad. El cálculo verificable permite convertirlo en un criterio que pueda verificarse continuamente: la correspondencia entre reservas y pasivos, el intervalo temporal y el método de agregación quedan fijados en una consulta reproducible que terceros pueden volver a ejecutar en cualquier momento.
El destino final de la tokenización no es llevar más activos a la cadena, sino lograr que se pueda confiar directamente en la cifra que aparece en ella. #sxt $SXT @SpaceandTime