Dusk acaba de lanzar una wallet y un SDK, pero ¿por qué no lo hicieron de la manera en que lo hace el mercado? Esa es la parte que vale la pena leer
La mayor parte de lo que he escrito sobre Dusk en esta campaña ha girado en torno al protocolo: emisión nativa, modelo de privacidad, socios institucionales. Pero hay una cosa que seguí saltándome: aquello que decide si algún protocolo se usa de verdad por constructores reales: la experiencia de desarrollador.
En abril de 2026, Dusk envió la versión beta de Dusk Wallet y el SDK Dusk Connect. Extensiones para Chrome y Firefox, con una sola base de código, que admite tanto cuentas públicas como cuentas blindadas en la misma interfaz.
El API del proveedor está modelado a partir de EIP-1193, la interfaz exacta que usa MetaMask, familiar para la mayoría de desarrolladores Web3. Como Dusk no es EVM, los métodos usan un prefijo dusk_*, y el protocolo de descubrimiento es basado en eventos, así que múltiples wallets compatibles pueden coexistir en la misma página sin conflictos.
La arquitectura del driver es la parte más distintiva: los desarrolladores despliegan un contrato inteligente junto con un "driver"; los usuarios lo instalan en la wallet para interactuar exactamente como el desarrollador pretendía. Esto resuelve un problema real: originalmente, las pruebas ZK requerían claves de prover de más de 200 MB. El equipo las comprimió hasta unos pocos KB usando tecnología de descriptores de circuitos.
Esto también explica por qué Dusk no siguió la tendencia de wallets embebidas dominante en 2026: donde los usuarios inician sesión con correo electrónico o Google y la wallet se crea en silencio detrás del SDK. Ese modelo pone la generación de pruebas ZK en un servidor de un tercero. Con Dusk, las pruebas tienen que ejecutarse del lado del cliente; no puedes delegarlas y aun así mantener el modelo de privacidad intacto.
La pregunta con la que me quedo es: la tasa a la que los constructores reales realmente despliegan dApps será una métrica más honesta que cualquier benchmark de protocolo.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
La mayor parte de lo que he escrito sobre Dusk en esta campaña ha girado en torno al protocolo: emisión nativa, modelo de privacidad, socios institucionales. Pero hay una cosa que seguí saltándome: aquello que decide si algún protocolo se usa de verdad por constructores reales: la experiencia de desarrollador.
En abril de 2026, Dusk envió la versión beta de Dusk Wallet y el SDK Dusk Connect. Extensiones para Chrome y Firefox, con una sola base de código, que admite tanto cuentas públicas como cuentas blindadas en la misma interfaz.
El API del proveedor está modelado a partir de EIP-1193, la interfaz exacta que usa MetaMask, familiar para la mayoría de desarrolladores Web3. Como Dusk no es EVM, los métodos usan un prefijo dusk_*, y el protocolo de descubrimiento es basado en eventos, así que múltiples wallets compatibles pueden coexistir en la misma página sin conflictos.
La arquitectura del driver es la parte más distintiva: los desarrolladores despliegan un contrato inteligente junto con un "driver"; los usuarios lo instalan en la wallet para interactuar exactamente como el desarrollador pretendía. Esto resuelve un problema real: originalmente, las pruebas ZK requerían claves de prover de más de 200 MB. El equipo las comprimió hasta unos pocos KB usando tecnología de descriptores de circuitos.
Esto también explica por qué Dusk no siguió la tendencia de wallets embebidas dominante en 2026: donde los usuarios inician sesión con correo electrónico o Google y la wallet se crea en silencio detrás del SDK. Ese modelo pone la generación de pruebas ZK en un servidor de un tercero. Con Dusk, las pruebas tienen que ejecutarse del lado del cliente; no puedes delegarlas y aun así mantener el modelo de privacidad intacto.
La pregunta con la que me quedo es: la tasa a la que los constructores reales realmente despliegan dApps será una métrica más honesta que cualquier benchmark de protocolo.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
