# Roles en Trustless Work
Los roles definen quién puede hacer qué dentro de un escrow de Trustless Work.
Cualquiera puede depositar fondos en un escrow. Pero solo las direcciones con roles asignados pueden actualizar hitos, aprobar el trabajo, liberar fondos o resolver disputas.
Esto es lo que hace que los escrows de Trustless Work sean programables.
En lugar de asumir que una sola plataforma, empresa o persona controla todo, cada escrow define explícitamente las direcciones responsables de cada acción.
Una buena configuración de roles responde:
> ¿Quién debe hacer qué antes de que el dinero pueda moverse?
***
Los roles se marcan en negro
***
### Por qué importan los roles
Un escrow es un sistema de coordinación.
Distintas partes pueden necesitar distintos poderes:
* una parte financia el escrow
* una parte realiza el trabajo
* una parte actualiza el estado del hito
* una parte valida la finalización
* una parte libera los fondos
* una parte recibe los fondos
* una parte resuelve disputas
* una plataforma recibe una tarifa
Trustless Work separa estas responsabilidades en roles.
Esto hace que el escrow sea más fácil de razonar, más seguro de configurar y más flexible en distintos casos de uso.
***
### Permisos basados en roles
Cada escrow incluye un objeto de roles.
Cada rol se asigna a una dirección.
Solo la dirección asignada a ese rol puede realizar las acciones asociadas con ese rol.
Por ejemplo:
* solo el **Proveedor de servicios** puede actualizar el estado del hito
* solo el **Aprobador** puede aprobar hitos
* solo el **Firmante de liberación** puede liberar fondos
* solo el **Resolutor de disputas** puede resolver disputas
* el **Receptor** recibe los fondos después de la liberación
* el **Dirección de la plataforma** recibe las tarifas de la plataforma y puede actualizar los detalles del escrow antes del financiamiento
Este modelo basado en roles permite a las plataformas diseñar distintos flujos de confianza sin escribir desde cero contratos inteligentes personalizados.
***
### Roles principales
### 1. Proveedor de servicios
El Proveedor de servicios es responsable de entregar el producto, servicio, hito o resultado definido en el escrow.
Este rol normalmente representa a la parte que realiza el trabajo.
#### Qué puede hacer el Proveedor de servicios
* cambiar el estado del hito
* añadir evidencia o prueba de entrega
* presentar una disputa
#### Ejemplos
| Caso de uso | Proveedor de servicios |
| --------------------- | ---------------------------------------------------------------- |
| Pago en marketplace | Vendedor, freelancer, proveedor o contratista |
| Hitos del proyecto | Contratista o equipo del proyecto |
| Pagos | Colaborador, proveedor o propietario del hito |
| Crowdfunding | Empresa o propietario de la campaña que actualiza el progreso |
| Flujo de cumplimiento | Equipo de cumplimiento marcando una verificación como completada |
#### Nota de diseño
El Proveedor de servicios comunica el progreso.
No aprueba automáticamente su propio trabajo.
En la mayoría de los flujos:
```txt
El Proveedor de servicios actualiza el estado
El Aprobador valida la finalización
El Firmante de liberación libera los fondos
```
***
### 2. Aprobador
El Aprobador valida que un hito realmente se haya completado.
Este rol es responsable de dar el visto bueno a la finalización antes de que los fondos puedan liberarse.
#### Qué puede hacer el Aprobador
* firmar la aprobación de un hito
* presentar una disputa si el trabajo no es satisfactorio
#### Ejemplos
| Caso de uso | Aprobador |
| --------------------- | --------------------------------------------------------------------- |
| Pago en marketplace | Comprador, cliente o revisor de la plataforma |
| Hitos del proyecto | Cliente, propietario del proyecto o revisor |
| Pagos | Revisor del programa, mantenedor o administrador de la plataforma |
| Depósito de seguridad | Anfitrión, administrador de la propiedad, inquilino o revisor neutral |
| Crowdfunding | Revisor de la plataforma o de la campaña |
#### Nota de diseño
La aprobación no es lo mismo que una actualización de estado.
Una actualización de estado comunica progreso.
La aprobación valida que se ha cumplido la condición acordada.
En algunos flujos, el Aprobador puede aprobar antes de que el Proveedor de servicios actualice el estado. El punto importante es que la aprobación debe seguir siendo una acción de validación explícita.
***
### 3. Firmante de liberación
El Firmante de liberación activa la liberación real de los fondos una vez que están en su lugar las aprobaciones requeridas.
Este rol es responsable de ejecutar el movimiento del pago.
#### Qué puede hacer el Firmante de liberación
* liberar fondos después de que todos los hitos estén aprobados en un escrow de liberación única
* liberar fondos por cada hito aprobado en un escrow de liberaciones múltiples
* presentar una disputa si hay desacuerdo en la etapa de liberación
#### Ejemplos
| Caso de uso | Firmante de liberación |
| --------------------- | ----------------------------------------------------------------------------------- |
| Pago en marketplace | Comprador, firmante de la plataforma o dirección de liberación autorizada |
| Hitos del proyecto | Cliente, firmante de la plataforma o propietario del proyecto |
| Pagos | Firmante de la plataforma, firmante del tesoro o dirección de liberación autorizada |
| Bono de DAO | Firmante de DAO o firmante autorizado de pago a colaboradores |
| Depósito de seguridad | Firmante controlado por la plataforma o autoridad de liberación acordada |
#### Nota de diseño
El Firmante de liberación ejecuta la liberación.
El Firmante de liberación no debe confundirse con el Aprobador.
En flujos simples, la misma dirección puede ser tanto Aprobador como Firmante de liberación. En flujos más sensibles, esos roles deben separarse.
Flujo normal de liberación:
```
Actualización de estado → Aprobación → Liberación
```
***
### 4. Receptor
El Receptor es el destino final de los fondos liberados.
Este rol recibe fondos una vez que se cumplen las condiciones del escrow y se activa la liberación.
#### Qué puede hacer el Receptor
* recibir fondos una vez que se activa la liberación
#### Ejemplos
| Caso de uso | Receptor |
| --------------------- | ----------------------------------------------------------------- |
| Pago en marketplace | Vendedor, freelancer, proveedor o contratista |
| Hitos del proyecto | Mismo contratista o equipo del proyecto a lo largo de los hitos |
| Pagos | Distinto colaborador, proveedor o equipo por hito |
| Crowdfunding | Empresa que recibe financiamiento basado en hitos |
| Depósito de seguridad | Inquilino, anfitrión u otro destinatario final según el resultado |
#### Nota de diseño
El Receptor no es automáticamente el Proveedor de servicios.
En muchos casos, son la misma parte.
Por ejemplo, un freelancer puede ser ambos:
```
Proveedor de servicios = freelancerReceptor = billetera del freelancer
```
Pero en otros casos, pueden ser diferentes.
Ejemplo:
```
Proveedor de servicios = gestor de proyectoReceptor = tesorería de la empresa
```
***
### 5. Resolutor de disputas
El Resolutor de disputas interviene cuando las partes no están de acuerdo o cuando algo sale mal.
Este es un rol central en el modelo de roles de Trustless Work.
#### Qué puede hacer el Resolutor de disputas
* resolver disputas redirigiendo fondos
#### Ejemplos
| Caso de uso | Resolutor de disputas |
| --------------------- | ------------------------------------------------------------------------- |
| Pago en marketplace | Marketplace, plataforma o resolutor neutral |
| Hitos del proyecto | Árbitro, administrador del proyecto o revisor de la plataforma |
| Pagos | Administrador del programa, mantenedor o proceso de gobernanza |
| Depósito de seguridad | Plataforma, administrador de la propiedad o resolutor neutral de disputas |
| Crowdfunding | Plataforma de campaña o revisor independiente |
#### Nota de diseño
El Resolutor de disputas debe configurarse de forma intencional.
Este rol tiene una autoridad importante porque puede afectar hacia dónde van los fondos cuando se presenta una disputa.
Una disputa no forma parte de todas las rutas normales del escrow, pero el rol de Resolutor de disputas existe para que el escrow tenga una autoridad de resolución definida si ocurre un conflicto.
Flujo con disputa:
```
Disputa presentada → El Resolutor de disputas revisa → Los fondos se redirigen o se resuelven
```
***
### 6. Dirección de la plataforma
La Dirección de la plataforma representa a la plataforma o aplicación que integra Trustless Work.
Este rol suele usarse para las tarifas de plataforma y los cambios de configuración previos al financiamiento.
#### Qué puede hacer la Dirección de la plataforma
* cobrar automáticamente las tarifas de la plataforma
* actualizar los detalles del escrow mientras el escrow no haya sido financiado
#### Ejemplos
| Caso de uso | Dirección de la plataforma |
| --------------------- | ------------------------------------------------------------------ |
| Pago en marketplace | Dirección de tarifa de marketplace |
| Hitos del proyecto | Dirección de tarifa de plataforma SaaS o de infraestructura |
| Pagos | Dirección de tarifa de programa, bono o tesorería de la plataforma |
| Crowdfunding | Dirección de tarifa de plataforma de crowdfunding |
| Depósito de seguridad | Dirección de tarifa de plataforma de alquiler |
#### Nota de diseño
La Dirección de la plataforma no es lo mismo que el Receptor.
La Dirección de la plataforma recibe la tarifa de la plataforma.
El Receptor recibe el pago del escrow.
Ejemplo:
```
Receptor = freelancerDirección de la plataforma = billetera de tarifas del marketplace
```
Además, la recaudación de tarifas no debe confundirse con el control total de los fondos. La Dirección de la plataforma puede actualizar los detalles del escrow antes del financiamiento, pero una vez que los fondos están bloqueados, el flujo del escrow debe seguir las reglas de roles y ciclo de vida.
***
### Otras direcciones que puedes ver
Algunas direcciones pueden interactuar con el escrow o aparecer en datos indexados, pero no tienen los mismos permisos de acción que los roles principales anteriores.
***
### Emisor
El Emisor no tiene poderes sobre el contrato.
Esta dirección puede estar presente por la forma en que se representan los activos, contratos o metadatos, pero no controla las acciones del escrow.
#### Puede realizar
* ninguna acción de escrow
***
### Depositante
El Depositante es cualquier dirección que envía fondos al escrow.
Cada transacción entrante al escrow se indexa.
Sin embargo, depositar fondos no otorga automáticamente a esa dirección permisos dentro del escrow.
#### Puede realizar
* depositar fondos
#### No puede realizar automáticamente
* actualizar hitos
* aprobar hitos
* liberar fondos
* resolver disputas
#### Nota de diseño
Esta distinción importa.
Una billetera puede financiar un escrow sin convertirse en el Aprobador, el Firmante de liberación o el Receptor.
***
### Observador
Observador está previsto para una versión futura.
Un Observador es una dirección que quiere seguir un escrow sin actuar sobre él.
#### Propósito previsto
* observar la actividad del escrow
* facilitar el seguimiento por rol
* dar soporte a paneles, notificaciones y casos de uso de transparencia
#### Puede realizar
* ninguna acción de escrow
***
### Estado, Aprobación, Disputa y Liberación son diferentes
No mezcles estas acciones en un solo concepto.
| Concepto | Rol normalmente responsable | Significado |
| ----------------------- | ---------------------------------------------------------- | ----------------------------------- |
| Actualización de estado | Proveedor de servicios | Comunica progreso |
| Aprobación | Aprobador | Valida la finalización |
| Disputa | Proveedor de servicios, Aprobador o Firmante de liberación | Señala desacuerdo |
| Resolución | Resolutor de disputas | Resuelve el resultado de la disputa |
| Liberación | Firmante de liberación | Mueve fondos |
| Pago | Receptor | Recibe fondos |
| Cobro de tarifas | Dirección de la plataforma | Recibe la tarifa de la plataforma |
Esta distinción es fundamental para el diseño del escrow.
***
### Matriz de capacidades de roles
| Rol | Actualizar estado del hito | Añadir evidencia | Aprobar hito | Presentar disputa | Resolver disputa | Liberar fondos | Recibir pago | Recibir tarifa de plataforma | Actualizar antes del financiamiento |
| -------------------------- | -------------------------- | ---------------- | ---------------- | ----------------- | ---------------- | ---------------- | -------------- | ---------------------------- | ----------------------------------- |
| Proveedor de servicios | Sí | Sí | No | Sí | No | No | A veces | No | No |
| Aprobador | No | No | Sí | Sí | No | No | Normalmente no | No | No |
| Firmante de liberación | No | No | No | Sí | No | Sí | Normalmente no | No | No |
| Receptor | No | No | No | No | No | No | Sí | No | No |
| Resolutor de disputas | No | No | Depende del caso | No | Sí | Depende del caso | No | No | No |
| Dirección de la plataforma | No por defecto | No por defecto | No por defecto | No por defecto | No por defecto | No por defecto | No | Sí | Sí |
| Emisor | No | No | No | No | No | No | No | No | No |
| Depositante | No | No | No | No | No | No | No | No | No |
| Observador | No | No | No | No | No | No | No | No | No |
***
### Cómo interactúan los roles
En un flujo normal de escrow:
```
1. El Depositante financia el escrow2. El Proveedor de servicios actualiza el estado del hito3. El Aprobador valida el hito4. El Firmante de liberación libera los fondos5. El Receptor recibe el pago6. La Dirección de la plataforma recibe la tarifa de la plataforma
```
Si algo sale mal:
```
1. El Proveedor de servicios, el Aprobador o el Firmante de liberación presenta una disputa2. El Resolutor de disputas revisa la situación3. El Resolutor de disputas resuelve la disputa4. Los fondos se liberan, redirigen o resuelven según la lógica del escrow
```
***
### Mapeo de roles por caso de uso
### Pago en Marketplace
Caso de uso: **escrow de liberación única**
| Rol | Ejemplo |
| -------------------------- | ------------------------------------------------------------------------- |
| Depositante | Comprador o cliente |
| Proveedor de servicios | Vendedor, freelancer o proveedor |
| Aprobador | Comprador, cliente o revisor de la plataforma |
| Firmante de liberación | Comprador, firmante de la plataforma o dirección de liberación autorizada |
| Receptor | Vendedor, freelancer o proveedor |
| Resolutor de disputas | Marketplace, plataforma o resolutor neutral |
| Dirección de la plataforma | Dirección de tarifa de marketplace |
Ideal para:
* un comprador
* un proveedor
* un pago final
* confirmación simple de entrega
***
### Hitos del proyecto
Caso de uso: **escrow de liberaciones múltiples, mismo receptor**
| Rol | Ejemplo |
| -------------------------- | ------------------------------------------------------------- |
| Depositante | Cliente, patrocinador o propietario del proyecto |
| Proveedor de servicios | Contratista, equipo del proyecto o proveedor |
| Aprobador | Cliente, revisor o propietario del proyecto |
| Firmante de liberación | Cliente, firmante de la plataforma o firmante autorizado |
| Receptor | Mismo contratista, equipo o proveedor a lo largo de los hitos |
| Resolutor de disputas | Plataforma, resolutor neutral o resolutor asignado |
| Dirección de la plataforma | Dirección de tarifa de la plataforma o de infraestructura |
Ideal para:
* proyectos por fases
* contratos basados en hitos
* subvenciones para un solo equipo
* trabajo de implementación
* acuerdos de servicio pagados con el tiempo
***
### Pagos
Caso de uso: **escrow de liberaciones múltiples, múltiples receptores**
| Rol | Ejemplo |
| -------------------------- | ----------------------------------------------------------------------------------- |
| Depositante | Patrocinador, plataforma, organización o tesorería |
| Proveedor de servicios | Colaborador, proveedor, equipo o propietario del hito |
| Aprobador | Revisor del programa, mantenedor, cliente o administrador de la plataforma |
| Firmante de liberación | Firmante de la plataforma, firmante del tesoro o dirección de liberación autorizada |
| Receptor | Un receptor diferente por hito |
| Resolutor de disputas | Plataforma, resolutor neutral, administrador del programa o proceso de gobernanza |
| Dirección de la plataforma | Dirección de tarifa de programa, bono o plataforma |
Ideal para:
* bonos
* pagos a colaboradores
* proyectos con múltiples proveedores
* recompensas de hackathon
* programas de incentivos del ecosistema
* subvenciones con múltiples equipos
***
### Patrones comunes de combinación de roles
La misma dirección a veces puede tener varios roles.
Esto debe hacerse de forma intencional.
#### Combinaciones comunes
| Combinación | Cuándo tiene sentido | Riesgo |
| -------------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------- |
| Proveedor de servicios + Receptor | Un freelancer realiza el trabajo y recibe el pago | Bajo, patrón común |
| Depositante + Aprobador | Un cliente financia y aprueba el trabajo | Común, pero el cliente puede retrasar la aprobación |
| Aprobador + Firmante de liberación | Flujos simples en los que el aprobador también libera los fondos | Concentra la autoridad de validación y ejecución |
| Dirección de la plataforma + Resolutor de disputas | La plataforma gestiona tarifas y resolución de disputas | La plataforma obtiene una influencia significativa sobre los resultados |
#### Combinaciones de riesgo
| Combinación | Por qué es riesgoso |
| -------------------------------------- | --------------------------------------------------------------------------------- |
| Proveedor de servicios + Aprobador | La parte puede aprobar su propio trabajo |
| Receptor + Firmante de liberación | El receptor podría activar un pago hacia sí mismo si las salvaguardas son débiles |
| Dirección de la plataforma + Receptor | Confunde al destinatario de la tarifa con el destinatario del pago |
| Una sola dirección con todos los roles | Recrea un control centralizado similar al de custodia |
***
### Lista de verificación de diseño de roles
Antes de desplegar un escrow, confirma:
* ¿Quién financia el escrow?
* ¿Quién actualiza el estado del hito?
* ¿Quién aprueba la finalización?
* ¿Quién puede presentar una disputa?
* ¿Quién resuelve las disputas?
* ¿Quién libera los fondos?
* ¿Quién recibe el pago?
* ¿Quién recibe las tarifas de la plataforma?
* ¿El Receptor es distinto de la Dirección de la plataforma?
* ¿El Proveedor de servicios también es el Receptor?
* ¿El Aprobador también es el Firmante de liberación?
* ¿Debería separarse algún rol por seguridad?
* ¿El caso de uso requiere un Resolutor de disputas neutral?
* ¿Estás usando liberación única o liberaciones múltiples?
* ¿Hay múltiples receptores?
---
# 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-es/introduccion/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.