# Funções na Trustless Work
Os papéis definem quem pode fazer o quê dentro de um escrow da Trustless Work.
Qualquer pessoa pode depositar fundos em um escrow. Mas apenas endereços com papéis atribuídos podem atualizar marcos, aprovar o trabalho, liberar fundos ou resolver disputas.
É isso que torna os escrows da Trustless Work programáveis.
Em vez de assumir que uma única plataforma, empresa ou pessoa controla tudo, cada escrow define explicitamente os endereços responsáveis por cada ação.
Uma boa configuração de papéis responde:
> Quem precisa fazer o quê antes que o dinheiro possa ser movimentado?
***
Os papéis são marcados em preto
***
### Por que os Papéis Importam
Um escrow é um sistema de coordenação.
Diferentes partes podem precisar de poderes diferentes:
* uma parte deposita fundos no escrow
* uma parte executa o trabalho
* uma parte atualiza o status do marco
* uma parte valida a conclusão
* uma parte libera os fundos
* uma parte recebe os fundos
* uma parte resolve disputas
* uma plataforma recebe uma taxa
A Trustless Work separa essas responsabilidades em papéis.
Isso torna o escrow mais fácil de entender, mais seguro de configurar e mais flexível entre diferentes casos de uso.
***
### Permissões Baseadas em Papéis
Todo escrow inclui um objeto de papéis.
Cada papel é atribuído a um endereço.
Somente o endereço atribuído a esse papel pode executar as ações associadas a ele.
Por exemplo:
* apenas o **Provedor de Serviço** pode atualizar o status do marco
* apenas o **Aprovador** pode aprovar marcos
* apenas o **Assinante da Liberação** pode liberar fundos
* apenas o **Resolutor de Disputas** pode resolver disputas
* o **Recebedor** recebe os fundos após a liberação
* o **Endereço da Plataforma** recebe as taxas da plataforma e pode atualizar os detalhes do escrow antes do financiamento
Esse modelo baseado em papéis permite que plataformas criem diferentes fluxos de confiança sem escrever contratos inteligentes personalizados do zero.
***
### Papéis Principais
### 1. Provedor de Serviço
O Provedor de Serviço é responsável por entregar o produto, serviço, marco ou resultado definido no escrow.
Esse papel normalmente representa a parte que está realizando o trabalho.
#### O que o Provedor de Serviço pode fazer
* alterar o status do marco
* adicionar evidências ou prova de entrega
* abrir uma disputa
#### Exemplos
| Caso de uso | Provedor de Serviço |
| ------------------------ | -------------------------------------------------------------- |
| Pagamento de marketplace | Vendedor, freelancer, fornecedor ou prestador de serviços |
| Marcos de projeto | Contratado ou equipe do projeto |
| Pagamentos | Colaborador, fornecedor ou proprietário do marco |
| Financiamento coletivo | Empresa ou responsável pela campanha atualizando o progresso |
| Fluxo de conformidade | Equipe de conformidade marcando uma verificação como concluída |
#### Nota de design
O Provedor de Serviço comunica o progresso.
Ele não aprova automaticamente o próprio trabalho.
Na maioria dos fluxos:
```txt
Provedor de Serviço atualiza o status
Aprovador valida a conclusão
Assinante da Liberação libera os fundos
```
***
### 2. Aprovador
O Aprovador valida se um marco foi realmente concluído.
Esse papel é responsável por dar a aprovação da conclusão antes que os fundos possam ser liberados.
#### O que o Aprovador pode fazer
* assinar a aprovação de um marco
* abrir uma disputa se o trabalho não estiver satisfatório
#### Exemplos
| Caso de uso | Aprovador |
| ------------------------ | -------------------------------------------------------------- |
| Pagamento de marketplace | Comprador, cliente ou revisor da plataforma |
| Marcos de projeto | Cliente, proprietário do projeto ou revisor |
| Pagamentos | Revisor do programa, mantenedor ou administrador da plataforma |
| Depósito de segurança | Anfitrião, gerente do imóvel, inquilino ou revisor neutro |
| Financiamento coletivo | Revisor da plataforma ou da campanha |
#### Nota de design
A aprovação não é a mesma coisa que uma atualização de status.
Uma atualização de status comunica progresso.
A aprovação valida que a condição acordada foi atendida.
Em alguns fluxos, o Aprovador pode aprovar antes de o Provedor de Serviço atualizar o status. O ponto importante é que a aprovação deve permanecer uma ação explícita de validação.
***
### 3. Assinante da Liberação
O Assinante da Liberação aciona a liberação real dos fundos quando as aprovações necessárias estão em vigor.
Esse papel é responsável por executar a movimentação do pagamento.
#### O que o Assinante da Liberação pode fazer
* liberar fundos depois que todos os marcos forem aprovados em um Escrow de Liberação Única
* liberar fundos para cada marco aprovado em um Escrow de Múltiplas Liberações
* abrir uma disputa se houver discordância na etapa de liberação
#### Exemplos
| Caso de uso | Assinante da Liberação |
| ------------------------ | ----------------------------------------------------------------------------------- |
| Pagamento de marketplace | Comprador, assinante da plataforma ou endereço autorizado para liberação |
| Marcos de projeto | Cliente, assinante da plataforma ou proprietário do projeto |
| Pagamentos | Assinante da plataforma, assinante do tesouro ou endereço autorizado para liberação |
| Recompensa de DAO | Assinante da DAO ou assinante autorizado para pagamento de colaboradores |
| Depósito de segurança | Assinante controlado pela plataforma ou autoridade de liberação acordada |
#### Nota de design
O Assinante da Liberação executa a liberação.
O Assinante da Liberação não deve ser confundido com o Aprovador.
Em fluxos simples, o mesmo endereço pode ser tanto Aprovador quanto Assinante da Liberação. Em fluxos mais sensíveis, esses papéis devem ser separados.
Fluxo normal de liberação:
```
Atualização de status → Aprovação → Liberação
```
***
### 4. Recebedor
O Recebedor é o destino final dos fundos liberados.
Esse papel recebe os fundos quando as condições do escrow são atendidas e a liberação é acionada.
#### O que o Recebedor pode fazer
* receber fundos assim que a liberação for acionada
#### Exemplos
| Caso de uso | Recebedor |
| ------------------------ | ------------------------------------------------------------------------- |
| Pagamento de marketplace | Vendedor, freelancer, fornecedor ou prestador de serviços |
| Marcos de projeto | Mesmo contratado ou equipe do projeto ao longo dos marcos |
| Pagamentos | Diferente colaborador, fornecedor ou equipe por marco |
| Financiamento coletivo | Empresa recebendo financiamento baseado em marcos |
| Depósito de segurança | Inquilino, anfitrião ou outro destinatário final, dependendo do resultado |
#### Nota de design
O Recebedor não é automaticamente o Provedor de Serviço.
Em muitos casos, eles são a mesma parte.
Por exemplo, um freelancer pode ser ambos:
```
Provedor de Serviço = freelancerRecebedor = carteira do freelancer
```
Mas em outros casos, eles podem ser diferentes.
Exemplo:
```
Provedor de Serviço = gerente de projetoRecebedor = tesouraria da empresa
```
***
### 5. Resolutor de Disputas
O Resolutor de Disputas intervém quando as partes discordam ou quando algo dá errado.
Esse é um papel central no modelo de papéis da Trustless Work.
#### O que o Resolutor de Disputas pode fazer
* resolver disputas redirecionando fundos
#### Exemplos
| Caso de uso | Resolutor de Disputas |
| ------------------------ | --------------------------------------------------------------- |
| Pagamento de marketplace | Marketplace, plataforma ou resolvedor neutro |
| Marcos de projeto | Árbitro, administrador do projeto ou revisor da plataforma |
| Pagamentos | Administrador do programa, mantenedor ou processo de governança |
| Depósito de segurança | Plataforma, gerente do imóvel ou resolvedor neutro de disputas |
| Financiamento coletivo | Plataforma da campanha ou revisor independente |
#### Nota de design
O Resolutor de Disputas deve ser configurado de forma intencional.
Esse papel tem autoridade importante porque pode afetar para onde os fundos vão quando uma disputa é aberta.
Uma disputa não faz parte de todos os fluxos normais de escrow, mas o papel de Resolutor de Disputas existe para que o escrow tenha uma autoridade de resolução definida caso ocorra um conflito.
Fluxo em disputa:
```
Disputa aberta → Resolutor de Disputas analisa → Fundos são redirecionados ou resolvidos
```
***
### 6. Endereço da Plataforma
O Endereço da Plataforma representa a plataforma ou aplicação que integra a Trustless Work.
Esse papel normalmente é usado para taxas da plataforma e alterações de configuração antes do financiamento.
#### O que o Endereço da Plataforma pode fazer
* cobrar taxas da plataforma automaticamente
* atualizar detalhes do escrow enquanto o escrow ainda não foi financiado
#### Exemplos
| Caso de uso | Endereço da Plataforma |
| ------------------------ | -------------------------------------------------------------------- |
| Pagamento de marketplace | Endereço de taxa do marketplace |
| Marcos de projeto | Endereço de taxa da plataforma SaaS ou de infraestrutura |
| Pagamentos | Endereço de taxa da plataforma do programa, recompensa ou tesouraria |
| Financiamento coletivo | Endereço de taxa da plataforma de crowdfunding |
| Depósito de segurança | Endereço de taxa da plataforma de aluguel |
#### Nota de design
O Endereço da Plataforma não é a mesma coisa que o Recebedor.
O Endereço da Plataforma recebe a taxa da plataforma.
O Recebedor recebe o pagamento do escrow.
Exemplo:
```
Recebedor = freelancerEndereço da Plataforma = carteira de taxas do marketplace
```
Além disso, a cobrança de taxas não deve ser confundida com controle total sobre os fundos. O Endereço da Plataforma pode atualizar os detalhes do escrow antes do financiamento, mas, uma vez que os fundos ficam travados, o fluxo do escrow deve seguir as regras de papéis e ciclo de vida.
***
### Outros Endereços que Você Pode Ver
Alguns endereços podem interagir com o escrow ou aparecer em dados indexados, mas eles não têm as mesmas permissões de ação dos papéis principais acima.
***
### Emissor
O Emissor não tem poderes sobre o contrato.
Esse endereço pode estar presente por causa de como ativos, contratos ou metadados são representados, mas ele não controla as ações do escrow.
#### Pode executar
* nenhuma ação de escrow
***
### Depositante
O Depositante é qualquer endereço que envia fundos para o escrow.
Toda transação de entrada no escrow é indexada.
No entanto, depositar fundos não concede automaticamente permissões a esse endereço dentro do escrow.
#### Pode executar
* depositar fundos
#### Não pode executar automaticamente
* atualizar marcos
* aprovar marcos
* liberar fundos
* resolver disputas
#### Nota de design
Essa distinção é importante.
Uma carteira pode financiar um escrow sem se tornar o Aprovador, o Assinante da Liberação ou o Recebedor.
***
### Observador
Observador está planejado para uma versão futura.
Um Observador é um endereço que deseja acompanhar um escrow sem agir sobre ele.
#### Finalidade pretendida
* observar a atividade do escrow
* facilitar o acompanhamento por papel
* dar suporte a painéis, notificações e casos de uso de transparência
#### Pode executar
* nenhuma ação de escrow
***
### Status, Aprovação, Disputa e Liberação são diferentes
Não reduza essas ações a um único conceito.
| Conceito | Papel geralmente responsável | Significado |
| --------------------- | -------------------------------------------------------- | ------------------------------ |
| Atualização de status | Provedor de Serviço | Comunica progresso |
| Aprovação | Aprovador | Valida a conclusão |
| Disputa | Provedor de Serviço, Aprovador ou Assinante da Liberação | Sinaliza discordância |
| Resolução | Resolutor de Disputas | Resolve o resultado da disputa |
| Liberação | Assinante da Liberação | Movimenta fundos |
| Pagamento | Recebedor | Recebe fundos |
| Cobrança de taxa | Endereço da Plataforma | Recebe a taxa da plataforma |
Essa distinção é central no design de escrows.
***
### Matriz de Capacidades dos Papéis
| Papel | Atualizar status do marco | Adicionar evidências | Aprovar marco | Abrir disputa | Resolver disputa | Liberar fundos | Receber pagamento | Receber taxa da plataforma | Atualizar antes do financiamento |
| ---------------------- | ------------------------- | -------------------- | --------------- | -------------- | ---------------- | --------------- | ----------------- | -------------------------- | -------------------------------- |
| Provedor de Serviço | Sim | Sim | Não | Sim | Não | Não | Às vezes | Não | Não |
| Aprovador | Não | Não | Sim | Sim | Não | Não | Geralmente não | Não | Não |
| Assinante da Liberação | Não | Não | Não | Sim | Não | Sim | Geralmente não | Não | Não |
| Recebedor | Não | Não | Não | Não | Não | Não | Sim | Não | Não |
| Resolutor de Disputas | Não | Não | Depende do caso | Não | Sim | Depende do caso | Não | Não | Não |
| Endereço da Plataforma | Não por padrão | Não por padrão | Não por padrão | Não por padrão | Não por padrão | Não por padrão | Não | Sim | Sim |
| Emissor | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Depositante | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Observador | Não | Não | Não | Não | Não | Não | Não | Não | Não |
***
### Como os Papéis Interagem
Em um fluxo normal de escrow:
```
1. O Depositante financia o escrow2. O Provedor de Serviço atualiza o status do marco3. O Aprovador valida o marco4. O Assinante da Liberação libera os fundos5. O Recebedor recebe o pagamento6. O Endereço da Plataforma recebe a taxa da plataforma
```
Se algo der errado:
```
1. O Provedor de Serviço, o Aprovador ou o Assinante da Liberação abre uma disputa2. O Resolutor de Disputas analisa a situação3. O Resolutor de Disputas resolve a disputa4. Os fundos são liberados, redirecionados ou resolvidos de acordo com a lógica do escrow
```
***
### Mapeamento de Papéis por Caso de Uso
### Pagamento de Marketplace
Caso de uso: **Escrow de liberação única**
| Papel | Exemplo |
| ---------------------- | ------------------------------------------------------------------------ |
| Depositante | Comprador ou cliente |
| Provedor de Serviço | Vendedor, freelancer ou fornecedor |
| Aprovador | Comprador, cliente ou revisor da plataforma |
| Assinante da Liberação | Comprador, assinante da plataforma ou endereço autorizado para liberação |
| Recebedor | Vendedor, freelancer ou fornecedor |
| Resolutor de Disputas | Marketplace, plataforma ou resolvedor neutro |
| Endereço da Plataforma | Endereço de taxa do marketplace |
Ideal para:
* um comprador
* um provedor
* um pagamento final
* confirmação simples de entrega
***
### Marcos de Projeto
Caso de uso: **Escrow de múltiplas liberações, mesmo recebedor**
| Papel | Exemplo |
| ---------------------- | ---------------------------------------------------------- |
| Depositante | Cliente, patrocinador ou proprietário do projeto |
| Provedor de Serviço | Contratado, equipe do projeto ou fornecedor |
| Aprovador | Cliente, revisor ou proprietário do projeto |
| Assinante da Liberação | Cliente, assinante da plataforma ou assinante autorizado |
| Recebedor | Mesmo contratado, equipe ou fornecedor ao longo dos marcos |
| Resolutor de Disputas | Plataforma, resolvedor neutro ou resolvedor designado |
| Endereço da Plataforma | Endereço de taxa da plataforma ou infraestrutura |
Ideal para:
* projetos em fases
* contratos baseados em marcos
* subsídios para uma equipe
* trabalho de implementação
* acordos de serviço pagos ao longo do tempo
***
### Pagamentos
Caso de uso: **Escrow de múltiplas liberações, múltiplos recebedores**
| Papel | Exemplo |
| ---------------------- | ----------------------------------------------------------------------------------- |
| Depositante | Patrocinador, plataforma, organização ou tesouraria |
| Provedor de Serviço | Colaborador, fornecedor, equipe ou proprietário do marco |
| Aprovador | Revisor do programa, mantenedor, cliente ou administrador da plataforma |
| Assinante da Liberação | Assinante da plataforma, assinante do tesouro ou endereço autorizado para liberação |
| Recebedor | Recebedor diferente por marco |
| Resolutor de Disputas | Plataforma, resolvedor neutro, administrador do programa ou processo de governança |
| Endereço da Plataforma | Endereço de taxa do programa, recompensa ou plataforma |
Ideal para:
* recompensas
* pagamentos a colaboradores
* projetos com vários fornecedores
* recompensas de hackathon
* programas de incentivo do ecossistema
* subsídios com várias equipes
***
### Padrões Comuns de Combinação de Papéis
O mesmo endereço às vezes pode acumular vários papéis.
Isso deve ser feito de forma intencional.
#### Combinações comuns
| Combinação | Quando faz sentido | Risco |
| ---------------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------- |
| Provedor de Serviço + Recebedor | Um freelancer executa o trabalho e recebe o pagamento | Baixo, padrão comum |
| Depositante + Aprovador | Um cliente financia e aprova o trabalho | Comum, mas o cliente pode atrasar a aprovação |
| Aprovador + Assinante da Liberação | Fluxos simples em que o aprovador também libera os fundos | Concentra autoridade de validação e execução |
| Endereço da Plataforma + Resolutor de Disputas | A plataforma lida com taxas e resolução de disputas | A plataforma ganha influência significativa sobre os resultados |
#### Combinações de risco
| Combinação | Por que é arriscado |
| ---------------------------------- | -------------------------------------------------------------------------------------------- |
| Provedor de Serviço + Aprovador | A parte pode aprovar o próprio trabalho |
| Recebedor + Assinante da Liberação | O recebedor pode conseguir acionar o pagamento para si mesmo se as salvaguardas forem fracas |
| Endereço da Plataforma + Recebedor | Confunde o destinatário da taxa com o destinatário do pagamento |
| Um endereço com todos os papéis | Recria um controle centralizado semelhante à custódia |
***
### Checklist de Design de Papéis
Antes de implantar um escrow, confirme:
* Quem financia o escrow?
* Quem atualiza o status do marco?
* Quem aprova a conclusão?
* Quem pode abrir uma disputa?
* Quem resolve disputas?
* Quem libera os fundos?
* Quem recebe o pagamento?
* Quem recebe as taxas da plataforma?
* O Recebedor é diferente do Endereço da Plataforma?
* O Provedor de Serviço também é o Recebedor?
* O Aprovador também é o Assinante da Liberação?
* Algum papel deve ser separado por segurança?
* O caso de uso exige um Resolutor de Disputas neutro?
* Você está usando Liberação Única ou Múltiplas Liberações?
* Há vários recebedores?
---
# 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/roles-in-trustless-work.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.