Audit adverse du contrat de règlement

Le chantier a corrigé les quatre défauts A à D. La relecture a vérifié dans le code — pas sur parole — que chaque correctif est réellement présent et sain, et que la nouvelle version compile :

• Défaut 1 (critique) : la pièce va désormais directement du vendeur à l'acheteur (asset_receiver == acheteur) ; le coffre ne détient plus une pièce non confiée. C'est la première piste de correction recommandée.
• Défaut 2 : un champ reserves retient combien d'acceptations le vendeur a réellement payées ; le remboursement en est borné, donc plus de capture. Résidu mineur : le vendeur honnête qui referme en premier ne récupère pas sa réserve — elle reste au coffre plutôt que d'aller à l'attaquant. Griefing possible à 0,1 ALGO, sans profit pour le tiers.
• Défaut 3 : un second dépôt en ALGO est exigé pour une offre en jeton.
• Défaut 4 : nouvelle méthode fermer_une_monnaie qui dés-opte et efface la boîte du plancher.

Le re-test sur la chaîne de ces correctifs, et la couverture des angles non vérifiés (vente à prix fixe en jeton, lots, enchères, signature matérielle), restent à faire sur une version stable, une fois le compte de test réapprovisionné.

Une offre ne peut jamais être acceptée

Le contrat porte la décision de conception la plus structurante du projet : le marché s'amorce par les offres. Un collectionneur dépose une offre en ALGO sur n'importe quelle pièce ; le détenteur la découvre et l'accepte. Sans cela, « un catalogue reste un musée ». Cette voie ne fonctionne pas.

accepter_l_offre exige que le vendeur envoie sa pièce au coffre (asset_receiver == current_application_address), puis le coffre la fait suivre à l'acheteur par transaction interne. Or, sur Algorand, un compte doit avoir accepté (opt-in) un actif pour pouvoir le recevoir. lister et mettre_aux_encheres optent bien le coffre dans les pièces qu'on y dépose ; accepter_un_jeton l'opte dans les monnaies de paiement. Mais aucune méthode n'opte le coffre dans la pièce d'une offre — et seul le contrat le pourrait, l'opt-in étant une transaction interne que l'utilisateur ne peut pas signer à sa place.

python essai_D_offre_algo.py

  ok   offre en ALGO de 0,1 ALGO créée (offre 3)
 RATÉ  acceptation à frais minimaux
    → motif : receiver error: must optin, asset 770778845 missing from [coffre]
 RATÉ  acceptation à frais suffisants
    → motif : receiver error: must optin, asset 770778845 missing from [coffre]

Testé dans les deux ordres de groupe possibles (pièce d'abord, appel d'abord) : même échec, avant même que la logique du contrat ne tourne. Le protocole rejette le transfert de la pièce vers un coffre non opté.

python essai_E_controle_positif.py

  ok   pièce mise en vente (annonce 2)
  ok   l'acheteur achète
  ok   la pièce est arrivée chez l'acheteur
  ok   le vendeur a reçu le prix (net du remboursement de dépôt)

La vente à prix fixe en ALGO fonctionne de bout en bout, parce que lister opte le coffre au moment du dépôt. Le défaut est donc ciblé sur l'acceptation d'offre, pas généralisé.

• Pour un NFT unique (total = 1, tout le corpus visé par le projet), le coffre n'est jamais opté dans la pièce offerte : l'offre est inacceptable à 100 %.
• Pas de perte de fonds permanente : l'offrant peut créer son offre et la retirer. retirer_l_offre rend le dépôt (mesuré : +131 900 µALGO sur 136 900 déposés, le reste en frais). Mais aucune vente par offre ne peut jamais se conclure.
• C'est la réalisation exacte de l'intuition posée en piste d'audit — « le coffre doit accepter un actif pour le recevoir » — mais au mauvais endroit : le trou n'est pas sur la monnaie de paiement (couverte par accepter_un_jeton), il est sur la pièce offerte.

La réserve d'acceptation d'une édition est captable par un tiers

Une édition limitée (tirage > 1, forme massivement présente dans le corpus de 2021) peut être détenue par plusieurs comptes. Le coffre n'accepte l'actif qu'une seule fois, au premier dépôt, et lister fait payer cette réserve de 0,1 ALGO au premier vendeur. Mais la réserve n'est libérée qu'au dernier exemplaire qui sort du coffre (asset_close_to). Celui qui referme en dernier l'empoche, qu'il l'ait payée ou non.

• Le vendeur liste son exemplaire : il paie la réserve, le coffre s'opte.
• L'attaquant liste le sien : le coffre est déjà opté, il ne paie aucune réserve.
• Le vendeur annule d'abord : le coffre détient encore 2 exemplaires, donc aucune fermeture, aucune réserve rendue.
• L'attaquant annule ensuite : dernier exemplaire, fermeture, la réserve lui revient.

python essai_A_reserve_edition.py

Le montant est borné à 0,1 ALGO par collision, mais c'est une perte de fonds réelle d'un utilisateur vers un autre, déclenchable à volonté sur toute édition dont l'attaquant détient un exemplaire.

Une offre en jeton est financée par le coffre

