@Dusk_Foundation Sigo volviendo a un estado de transacción incómodo en Dusk: la cartera todavía puede ser un titular válido, el activo sigue estando allí, no se ha confiscado ni roto nada—y aun así un venue puede necesitar rechazar la próxima operación.
Al principio eso me pareció un cumplimiento duplicado. Si la cartera ya pasó una comprobación de elegibilidad, ¿por qué volver a preguntarlo?
Pero cuanto más lo miraba, menos útil parecía una sola bandera aprobada/no aprobada.
Tener un activo responde una pregunta. Operarlo en algún lugar responde otra. Un participante podría cumplir las condiciones de transferencia del activo mientras falla una regla específica del venue debido a la jurisdicción, el estado de incorporación, o algún permiso que cambió después de que el activo se adquirió.
Esa separación es importante a nivel operativo. De lo contrario, cada regla del venue empieza a filtrarse en la lógica de propiedad del activo, y una restricción local de negociación puede convertirse accidentalmente en una restricción global para el titular.
Me interesa más dónde ocurre el rechazo. Si los controles de transferencia basados en Dusk, las credenciales y la lógica del venue pueden identificar la discordancia antes de que empiece el trabajo de liquidación, eso transforma el fallo de un problema de deshacer a un problema de enrutamiento.
Aun así, hay una pregunta más difícil debajo: ¿quién explica el rechazo cuando cada capa dice algo ligeramente diferente?
Eso es lo que observaría en un mercado en vivo—con qué frecuencia “puede mantener” y “puede operar aquí” divergen, y si el sistema lo detecta a tiempo.#dusk $DUSK
Al principio eso me pareció un cumplimiento duplicado. Si la cartera ya pasó una comprobación de elegibilidad, ¿por qué volver a preguntarlo?
Pero cuanto más lo miraba, menos útil parecía una sola bandera aprobada/no aprobada.
Tener un activo responde una pregunta. Operarlo en algún lugar responde otra. Un participante podría cumplir las condiciones de transferencia del activo mientras falla una regla específica del venue debido a la jurisdicción, el estado de incorporación, o algún permiso que cambió después de que el activo se adquirió.
Esa separación es importante a nivel operativo. De lo contrario, cada regla del venue empieza a filtrarse en la lógica de propiedad del activo, y una restricción local de negociación puede convertirse accidentalmente en una restricción global para el titular.
Me interesa más dónde ocurre el rechazo. Si los controles de transferencia basados en Dusk, las credenciales y la lógica del venue pueden identificar la discordancia antes de que empiece el trabajo de liquidación, eso transforma el fallo de un problema de deshacer a un problema de enrutamiento.
Aun así, hay una pregunta más difícil debajo: ¿quién explica el rechazo cuando cada capa dice algo ligeramente diferente?
Eso es lo que observaría en un mercado en vivo—con qué frecuencia “puede mantener” y “puede operar aquí” divergen, y si el sistema lo detecta a tiempo.#dusk $DUSK