# Diseño de escrow Trustless Work escrows son primitivas de confianza programables. Permiten que plataformas, marketplaces, aplicaciones y organizaciones definan cómo deben retenerse, actualizarse, aprobarse y liberarse los fondos entre distintas partes.\ \ Un escrow no es solo un lugar donde se guardan los fondos. Es una capa de coordinación entre: * partes * fondos * roles * hitos * actualizaciones de estado * aprobaciones * condiciones de liberación * tarifas de la plataforma * flujos de disputa o excepción Antes de crear un escrow, la pregunta más importante es: > ¿Quién debe hacer qué antes de que el dinero pueda moverse? Si puedes responder eso con claridad, puedes diseñar un buen escrow. *** ### El modelo mental de diseño de escrow Antes de elegir un tipo de escrow o llamar a la API, mapea la transacción. Empieza con cuatro preguntas: 1. **¿Quiénes son las partes involucradas?** 2. **¿Hacia dónde se mueven los fondos?** 3. **¿Quién tiene permiso para actualizar, aprobar y liberar?** 4. **¿Qué condiciones deben cumplirse antes de que se liberen los fondos?** Esta es la base del diseño de escrow. Trustless Work te proporciona la infraestructura para convertir esa lógica en un escrow inteligente. *** ### Paso 1: Mapear las partes Cada escrow involucra partes. Algunas partes financian el escrow.\ Algunas realizan el trabajo.\ Algunas actualizan el estado.\ Algunas aprueban la finalización.\ Algunas resuelven disputas.\ Algunas liberan fondos.\ Algunas reciben fondos.\ Algunas reciben las tarifas de la plataforma. Los roles comunes incluyen: | Parte | Qué representan | | ----------------------------------------- | --------------------------------------------------------------------------------------------- | | Receptor | La parte que recibe los fondos después de la liberación | | Proveedor de servicios / Marcador de hito | La parte que actualiza el progreso o marca el trabajo como completado | | Aprobador | La parte que valida si se ha cumplido un hito o condición | | Firmante de liberación | La parte que firma o activa la liberación de fondos | | Dirección de la plataforma | Puede hacer cambios antes de que el escrow sea financiado y recibe la tarifa de la plataforma | | Resolutor de disputas | Arbitra disputas y puede redirigir fondos cuando se presenta una disputa | Los roles se asignan a direcciones. Solo la dirección asignada a un rol puede realizar las acciones permitidas para ese rol. La misma persona, organización o billetera del mundo real a veces puede tener varios roles, pero las combinaciones de roles deben ser intencionales. Por ejemplo, un freelancer puede ser tanto el **Receptor** como el **Proveedor de servicios**, pero normalmente no debería ser también el **Aprobador** de su propio trabajo. *** ### Paso 2: Mapear la dirección de los fondos Después, mapea cómo deben moverse los fondos. La dirección de los fondos debe responder: > ¿Quién financia el escrow y quién debe recibir los fondos después de que se cumplan las condiciones correctas? ### Patrón 1: Pago de marketplace Caso de uso: **escrow de liberación única** Un comprador contrata o compra a un vendedor, freelancer o proveedor de servicios. El comprador financia el escrow. El proveedor de servicios entrega el trabajo o producto. El aprobador valida la finalización. Luego los fondos se liberan una sola vez. ```txt Comprador / Cliente → financia el escrow → Vendedor / Proveedor de servicios recibe un pago final único ``` ### Patrón 2: Hitos de proyecto Caso de uso: **escrow de múltiples liberaciones, mismo receptor** Un cliente financia un proyecto que tiene varios hitos. El mismo proveedor de servicios recibe pagos progresivamente a medida que cada hito se completa y aprueba. ``` Cliente → financia el escrow → pago del hito 1 al mismo receptor → pago del hito 2 al mismo receptor → pago del hito 3 al mismo receptor ``` ### Patrón 3: Pagos Caso de uso: **escrow de múltiples liberaciones, múltiples receptores** Un patrocinador, plataforma u organización financia un escrow que necesita pagar a diferentes personas o entidades a lo largo de distintos hitos. ``` Patrocinador / Plataforma → financia el escrow → pago del hito 1 al Receptor A → pago del hito 2 al Receptor B → pago del hito 3 al Receptor C ``` *** ### Paso 3: Separar estado, aprobación y liberación Un error común es tratar las actualizaciones de estado, las aprobaciones y las liberaciones de fondos como si fueran lo mismo. En Trustless Work, deben entenderse por separado: | Concepto | Significado | | ---------- | ---------------------------------------------- | | Estado | Comunicación sobre el progreso | | Aprobación | Validación de que se ha cumplido una condición | | Liberación | Ejecución del pago | #### Estado = Comunicación Una actualización de estado les dice a las otras partes lo que está ocurriendo. Ejemplos: * trabajo iniciado * documentación enviada * envío en tránsito * entrega completada * hito listo para revisión * evidencia cargada El Proveedor de servicios o el Marcador de hito normalmente actualiza el estado del hito. Las actualizaciones de estado pueden ocurrir muchas veces antes de que un hito alcance su estado final esperado. #### Aprobación = Validación Aprobación significa que una parte autorizada ha validado que se cumplió la condición acordada. Por ejemplo: * el cliente aprueba el trabajo * el revisor de la subvención aprueba el entregable * el comprador confirma que el envío llegó * la plataforma aprueba la evidencia enviada El Aprobador no simplemente informa el progreso. El Aprobador valida la finalización. #### Liberación = Ejecución La liberación es cuando los fondos realmente salen del escrow. El Firmante de liberación solo puede liberar fondos después de que se hayan cumplido las condiciones de aprobación requeridas. Esto crea una cadena lógica clara: ``` Actualización de estado / evidencia → Aprobación → Liberación ``` *** ### Caso límite importante: la aprobación puede ocurrir antes de la actualización de estado En algunos flujos, un Aprobador puede aprobar un hito antes de que el Proveedor de servicios actualice el estado del hito. Esto significa que el diseño de tu escrow no debe asumir que el estado siempre viene antes de la aprobación. En su lugar, trata el estado y la aprobación como piezas de estado relacionadas pero separadas. La condición de liberación debe depender de la lógica de aprobación requerida, no solo de un estado de texto. *** ### Paso 4: Asignar roles Cada escrow de Trustless Work incluye una configuración de roles. Los roles determinan qué dirección puede realizar qué acción. Los roles principales actuales incluyen: | Rol | Responsabilidad principal | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Proveedor de servicios | Actualiza el estado y el progreso del hito | | Aprobador | Valida la finalización del hito | | Dirección de la plataforma | Puede recibir tarifas de la plataforma y puede gestionar la configuración antes del financiamiento, según la implementación | | Firmante de liberación | Ejecuta la liberación de fondos después de que se cumplan las condiciones de aprobación | | Resolutor de disputas | Gestiona disputas o flujos de excepción cuando se señalan | | Receptor | Recibe los fondos liberados | | Emisor | Quien despliega el contrato. No tiene poderes sobre el contrato | | Depositante | Financia el escrow pero no recibe automáticamente permisos del contrato | | Observador | Llegará en una versión futura; sigue escrows sin actuar sobre ellos | Los roles se asignan a direcciones. Solo la dirección asignada a un rol puede realizar las acciones permitidas para ese rol. *** ### Resumen de capacidades de los roles | Rol | ¿Puede actualizar el estado? | ¿Puede aprobar? | ¿Puede presentar una disputa? | ¿Puede resolver disputas? | ¿Puede liberar fondos? | ¿Recibe fondos? | Notas | | -------------------------- | ---------------------------: | --------------: | ----------------------------: | ------------------------: | ---------------------: | ------------------: | --------------------------------------------------------- | | Proveedor de servicios | Sí | No | Sí | No | No | no | Actualiza el progreso del hito | | Aprobador | No requerido | Sí | Sí | No | No | no | Valida la finalización del hito | | Dirección de la plataforma | Antes del financiamiento | No por defecto | No por defecto | No por defecto | No por defecto | Receptor de tarifas | Puede hacer cambios antes de que el escrow sea financiado | | Firmante de liberación | No requerido | No requerido | No | No | Sí | no | Solo libera cuando las condiciones lo permiten | | Resolutor de disputas | No requerido | Según el caso | No requerido | Sí | Según el caso | No | Arbitra y puede redirigir fondos | | Receptor | No por defecto | Normalmente no | No por defecto | No | No | Sí | Destino final de los fondos liberados | | Emisor | No | No | No | No | No | No | No tiene poderes sobre el contrato | | Depositante | No | No | No | No | No | No | Las transacciones entrantes se indexan | | Observador | No | No | No | No | No | No | Rol futuro de seguimiento | *** ### Paso 5: Definir las propiedades del escrow Los roles son solo una parte del diseño del escrow. Un escrow también incluye propiedades que describen qué es el escrow, cómo debe indexarse, qué activo se usa y en qué estado se encuentra. Las propiedades comunes del escrow incluyen: | Propiedad | Descripción | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | ID del escrow / Dirección del contrato | Identificador en cadena del contrato de escrow. También se usa como dirección de depósito | | ID de compromiso | Identificador externo configurable usado para conectar el escrow con una factura, pedido, proyecto o sistema externo | | Título | Título legible por humanos del escrow | | Descripción | Explicación de por qué existe el escrow | | Roles | Direcciones asignadas a permisos como actualizaciones de estado, aprobaciones, liberaciones, resolución de disputas y recepción de tarifas | | Hitos | Acciones, entregables o condiciones que deben completarse | | Monto | Monto total bloqueado o esperado en el escrow | | Tarifa de la plataforma | Tarifa opcional configurable para la plataforma o aplicación | | Trustline / Activo | El activo usado en el escrow, como USDC u otro token emitido en Stellar | | Indicadores | Indicadores de estado como en disputa, liberado o resuelto | Estas propiedades ayudan a las plataformas a conectar el escrow en cadena con flujos de trabajo del mundo real. *** ### Paso 6: Elegir tu tipo de escrow Trustless Work actualmente admite dos tipos principales de escrow: 1. **escrow de liberación única** 2. **escrow de múltiples liberaciones** Ambos usan la misma idea central: los fondos se retienen hasta que se cumplen las condiciones definidas. La diferencia es cómo se liberan los fondos. *** ### escrow de liberación única Un escrow de liberación única libera los fondos una sola vez. Puede contener varios hitos, pero todos los hitos requeridos deben aprobarse antes de que ocurra la liberación final. Estructura típica: ``` Pagador → escrow → Receptor ``` Flujo típico: ``` Crear escrow Financiar escrow Actualizar hito 1 Aprobar hito 1 Actualizar hito 2 Aprobar hito 2 Liberar el monto completo Cerrar escrow ``` Ideal para: * depósitos * trabajos puntuales * entregas simples * finalización completa del proyecto * compras en marketplace * entrega final antes del pago Características clave: | Dimensión | escrow de liberación única | | -------------------- | ----------------------------------------------------------------- | | Patrón de liberación | Un pago final único | | Hitos | Puede tener varios hitos | | Receptor | Normalmente un solo receptor | | Lógica de aprobación | Todos los hitos requeridos deben aprobarse antes de la liberación | | Complejidad | Menor | *** ### escrow de múltiples liberaciones Un escrow de múltiples liberaciones libera fondos progresivamente. Cada hito puede tener su propio pago, y cada pago puede ir potencialmente a un receptor diferente. Estructura típica: ``` Pagador → escrow → Receptor del hito 1 → Receptor del hito 2 → Receptor del hito 3 ``` Flujo típico: ``` Crear escrow Financiar escrow Actualizar hito 1 Aprobar hito 1 Liberar fondos del hito 1 Actualizar hito 2 Aprobar hito 2 Liberar fondos del hito 2 Cerrar escrow ``` Ideal para: * subvenciones * recompensas * financiamiento basado en hitos * proyectos por fases * pagos a colaboradores * proyectos con múltiples proveedores * acuerdos de servicio de larga duración Características clave: | Dimensión | escrow de múltiples liberaciones | | -------------------- | ------------------------------------------ | | Patrón de liberación | Pagos múltiples | | Hitos | Cada hito puede tener su propia liberación | | Receptor | Puede admitir múltiples receptores | | Lógica de aprobación | Cada hito puede aprobarse por separado | | Complejidad | Mayor | *** ### Liberación única vs múltiples liberaciones | Pregunta | Usar liberación única | Usar múltiples liberaciones | | ---------------------------------------------------------------------------- | --------------------- | --------------------------- | | ¿Los fondos se liberan una vez o progresivamente? | Una vez | Progresivamente | | ¿Hay múltiples receptores? | Normalmente no | A menudo sí | | ¿Cada hito necesita su propio pago? | No | Sí | | ¿Deberían aprobarse todos los hitos antes del pago? | Sí | No necesariamente | | ¿El flujo de trabajo es simple? | Sí | Más complejo | | ¿El flujo de trabajo es similar a una subvención, una recompensa o una fase? | A veces | Normalmente | *** ### Paso 7: Entender el ciclo de vida El ciclo de vida del escrow describe cómo un escrow pasa de la configuración a la finalización. Ciclo de vida canónico: ``` Diseño → Inicio → Financiamiento → Actualizaciones de hitos → Aprobación → Liberación → Cierre ``` #### 1. Diseño Mapea las partes, la dirección de los fondos, los roles, los hitos, las condiciones de liberación y el tipo de escrow. #### 2. Inicio Crea y configura el escrow. Esto incluye: * roles * hitos * monto * activo * receptor * tarifa de la plataforma * ID de compromiso * metadatos #### 3. Financiamiento El pagador deposita fondos en el escrow. Los posibles estados de financiamiento incluyen: * sin financiar * financiado parcialmente * financiado completamente #### 4. Actualizaciones de hitos El Proveedor de servicios o el Marcador de hito actualiza el estado del hito. Esto crea visibilidad sobre el progreso. #### 5. Aprobación El Aprobador valida si se cumplió la condición del hito. La aprobación es el paso clave de validación antes de la liberación. #### 6. Liberación El Firmante de liberación ejecuta la liberación de fondos después de que se cumplan las condiciones de aprobación. En un escrow de liberación única, esto normalmente ocurre una sola vez. En un escrow de múltiples liberaciones, esto puede ocurrir hito por hito. #### 7. Cierre El escrow alcanza un estado terminal. Los posibles estados terminales incluyen: * completado * cancelado * reembolsado * en disputa * resuelto *** ### Lista de verificación de diseño Antes de crear un escrow, responde estas preguntas: * ¿Quién financia el escrow? * ¿Quién recibe los fondos? * ¿Hay un receptor o varios receptores? * ¿Quién actualiza el estado del hito? * ¿Quién aprueba la finalización del hito? * ¿Quién firma la liberación? * ¿El pago se libera una vez o por hito? * ¿Qué activo se usa? * ¿Qué tarifa de plataforma aplica? * ¿Con qué sistema externo debería conectarse este escrow? * ¿Qué sucede si un hito no se aprueba? * ¿Qué sucede si se asigna un rol a la parte equivocada? * ¿Este caso de uso requiere resolución de disputas? *** ### Ejemplo: Pago por servicio en marketplace Un cliente quiere pagar a un freelancer después de que se complete un proyecto. Diseño sugerido: | Elemento | Ejemplo | | -------------------------- | -------------------------------------------------------------- | | Pagador | Cliente | | Receptor | Freelancer | | Proveedor de servicios | Freelancer | | Aprobador | Cliente | | Firmante de liberación | Cliente o firmante controlado por la plataforma | | Dirección de la plataforma | Dirección de tarifa del marketplace | | Tipo de escrow | Liberación única o múltiple, según la complejidad del proyecto | Versión simple: ``` El cliente financia el escrow El freelancer completa el trabajo El freelancer marca el hito como completado El cliente aprueba El firmante de liberación libera los fondos al freelancer El marketplace recibe la tarifa ``` *** ### Ejemplo: Pago de tramo de subvención Una fundación quiere liberar fondos progresivamente después de que se completen los entregables. Diseño sugerido: | Elemento | Ejemplo | | -------------------------- | ------------------------------------------------ | | Pagador | Fundación o patrocinador | | Receptor | Beneficiario de la subvención | | Proveedor de servicios | Beneficiario de la subvención | | Aprobador | Revisor de la subvención o comité | | Firmante de liberación | Firmante de la fundación o firmante del programa | | Dirección de la plataforma | Dirección de tarifa del programa | | Tipo de escrow | Múltiples liberaciones | Versión simple: ``` La fundación financia el escrow El beneficiario presenta el entregable 1 El revisor aprueba el entregable 1 El firmante de liberación libera el tramo 1 El beneficiario presenta el entregable 2 El revisor aprueba el entregable 2 El firmante de liberación libera el tramo 2 ``` *** ### Ejemplo: Depósito de seguridad Un inquilino deposita fondos que deben retenerse hasta que se complete la condición del alquiler. Diseño sugerido: | Elemento | Ejemplo | | -------------------------- | ----------------------------------------------------------------------- | | Pagador | Inquilino | | Receptor | Inquilino, propietario o ambos, según el resultado | | Proveedor de servicios | Administrador de la propiedad o plataforma | | Aprobador | Administrador de la propiedad, propietario, inquilino o revisor neutral | | Firmante de liberación | Firmante controlado por la plataforma o firmante acordado | | Dirección de la plataforma | Dirección de tarifa del depósito | | Tipo de escrow | Liberación única o flujo condicional | Versión simple: ``` El inquilino financia el escrow El depósito permanece bloqueado La condición se revisa El aprobador valida el resultado El firmante de liberación libera los fondos según el resultado ``` *** ### Cómo pensar en Trustless Work Trustless Work no es solo una aplicación de escrow. Es infraestructura para la coordinación programable de transacciones. Úsalo cuando tu producto necesite responder: > ¿Qué debe pasar antes de que los fondos se muevan? Si la respuesta implica múltiples partes, hitos, aprobaciones o condiciones de liberación, Trustless Work puede ayudarte a codificar esa lógica en un escrow inteligente. *** ### Siguientes pasos Ahora que entiendes el modelo de diseño de escrow: 1. Define [Propiedades del escrow](/trustless-work/v1-es/introduccion/technology-overview/what-does-a-smart-escrow-look-like.md) 2. Elige tu[ Tipo de escrow](/trustless-work/v1-es/introduccion/technology-overview/tipos-de-escrow.md) 3. Asigna [Roles](/trustless-work/v1-es/introduccion/technology-overview/roles-in-trustless-work.md) 4. Sigue el [ciclo de vida](/trustless-work/v1-es/introduccion/technology-overview/escrow-lifecycle.md) 5. Integra a través de la [API](/trustless-work/v1-es/api-rest/introduction.md), [SDK](/trustless-work/v1-es/escrow-react-sdk/introduccion.md), o [Blocks](/trustless-work/v1-es/escrow-blocks-sdk/introduccion.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-es/introduccion/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.