#dusk $DUSK
Lo que captó mi atención no fue la cifra de 300M€ asociada a NPEX; fue un detalle más pequeño, oculto en la documentación de la infraestructura de mercado de Dusk: antes de que un activo pueda moverse, una billetera tiene que estar vinculada a un participante verificado. No “KYC” una vez y se olvida. Vinculación por activo como condición de transferencia exigible.
Quería comprobar qué significa eso mecánicamente, porque la tokenización conforme se menciona con ligereza.
Esta es la secuencia que Dusk documenta para algo como el onboarding de NPEX: un emisor define reglas de elegibilidad para el activo. Las billeteras de los inversores se vinculan a credenciales verificadas. A partir de ahí, la capa del contrato de Transferencia impone quién siquiera tiene permitido mantener o mover el token; la restricción vive en la capa de liquidación, no en una casilla de verificación del frontend. La propia liquidación une la pata del activo y la pata del pago para lograr una finalidad determinista, de modo que no obtienes un estado donde las acciones se movieron pero el pago no.
Por qué esto importa: NPEX es un MTF holandés bajo supervisión de la AFM. No puede simplemente señalar a un ERC-20 público y llamarlo un valor. La comprobación de elegibilidad tiene que ser exigible on-chain, no solo en la interfaz; de lo contrario, la parte regulada es teatro.
La parte que me gustaría verificar y que no he visto especificada del todo: qué ocurre cuando cambia la elegibilidad; si un inversor se desregistra o si se actualiza una norma de jurisdicción para tokens ya mantenidos. ¿El vínculo se revoca de forma retroactiva o solo bloquea las transferencias futuras?
Esa es la prueba real de si es un sistema de activo regulado de verdad o solo una comprobación de conformidad en el momento de la emisión.
El movimiento de 300M€ por parte de NPEX es un dato. Que la lógica de control de transferencias resista un caso límite regulatorio en vivo es lo que decide si esto se generaliza al resto del sector.
Sinceramente, me da curiosidad cómo gestiona Dusk el caso de revocación: ¿alguien se metió de cerca en la especificación del Transfer controlado por Zedger/Hedger lo suficientemente como para saberlo?
@Dusk_Foundation $DUSK #dusk
Lo que captó mi atención no fue la cifra de 300M€ asociada a NPEX; fue un detalle más pequeño, oculto en la documentación de la infraestructura de mercado de Dusk: antes de que un activo pueda moverse, una billetera tiene que estar vinculada a un participante verificado. No “KYC” una vez y se olvida. Vinculación por activo como condición de transferencia exigible.
Quería comprobar qué significa eso mecánicamente, porque la tokenización conforme se menciona con ligereza.
Esta es la secuencia que Dusk documenta para algo como el onboarding de NPEX: un emisor define reglas de elegibilidad para el activo. Las billeteras de los inversores se vinculan a credenciales verificadas. A partir de ahí, la capa del contrato de Transferencia impone quién siquiera tiene permitido mantener o mover el token; la restricción vive en la capa de liquidación, no en una casilla de verificación del frontend. La propia liquidación une la pata del activo y la pata del pago para lograr una finalidad determinista, de modo que no obtienes un estado donde las acciones se movieron pero el pago no.
Por qué esto importa: NPEX es un MTF holandés bajo supervisión de la AFM. No puede simplemente señalar a un ERC-20 público y llamarlo un valor. La comprobación de elegibilidad tiene que ser exigible on-chain, no solo en la interfaz; de lo contrario, la parte regulada es teatro.
La parte que me gustaría verificar y que no he visto especificada del todo: qué ocurre cuando cambia la elegibilidad; si un inversor se desregistra o si se actualiza una norma de jurisdicción para tokens ya mantenidos. ¿El vínculo se revoca de forma retroactiva o solo bloquea las transferencias futuras?
Esa es la prueba real de si es un sistema de activo regulado de verdad o solo una comprobación de conformidad en el momento de la emisión.
El movimiento de 300M€ por parte de NPEX es un dato. Que la lógica de control de transferencias resista un caso límite regulatorio en vivo es lo que decide si esto se generaliza al resto del sector.
Sinceramente, me da curiosidad cómo gestiona Dusk el caso de revocación: ¿alguien se metió de cerca en la especificación del Transfer controlado por Zedger/Hedger lo suficientemente como para saberlo?
@Dusk_Foundation $DUSK #dusk