#dusk $DUSK
Cada cadeia RWA afirma conformidade incorporada. O que realmente me fez parar foi uma linha específica nos documentos de infraestrutura de mercado da Dusk: controles de transferência existem como uma etapa distinta e imposta Enforce who can hold or transfer separada do onboarding e separada da liquidação. A maioria das cadeias mistura tudo isso em uma coisa: se você tem tokens, você pode movê-los.
Então eu quis verificar o que essa separação de fato significa para a NPEX ao colocar em onchain.
Documentado: a arquitetura da Dusk divide o ciclo de vida do ativo regulamentado em etapas: configuração do emissor, onboarding de investidores (vinculação da carteira a participantes verificados), controles de transferência, negociação/distribuição e liquidação com finalização determinística. Cada etapa é um checkpoint, não apenas um passo de interface. Zedger executa isso nativamente na DuskDS; Hedger traz um modelo semelhante para a DuskEVM usando criptografia homomórfica + provas ZK, para que os saldos permaneçam criptografados enquanto continuam auditáveis.
Por que isso importa: um livro-razão público pode provar que uma transação aconteceu. Ele não pode, por si só, provar que o destinatário era elegível para receber aquele ativo. Essa verificação de elegibilidade é o que separa Tokenized de regulamentado. A NPEX trazendo seu ~€300M+ de AUM para o onchain é o primeiro teste real de se essa camada de enforcement roda ao vivo — e não apenas nos documentos.
O que eu não consigo confirmar com material público: se a atividade onchain atual da NPEX de fato roteia pela lógica de vinculação de carteira e de controles de transferência no nível do contrato, ou se esse enforcement ainda acontece off-chain hoje, com a blockchain atuando principalmente como camada de liquidação e registro. Os documentos da Dusk descrevem o design; eles não mostram a configuração ao vivo da NPEX.
Curiosidade genuína: alguém já viu uma transação (ou uma transação rejeitada) do deployment da NPEX que mostre a lógica de controle de transferência bloqueando de fato um detentor inelegível onchain, e não apenas na camada da corretora?
@Dusk_Foundation $DUSK #dusk
Cada cadeia RWA afirma conformidade incorporada. O que realmente me fez parar foi uma linha específica nos documentos de infraestrutura de mercado da Dusk: controles de transferência existem como uma etapa distinta e imposta Enforce who can hold or transfer separada do onboarding e separada da liquidação. A maioria das cadeias mistura tudo isso em uma coisa: se você tem tokens, você pode movê-los.
Então eu quis verificar o que essa separação de fato significa para a NPEX ao colocar em onchain.
Documentado: a arquitetura da Dusk divide o ciclo de vida do ativo regulamentado em etapas: configuração do emissor, onboarding de investidores (vinculação da carteira a participantes verificados), controles de transferência, negociação/distribuição e liquidação com finalização determinística. Cada etapa é um checkpoint, não apenas um passo de interface. Zedger executa isso nativamente na DuskDS; Hedger traz um modelo semelhante para a DuskEVM usando criptografia homomórfica + provas ZK, para que os saldos permaneçam criptografados enquanto continuam auditáveis.
Por que isso importa: um livro-razão público pode provar que uma transação aconteceu. Ele não pode, por si só, provar que o destinatário era elegível para receber aquele ativo. Essa verificação de elegibilidade é o que separa Tokenized de regulamentado. A NPEX trazendo seu ~€300M+ de AUM para o onchain é o primeiro teste real de se essa camada de enforcement roda ao vivo — e não apenas nos documentos.
O que eu não consigo confirmar com material público: se a atividade onchain atual da NPEX de fato roteia pela lógica de vinculação de carteira e de controles de transferência no nível do contrato, ou se esse enforcement ainda acontece off-chain hoje, com a blockchain atuando principalmente como camada de liquidação e registro. Os documentos da Dusk descrevem o design; eles não mostram a configuração ao vivo da NPEX.
Curiosidade genuína: alguém já viu uma transação (ou uma transação rejeitada) do deployment da NPEX que mostre a lógica de controle de transferência bloqueando de fato um detentor inelegível onchain, e não apenas na camada da corretora?
@Dusk_Foundation $DUSK #dusk