For the complete documentation index, see llms.txt. This page is also available as Markdown.

Diseño de escrow

No retenemos tu dinero, retenemos la lógica.

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.

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.

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.


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:


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

No

No

No

no

Actualiza el progreso del hito

Aprobador

No requerido

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

no

Solo libera cuando las condiciones lo permiten

Resolutor de disputas

No requerido

Según el caso

No requerido

Según el caso

No

Arbitra y puede redirigir fondos

Receptor

No por defecto

Normalmente no

No por defecto

No

No

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:

Flujo típico:

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:

Flujo típico:

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

¿Deberían aprobarse todos los hitos antes del pago?

No necesariamente

¿El flujo de trabajo es simple?

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:

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:


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:


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:


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. Asigna Roles

  2. Sigue el ciclo de vida

  3. Integra a través de la API, SDK, o Blocks


Última actualización