# Entrega y aprobación ## Entrega y Aprobación ### Contexto Una vez que un pedido está **financiado**, el mercado entra en la **fase de ejecución**. En este punto: * los fondos están bloqueados en escrow, * el vendedor puede entregar de forma segura, * el comprador sabe que el pago está asegurado, * la plataforma hace cumplir el proceso. Este flujo se aplica a **tanto bienes como servicios**. *** ### Objetivo Permitir al vendedor: * proporcionar actualizaciones de entrega, * marcar el pedido como completado, y permitir al comprador: * aprobar la entrega **o** * abrir una disputa, con resultados aplicados por el escrow. *** ### Actores * **Vendedor** * **Comprador** * **Interfaz OfferHub** * **Backend de OfferHub (Orquestador)** * **Supabase** (perfiles y roles) * **Trustless Work Escrow** * **Red Stellar** *** ### Precondiciones * El pedido existe y está **Financiado / En Progreso** * El escrow existe y está completamente financiado * Vendedor y comprador están vinculados al pedido * Los roles del escrow ya están asignados: * Vendedor = Marcador de Hito * Comprador = Aprobador * Plataforma = Resolver de Disputas y Firmante de Liberación *** ### Alineación del Ciclo de Vida Este flujo mueve el pedido y el escrow a través de estos estados: ``` En Progreso → Para Revisión (Entrega Realizada) → Aprobado O Disputado → Liberado O Reembolsado ``` *** ### Experiencia del Vendedor — Fase de Entrega #### 1. El vendedor es notificado ``` Escrow financiado → Vendedor notificado ``` El vendedor ahora puede comenzar con el cumplimiento. *** #### 2. El vendedor proporciona actualizaciones de entrega (Off-Chain) El vendedor tiene acceso a un **panel del vendedor** donde puede: * actualizar el estado del pedido (p. ej. “procesando”, “enviado”) * subir evidencia (número de seguimiento, archivos, notas) * comunicarse con el comprador Estas actualizaciones son: * **off-chain** * **informativas** * **no aplicadas por el escrow** Existen para apoyar la experiencia de usuario y la resolución de disputas más adelante. *** #### 3. El vendedor marca la entrega como realizada (Señal On-Chain) Cuando la entrega se completa: ``` Vendedor → Interfaz OfferHub: Marcar como Entregado OfferHub → Trustless Work: Marcar hito como Realizado ``` Esta acción: * mueve el escrow a **Para Revisión** * señala que el vendedor reclama la finalización * **no libera fondos** En este punto: * el vendedor ya no puede cambiar el estado de la entrega * se requiere acción del comprador *** ### Experiencia del Comprador — Fase de Revisión #### 4. El comprador revisa el pedido El comprador ve: * estado de la entrega * actualizaciones y evidencia del vendedor * línea de tiempo del pedido El comprador debe elegir **una de dos acciones**. *** ### Camino A — El comprador aprueba la entrega #### Experiencia de usuario > “Todo se ve bien.” *** #### Flujo del sistema ``` Comprador → Interfaz OfferHub: Aprobar OfferHub → Trustless Work: Aprobar hito ``` Esto mueve el escrow a **Aprobado**. ⚠️ **Requisito de Firma (Importante)**\ Esta aprobación **requiere una firma** vinculada al rol de Aprobador. Qué firma esta aprobación depende del modelo de integración final: * **Opción 1 (UX preferida):** * La aprobación del comprador se autoriza vía OfferHub * La plataforma firma on-chain como autoridad delegada * **Opción 2 (A validar con Airtm):** * La cuenta vinculada a Airtm del comprador puede autorizar/firmar la aprobación del escrow * Esto requeriría soporte de Airtm para firmar o firma delegada 👉 **Este es un punto clave de exploración en el piloto con Airtm.** *** ### Camino B — El comprador abre una disputa #### Experiencia de usuario > “Algo está mal.” *** #### Flujo del sistema ``` Comprador → Interfaz OfferHub: Abrir Disputa OfferHub → Trustless Work: Marcar el escrow como Disputado ``` Esto: * congela el escrow * impide la liberación * pone el control en manos de la plataforma (resolutor de disputas) A partir de aquí, el **Flujo de Disputas y Resolución** se aplica. *** ### Qué sucede después #### Si se aprueba * El escrow está listo para la liberación * La plataforma ejecuta la liberación de fondos * El vendedor recibe el pago #### Si hay disputa * El escrow permanece bloqueado * La plataforma investiga y resuelve * El resultado se aplica on-chain *** ### Resultados * ✅ Entrega marcada como realizada * ✅ Escrow movido a **Para Revisión** * ✅ Acción del comprador registrada (aprobar o disputar) * ✅ Rastro de auditoría completo (off-chain + on-chain) *** ### Fallas y Casos Límite #### El vendedor marca la entrega demasiado pronto * El comprador puede disputar * La evidencia es revisada * No ocurre liberación automática #### El comprador está inactivo * El escrow permanece en **Para Revisión** * Sin liberación automática basada en tiempo por defecto * La plataforma puede intervenir manualmente (decisión de política) *** ### Notas de Seguridad y Confianza * Vendedor **no puede liberar fondos** * Comprador **no puede auto-liberar fondos** * Plataforma **no puede liberar fondos a menos que se cumplan las condiciones** * El escrow aplica las transiciones de estado *** ### Notas Educativas #### Por qué las actualizaciones de entrega son Off-Chain * Flexible * Amigable para la experiencia de usuario * Evita escrituras on-chain innecesarias * Aún útiles como evidencia en disputas #### Por qué la aprobación requiere firma La aprobación es el **disparador económico** para la liberación.\ Debe estar autorizada criptográficamente, no solo con un clic en la interfaz. *** ### Preguntas Abiertas (Validación del Piloto) El piloto de Offer Hub explorará explícitamente: 1. **¿Pueden las cuentas de Airtm participar en los flujos de firma de escrow?** 2. **¿Puede Airtm soportar firma delegada o por proxy?** 3. **¿Deberían las aprobaciones ser siempre firmadas por la plataforma para simplicidad de UX?** Estas decisiones afectan: * suposiciones de confianza * fricción en la experiencia de usuario * límites de cumplimiento --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.trustlesswork.com/trustless-work/v1-es/dapps-oss/offerhub-marketplace/flujos-principales/entrega-y-aprobacion.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.