Esta semana básicamente he desarmado de arriba abajo la sección de XSC del libro amarillo de Dusk. Al principio, como la mayoría, también creí que XSC (Confidential Security Contract) era “ERC-20 con una cápsula de privacidad ZK”: escondes el saldo, ocultas un poco las transferencias y ya. Pero cuando lo recorres de verdad siguiendo el ciclo de vida del contrato, te das cuenta de que no es para nada así. XSC compila dentro del storage del token cosas que normalmente se manejan con cartas de un despacho de abogados y Excel: credenciales KYC, ejecución obligatoria de listas blancas, periodos de lock-up, derechos de dividendos, etc. En el momento del transfer, el circuito interno valida: si la dirección no pasa la capa de identidad de Citadel, revierte. Incluso aunque caiga el backend del proyecto, no afecta el juicio de cumplimiento.
Me di cuenta de la diferencia después de probar un poco de pseudocódigo en testnet: en ERC-20 el transfer solo mira el balance; en ERC-1400 se consulta la lista blanca en el modifier, pero la lista blanca normalmente vive en la base de datos del proyecto; en XSC se usa el modelo de cuenta de Zedger para convertir si “el poseedor de monedas pasó el KYC” en una declaración verificable con ZK, y eso se guarda como estado en el contrato. El cumplimiento no es una etiqueta pegada fuera del token; es un “gen” que viene con el token desde su nacimiento.
Lo más contraintuitivo es que privacidad y auditoría, en realidad, no se pelean: montas una prueba de conocimiento cero para ocultar importes y tenencias, pero la regulación tiene una view key para divulgación selectiva: cuánto tiene una dirección concreta, si está dentro de la lista con permisos o si ya pasó el periodo de lock-up. Esto es más sofisticado que un mezclador, y también más real que andar diciendo “cumplimiento de valores” solo con ERC-1400.
Acabo de ir a Binance y compré un poco de DUSK al contado con 15U para completar la tarea (después de comisiones, si no te quedas justo con 10U redondos, puede caducar), y de paso incrusté una tarjeta de trading: perder 0.3U también es un PNL real, no como el típico “despegue” con CreatorPad quitándote el original fee. Ustedes creen que la idea de “KYC dentro del token”, como XSC, es un verdadero avance de cumplimiento, o es una forma que las instituciones evitan porque incluye una puerta trasera bajo supervisión?
@Dusk_Foundation $DUSK #dusk
Me di cuenta de la diferencia después de probar un poco de pseudocódigo en testnet: en ERC-20 el transfer solo mira el balance; en ERC-1400 se consulta la lista blanca en el modifier, pero la lista blanca normalmente vive en la base de datos del proyecto; en XSC se usa el modelo de cuenta de Zedger para convertir si “el poseedor de monedas pasó el KYC” en una declaración verificable con ZK, y eso se guarda como estado en el contrato. El cumplimiento no es una etiqueta pegada fuera del token; es un “gen” que viene con el token desde su nacimiento.
Lo más contraintuitivo es que privacidad y auditoría, en realidad, no se pelean: montas una prueba de conocimiento cero para ocultar importes y tenencias, pero la regulación tiene una view key para divulgación selectiva: cuánto tiene una dirección concreta, si está dentro de la lista con permisos o si ya pasó el periodo de lock-up. Esto es más sofisticado que un mezclador, y también más real que andar diciendo “cumplimiento de valores” solo con ERC-1400.
Acabo de ir a Binance y compré un poco de DUSK al contado con 15U para completar la tarea (después de comisiones, si no te quedas justo con 10U redondos, puede caducar), y de paso incrusté una tarjeta de trading: perder 0.3U también es un PNL real, no como el típico “despegue” con CreatorPad quitándote el original fee. Ustedes creen que la idea de “KYC dentro del token”, como XSC, es un verdadero avance de cumplimiento, o es una forma que las instituciones evitan porque incluye una puerta trasera bajo supervisión?
@Dusk_Foundation $DUSK #dusk