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