@Dusk_Foundation I mantinha voltando a um estado de transação awkward em Dusk: a carteira ainda pode ser um detentor válido, o ativo ainda está lá, nada foi confiscado ou quebrado—e ainda assim um local pode precisar rejeitar a próxima negociação.
No começo, isso pareceu uma conformidade duplicada. Se a carteira já passou por uma verificação de elegibilidade, por que pedir de novo?
Mas quanto mais eu olhava, menos útil parecia ser uma única flag de aprovado/não aprovado.
Manter um ativo responde a uma pergunta. Negociá-lo em algum lugar responde a outra. Um participante pode atender às condições de transferência do ativo enquanto falha uma regra específica do local por causa de jurisdição, status de onboarding ou alguma permissão que mudou depois que o ativo foi adquirido.
Essa separação importa operacionalmente. Caso contrário, todas as regras do local começam a vazar para a lógica de propriedade do ativo, e uma restrição local de negociação pode acidentalmente virar uma restrição global para o detentor.
Estou mais interessado em onde acontece a rejeição. Se os controles de transferência baseados em Dusk, as credenciais e a lógica do local conseguem identificar a divergência antes de começar o trabalho de liquidação, isso transforma a falha de um problema de desfazer/rollback em um problema de roteamento.
Ainda assim, há uma pergunta mais difícil por baixo disso: quem explica a rejeição quando cada camada diz algo ligeiramente diferente?
É isso que eu observaria em um mercado ao vivo—com que frequência “pode manter” e “pode negociar aqui” divergem e se o sistema consegue detectar isso cedo o suficiente.#dusk $DUSK
No começo, isso pareceu uma conformidade duplicada. Se a carteira já passou por uma verificação de elegibilidade, por que pedir de novo?
Mas quanto mais eu olhava, menos útil parecia ser uma única flag de aprovado/não aprovado.
Manter um ativo responde a uma pergunta. Negociá-lo em algum lugar responde a outra. Um participante pode atender às condições de transferência do ativo enquanto falha uma regra específica do local por causa de jurisdição, status de onboarding ou alguma permissão que mudou depois que o ativo foi adquirido.
Essa separação importa operacionalmente. Caso contrário, todas as regras do local começam a vazar para a lógica de propriedade do ativo, e uma restrição local de negociação pode acidentalmente virar uma restrição global para o detentor.
Estou mais interessado em onde acontece a rejeição. Se os controles de transferência baseados em Dusk, as credenciais e a lógica do local conseguem identificar a divergência antes de começar o trabalho de liquidação, isso transforma a falha de um problema de desfazer/rollback em um problema de roteamento.
Ainda assim, há uma pergunta mais difícil por baixo disso: quem explica a rejeição quando cada camada diz algo ligeiramente diferente?
É isso que eu observaria em um mercado ao vivo—com que frequência “pode manter” e “pode negociar aqui” divergem e se o sistema consegue detectar isso cedo o suficiente.#dusk $DUSK