Entrega & Aprovação

Entrega & Aprovação

Contexto

Uma vez que um pedido é financiado, o marketplace entra na fase de execução.

Neste ponto:

• os fundos ficam presos em escrow,

• o vendedor pode entregar com segurança,

• o comprador sabe que o pagamento está garantido,

• a plataforma aplica o processo.

Este fluxo se aplica a tanto bens quanto serviços.

---

Objetivo

Permitir que o vendedor:

• forneça atualizações de entrega,

• marque o pedido como concluído,

e permitir que o comprador:

• aprove a entrega ou

• abra uma disputa,

com desfechos aplicados pelo escrow.

---

Atores

• Vendedor

• Comprador

• UI do OfferHub

• Backend do OfferHub (Orquestrador)

• Supabase (perfis & papéis)

• Escrow Trustless Work

• Rede Stellar

---

Pré-condições

• O pedido existe e está em Financiado / Em Progresso

• Escrow existe e está totalmente financiado

• Vendedor e comprador estão vinculados ao pedido

• Papéis no escrow já estão atribuídos:

  • Vendedor = Marcador de Marco (Milestone Marker)

  • Comprador = Aprovador

  • Plataforma = Resolutor de Disputas & Assinante de Liberação

---

Alinhamento do Ciclo de Vida

Este fluxo move o pedido e o escrow através destes estados:

Em Progresso
→ Para Revisão (Entrega Concluída)
→ Aprovado OU Disputado
→ Liberado OU Reembolsado

---

Experiência do Vendedor — Fase de Entrega

1. Vendedor é Notificado

Escrow financiado → Vendedor notificado

O vendedor agora pode começar o cumprimento.

---

2. Vendedor Fornece Atualizações de Entrega (Off-Chain)

O vendedor tem acesso a um painel do vendedor onde ele pode:

• atualizar o status do pedido (ex.: “processando”, “enviado”)

• fazer upload de evidências (número de rastreamento, arquivos, notas)

• comunicar-se com o comprador

Essas atualizações são:

• off-chain

• informacionais

• não aplicadas pelo escrow

Elas existem para apoiar a UX e a resolução de disputas posteriormente.

---

3. Vendedor Marca a Entrega como Concluída (Sinal On-Chain)

Quando a entrega estiver completa:

Vendedor → UI do OfferHub: Marcar como Entregue
OfferHub → Trustless Work:
  Marcar marco como Concluído

Esta ação:

• move o escrow para Para Revisão

• sinaliza que o vendedor declara conclusão

• não libera fundos

Neste ponto:

• o vendedor não pode mais alterar o status da entrega

• é necessária uma ação do comprador

---

Experiência do Comprador — Fase de Revisão

4. Comprador Revisa o Pedido

O comprador vê:

• status da entrega

• atualizações e evidências do vendedor

• linha do tempo do pedido

O comprador deve escolher uma das duas ações.

---

Caminho A — Comprador Aprova a Entrega

Experiência do Usuário

“Tudo parece certo.”

---

Fluxo do Sistema

Comprador → UI do OfferHub: Aprovar
OfferHub → Trustless Work:
  Aprovar marco

Isto move o escrow para Aprovado.

⚠️ Requisito de Assinatura (Importante) Esta aprovação exige uma assinatura vinculada ao papel de Aprovador.

O que assina esta aprovação depende do modelo final de integração:

• Opção 1 (UX Preferida):

  • Aprovação do comprador é autorizada via OfferHub

  • A plataforma assina on-chain como autoridade delegada

• Opção 2 (A ser validada com a Airtm):

  • A conta do comprador vinculada à Airtm pode autorizar/assinar a aprovação do escrow

  • Isso exigiria suporte da Airtm para assinatura ou assinatura delegada

👉 Este é um ponto-chave de exploração no piloto com a Airtm.

---

Caminho B — Comprador Abre uma Disputa

Experiência do Usuário

“Algo está errado.”

---

Fluxo do Sistema

Comprador → UI do OfferHub: Abrir Disputa
OfferHub → Trustless Work:
  Marcar escrow como Disputado

Isto:

• congela o escrow

• impede a liberação

• entrega o controle à plataforma (resolutor de disputas)

A partir daqui, o Disputas & Resolução fluxo se aplica.

---

O Que Acontece Em Seguido

Se Aprovado

• Escrow está pronto para liberação

• A plataforma executa a liberação dos fundos

• O vendedor recebe o pagamento

Se Disputado

• Escrow permanece bloqueado

• A plataforma investiga e resolve

• O resultado é aplicado on-chain

---

Saídas

• ✅ Entrega marcada como concluída

• ✅ Escrow movido para Para Revisão

• ✅ Ação do comprador registrada (aprovar ou disputar)

• ✅ Trilha de auditoria completa (off-chain + on-chain)

---

Falhas & Casos Limítrofes

Vendedor Marca Entrega Cedo Demais

• Comprador pode disputar

• Evidências são revisadas

• Nenhuma liberação automática ocorre

Comprador Está Inativo

• Escrow permanece em Para Revisão

• Sem liberação automática baseada em tempo por padrão

• A plataforma pode intervir manualmente (decisão de política)

---

Notas de Segurança & Confiança

• Vendedor não pode liberar fundos

• Comprador não pode liberar fundos por si só

• Plataforma não pode liberar fundos a menos que as condições sejam atendidas

• O escrow aplica as transições de estado

---

Notas Educacionais

Por que as Atualizações de Entrega são Off-Chain

• Flexível

• Amigável à UX

• Evita gravações on-chain desnecessárias

• Ainda utilizável como evidência em disputas

Por que a Aprovação Exige Assinatura

A aprovação é o gatilho econômico para a liberação. Deve ser autorizada criptograficamente, não apenas um clique na interface.

---

Perguntas em Aberto (Validação do Piloto)

O piloto do Offer Hub irá explorar explicitamente:

1. Contas Airtm podem participar dos fluxos de assinatura do escrow?

2. A Airtm pode suportar assinatura delegada ou por procuração?

3. As aprovações devem sempre ser assinadas pela plataforma para simplicidade de UX?

Essas decisões afetam:

• pressupostos de confiança

• atrito de UX

• limites de conformidade