Design de escrow
Nós não guardamos seu dinheiro — guardamos a lógica.
As garantias Trustless Work são primitivas de confiança programáveis. Elas permitem que plataformas, marketplaces, aplicativos e organizações definam como os fundos devem ser mantidos, atualizados, aprovados e liberados entre diferentes partes. Uma garantia não é apenas um lugar onde os fundos ficam parados.
É uma camada de coordenação entre:
partes
fundos
funções
marcos
atualizações de status
aprovações
condições de liberação
taxas da plataforma
fluxos de disputa ou exceção
Antes de criar uma garantia, a pergunta mais importante é:
Quem precisa fazer o quê antes que o dinheiro possa ser movimentado?
Se você conseguir responder isso com clareza, conseguirá projetar uma boa garantia.
O Modelo Mental de Design de Garantia
Antes de escolher um tipo de garantia ou chamar a API, mapeie a transação.
Comece com quatro perguntas:
Quem são as partes envolvidas?
Para onde os fundos estão indo?
Quem tem permissão para atualizar, aprovar e liberar?
Quais condições precisam ser atendidas antes que os fundos sejam liberados?
Essa é a base do design de garantias.
A Trustless Work oferece a infraestrutura para transformar essa lógica em uma garantia inteligente.
Passo 1: Mapear as Partes
Toda garantia envolve partes.
Algumas partes financiam a garantia. Algumas executam o trabalho. Algumas atualizam o status. Algumas aprovam a conclusão. Algumas resolvem disputas. Algumas liberam os fundos. Algumas recebem os fundos. Algumas recebem as taxas da plataforma.
As funções comuns incluem:
Recebedor
A parte que recebe os fundos após a liberação
Prestador de Serviço / Marcador de Marco
A parte que atualiza o progresso ou marca o trabalho como concluído
Aprovador
A parte que valida se um marco ou condição foi atendido
Assinante da Liberação
A parte que assina ou aciona a liberação dos fundos
Endereço da Plataforma
Pode fazer alterações antes que a garantia seja financiada e recebe a taxa da plataforma
Resolvedor de Disputas
Arbitra disputas e pode redirecionar os fundos quando uma disputa é aberta
As funções são atribuídas a endereços.
Somente o endereço atribuído a uma função pode executar as ações permitidas para essa função.
A mesma pessoa, organização ou carteira do mundo real às vezes pode ter várias funções, mas as combinações de funções devem ser intencionais.
Por exemplo, um freelancer pode ser tanto o Recebedor quanto o Prestador de Serviço, mas normalmente não deveria também ser o Aprovador do próprio trabalho.
Passo 2: Mapear a Direção dos Fundos
Em seguida, mapeie como os fundos devem se mover.
A direção dos fundos deve responder:
Quem financia a garantia e quem deve receber os fundos após as condições corretas serem atendidas?
Padrão 1: Pagamento de Marketplace
Caso de uso: Garantia de liberação única
Um comprador contrata ou compra de um vendedor, freelancer ou prestador de serviço. O comprador financia a garantia. O prestador de serviço entrega o trabalho ou produto. O aprovador valida a conclusão. Então os fundos são liberados uma única vez.
Padrão 2: Marcos de Projeto
Caso de uso: Garantia de múltiplas liberações, mesmo recebedor
Um cliente financia um projeto que tem vários marcos. O mesmo prestador de serviço recebe pagamentos progressivamente à medida que cada marco é concluído e aprovado.
Padrão 3: Pagamentos
Caso de uso: Garantia de múltiplas liberações, vários recebedores
Um patrocinador, plataforma ou organização financia uma única garantia que precisa pagar pessoas ou entidades diferentes ao longo de vários marcos.
Passo 3: Separar Status, Aprovação e Liberação
Um erro comum é tratar atualizações de status, aprovações e liberação de fundos como sendo a mesma coisa.
Na Trustless Work, eles devem ser entendidos separadamente:
Status
Comunicação sobre o progresso
Aprovação
Validação de que uma condição foi atendida
Liberação
Execução do pagamento
Status = Comunicação
Uma atualização de status informa às outras partes o que está acontecendo.
Exemplos:
trabalho iniciado
documentação enviada
envio em trânsito
entrega concluída
marco pronto para revisão
evidência enviada
O Prestador de Serviço ou Marcador de Marco geralmente atualiza o status do marco.
As atualizações de status podem ocorrer muitas vezes antes que um marco atinja seu estado final esperado.
Aprovação = Validação
A aprovação significa que uma parte autorizada validou que a condição acordada foi atendida.
Por exemplo:
o cliente aprova o trabalho
o revisor da bolsa aprova o entregável
o comprador confirma que o envio chegou
a plataforma aprova a evidência enviada
O Aprovador não apenas relata o progresso. O Aprovador valida a conclusão.
Liberação = Execução
Liberação é quando os fundos de fato saem da garantia.
O Assinante da Liberação só pode liberar os fundos depois que as condições de aprovação exigidas forem satisfeitas.
Isso cria uma cadeia lógica clara:
Caso Limite Importante: A Aprovação Pode Acontecer Antes da Atualização de Status
Em alguns fluxos, um Aprovador pode aprovar um marco antes que o Prestador de Serviço atualize o status do marco.
Isso significa que o design da sua garantia não deve assumir que o status sempre vem antes da aprovação.
Em vez disso, trate status e aprovação como estados relacionados, mas separados.
A condição de liberação deve depender da lógica de aprovação exigida, não apenas de um status textual.
Passo 4: Atribuir Funções
Toda garantia da Trustless Work inclui uma configuração de funções. As funções determinam qual endereço pode executar qual ação.
As funções principais atuais incluem:
Prestador de Serviço
Atualiza o status e o progresso do marco
Aprovador
Valida a conclusão do marco
Endereço da Plataforma
Pode receber taxas da plataforma e pode gerenciar a configuração antes do financiamento, dependendo da implementação
Assinante da Liberação
Executa a liberação dos fundos após as condições de aprovação serem atendidas
Resolvedor de Disputas
Lida com disputas ou fluxos de exceção quando sinalizados
Recebedor
Recebe os fundos liberados
Emissor
Quem implanta o contrato. Não tem poderes sobre o contrato
Depositante
Financia a garantia, mas não recebe automaticamente permissões do contrato
Observador
Chegará em uma versão futura; acompanha as garantias sem agir sobre elas
As funções são atribuídas a endereços.
Somente o endereço atribuído a uma função pode executar as ações permitidas para essa função.
Visão Geral das Capacidades das Funções
Prestador de Serviço
Sim
Não
Sim
Não
Não
não
Atualiza o progresso do marco
Aprovador
Não exigido
Sim
Sim
Não
Não
não
Valida a conclusão do marco
Endereço da Plataforma
Antes do financiamento
Não por padrão
Não por padrão
Não por padrão
Não por padrão
Beneficiário da taxa
Pode fazer alterações antes que a garantia seja financiada
Assinante da Liberação
Não exigido
Não exigido
Não
Não
Sim
não
Libera apenas quando as condições permitem
Resolvedor de Disputas
Não exigido
Depende do caso
Não exigido
Sim
Depende do caso
Não
Arbitra e pode redirecionar os fundos
Recebedor
Não por padrão
Geralmente não
Não por padrão
Não
Não
Sim
Destino final dos fundos liberados
Emissor
Não
Não
Não
Não
Não
Não
Não tem poderes sobre o contrato
Depositante
Não
Não
Não
Não
Não
Não
Transações recebidas são indexadas
Observador
Não
Não
Não
Não
Não
Não
Função futura de acompanhamento
Passo 5: Definir as Propriedades da Garantia
As funções são apenas parte do design da garantia.
Uma garantia também inclui propriedades que descrevem o que a garantia é, como ela deve ser indexada, qual ativo é usado e em que estado ela está.
As propriedades comuns da garantia incluem:
ID da Garantia / Endereço do Contrato
Identificador on-chain do contrato de garantia. Também usado como endereço de depósito
ID de Engajamento
Identificador externo configurável usado para conectar a garantia a uma fatura, pedido, projeto ou sistema externo
Título
Título da garantia em linguagem humana
Descrição
Explicação do motivo pelo qual a garantia existe
Funções
Endereços atribuídos a permissões como atualização de status, aprovações, liberações, resolução de disputas e recebimento de taxas
Marcos
Ações, entregáveis ou condições que precisam ser concluídas
Valor
Valor total bloqueado ou esperado na garantia
Taxa da Plataforma
Taxa opcional e configurável para a plataforma ou aplicativo
Trustline / Ativo
O ativo usado na garantia, como USDC ou outro token emitido na Stellar
Marcadores
Indicadores de estado como disputado, liberado ou resolvido
Essas propriedades ajudam as plataformas a conectar a garantia on-chain com fluxos de trabalho do mundo real.
Passo 6: Escolher o Seu Tipo de Garantia
A Trustless Work atualmente oferece suporte a dois tipos principais de garantia:
Garantia de Liberação Única
Garantia de Múltiplas Liberações
Ambas usam a mesma ideia central: os fundos ficam retidos até que condições definidas sejam atendidas.
A diferença é como os fundos são liberados.
Garantia de Liberação Única
Uma Garantia de Liberação Única libera os fundos uma vez.
Ela pode conter vários marcos, mas todos os marcos exigidos precisam ser aprovados antes que a liberação final aconteça.
Estrutura típica:
Fluxo típico:
Melhor para:
depósitos
trabalhos pontuais
entregas simples
conclusão total do projeto
compras em marketplace
entrega final antes do pagamento
Características principais:
Padrão de liberação
Um pagamento final
Marcos
Pode ter vários marcos
Recebedor
Normalmente um único recebedor
Lógica de aprovação
Todos os marcos exigidos precisam ser aprovados antes da liberação
Complexidade
Menor
Garantia de Múltiplas Liberações
Uma Garantia de Múltiplas Liberações libera os fundos progressivamente.
Cada marco pode ter seu próprio pagamento, e cada pagamento pode potencialmente ir para um recebedor diferente.
Estrutura típica:
Fluxo típico:
Melhor para:
bolsas
recompensas
financiamento baseado em marcos
projetos em fases
pagamentos a contribuidores
projetos com vários fornecedores
acordos de serviço de longa duração
Características principais:
Padrão de liberação
Vários pagamentos
Marcos
Cada marco pode ter sua própria liberação
Recebedor
Pode suportar vários recebedores
Lógica de aprovação
Cada marco pode ser aprovado separadamente
Complexidade
Maior
Liberação Única vs Múltiplas Liberações
Os fundos são liberados uma vez ou progressivamente?
Uma vez
Progressivamente
Há vários recebedores?
Geralmente não
Frequentemente sim
Cada marco precisa de seu próprio pagamento?
Não
Sim
Todos os marcos devem ser aprovados antes do pagamento?
Sim
Não necessariamente
O fluxo de trabalho é simples?
Sim
Mais complexo
O fluxo de trabalho é semelhante a bolsa, recompensa ou fases?
Às vezes
Normalmente
Passo 7: Entender o Ciclo de Vida
O ciclo de vida da garantia descreve como uma garantia passa da configuração até a conclusão.
Ciclo de vida canônico:
1. Design
Mapeie partes, direção dos fundos, funções, marcos, condições de liberação e tipo de garantia.
2. Iniciação
Crie e configure a garantia.
Isso inclui:
funções
marcos
valor
ativo
recebedor
taxa da plataforma
ID de engajamento
metadados
3. Financiamento
O pagador deposita fundos na garantia.
Os possíveis estados de financiamento incluem:
não financiada
parcialmente financiada
totalmente financiada
4. Atualizações de Marcos
O Prestador de Serviço ou Marcador de Marco atualiza o status do marco.
Isso cria visibilidade sobre o progresso.
5. Aprovação
O Aprovador valida se a condição do marco foi atendida.
A aprovação é a etapa-chave de validação antes da liberação.
6. Liberação
O Assinante da Liberação executa a liberação dos fundos após as condições de aprovação serem atendidas.
Em uma Garantia de Liberação Única, isso normalmente acontece uma vez.
Em uma Garantia de Múltiplas Liberações, isso pode acontecer marco por marco.
7. Encerramento
A garantia atinge um estado terminal.
Os possíveis estados terminais incluem:
concluída
cancelada
reembolsada
em disputa
resolvida
Checklist de Design
Antes de criar uma garantia, responda a estas perguntas:
Quem financia a garantia?
Quem recebe os fundos?
Há um recebedor ou vários recebedores?
Quem atualiza o status do marco?
Quem aprova a conclusão do marco?
Quem assina a liberação?
O pagamento é liberado uma vez ou por marco?
Qual ativo é usado?
Qual taxa da plataforma se aplica?
A que sistema externo essa garantia deve se conectar?
O que acontece se um marco não for aprovado?
O que acontece se a função for atribuída à parte errada?
Este caso de uso exige resolução de disputas?
Exemplo: Pagamento de Serviço de Marketplace
Um cliente quer pagar um freelancer após a conclusão de um projeto.
Design sugerido:
Pagador
Cliente
Recebedor
Freelancer
Prestador de Serviço
Freelancer
Aprovador
Cliente
Assinante da Liberação
Cliente ou assinante controlado pela plataforma
Endereço da Plataforma
Endereço da taxa do marketplace
Tipo de Garantia
Liberação Única ou Múltiplas Liberações, dependendo da complexidade do projeto
Versão simples:
Exemplo: Pagamento de Parcela de Bolsa
Uma fundação quer liberar financiamento progressivamente após a conclusão dos entregáveis.
Design sugerido:
Pagador
Fundação ou patrocinador
Recebedor
Beneficiário
Prestador de Serviço
Beneficiário
Aprovador
Revisor da bolsa ou comitê
Assinante da Liberação
Assinante da fundação ou assinante do programa
Endereço da Plataforma
Endereço da taxa do programa
Tipo de Garantia
Múltiplas Liberações
Versão simples:
Exemplo: Caução
Um inquilino deposita fundos que devem ser mantidos até que a condição da locação seja concluída.
Design sugerido:
Pagador
Inquilino
Recebedor
Inquilino, proprietário ou ambos, dependendo do resultado
Prestador de Serviço
Administrador do imóvel ou plataforma
Aprovador
Administrador do imóvel, proprietário, inquilino ou revisor neutro
Assinante da Liberação
Assinante controlado pela plataforma ou assinante acordado
Endereço da Plataforma
Endereço da taxa de depósito
Tipo de Garantia
Liberação Única ou fluxo condicional
Versão simples:
Como Pensar Sobre a Trustless Work
A Trustless Work não é apenas um aplicativo de garantia.
É infraestrutura para coordenação programável de transações.
Use-a quando seu produto precisar responder:
O que precisa acontecer antes que os fundos se movimentem?
Se a resposta envolver várias partes, marcos, aprovações ou condições de liberação, a Trustless Work pode ajudá-lo a codificar essa lógica em uma garantia inteligente.
Próximos Passos
Agora que você entende o modelo de design de garantia:
Defina Propriedades da Garantia
Escolha seu Tipo de Garantia
Atribua Funções
Siga o Ciclo de Vida
Atualizado