A Dusk acabou de lançar uma wallet e um SDK, mas por que eles não fizeram isso do jeito que o mercado faz é a parte que vale a pena ler
Grande parte do que eu escrevi sobre a Dusk nesta campanha girou em torno do protocolo: emissão nativa, modelo de privacidade, parceiros institucionais. Mas há uma coisa que eu continuei pulando — a coisa que decide se qualquer protocolo será realmente usado por construtores: a experiência do desenvolvedor.
Em abril de 2026, a Dusk lançou a versão beta da Dusk Wallet e do Dusk Connect SDK. Extensões para Chrome e Firefox, uma única base de código, compatível com contas públicas e protegidas na mesma interface.
A API do provedor é modelada após a EIP-1193, a interface exata que o MetaMask usa, familiar para a maioria dos desenvolvedores Web3. Como a Dusk não é EVM, os métodos usam um prefixo dusk_*, e o protocolo de descoberta é baseado em eventos, então múltiplas wallets compatíveis podem coexistir na mesma página sem conflitos.
A arquitetura do driver é a parte mais distinta: desenvolvedores implantam um contrato inteligente junto de um "driver" que os usuários instalam na wallet para interagir exatamente do jeito que o desenvolvedor pretendia. Isso resolve um problema real: provas ZK originalmente exigiam chaves de prover maiores do que 200MB. O time as compactou para alguns KB usando tecnologia de descritor de circuito.
Isso também explica por que a Dusk não seguiu a tendência de embedded wallet dominante em 2026 — em que os usuários fazem login com e-mail ou Google e uma wallet é criada silenciosamente por trás do SDK. Esse modelo coloca a geração de provas ZK em um servidor de terceiros. Com a Dusk, as provas precisam rodar do lado do cliente — você não consegue delegar isso e ainda manter o modelo de privacidade intacto.
A pergunta com a qual eu estou ficando é: a taxa na qual os construtores reais efetivamente implantam dApps será uma métrica mais honesta do que qualquer benchmark de protocolo.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
Grande parte do que eu escrevi sobre a Dusk nesta campanha girou em torno do protocolo: emissão nativa, modelo de privacidade, parceiros institucionais. Mas há uma coisa que eu continuei pulando — a coisa que decide se qualquer protocolo será realmente usado por construtores: a experiência do desenvolvedor.
Em abril de 2026, a Dusk lançou a versão beta da Dusk Wallet e do Dusk Connect SDK. Extensões para Chrome e Firefox, uma única base de código, compatível com contas públicas e protegidas na mesma interface.
A API do provedor é modelada após a EIP-1193, a interface exata que o MetaMask usa, familiar para a maioria dos desenvolvedores Web3. Como a Dusk não é EVM, os métodos usam um prefixo dusk_*, e o protocolo de descoberta é baseado em eventos, então múltiplas wallets compatíveis podem coexistir na mesma página sem conflitos.
A arquitetura do driver é a parte mais distinta: desenvolvedores implantam um contrato inteligente junto de um "driver" que os usuários instalam na wallet para interagir exatamente do jeito que o desenvolvedor pretendia. Isso resolve um problema real: provas ZK originalmente exigiam chaves de prover maiores do que 200MB. O time as compactou para alguns KB usando tecnologia de descritor de circuito.
Isso também explica por que a Dusk não seguiu a tendência de embedded wallet dominante em 2026 — em que os usuários fazem login com e-mail ou Google e uma wallet é criada silenciosamente por trás do SDK. Esse modelo coloca a geração de provas ZK em um servidor de terceiros. Com a Dusk, as provas precisam rodar do lado do cliente — você não consegue delegar isso e ainda manter o modelo de privacidade intacto.
A pergunta com a qual eu estou ficando é: a taxa na qual os construtores reais efetivamente implantam dApps será uma métrica mais honesta do que qualquer benchmark de protocolo.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
