#dusk $DUSK @Dusk ‎Ayer intenté enviar dinero a un amigo, pero su cuenta había sido marcada para KYC. El banco lo detuvo en ese momento; la transacción ni siquiera llegó a completarse. Eso se me quedó grabado: este tipo de revisión debería ocurrir antes, no después.

@Dusk aplica el mismo criterio a las transferencias de activos regulados. Una transferencia normal de cripto solo necesita saldo y gas, y se ejecuta. Pero para un activo regulado, Dusk primero comprueba si la billetera receptora es siquiera elegible.

‎Durante el proceso de incorporación de inversores, las billeteras se vinculan a credenciales verificadas, y las reglas de elegibilidad se definen cuando el activo se emite. Así que, cuando se envía una transferencia, el sistema la contrasta primero con esas reglas. Si el tercero no es elegible, la transferencia simplemente no se ejecuta. No hay nada que revertir, nada que congelar más tarde.

‎Esto importa muchísimo en las finanzas reguladas. Si una transferencia inválida llegara a asentarse, no sería solo un fallo: se convertiría en una infracción de cumplimiento que luego habría que deshacer, a veces involucrando a un regulador. Bloquearla antes de enviarla evita todo eso por completo. Este es exactamente el tipo de problema #Dusk. diseñado para resolver a nivel de protocolo.

‎Lo que no había considerado antes es cuánta actualización y mantenimiento requiere. El estado del inversor, la jurisdicción, las credenciales: nada de eso permanece fijo. Si esos datos se vuelven obsoletos, incluso un inversor genuino podría acabar bloqueado también.

‎Cambiaron la forma en que veo el cumplimiento aquí: menos como papeleo que se adjunta después, y más como una condición que debe cumplirse antes de que la transferencia pueda siquiera ocurrir.

‎¿Quién termina siendo responsable de mantener estas reglas de elegibilidad actualizadas y cómo se evita que eso se convierta, a su vez, en un cuello de botella?

‎¿Quién debería actualizar las reglas de elegibilidad?

@Dusk #Dusk/usdt✅
$TUT
$PORTAL
Issuer
60%
Compliance provider
0%
Regulator
20%
On-chain automation
20%
5 Votos • Votación cerrada