L’adresse dangereuse de Dusk n’est pas toujours une adresse invalide. Elle peut tout à fait être une adresse parfaitement valide provenant du mauvais modèle de transaction.

Les adresses Moonlight et Phoenix sont toutes deux en Base58, donc un simple test « est-ce que ça ressemble à du Base58 ? » me dit trop peu. Moonlight correspond à une clé publique BLS12-381 G2 compressée. Phoenix correspond à deux points Jubjub compressés. Même alphabet à l’écran, structure différente en dessous.

Cela compte si je construis un formulaire de dépôt ou de retrait DUSK autour de Moonlight. Le chemin d’échange de Dusk est explicitement Moonlight, tandis que Phoenix nécessite un modèle de garde et d’analyse différent. Si mon champ d’adresse ne fait qu’un contrôle des caractères, je peux accepter une adresse Phoenix protégée dans un flux conçu pour affecter, analyser ou envoyer vers des comptes publics Moonlight.

L’échec apparaît tardivement. L’utilisateur voit « adresse acceptée ». Je l’enregistre dans ma base de données. Ensuite, le générateur de transaction ou le pipeline de dépôt est le premier endroit qui découvre que l’adresse appartient à la mauvaise famille.

Je parserais l’adresse de manière structurelle à la frontière et j’affirmerais le modèle attendu avant de la sauvegarder.

Sur Dusk, une adresse valide et une destination valide sont deux contrôles différents.

$GNO $SOXSB #dusk $DUSK @Dusk