# Design de escrow 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: 1. **Quem são as partes envolvidas?** 2. **Para onde os fundos estão indo?** 3. **Quem tem permissão para atualizar, aprovar e liberar?** 4. **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: | Parte | O que representam | | ---------------------------------------- | ---------------------------------------------------------------------------------------- | | 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. ```txt Comprador / Cliente → financia a garantia → Vendedor / Prestador de Serviço recebe um pagamento final ``` ### 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. ``` Cliente → financia a garantia → pagamento do Marco 1 para o mesmo recebedor → pagamento do Marco 2 para o mesmo recebedor → pagamento do Marco 3 para o mesmo recebedor ``` ### 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. ``` Patrocinador / Plataforma → financia a garantia → pagamento do Marco 1 para o Recebedor A → pagamento do Marco 2 para o Recebedor B → pagamento do Marco 3 para o Recebedor C ``` *** ### 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: | Conceito | Significado | | --------- | ------------------------------------------ | | 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: ``` Atualização de status / evidência → Aprovação → Liberação ``` *** ### 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: | Função | Responsabilidade principal | | ---------------------- | -------------------------------------------------------------------------------------------------------------------- | | 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 | Função | Pode atualizar o status? | Pode aprovar? | Pode abrir disputa? | Pode resolver disputa? | Pode liberar fundos? | Recebe fundos? | Observaçõ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: | Propriedade | Descrição | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | 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: 1. **Garantia de Liberação Única** 2. **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: ``` Pagador → Garantia → Recebedor ``` Fluxo típico: ``` Criar garantia Financiar garantia Atualizar marco 1 Aprovar marco 1 Atualizar marco 2 Aprovar marco 2 Liberar valor total Encerrar garantia ``` Melhor para: * depósitos * trabalhos pontuais * entregas simples * conclusão total do projeto * compras em marketplace * entrega final antes do pagamento Características principais: | Dimensão | Garantia de Liberação Única | | ------------------- | ------------------------------------------------------------------ | | 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: ``` Pagador → Garantia → Recebedor do Marco 1 → Recebedor do Marco 2 → Recebedor do Marco 3 ``` Fluxo típico: ``` Criar garantia Financiar garantia Atualizar marco 1 Aprovar marco 1 Liberar fundos do marco 1 Atualizar marco 2 Aprovar marco 2 Liberar fundos do marco 2 Encerrar garantia ``` 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: | Dimensão | Garantia de Múltiplas Liberações | | ------------------- | ------------------------------------------ | | 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 | Pergunta | Use Liberação Única | Use 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: ``` Design → Iniciação → Financiamento → Atualizações de Marcos → Aprovação → Liberação → Encerramento ``` #### 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: | Elemento | Exemplo | | ---------------------- | ------------------------------------------------------------------------------ | | 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: ``` Cliente financia a garantia Freelancer conclui o trabalho Freelancer marca o marco como concluído Cliente aprova Assinante da liberação libera os fundos para o freelancer Marketplace recebe a taxa ``` *** ### Exemplo: Pagamento de Parcela de Bolsa Uma fundação quer liberar financiamento progressivamente após a conclusão dos entregáveis. Design sugerido: | Elemento | Exemplo | | ---------------------- | ---------------------------------------------- | | 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: ``` A fundação financia a garantia O beneficiário envia o entregável 1 O revisor aprova o entregável 1 O assinante da liberação libera a tranche 1 O beneficiário envia o entregável 2 O revisor aprova o entregável 2 O assinante da liberação libera a tranche 2 ``` *** ### Exemplo: Caução Um inquilino deposita fundos que devem ser mantidos até que a condição da locação seja concluída. Design sugerido: | Elemento | Exemplo | | ---------------------- | ------------------------------------------------------------------ | | 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: ``` Inquilino financia a garantia Depósito permanece bloqueado A condição é analisada O aprovador valida o resultado O assinante da liberação libera os fundos de acordo com o resultado ``` *** ### 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: 1. Defina [Propriedades da Garantia](/trustless-work/v1-pt/introducao/technology-overview/what-does-a-smart-escrow-look-like.md) 2. Escolha seu[ Tipo de Garantia](/trustless-work/v1-pt/introducao/technology-overview/tipos-de-escrow.md) 3. Atribua [Funções](/trustless-work/v1-pt/introducao/technology-overview/roles-in-trustless-work.md) 4. Siga o [Ciclo de Vida](/trustless-work/v1-pt/introducao/technology-overview/escrow-lifecycle.md) 5. Integre por meio da [API](/trustless-work/v1-pt/api-rest/introduction.md), [SDK](/trustless-work/v1-pt/sdk-react-de-escrow/introducao.md), ou [Blocos](/trustless-work/v1-pt/sdk-blocks-de-escrow/introducao.md) *** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.trustlesswork.com/trustless-work/v1-pt/introducao/technology-overview.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.