#dusk $DUSK @Dusk ........ Esperaba que la parte difícil de conectar DUSK con BSC fuera la infraestructura entre cadenas. El detalle que llamó mi atención fue mucho más pequeño: un campo de memo.
Piensa en ello como una etiqueta de envío. El paquete puede salir correctamente, pero si la etiqueta contiene espacios en blanco ocultos o la dirección es incorrecta, el sistema puede no saber a dónde enviarlo......
Eso es lo que hace interesante el puente BEP20 de Dusk.
El DUSK nativo se bloquea primero en la red principal de Dusk y, luego, el equivalente DUSK BEP20 se acuña en BSC. El activo de la red principal sigue siendo la fuente de verdad, mientras que el puente cobra una tarifa fija de 1 DUSK. La documentación actual indica que el procesamiento normalmente tarda alrededor de una hora.
Se fue más a fondo.......
El Web Wallet de Dusk ahora aborda directamente el caso límite de copiar y pegar. La actividad pública en GitHub muestra el PR #954, “Normalizar los memos del puente BEP20 antes de enviarlos,” que llega a ready_for_review, con verificaciones automatizadas y actividad de revisión visible.
La idea es simple: normalizar el memo una vez y luego usar ese mismo valor ya limpio a través de la validación, la revisión y el envío.
Ese último detalle captó mi atención..........
La propia documentación de Dusk advierte que un memo faltante o inválido puede impedir el enrutamiento automático y hacer que una transferencia sea irrecuperable. Los usuarios aún deben verificar el destino, pero el wallet puede eliminar una fuente de desajuste evitable.....
Y la dirección a más largo plazo es incluso más interesante.
Los planes de arquitectura de Dusk apuntan a migrar ERC20 y BEP20 DUSK hacia DuskEVM, usando un puente nativo y sin confianza, sin custodios externos ni activos envueltos...
Así que esta corrección mejora el puente de hoy........
El roadmap busca que la arquitectura del puente de mañana sea fundamentalmente diferente.....................
Para la infraestructura que mueve valor real, ¿no es mejor eliminar un modo de fallo que simplemente advertir a los usuarios sobre ello?
$ADA $ONG
Piensa en ello como una etiqueta de envío. El paquete puede salir correctamente, pero si la etiqueta contiene espacios en blanco ocultos o la dirección es incorrecta, el sistema puede no saber a dónde enviarlo......
Eso es lo que hace interesante el puente BEP20 de Dusk.
El DUSK nativo se bloquea primero en la red principal de Dusk y, luego, el equivalente DUSK BEP20 se acuña en BSC. El activo de la red principal sigue siendo la fuente de verdad, mientras que el puente cobra una tarifa fija de 1 DUSK. La documentación actual indica que el procesamiento normalmente tarda alrededor de una hora.
Se fue más a fondo.......
El Web Wallet de Dusk ahora aborda directamente el caso límite de copiar y pegar. La actividad pública en GitHub muestra el PR #954, “Normalizar los memos del puente BEP20 antes de enviarlos,” que llega a ready_for_review, con verificaciones automatizadas y actividad de revisión visible.
La idea es simple: normalizar el memo una vez y luego usar ese mismo valor ya limpio a través de la validación, la revisión y el envío.
Ese último detalle captó mi atención..........
La propia documentación de Dusk advierte que un memo faltante o inválido puede impedir el enrutamiento automático y hacer que una transferencia sea irrecuperable. Los usuarios aún deben verificar el destino, pero el wallet puede eliminar una fuente de desajuste evitable.....
Y la dirección a más largo plazo es incluso más interesante.
Los planes de arquitectura de Dusk apuntan a migrar ERC20 y BEP20 DUSK hacia DuskEVM, usando un puente nativo y sin confianza, sin custodios externos ni activos envueltos...
Así que esta corrección mejora el puente de hoy........
El roadmap busca que la arquitectura del puente de mañana sea fundamentalmente diferente.....................
Para la infraestructura que mueve valor real, ¿no es mejor eliminar un modo de fallo que simplemente advertir a los usuarios sobre ello?
$ADA $ONG
