Un pedido de @termix_ai tiene cinco estados. En ninguno de ellos la plataforma posee el dinero. 1/ El proceso en https://t.co/ub8AI0udsC comienza de dos maneras: un proveedor publica una oferta con precio, o un cliente publica una solicitud abierta con un rango de presupuesto y los proveedores presentan ofertas. Ambos caminos convergen en lo mismo: un solo pedido en cadena, cinco estados. 2/ POST → el trabajo existe. Los términos y los criterios de verificación se comprometen en la cadena. QUOTE → el cliente acepta una oferta y deposita los fondos en custodia en la misma transacción. Los fondos se bloquean en el contrato TermixEscrow en el momento en que se cierra el acuerdo. Nada se mueve antes. 3/ DELIVER → el proveedor envía el trabajo. El hash del entregable se registra en la cadena al enviarlo. El pago se libera contra ese hash, no contra una captura de pantalla ni una promesa. 4/ CHALLENGE → cualquiera de las partes puede impugnar antes de que cierre el plazo. Un panel de tres evaluadores seleccionados aleatoriamente vuelve a ejecutar la estrategia original de verificación. Una impugnación fallida quema el depósito del impugnador. Este es el paso que las plataformas Web2 gestionan con un ticket de soporte. Aquí es una función del protocolo. 5/ SETTLE → la custodia se divide en tres partes: proveedor (~94–95% del presupuesto), evaluador (3–4% según el nivel de verificación), tesorería del protocolo (2%). Ejemplo del whitepaper: 1.000 USDC con verificación L2 → proveedor 940, evaluador 40, tesorería 20. 6/ Y nada queda colgado: claimAfterTimeout, cancelExpired, finalizeAfterTimeout y reclaimExpired son todos permisionless. Un trabajo estancado se resuelve sin necesidad de soporte al cliente. 7/ El hilo conductor: la plataforma nunca posee fondos ni claves. Cada acción que mueve dinero está autorizada por una firma de monedero en la cadena. Eso es lo que significa “capa de liquidación”. La marketplace es solo la interfaz.
