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:
Experiencia del Vendedor — Fase de Entrega
1. El vendedor es 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:
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
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
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:
¿Pueden las cuentas de Airtm participar en los flujos de firma de escrow?
¿Puede Airtm soportar firma delegada o por proxy?
¿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
Última actualización