Roles en Trustless Work
¡Entendamos qué representa cada rol!
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?
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
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:
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
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
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:
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
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:
Pero en otros casos, pueden ser diferentes.
Ejemplo:
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
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:
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
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:
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.
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
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:
Si algo sale mal:
Mapeo de roles por caso de uso
Pago en Marketplace
Caso de uso: escrow de liberación única
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
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
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
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
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?
Última actualización