Un trade basé sur l’IA a expiré. Que doit réellement retenter “réessayer” ?
Imaginez un agent qui soumet un échange $ETH → $USDC. Le portefeuille renvoie un hash de transaction, mais l’observation de l’exécution ne se termine pas avant l’expiration de l’attente côté client.
Ceci est un exemple hypothétique.
L’expiration nous indique que l’attente s’est terminée. La transaction d’origine peut toujours être en attente ou avoir déjà été exécutée. Son statut nécessite une investigation plus approfondie.
Je veux que l’agent conserve :
• Le hash de la transaction d’origine
• Son enregistrement d’autorisation
• L’identifiant de la tâche d’observation
• L’état connu le plus récent
Il peut ensuite reprendre l’observation et la vérification, en préservant les issues en attente, annulées, réorganisées (reorged) ou indéterminées.
À lui seul, un timeout ne devrait pas déclencher un nouvel échange.
Ceci fait partie de mon travail sur PriorSeal : récupérer des preuves d’autorisation et d’exécution via des opérations existantes après un redémarrage ou une perte de réponse.
Le portefeuille ou l’exécuteur continue de contrôler la soumission des transactions. La récupération d’éléments historiques ne renouvelle pas non plus une autorisation expirée.
Après un redémarrage, votre agent peut-il continuer à investiguer la transaction d’origine — ou doit-il redémarrer l’ensemble du workflow ?
https://priorseal.xyz/
#AIAgents #Web3Security
Imaginez un agent qui soumet un échange $ETH → $USDC. Le portefeuille renvoie un hash de transaction, mais l’observation de l’exécution ne se termine pas avant l’expiration de l’attente côté client.
Ceci est un exemple hypothétique.
L’expiration nous indique que l’attente s’est terminée. La transaction d’origine peut toujours être en attente ou avoir déjà été exécutée. Son statut nécessite une investigation plus approfondie.
Je veux que l’agent conserve :
• Le hash de la transaction d’origine
• Son enregistrement d’autorisation
• L’identifiant de la tâche d’observation
• L’état connu le plus récent
Il peut ensuite reprendre l’observation et la vérification, en préservant les issues en attente, annulées, réorganisées (reorged) ou indéterminées.
À lui seul, un timeout ne devrait pas déclencher un nouvel échange.
Ceci fait partie de mon travail sur PriorSeal : récupérer des preuves d’autorisation et d’exécution via des opérations existantes après un redémarrage ou une perte de réponse.
Le portefeuille ou l’exécuteur continue de contrôler la soumission des transactions. La récupération d’éléments historiques ne renouvelle pas non plus une autorisation expirée.
Après un redémarrage, votre agent peut-il continuer à investiguer la transaction d’origine — ou doit-il redémarrer l’ensemble du workflow ?
https://priorseal.xyz/
#AIAgents #Web3Security