Dans cette application éducative et expérimentale, les jetons ERC20 sous-jacents se trouvent dans le compte EVM du coffre. Sur Midnight, les utilisateurs détiennent des jetons de coffre protégés représentant leurs droits sur ce pool. Le fait que les actifs natifs restent sur Ethereum indique donc où les actifs sont enregistrés, mais ne répond pas, à lui seul, à la question de savoir qui peut les déplacer.

Cette distinction explique aussi la destruction. Le lancement d’un retrait détruit le droit protégé utilisé pour le remboursement, et non les jetons ERC20 sous-jacents. Un paiement externe réussi achève le remboursement. Si le paiement aboutit à l’un des résultats d’échec documentés, l’application peut rétablir le droit.

Le parcours de retrait considère la dépense de la pièce du détenteur comme une autorisation. Le détenteur fournit une pièce de coffre protégée correspondant au jeton et au montant exact du retrait, puis choisit une adresse de destination. Le circuit rejette une destination nulle.

Le circuit startWithdraw détruit cette pièce et met la demande en file d’attente. Un vidage ultérieur de la file attribue au compte du coffre le numéro de séquence de transaction, appelé nonce. L’étape d’envoi enregistre ensuite une demande de transfert ERC20 du montant exact et informe le service de signature MPC, ou calcul multipartite.

La suite consiste en une série de responsabilités distinctes :

Le service de signature ne diffuse pas la transaction. La dApp ou le relais l’assemble avec la signature vérifiée et l’envoie à la chaîne EVM.

Un transfert échoué et le silence d’un service sont deux choses différentes

Le service a une deuxième tâche après la signature. Il fournit une attestation du résultat de la transaction externe, distincte de la signature qui a autorisé cette transaction. Le protocole d’intégration décrit comment lier ce résultat à la demande et aux données renvoyées.

Le coffre vérifie l’attestation par rapport à la clé de réponse MPC qu’il a configurée avant d’autoriser le règlement.

La spécification du retrait décrit trois situations dans lesquelles le droit peut être rétabli : une transaction annulée, une transaction devenue impossible à exécuter parce qu’une autre a consommé son nonce, ou un transfert ERC20 exécuté ayant renvoyé false. Une fois le résultat attesté mis en file d’attente puis traité, le demandeur du retrait finalise la demande et reçoit un montant protégé nouvellement créé.

Un transfert réussi renvoyant true maintient la destruction et clôt la demande. En cas d’échec, le droit rétabli est une créance sur le coffre de Midnight, plutôt qu’un nouveau paiement de l’actif natif à l’adresse de destination.

La procédure de remboursement documentée exige une attestation vérifiée et traitée. Une demande de signature sans réponse ou l’absence d’une réponse sur le résultat ne remplissent pas, à elles seules, cette condition.

L’exemple comprend aussi un mécanisme d’urgence dans le code du coffre. Le déployeur peut lancer une demande de remplacement de nonce pour une transaction du coffre bloquée, au moyen d’un transfert de valeur nulle depuis le compte du coffre vers lui-même, avec le même nonce.

L’objectif est de rendre la transaction d’origine impossible à exécuter, après quoi un résultat attesté peut justifier son règlement en échec. Le lancement de cette procédure de récupération est réservé au déployeur, bien que l’envoi d’une demande déjà définie soit libre d’accès. Il s’agit d’une autre transaction signée, suivie d’une attestation, et non d’une sortie qui contourne le service MPC.

Le code comporte également un avertissement précis : remplacer une demande d’origine avant que le MPC ne l’ait signée peut créer une course avec cette demande et potentiellement la laisser sans attestation, tandis que le droit protégé remis est détruit.

Le déployeur définit aussi les paramètres initiaux du compte, de la chaîne et de la clé de réponse, et peut modifier les paramètres de gaz du coffre. Les demandes déjà lancées conservent les valeurs de gaz copiées au moment de leur lancement.

Le test de mise en production porte sur le parcours de sortie complet

La prise en charge du mainnet reste liée à ledger v9 sur la feuille de route de SIG. La mise à jour du dépôt du 21 oct. prépare la version 0.5.0 du package du coffre sur SIG Midnight 0.25.0. À cette version du code, le registre d’adresses publié contient une adresse de coffre pour stagenet et une entrée mainnet vide, que le fichier définit comme n’étant pas encore déployée ou publiée.

La démonstration distincte de SIG, couvrant toute la pile, utilise Midnight stagenet et Ethereum Sepolia, deux réseaux de test publics, avec un répondant MPC « fakenet ». Cela démontre un flux applicatif. Cela ne prouve pas qu’un quorum de production composé de signataires indépendants exploite cette démonstration.

La description de la signature à seuil de SIG explique comment une signature est produite. Pour évaluer un déploiement réel, il faut aussi savoir combien de signataires doivent coopérer, qui les exploite, comment ces dispositions peuvent évoluer et quelle procédure de récupération peut aboutir lorsque le service ordinaire est indisponible.

La portée de l’audit exige la même précision. Le rapport final de Hacken daté du 21 févr. 2025 couvre les contrats Solidity de signature inter-chaînes d’Ethereum. Sa portée n’établit pas que le coffre Compact plus récent ou l’ensemble du système Nightmode sont couverts.

Les prochains éléments probants concernant le déploiement sont donc plus importants qu’une nouvelle annonce d’expansion : le code et les adresses exacts de la version de production, sa configuration de signature et d’attestation, la couverture d’audit de ces composants et une procédure de récupération adaptée à une défaillance du service.