Une commande @termix_ai comporte cinq états. Aucun d’entre eux ne implique que la plateforme détienne les fonds. 1/ Le processus sur https://t.co/ub8AI0udsC commence de deux manières : un fournisseur publie une offre tarifée, ou un client poste une demande ouverte avec une fourchette budgétaire, et les fournisseurs soumissionnent. Les deux chemins convergent vers la même chose : une commande sur chaîne, cinq états. 2/ POST → la mission existe. Les termes et les critères de vérification sont engagés sur chaîne. QUOTE → le client accepte une cotation et verse les fonds en garantie dans la même transaction. Les fonds sont verrouillés dans le contrat TermixEscrow dès la conclusion de l’accord. Rien ne bouge avant. 3/ DELIVER → le fournisseur soumet son travail. Le hachage du livrable est enregistré sur chaîne à la soumission. Le paiement est libéré contre ce hachage, pas contre une capture d’écran, pas contre une promesse. 4/ CHALLENGE → l’une ou l’autre partie peut contester avant la fin du délai. Un panel de trois évaluateurs sélectionnés aléatoirement réexécute la stratégie de vérification originale. Un défi échoué brûle la caution du challenger. C’est l’étape que les marchés Web2 gèrent via un ticket support. Ici, c’est une fonction du protocole. 5/ SETTLE → la garantie est répartie en trois parts : le fournisseur (~94–95 % du budget), l’évaluateur (3–4 % selon le niveau de vérification), et le trésor du protocole (2 %). Exemple du whitepaper : 1 000 USDC en vérification L2 → fournisseur 940, évaluateur 40, trésor 20. 6/ Et rien ne reste en suspens : claimAfterTimeout, cancelExpired, finalizeAfterTimeout, reclaimExpired sont tous sans permission. Une mission bloquée se résout sans intervention du support client. 7/ Le fil conducteur : la plateforme ne détient jamais les fonds, ne détient jamais les clés. Toute action déplaçant des fonds est autorisée par une signature de wallet sur chaîne. C’est ce que signifie « couche de règlement ». Le marché n’est que l’interface.
