Este artículo tiene como objetivo proporcionar a los desarrolladores del ecosistema Pharos una referencia más práctica y profunda para la integración de RWA. Intentamos, desde la lógica empresarial y la arquitectura de gestión de riesgos, abordar los complejos desafíos y las soluciones al integrar activos del mundo real (RWA) en la cadena.
Introducción
El ecosistema Pharos se dedica a ser una infraestructura que conecta los activos financieros tradicionales con el mundo Web3. A diferencia de los activos criptográficos nativos, los activos del mundo real (RWA) combinan derechos de entidades del mundo real con atributos de transacción en cadena. Esta doble naturaleza determina que su perímetro de seguridad no puede limitarse solo al nivel de los contratos inteligentes, sino que debe extenderse a cada grieta de la verificación de derechos de los activos, la sincronización de datos y la supervisión regulatoria.
Basándonos en un análisis profundo de los principales proyectos RWA [1], abordaremos desde tres dimensiones—modelos de arquitectura, zonas centrales de riesgo y estrategias de integración—para trazar el camino clave que los desarrolladores de Pharos deben seguir para construir aplicaciones RWA robustas.
I. ¿Por qué Pharos es adecuado para RWA?
Pharos es una capa 1 (Layer 1) diseñada para una escala a nivel de internet. Para los desarrolladores de RWA, no es necesario profundizar en los detalles del consenso subyacente, solo deben centrarse en resolver dos aspectos centrales: la liquidación de activos y los cálculos complejos.
-
Ejecución en paralelo y confirmación en submilisegundos (Block-STM) El EVM tradicional procesa las transacciones en serie, lo que puede causar congestión durante distribuciones de dividendos o rebalanceos de grandes volúmenes de RWA. Pharos introduce el motor de ejecución en paralelo Block-STM, logrando una finalidad en submilisegundos.
-
Esto significa que la recepción de fondos fuera de la cadena y la liquidación en cadena pueden completarse casi de forma sincronizada, eliminando los riesgos de fluctuación cambiaria y deslizamiento (slippage) asociados al "T+1".
-
Arquitectura Dual-VM (EVM + WASM) Pharos es compatible de forma nativa con dos entornos de ejecución: EVM y WASM.
-
Capa EVM: Se encarga de la conexión. Los protocolos de préstamo y los códigos de DEX existentes escritos en Solidity se pueden desplegar directamente para manejar activos RWA.
-
Capa WASM: Se encarga del cálculo. Los RWA implican lógicas complejas de impuestos sobre intereses, gestión de riesgos por niveles y listas blancas de cumplimiento, que son extremadamente costosas en Gas y poco eficientes si se ejecutan en EVM. Esta lógica intensiva en cálculo puede migrarse a módulos WASM, logrando una gestión de riesgos en cadena de alto rendimiento y bajo coste.
https://docs.pharosnetwork.xyz
II. Las dos lógicas operativas de los RWA
Antes de diseñar un protocolo RWA en Pharos, los desarrolladores deben comprender claramente los dos modelos principales de flujo de activos y sus circuitos de capital:
-
Modo On-chain a Off-chain
Este es el modo más común actualmente, cuya esencia es la recaudación de fondos en cadena y la gestión financiera fuera de cadena. Los inversores bloquean stablecoins (como USDC) en cadena → el equipo del proyecto las consolida y convierte a moneda fiduciaria (USD) → invierte en activos de alta liquidez fuera de cadena (como bonos del Tesoro estadounidense) → los intereses obtenidos regresan a la cadena y se distribuyen a los holders de los tokens.
Ejemplo: $STBT de Matrixdock. Los inversores acreditados acuñan $STBT (anclado 1:1 a bonos del tesoro a corto plazo), los fondos son utilizados por el equipo del proyecto para comprar bonos del estado, y los holders en cadena disfrutan de un rendimiento anualizado de aproximadamente 4.8%.
-
Modo de Activos Tokenizados
Este modo se centra en la titularización y fragmentación de activos específicos. El equipo del proyecto bloquea un activo específico fuera de cadena (como una propiedad) y lo valora → emite tokens ERC-20 que representan las participaciones → los inversores suscriben con stablecoins → el equipo del proyecto se encarga del mantenimiento y operación del activo fuera de cadena → los flujos de caja generados (como alquileres) se distribuyen periódicamente como dividendos en cadena.
Ejemplo: Tokenización de propiedades de RealT. Por ejemplo, una propiedad en Detroit valorada en 65,900 USD se divide en 1300 tokens, los inversores que compran tokens tienen derecho a los dividendos por alquiler de esa propiedad.
III. Mapa de Riesgos y Estrategias de Integración en Pharos
Los riesgos críticos de los RWA a menudo no están en el código, sino en los eslabones que conectan off-chain con on-chain. Los proyectos RWA existentes presentan deficiencias estructurales significativas en verificación de identidad, anclaje de activos y transparencia de datos. Al construir aplicaciones en Pharos, los desarrolladores deben defenderse principalmente de los siguientes riesgos de "rinoceronte gris".
https://dl.acm.org/doi/epdf/10.1145/3689931.3694913
-
Cumplimiento Identitario Transparente
Los proyectos afirman ser compliantes, pero en realidad es pura formalidad. Según estadísticas, menos de la mitad de los proyectos implementan KYC efectivo, e incluso proyectos conocidos (como RealT) han tenido procesos de verificación por video que se podían eludir fácilmente con una simple fotografía. Aunque algunos proyectos enfatizan el AML en sus whitepapers, en la práctica operativa solo requieren conectar una cartera para operar, sin poder rastrear en absoluto el origen de los fondos.
https://dl.acm.org/doi/epdf/10.1145/3689931.3694913
Recomendación de desarrollo para Pharos:
-
No realices comprobaciones de identidad solo en el frontend web. Es imperativo integrar un mecanismo de lista blanca (whitelist) a nivel de contrato inteligente, asegurando que solo las direcciones validadas mediante DID (Identidad Descentralizada) o KYC fuera de cadena puedan invocar las funciones de mint o transfer. Tomando $STBT como ejemplo, reescribir las funciones transfer y transferFrom de ERC-20, de modo que solo las direcciones de la whitelist certificada puedan llamarlas.
https://etherscan.io/address/0x530824da86689c9c17cdc2871ff29b058345b44a#code
-
Para transacciones de activos de alto valor, introducir mecanismos de autenticación de dos factores (2FA) para prevenir el robo de activos debido a la filtración de claves privadas; estudios muestran que actualmente solo una minoría de proyectos implementa esto.
-
Dependencia y Fusible de las Stablecoins
Las stablecoins son la sangre de los RWA, casi el 90% de los proyectos dependen de ellas para la liquidación. Pero los desarrolladores a menudo pasan por alto el riesgo de desanclaje (depeg) de las propias stablecoins, como el desanclaje de USDC debido al evento SVB o los riesgos de desanclaje de USDe, etc. [2]. Si ocurre un desanclaje, ¿el proyecto tiene un fondo de reserva de riesgo específico para manejar la crisis?
https://x.com/ethena_labs/status/1976773136294224071
Recomendación de desarrollo para Pharos:
-
Los oráculos no solo deben usarse para proporcionar precios, sino también como disparadores de control de riesgos. Cuando se detecte que el precio de la stablecoin utilizada para liquidación (p.ej., USDC/USDT) se desvía de su valor anclado por encima de un umbral (p.ej., 5%), el contrato debería pausar automáticamente la acuñación (mint) y el reembolso (redemption), previniendo ataques de arbitraje contra el protocolo.
-
Al diseñar pools de liquidez, considerar la posibilidad de admitir múltiples stablecoins o incluso una cesta de monedas, para reducir el impacto del riesgo sistémico de un solo activo. Al mismo tiempo, en la selección de stablecoins, evitar en la medida de lo posible las stablecoins algorítmicas de mecanismo complejo, ya que son las más propensas a desanclarse.
-
Puenteo de Datos y Verificación de Autenticidad
La mayor caja negra de los RWA radica en si el activo en cadena corresponde realmente a un activo físico fuera de cadena. Muchos proyectos所谓的 divulgación de información (所谓的, suowei - "llamada") consiste simplemente en colgar algunos archivos PDF en una página web, e incluso ha habido casos absurdos de usar grabaciones en bucle haciéndolas pasar por monitorización en tiempo real. Los informes de valor neto de activos (NAV) de OpenEden también han tenido retrasos de hasta un mes.
https://dl.acm.org/doi/epdf/10.1145/3689931.3694913
Recomendación de desarrollo para Pharos:
-
Utilizar redes de oráculos como Chainlink para conectarse directamente a las API de los bancos custodios o firms de auditoría fuera de cadena. Los desarrolladores de Pharos deberían esforzarse por lograr que el valor neto de los activos (NAV) se actualice en cadena cada minuto, en lugar de depender de informes mensuales o trimestrales del equipo del proyecto.
-
El riesgo de desviación en la valoración de los proyectos ocurre con frecuencia. Durante el desarrollo, se debe introducir la alimentación de precios (feed) de oráculos de múltiples fuentes, buscando que el precio en cadena refleje lo más fielmente posible el mercado fuera de cadena.
-
Aislamiento y Transparencia de la Entidad Legal
El incumplimiento (default) de activos fuera de cadena es un riesgo ineludible para los RWA, por ejemplo, Goldfinch experimentó un incumplimiento crediticio de 5.9 millones de USD [4]. La clave para aislar el riesgo reside en el SPV (Vehículo de Propósito Especial), pero solo una minoría de proyectos declara públicamente utilizar una estructura SPV, y la mayoría no divulga los nombres específicos de las entidades registradas. Tomando la crisis de Goldfinch como ejemplo, causó directamente una caída del 20% en el token $GFI, perjudicando gravemente a inversores que no entendían lo que ocurría.
Recomendación de desarrollo para Pharos:
-
En los metadatos del proyecto o en la documentación, es obligatorio divulgar el nombre legal y la jurisdicción de registro del SPV que posee los activos.
-
Asegurar que cada pool de activos corresponda a un SPV independiente. En el diseño de contratos de Pharos, los fondos de diferentes pools de activos deben estar completamente aislados lógicamente, evitando que el incumplimiento de un solo activo agote la liquidez de todo el protocolo.
-
Agotamiento de Liquidez tras la Falsa Prosperidad
La liquidez es el aspecto más fácil de falsificar pero también el más propenso a colapsar en los proyectos RWA [2]. La profundidad inicial del mercado de muchos proyectos RWA depende en gran medida de los acuerdos con market makers (creadores de mercado). Una vez que expiran los acuerdos de market making o se detienen los subsidios, la profundidad del mercado secundario a menudo sufre una caída en picado, desapareciendo las órdenes de compra instantáneamente. Además, existe una inherente desincronización temporal entre la baja frecuencia de valoración de activos fuera de cadena (generalmente NAV mensual o trimestral) y la alta frecuencia de las transacciones en cadena (bloques por segundos). Cuando ocurren grandes ventas en cadena, los pools AMM a menudo no pueden recomponerse rápidamente por falta de una guía de valor justo en tiempo real, lo que lleva a que el precio se desvíe severamente del valor neto, formando un agujero negro de liquidez. Como se muestra en el gráfico de $USDR, debido a una corrida (bank run), el precio del token cayó rápidamente de 1 dólar a 0.5 dólares en unas pocas horas [5].
https://www.blocktempo.com/not-so-tangible-usdr-stablecoin-collapses/
Recomendación de desarrollo para Pharos:
-
No apuestes toda la liquidez únicamente en el mercado secundario de DEX o CEX. Los desarrolladores pueden integrar en el contrato una funcionalidad integrada de cola de recompra/reembolso. Cuando el precio del mercado secundario esté significativamente por debajo del NAV (por ejemplo, con un descuento superior al 3%), permitir que los holders omitan el mercado secundario y soliciten directamente al protocolo el reembolso contra los activos subyacentes del SPV, gestionando la cola de reembolsos y la distribución de fondos mediante un contrato inteligente.
-
Imitar el sistema de reserva fraccionaria de los bancos tradicionales, reteniendo obligatoriamente en el环节 de acuñación (Mint) un porcentaje (p.ej., 5%-10%) de stablecoins como pool de amortiguación de liquidez en cadena. Estos fondos no se utilizan para comprar activos fuera de cadena, sino que se destinan específicamente a ejecutar recompras instantáneas automáticamente a través del contrato inteligente cuando la liquidez del mercado secundario se agota, defendiendo así el límite inferior del precio.
-
Riesgo Heredado de Vulnerabilidades Nativas de EVM
Pharos logra una compatibilidad completa con EVM, lo que significa que los desarrolladores, al disfrutar de la conveniencia del ecosistema Solidity, también heredan por completo sus vectores de ataque clásicos. Los contratos RWA, debido a las necesidades de cumplimiento, suelen contener muchas funciones de alto privilegio (como blacklist, forceTransfer, pause), lo que convierte la gestión de permisos y las actualizaciones por proxy en puntos débiles mortales más sensibles que en los protocolos DeFi.
https://owasp.org/www-project-smart-contract-top-10/
Recomendación de desarrollo para Pharos:
-
Adherirse estrictamente a librerías estándar: No reinventes la rueda. El control de acceso debe utilizar obligatoriamente AccessControl u Ownable2Step de OpenZeppelin. Si la clave privada del administrador de un RWA es robada debido a un漏洞 (vulnerabilidad) en una lógica personalizada, significa que la propiedad del activo físico fuera de cadena podría verse envuelta en una disputa legal.
-
Gestión de riesgos en actualizaciones por proxy: Los contratos RWA suelen ser en su mayoría actualizables (modo UUPS/Transparent). Al desplegar actualizaciones, se debe verificar estrictamente el conflicto de ranuras de almacenamiento (Storage Slot), para prevenir la corrupción de la tabla de mapeo de activos (Mapping) debido a la sobrescritura de variables.
-
Defensa contra ataques de reentrada: Al manejar la lógica de distribución de dividendos (Distribute Yield) o reembolso, incluso para usuarios de la whitelist, se debe agregar ReentrancyGuard en todas las llamadas externas (Call), para prevenir que contratos maliciosos utilicen funciones de callback para vaciar el pool de fondos.
IV. Resumen
Repasando el desarrollo del sector RWA, hemos visto demasiada falsa prosperidad basada en interfaces de usuario que empaquetan el cumplimiento y en market making que sostiene la liquidez. En el ecosistema Pharos, abogamos por un paradigma de desarrollo más resistente.
Como desarrolladores, es necesario reconocer claramente: Los riesgos de seguridad de los RWA no solo existen en el nivel de implementación del código de los contratos inteligentes, sino que también deben tomarse en serio problemas de seguridad como la invalidación de los derechos de los activos fuera de cadena y el desajuste de liquidez. La finalidad en submilisegundos de Pharos nos da la confianza para manejar operaciones financieras complejas, pero esto exige que los desarrolladores sean más rigurosos en sus estrategias de integración, incorporando KYC/AML en la lógica subyacente, haciendo que el sistema de fondos de reserva de riesgo se ejecute coercitivamente por código, y llevando la transparencia de los datos de activos al extremo.
La futura competencia entre protocolos RWA ya no será un juego de números de TVL, sino una contienda sobre la autenticidad de los activos y la robustez del sistema. Completar este último kilómetro de闭环 de seguridad (bucle cerrado de seguridad) es una lección obligatoria para todos los constructores del ecosistema Pharos.