Quand une offre est libellée dans un jeton, offrir stocke depot_boite = 0 : la boîte de l'offre (0,0349 ALGO) est immobilisée sur le solde disponible du coffre, l'offrant ne versant aucun ALGO. Le contrat le reconnaît lui-même comme « une limite connue ».

python essai_BC_jeton_fermeture.py

Conséquence : le coffre subventionne chaque offre en jeton sur son propre solde. Un attaquant peut répéter l'opération pour épuiser l'ALGO disponible du coffre et le rendre incapable d'émettre ses transactions internes — un griefing gratuit, l'offrant ne risquant rien. La porte est ouverte dès qu'une monnaie de paiement est acceptée.

Le marché ne peut plus être fermé après avoir accepté une monnaie

fermer_le_marche existe précisément pour éviter que le solde immobilisé reste « prisonnier pour toujours ». Elle exige que le solde minimum du coffre soit retombé à celui d'un compte nu. Mais une fois accepter_un_jeton appelé, le coffre garde pour toujours un opt-in d'actif (0,1 ALGO) et une boîte de plancher (0,0093 ALGO) qu'aucune méthode ne peut défaire. La condition de fermeture devient inatteignable.

python essai_BC_jeton_fermeture.py

C'est exactement le défaut « prisonnier pour toujours » que la méthode prétend éviter. La note de tête promet « l'exploitant ne peut que fermer une caisse déjà vide » ; en pratique, la caisse ne peut plus jamais être vidée de ses opt-in de monnaies.

Les frais d'acceptation doivent être surpayés

Les commentaires disent que l'offrant provisionne « les deux transactions qui la refermeront ». En réalité, ces frais provisionnés sont retenus par le coffre et n'entrent pas dans la réserve de frais du groupe (le fee pooling). L'acceptant doit donc gonfler lui-même le frais de son appel pour couvrir les transactions internes à fee=0.

 RATÉ  acceptation à frais minimaux
    → motif : group fee too small (needs 1mA more)

Sans gravité pour la sécurité, et une intégration soignée du site le gère en fixant un frais d'appel suffisant. À noter tout de même : le provisionnement décrit ne joue pas le rôle que les commentaires lui prêtent, et le petit surplus retenu par le coffre à chaque offre s'y accumule sans issue (même famille que le défaut 4).

Le bytecode déployé sur le testnet est périmé

La compilation de la version figée est identique octet pour octet aux artefacts du dépôt (marche/artefacts/), mais différente du bytecode réellement déployé sur l'app de test partagée.

Tout essai lancé contre l'app partagée teste donc du code plus ancien que la source. Il faut redéployer avant de conclure quoi que ce soit sur cette app. La relecture a contourné le problème en déployant sa propre instance depuis la version figée.

• Les enchères, en conditions réelles. mettre_aux_encheres, encherir, annuler_l_enchere et clore_l_enchere ont été lues, non jouées sur la chaîne. Le remboursement de l'enchérisseur dépassé, la prolongation automatique, la logique de réserve et la mise en commun des frais à la clôture restent à éprouver en transactions réelles.
• La vente à prix fixe en jeton n'a pas été rejouée sur l'instance d'audit ; elle n'est couverte que par le scénario du chantier, contre l'app périmée (défaut 6).
• Les lots multi-pièces (jusqu'à 13) n'ont pas été exercés — seule la pièce unique l'a été.
• La signature par portefeuille matériel (Ledger) ou compte rekeyé. Les essais utilisent des signataires logiciels : ils prouvent qu'un compte standard sait signer ces groupes, pas qu'un Ledger le peut. Simuler contre un nœud prouve que le contrat accepte, pas que le portefeuille sait signer — les deux vérifications sont distinctes, et la seconde reste à faire sur les groupes d'offre et d'enchère.
• L'exactitude des constantes de taille de boîte (BOITE_*) n'a pas été redérivée : la relecture s'est fiée au fait que les dépôts passent.
• Le seuil d'exonération et l'arrondi de commission aux bornes de prix (plancher 0,01 ALGO) n'ont pas été joués en direct.
• La réentrance et la concurrence ont été raisonnées, non éprouvées par fuzzing.

La version auditée a été compilée depuis la source figée (empreinte f33e994b…), puis déployée en propre sur le testnet (app 770778378). Chaque attaque a été jouée en transactions réelles signées et confirmées sur la chaîne, et non simulée. Les essais reproductibles vivent dans audit-contrat/ : essai_A_reserve_edition.py, essai_BC_jeton_fermeture.py, essai_D_offre_algo.py, essai_E_controle_positif.py. Ils tournent avec le même banc d'essai que les scénarios du chantier (contrat/commun.py), pointé sur l'instance d'audit.

Conclusion : un défaut critique empêche aujourd'hui la fonctionnalité qui devait amorcer le marché. Le chemin à prix fixe, lui, tient. Les trois défauts moyens touchent des fonds réels mais bornés, ou la capacité à retirer le contrat. L'échange ne devrait pas ouvrir avant correction du défaut 1 au minimum, et avant que les angles non vérifiés — les enchères et la signature matérielle en tête — aient été éprouvés.