TREASURY - FIX BLOCK HEIGHT assert

[herissondev]

l'assert block height est trop restrictif, j'arrive pas à avoir une transaction qui passe :

https://github.com/EclipseAleo/aleo-eclipse/blob/4e74f97967bd4d4380e4947088f9991f2997681c/lending/treasury/src/main.leo#L65C9-L65C47

[herissondev]

Voici les points qui “sonnent faux” ou, à tout le moins, méritent une sérieuse re-lecture avant de déployer ce contrat Aleo ; je les classe par ordre de gravité :

---

1. Contrôle d’accès et falsification de stake_position

Endroit	Problème	Risque
withdraw & claim	Aucune vérification que caller == stake_pos.owner	Quiconque peut forger un objet stake_position (c’est un input privé, donc non authentifié) et retirer/claimer les fonds d’un autre.
stake	Pas de contrôle que token_input.id == ECLP_TOKEN_ID	On peut « staker » n’importe quel token, mais le contrat l’enregistre comme ECLP. Incohérence comptable et retrait impossible ensuite.

---

4. Sous-/sur-flux et cast dangereux

• Dans finalize_withdraw :

  total_staked.set(...,  total_staked.get_or_use(...) - amount);
  

  Si, pour une raison X, amount > solde, l’underflow u128 sautera avant l’assert.

• Dans claim, claimable_fees est un u128 mais converti en u64 sans garde-fou ; au-delà de 2⁶⁴-1, on tronque les fonds.

---

5. Logique économique fragile

• On confie à l’utilisateur le soin de passer fees_tot et tot_staked comme input « public », puis on vérifie l’égalité.

  • ⇒ risque de front-run / condition de concurrence : si quelqu’un dépose ou retire entre le moment où l’utilisateur prépare sa proof et le moment où elle est minée, l’assertion échoue et l’UX est médiocre.

• Aucune pénalité ni délai de retrait ; un utilisateur peut « stake & drain » les rewards dans le même bloc si les frais sont antérieurs.

---

6. Détails syntaxe / style

1. mapping total_staked: field => u128; – puisque vous ne gérez qu’un seul token, un simple const ou une variable unique suffirait.

2. Les constantes ECLP_TOKEN_ID et USDA_TOKEN_ID sont codées en dur ; préférez les tirer du token_registry pour éviter les collisions.

3. Pas de décorateur/inline pour is_admin : la fonction n’est jamais appelée.

---

Recommandations rapides

1. Signer les positions : conservez un hash dans l’état on-chain (mapping position_hashes: address => field) ou vérifiez explicitement assert(caller == stake_pos.owner) dans chaque transition.

2. Supprimer actual_block des inputs et utilisez directement block.height côté contrat.

3. Corriger les imports et payez les frais avec le bon asset (token_registry → USDA).

4. Vérifier l’ID du token à l’entrée de stake.

5. Encadrer la conversion u128 → u64 par assert(claimable_fees <= u64::MAX as u128).

6. Ré-examiner la logique asynchrone : si le Future se résout au bloc +1, passez de assert_eq à assert(actual_block < block.height) ou stockez la hauteur d’origine dans l’état plutôt que de la passer en paramètre.

N’hésite pas si tu veux un patch concret ou un test-net pour reproduire les failles ; je peux te proposer un diff complet ou des scénarios d’attaque pas-à-pas.