# 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