Comment ça marche

Vanitas est une forge d'adresses personnalisées multi-chaînes côté client. Vous choisissez un préfixe et/ou un suffixe ; l'application recherche une paire de clés dont l'adresse publique correspond à ce modèle. La génération s'exécute dans Web Workers sur votre processeur. Les clés privées sont créées en mémoire sur votre appareil et ne sont jamais téléchargées.

Une adresse personnalisée est toujours une adresse cryptographique normale. La clé privée est aléatoire ; seul l'encodage public est filtré jusqu'à ce qu'il ressemble à ce que vous souhaitez – utile pour l'image de marque, les dons, les monnaies et les portefeuilles publics mémorables.

Chaque forge suit la même boucle de haut niveau, répétée des millions de fois :

1. Dessinez une clé privée aléatoire cryptographiquement sécurisée (crypto.getRandomValues).
2. Dérivez la clé publique avec la courbe de la chaîne (Ed25519 ou secp256k1).
3. Encodez l'adresse comme prévu par la chaîne (Base58, hex, bech32, …).
4. Comparez avec votre préfixe/suffixe (et vos règles de mode).
5. Sur match : arrêter les ouvriers, afficher le résultat, son/preuve/export en option.

Les travailleurs exécutent cette boucle en parallèle sur les cœurs du processeur. Le fil de discussion de l'interface utilisateur reste réactif ; la progression (tentatives, taux, ETA) est agrégée à partir des messages du travailleur. Lorsqu'un travailleur trouve un résultat positif, le pool est terminé.

Pourquoi c'est sécurisé

La recherche d'une adresse personnalisée n'affaiblit pas la clé privée. Vous rejetez des candidats jusqu'à ce que l'adresse publique semble correcte – le même processus que pour générer des clés aléatoires et conserver la plus chanceuse.

Échelles de temps attendues avec la longueur du motif et la taille de l'alphabet. Chaque caractère supplémentaire multiplie l'espace de recherche. L'interface utilisateur de Forge affiche une estimation de la difficulté en direct basée sur votre modèle et un taux de hachage mesuré ou supposé.

Pièges alphabétiques

• Solana / Bitcoin Base58 — pas de 0, O, I ou l (rejet de sosie).
• EVM — uniquement hexadécimal après 0x. Les lettres au-delà de a–f ne sont pas valides.
• Tron — les adresses commencent par T ; le caractère suivant est généralement en majuscule. Les préfixes minuscules sensibles à la casse ne correspondent souvent jamais.
• Préfixe + suffixe — les deux contraintes multiplient la difficulté. Commencez court ; développez le modèle une fois que vous connaissez votre taux.

Neuf forges partagent le même modèle UX – choisissez un mode, définissez un modèle, démarrez les travailleurs – mais chaque chaîne utilise des courbes, des hachages et des encodages d'adresse différents.

Menthe

Cryptographiquement identique à une paire de clés de portefeuille. Les Launchpads demandent une paire de clés Mint/clé privée personnalisée ; Vanitas qualifie le résultat de menthe afin que l'exportation corresponde à ce flux de travail. Ouvrez /sol?mode=mint, trouvez un motif, collez la clé dans pump.fun, Raydium, Meteora, etc.

CREATE

Le premier contrat déployé à partir d'un EOA avec un nonce 0 a une adresse déterministe : keccak256(RLP([sender, 0]))[12:]. Vanitas broie les EOA jusqu'à ce que cette adresse de contrat dérivée corresponde à votre modèle. Vous recevez la clé privée du déployeur : déployez une fois à partir d'un nouveau compte nonce-0.

CREATE2

Adresse = keccak256(0xff ‖ deployer ‖ salt ‖ initCodeHash)[12:]. Deux stratégies de mouture :

• create2-salt — correction de la clé du déployeur + hachage du code d'initialisation ; recherchez un sel qui donne l'adresse personnalisée.
• create2-deployer — correction du hachage du code salt + init ; recherchez une clé de déploiement dont l'adresse CREATE2 correspond.

Vous devez fournir un initCodeHash correct (keccak du bytecode de déploiement). Mauvais hachage → mauvaise adresse en chaîne.

Les sources de travail vivent sous src/workers/*.worker.source.ts et sont regroupées avec esbuild dans public/*-worker.js. Chaque build écrit les résumés SHA-256 dans public/worker-hash.json pour le live audit.

Après une recherche, des vérifications de sécurité clés facultatives sondent l'entropie, la disponibilité de CSPRNG et un test d'uniformité du chi carré sur des octets aléatoires — confirmant que le chemin RNG du navigateur semble sain.

Share proof crée un lien public vers /proof avec une chaîne, une adresse et un modèle uniquement — jamais la clé privée. N'importe qui peut ouvrir le lien et vérifier que l'adresse correspond au préfixe/suffixe revendiqué côté client.

Les découvertes récentes dans l'interface utilisateur utilisent sessionStorage uniquement pour les métadonnées d'adresse et de modèle. La fermeture de l'onglet efface cet historique ; les clés n’y sont pas stockées.

Même idée en dehors du navigateur : npx vanitas ouvre un assistant ou transmet des indicateurs pour les paramètres chaîne, mode, préfixe, threads et CREATE2. Les résultats écrivent un fichier JSON avec le mode 0600 lorsque le système d'exploitation le prend en charge. Forfait : npmjs.com/package/vanitas.

npx vanitas evm --mode contrat --prefix café --threads 8

1. Ouvrez DevTools → Réseau, effacez le journal, démarrez une forge — vous ne devriez voir aucune demande pendant l'exploitation minière.
2. Chargez la page, déconnectez-vous, générez à nouveau – cela fonctionne toujours.
3. Exécutez le live audit et comparez les hachages des travailleurs à worker-hash.json.
4. Lisez la source sur GitHub – en particulier src/workers/.