proteus

FIDUS Escrow y su “Puente Oracle”:

El objetivo del modulo FIDUS Escrow consiste en la gestión segura y automatizada de pagos de los entregables D_ij de un Proyecto determinado, según las condiciones pre-establecidas en el Smart Contract respectivo [sctId]. Aunque se centre en la función financiera de pago del Smart Contract (en nuestro caso 1000010-D3.3), incorpora la colaboración de los “oráculos humanos”, como revisores de calidad del Sistema de Gestión de Calidad IASAP-qm y validadores a través del la interfaz PROTEUS-UI (TV, MV, AV)). En su fase de prototipo funcional, el módulo está diseñado para validar la gestión segura de una transacción de custodia de pago simple en la red de pruebas de Stellar (https://developers.stellar.org/).

El Rol del Validador Administrativo (AV)

En el caso de la versión de demostración de FIDUS Escrow (V0.0.7), es fundamental la actuación del Validador Administrativo (AV) para configurar el Smart Contract definitivo: Actúa como el custodio y supervisor final antes de que el contrato inteligente se active plenamente en la red Stellar XLM. Esto incluye la configuración correcta de las firmas de los validadores (TV, MV, AV, NO, CO) que participarán en el proceso de liberación de fondos, los umbrales para la liberación de fondos (ej. 3 de 5 firmas), además de los detalles de los Estados de Pago (EdP), montos y fechas límite para cada tramo del pago (REV A, REV B, Pago C). La interfaz PROTEUS UI registra y refleja cada uno de estos pasos, los cuales también están siendo actualizados automáticamente en la plantilla FIDUS_Smart_Contract_Data de IASAP-qm (específicamente en la Sección J de la pestaña del contrato, ej. E_1000010-D3.3). Solo cuando el contrato está correctamente configurado (lo que puede ser confirmado por todos las partes a través de la clavepública en el dashboard), se traspasan los fondos.

El Rol de los demás Validadores (TV, MV, NO, CO):

Cada uno de los demás validadores (“oráculos humanos”) cumple un doble rol, en primer lugar en el control de calidad (IASAP-qm) como revisor de los entregables D^_ij y, segundo al cumplirse un hito del contrato, en la firma de los estados de pago del Smart Contract respectivo (REV A, REV B y C).

Para resolver posibles desacuerdos entre las partes, el contrato considera un mecanismo de arbitraje, a través de una intervención del Administrador (AV), de un cuarto o quinto firmante “override” (NO, CO), quienes pueden liberar los pagos del Proveedor o devolver los fondos a su Cliente.

PASO 3: VALIDACIÓN ADMINISTRATIVA Y CONFIGURACIÓN DEL CONTRATO INTELIGENTE (HSC)

Este paso se inicia después de que la plantilla del Smart Contract [sctId] (ej. E_1000010-D3.3) ha sido firmada por el Proveedor Pj, el Validador Gerencial (MV) y Administrativo (AV).

3.1 Creación de la “Cuenta Escrow”:

• El Administrador del fondo escrow configura una cuenta en el Stellar Testnet (https://lab.stellar.org/), a través de la Función “Generate Keypairs”, la cual entrega una clave pública (“public key”) y una clave privada (“secret key”):

• Por el momento, solo el Administrador de los fondos escrow maneja las llaves de la cuenta, la cual no recibirá fondos hasta que no se hayan configurado la multifirma, plazo y/o demás condiciones del Smart Contract.
• Cada uno de los validadores de la red profesional cuenta con un par de llaves (keypair), una clave pública y una privada.

NOTA: Las llaves secretas NUNCA se comparten, aun así hemos vulnerado este principio para efectos del presente prototipo, el uso exclusivo dentro de nuestra red privada de co-desarrollo y de tokens de Stellar Testnet (sin fondos reales).

3.2 Configuración de la Multifirma de la Cuenta

• Con su clave privada del depósito “escrow” (hasta ese momento la única), el Administrador AV configura las condiciones de multi-firma de la cuenta, estableciendo para cada caso la clave pública del firmante y el peso de la firma respectiva:
  • Firma del Validador Técnico (TV)
  • Firma del Validador Gerencial (MV)
  • Firma del Validador Administrativo (AV)
  • Neutral Override (NO)
  • Collective Override (CO)
  • Cada firma se puede ponderar con un peso entre 0 y 1
• Al final configura el umbral para la liberación de los fondos, por ej. 3 (de 4 o 5).
• La clave pública (“public key”) permite a toda las partes del Smart Contract verificar la creación del fondo escrow (por ej. en stellar.expert), incluyendo el monto comprometido (en UN XLM), las condiciones multifirma para su liberación y el plazo de devolución, en el caso de incumplimiento del contrato.

3.3 Depósito de Fondos en la Cuenta Escrow (Acción Externa, Verificación por AV):

• El Administrador AV revisa que todos los parámetros del contrato (validadores, porcentajes de pago, etc., tomados de la plantilla de FIDUS_Smart_Contract_Data (IASAP-qm) sean correctos antes del financiamiento de la cuenta escrow en Stellar Testnet).
• Para el seguimiento del Cliente final, Subcontratante y su Validador Gerencial, PROTEUS-UI ofrece un resumen de estos parámetros.
• Accede al prototipo FIDUS (proteus.exchange/fidus/prototype/).
• En el Dashboard selecciona el rol “AV (Administrative Validator)” en el selector “Act as Role”; abre la pestáña “Admin Tools”.
• Ubica el contrato 1000010-D3.3. Debería haber una acción disponible como “Confirmar Fondeo” o “Registrar Depósito”.

Una vez verificado, se transfieren los fondos totales del contrato (ej. 100 UN de Stablecoin USDC o EURC) desde la cuenta del Financiador (Funder Account Public Key especificada en la Hoja de Contrato, celda G28) a la cuenta Escrow del contrato (Escrow Account Public Key, celda G29) en la Stellar Testnet.

En el caso de nuestro prototipo FIDUS Escrow, el Administrador y las Partes pueden verificar que la transacción se haya completado exitosamente en la Stellar Testnet con la ID de la cuenta escrow o el ID de la transacción, por ej. a través de un explorador de bloques de Stellar (el detalle del contrato proporciona un link de acceso): Haz clic en esta opción. Es posible que la interfaz te pida ingresar el ID de la transacción de fondeo de Stellar para referencia.

Resultado de esta Etapa y Próximos Pasos:

El sistema actualiza la hoja de cálculo E_1000010-D3.3:

• El estado funding_overall_status (celda H82) cambia a “Funded” o similar.
• Se registra el timestamp de esta confirmación en la celda J82.
• Se registra el TxID de la transacción de fondeo en la celda L82.
• Se envía una notificación por email a las partes relevantes informando que el contrato ha sido fondeado.

El Smart Contract se encuentra configurado y ejecutable; internamente el Jefe de Proyecto queda a cargo de las actividades de gestión de proyecto y control de calidad, como ahora: Para efectos del Sistema de Gestión de Calidad (SGC) registra las entregas, revisiones y la aprobación de cada hito del proyecto (REV A, REV B y C).