rCOP — Libro blanco técnico (Fase 1)

Representative Colombian Peso. Stablecoin sintética del peso colombiano, colateralizada en USDC sobre Celo.

Este documento describe un prototipo experimental construido para una tesis de maestría en Derecho y Economía. No es una oferta, no es asesoría financiera ni jurídica y no promete rendimiento alguno. Antes de usar la dApp, lea los cinco disclaimers de la sección 7: son el texto que rige y es idéntico en el contrato, en la aplicación y en este documento.

#Resumen

rCOP es un token ERC-20 que busca representar el valor de un peso colombiano (COP). Quien deposita USDC recibe rCOP al precio COP/USD vigente, y quien entrega rCOP recibe USDC al mismo precio, menos una comisión pequeña. No hay préstamos, liquidaciones ni deuda: el contrato funciona como una casa de cambio automática, un diseño que en finanzas descentralizadas se llama transmuter. Es una versión mínima del Transmuter de Angle Protocol, con un único colateral (USDC).

El precio COP/USD lo publica en la cadena, cada cinco minutos, un bot que combina la Tasa Representativa del Mercado (TRM) certificada por la Superintendencia Financiera (60 %), una tasa de cambio de mercado (25 %) y el mercado P2P de Binance (15 %). El contrato valida ese precio con límites absolutos, un tope de desviación frente al promedio de las últimas publicaciones y una ventana de frescura de diez minutos.

El diseño prioriza la transparencia y los límites explícitos sobre la escala. El supply total está limitado a 8.000.000 rCOP y cada dirección puede acuñar hasta 800.000 rCOP. Los fees de redención suben cuando las reservas no alcanzan, y el sistema se pausa solo si la cobertura cae por debajo del 75 %. Este documento también expone, con números reproducibles, las limitaciones conocidas del diseño. La más importante es estructural: las reservas están en dólares y el pasivo en pesos, de modo que una apreciación del peso reduce la cobertura sin que nadie haga nada.

#1. Introducción y contexto

#1.1 El problema

Las stablecoins dominantes están denominadas en dólares. Para un usuario colombiano, usar una de ellas implica asumir el riesgo cambiario del dólar frente al peso. Existen iniciativas de stablecoins en pesos, pero el diseño, las reservas y la gobernanza de muchas de ellas no se pueden verificar desde fuera. rCOP explora la alternativa opuesta: un mecanismo mínimo, con parámetros cerrados y código verificable, cuyo comportamiento en situaciones adversas se pueda estudiar y reproducir.

#1.2 Qué es rCOP y qué no es

rCOP es una stablecoin sintética mono-colateral: su valor en pesos se sostiene con reservas en USDC y un oráculo de tipo de cambio, no con depósitos en pesos. En el vocabulario del proyecto es una stablecoin de Categoría 3 (colateral cripto con oráculo FX).

Emisor. El emisor y creador de rCOP es Grupo New Way SAS, sociedad comercial constituida bajo las leyes de la República de Colombia, identificada con NIT 901.855.061-7.

rCOP no es moneda de curso legal, no está respaldada por depósitos en pesos, no está garantizada por ninguna entidad pública, no paga rendimiento y no se ofrece al público general. La sección 7 recoge estas limitaciones en su texto vinculante.

#1.3 Relación con la tesis

rCOP es el caso aplicado de una tesis de maestría en Derecho y Economía. Cada decisión técnica (topes, fees, gobernanza, disclaimers, elección del colateral) se tomó para poder discutirla desde el punto de vista jurídico y económico, y está registrada como una decisión de arquitectura (ADR) en el repositorio del proyecto. El análisis jurídico corresponde a la tesis: este documento describe el sistema y no califica jurídicamente la actividad.

#1.4 Fases

#2. Arquitectura del sistema

El sistema tiene tres contratos, escritos en Solidity 0.8.24 sobre OpenZeppelin 5.0.2, y un conjunto de componentes fuera de la cadena que publican el precio y vigilan la operación.

#2.1 Token RCop

• ERC-20 con name = "Representative Colombian Peso", symbol = "rCOP" y 18 decimales.
• Incluye permit (EIP-2612), pausa de transferencias y control de acceso por roles.
• No es actualizable. Solo el Engine tiene MINTER_ROLE (invariante I6). La cuenta administradora podría conceder ese rol a otra dirección: es uno de los poderes que describe la sección 5.2.

#2.2 RCopEngine

Es el núcleo económico: recibe USDC, acuña rCOP, quema rCOP y devuelve USDC. Lleva la contabilidad de las reservas, calcula el Reserve Ratio (RR), aplica los fees escalonados y hace cumplir los topes y la auto-pausa.

• Es actualizable con el patrón UUPS (ERC-1822/ERC-1967). La versión desplegada es la v2, que lee el precio publicado por el bot.
• Guarda su estado en almacenamiento con espacio de nombres (ERC-7201), para que una actualización no pueda pisar variables existentes.
• Protege mint y burn contra reentrancia y sigue el patrón checks-effects-interactions.

#2.3 RCopOracleWrapper

Recibe el precio COP/USD del bot (pushPrice), lo valida y lo guarda. El Engine lo consulta con getLastPrice(). El contrato no es actualizable, pero el Engine puede reemplazarlo por otro mediante gobernanza (setOracleFor). Así se instalaría la propuesta de oráculo v3 descrita en la sección 4.6.

#2.4 Componentes fuera de la cadena

#2.5 Direcciones desplegadas (Celo Sepolia)

Las transacciones se pueden consultar en el explorador sepolia.celoscan.io. La verificación pública del código fuente en el explorador está pendiente (ADR-032).

#3. Mecanismo de paridad (transmuter)

La paridad es contractual frente al oráculo: el Engine acuña y redime rCOP al precio COP/USD publicado, menos fees, mientras haya reservas y el sistema no esté pausado. No existe un mercado secundario oficial ni un formador de liquidez.

En las fórmulas, P es el precio COP/USD con 18 decimales y los montos de USDC tienen 6 decimales. Todas las operaciones usan Math.mulDiv (precisión intermedia de 512 bits) y redondean hacia abajo, a favor de las reservas.

#3.1 Mint (USDC → rCOP)

rCOP_bruto = USDC × 10¹² × P / 10¹⁸
rCOP_neto  = rCOP_bruto × (10.000 − fee_mint) / 10.000        fee_mint = 10 pb

La operación revierte si el precio tiene más de diez minutos, si el sistema está pausado, si el RR está por debajo del 75 %, si se supera un tope o si el resultado es menor que el mínimo aceptado por el usuario (protección de slippage).

#3.2 Burn (rCOP → USDC)

USDC_bruto = rCOP × 10⁶ / P
USDC_neto  = USDC_bruto × (10.000 − fee_burn(RR)) / 10.000

El fee de burn depende del Reserve Ratio antes de la operación. Además, el contrato proyecta el RR posterior y revierte si quedaría por debajo del 75 %, o si las reservas no alcanzan para pagar.

#3.3 Reserve Ratio, fees escalonados y auto-pausa

RR = (reservas_USDC × 10¹² × P / 10¹⁸) / supply_rCOP

Un RR de 1 significa que las reservas, valoradas al precio del oráculo, cubren exactamente el supply en pesos.

El principio es asimétrico: el fee de mint es constante y solo el fee de burn sube cuando las reservas no alcanzan. La auto-pausa no cambia el estado paused(): las operaciones revierten mientras el RR esté por debajo del 75 % y se reanudan solas si el RR se recupera (ADR-016).

#3.4 Topes

Los topes están expresados en rCOP y no en dólares, así que su equivalente en dólares cambia con la TRM. El tope por dirección se puede eludir usando varias direcciones o transfiriendo tokens: limita el monto total expuesto, no el número de usuarios.

#3.5 Ejemplo verificado

El 25 de septiembre de 2026 se ejecutó un mint y un burn a través de la aplicación publicada en www.rcop.lat, con una wallet simulada y sobre una copia local de la red. Ninguna transacción llegó a la red real.

La cotización que mostró la aplicación, el evento emitido por el contrato y el cambio de saldos coincidieron sin diferencia de un solo wei, que es la unidad mínima del token. La aprobación de USDC fue por el monto exacto, sin permisos ilimitados. La prueba verificó 47 condiciones y un segundo agente la repitió de forma independiente.

#4. Oráculo COP/USD

#4.1 De RedStone a un oráculo propio

El diseño original preveía un oráculo pull de RedStone. En la implementación se comprobó que el par COP/USD no existe en el servicio primario de RedStone. Por eso el Engine v2 lee un precio publicado por un bot con el rol PRICE_PUSHER_ROLE (ADR-023). El código de la ruta RedStone sigue en el contrato, pero está inactivo.

#4.2 Agregación fuera de la cadena

El precio final es el promedio ponderado de las fuentes que pasan los filtros, con los pesos re-normalizados. La TRM es el ancla: si falta, no se publica nada (ADR-025 y ADR-031).

Antes de enviar la transacción, el bot hace cuatro comprobaciones:

1. que el precio esté entre 2.000 y 10.000;
2. que el contrato lo vaya a aceptar frente a su promedio;
3. que la transacción no revierta, simulándola;
4. que tenga saldo para el gas.

Si algo falla, no envía la transacción y termina con un código de salida que identifica la causa.

#4.3 Validaciones en la cadena

La media de referencia se cuenta por publicación, no por tiempo. No hay intervalo mínimo entre publicaciones ni tope de cambio por publicación. Las consecuencias se explican en la sección 6.5.

#4.4 Operación, costos y monitoreo

• Cada publicación consume unos 122.000 de gas. Con el precio mínimo de la red de prueba (50 gwei), eso son ≈ 0,0061 CELO por publicación y ≈ 1,75 CELO al día. El CELO de la red de prueba no tiene valor monetario, pero se agota: hay que recargarlo desde un faucet.
• Hasta septiembre de 2026 el bot corrió en GitHub Actions. Como GitHub cobra un minuto completo por cada corrida, 288 corridas al día superaban el cupo gratuito de un repositorio privado. El 25 de septiembre el bot pasó a una función serverless que no consume ese cupo (ADR-035).
• La liveness (que el precio siga llegando) se vigila desde fuera con /api/health (ADR-030).

#4.5 Evidencia operativa de la Fase 1

La operación real del oráculo produjo la evidencia más relevante de la Fase 1: el riesgo principal de un oráculo propio no es la manipulación, sino dejar de publicar.

• Primer periodo sin precio (21 de junio – 24 de septiembre de 2026, ≈ 95 días). Durante ese tiempo mint y burn revertían: nadie pudo acuñar ni redimir. Las causas fueron tres:
  • el bot se quedó sin gas (causa muy probable; los registros ya habían expirado);
  • desde el 19 de agosto, GitHub Actions dejó de ejecutar el bot por el cupo de facturación;
  • no había monitoreo que avisara.
• Rotación de llave. La llave anterior del bot había quedado expuesta y se rotó el 24 de septiembre (ADR-027).
• Oráculo trabado. Al volver, el precio de mercado estaba ≈ 6 % por debajo del promedio congelado. Como el límite es de 3 %, ninguna llave podía publicar. La recuperación exigió que la cuenta administradora subiera temporalmente el límite de desviación, publicara 21 veces y lo restaurara (procedimiento UNSTICK, ADR-027).
• Segundo periodo sin precio (desde el 27 de septiembre de 2026, 09:05 UTC). El programador externo desactiva un job que falla más de 25 veces seguidas. Con el saldo del bot por debajo de 1 CELO, cada corrida publicaba el precio pero respondía como fallida para avisar del saldo bajo. Esa es la causa probable, deducida de la política del servicio y del número de publicaciones hechas con saldo bajo. A la fecha de corte, el disparo automático estaba pendiente de reactivación.

#4.6 Propuesta de oráculo v3 (no desplegada)

Hay una versión alternativa del contrato del oráculo, con pruebas propias, que podría reemplazar a la v2 mediante setOracleFor sin actualizar el Engine. Sus cambios son:

• a lo sumo una publicación por bloque y un intervalo mínimo de 60 segundos entre publicaciones;
• un tope al cambio de precio por publicación, que se amplía con el tiempo transcurrido (0,5 pb por segundo);
• un promedio ponderado por tiempo, de 30 minutos, como referencia;
• bandas que se abren durante el silencio, para que el oráculo se recupere solo después de una caída.

La v3 vuelve la manipulación lenta y visible, pero no elimina la extracción mientras el Engine liquide al precio del momento. Se evalúa para después de la defensa de la tesis, porque los contratos desplegados están congelados hasta entonces (ADR-028).

#5. Gobernanza

#5.1 Roles

#5.2 Estado real en la Fase 1

En Celo Sepolia no hay multisig ni timelock desplegados. Una sola cuenta del autor (0x3b4b…149e), con un keystore de software, tiene todos los roles privilegiados de los tres contratos (ADR-019). Eso incluye decidir quién publica precios y el límite de desviación del oráculo. En consecuencia, los cambios de gobernanza son instantáneos: el re-anclaje de septiembre de 2026 se hizo en minutos.

#5.3 Objetivo de la Fase 2

Un Safe multisig 3-de-5 propondría y cancelaría operaciones en el timelock, y cualquier dirección podría ejecutarlas una vez vencido el plazo. La asimetría es deliberada: pausar es inmediato, despausar exige multisig y 24 horas. Las pruebas del repositorio ensayan el traspaso completo a este esquema en los tres contratos.

#5.4 Disclosure de concentración

La siguiente declaración describe la configuración prevista del multisig. En la testnet actual la concentración es todavía mayor, porque una sola cuenta tiene todos los roles (sección 5.2).

El MVP opera bajo multisig 3-of-5 Safe, compuesto por 3 wallets del autor (hot + 2 hardware wallets geográficamente separadas) y 2 wallets de validadores externos. En consecuencia, el autor puede actuar unilateralmente por concentración de umbral. Esta es una limitación reconocida de la arquitectura de Fase 1 testnet, subsanable en Fase 2 mainnet mediante redistribución de signers hacia 2 del autor + 3 terceros independientes. Esta redistribución es condición de lanzamiento de Fase 2.

#6. Análisis de riesgos

El análisis sigue los cuatro ejes de la propuesta normativa de la tesis para Colombia, más la protección al consumidor. En cada eje se describe qué hace el diseño y dónde están sus límites. La calificación jurídica corresponde a la tesis.

#6.1 Riesgo de corrida y pérdida de paridad

Qué hace el diseño:

• usa un único colateral (USDC nativo de Circle);
• impone topes bajos;
• sube el fee de burn cuando el RR baja;
• se auto-pausa por debajo del 75 %.

Límites conocidos:

• Descalce cambiario. Las reservas están en dólares y el pasivo en pesos. Si el peso se aprecia, el RR baja sin que nadie opere. No hay cobertura cambiaria, capital de primera pérdida ni sobrecolateralización objetivo. Los fees son un colchón mínimo.
• Redención por orden de llegada. Con RR < 1, cada burn paga a la par del oráculo, menos un fee calculado con el RR previo, y no aplica ningún descuento proporcional. Quien sale primero cobra casi completo y los últimos cargan el déficit. Un burn grande paga el fee del tramo inicial aunque cruce varios umbrales.
• Dilución. Con RR < 1 el mint sigue abierto: el USDC de quien entra financia la salida de los anteriores.
• La pausa también bloquea las redenciones. No existe un modo "solo redención", y con RR < 0,75 el USDC queda inmovilizado.

#6.2 Riesgo de captación no autorizada

Qué hace el diseño:

• no paga rendimiento (D4);
• la redención es por mejor esfuerzo (D3);
• los fees permanecen en las reservas: no hay tesorería del emisor;
• no se ofrece al público y opera en testnet con topes (D5).

Límites: el contrato redime a la par del oráculo mientras haya reservas, y esa es una característica del código que la tesis debe analizar. Los disclaimers delimitan el alcance del proyecto, pero no sustituyen ese análisis ni constituyen, por sí mismos, una opinión jurídica.

#6.3 Riesgo de lavado de activos y financiación del terrorismo

Qué hace el diseño:

• en la Fase 1 los activos son de testnet y no tienen valor monetario;
• no hay entrada ni salida de dinero fiduciario;
• los montos están limitados por los topes.

Límites: no hay verificación de identidad. Una Fase 2 con valor real exigiría un análisis previo de obligaciones de prevención y reporte.

#6.4 Riesgo para la transmisión de la política monetaria

Qué hace el diseño: el supply máximo equivale a unos pocos miles de dólares, así que el efecto en la Fase 1 es despreciable. El modelo sintético no capta depósitos en pesos.

Límites: a escala, una stablecoin en pesos respaldada en dólares crearía demanda de dólares y exposición cambiaria agregada. La tesis analiza esa cuestión.

#6.5 Riesgos técnicos y del oráculo

Los resultados de esta sección se reproducen con las pruebas de caracterización del repositorio.

• Caminata del promedio. Como la referencia es una media por publicación y no hay intervalo mínimo, una llave de bot comprometida puede publicar muchas veces en un mismo bloque. Con 10 publicaciones en un bloque el promedio sube 6,22 % y el último precio 9,11 %. Con 444 publicaciones en un solo bloque el precio va de 4.000 al máximo de 10.000.
• Extracción de reservas. El escenario de prueba tiene cinco usuarios honestos. Un atacante con la llave del bot sube el precio, acuña, lo baja y redime: recibe 187,03 USDC por 150 (+24,69 %) en 178 publicaciones. El RR queda en 0,961, así que el ataque se puede repetir. La precondición no es teórica: una llave del bot estuvo expuesta.
• Oráculo trabado tras una caída. El límite de desviación no se relaja con el tiempo. Sin gobernanza, la única salida sería publicar una "escalera" de 24 precios que no son de mercado, y esa opción se descartó. Con el timelock de la Fase 2, un re-anclaje tardaría al menos 48 horas.
• Arbitraje de latencia. Mint y burn liquidan al precio publicado, sin spread ni retardo, y la TRM del día siguiente se conoce por adelantado. Un salto de TRM de +1,74 % equivale a ≈ 104 pb en el precio agregado, frente a un fee de ida y vuelta de 25 pb.
• Marca de tiempo. El contrato guarda la hora de publicación, no la del dato: una TRM de fin de semana se considera fresca.
• Gobernanza sin validaciones. Algunos setters no validan sus parámetros; por ejemplo, un oráculo nulo o un fee mayor al 100 % congelarían el sistema. En la Fase 1, un error de la cuenta administradora tendría efecto inmediato.
• Secuenciador. En mainnet, una caída del secuenciador de Celo congelaría mint y burn al menos 70 minutos: los 10 minutos de frescura más la hora de gracia.

#6.6 Protección al consumidor

• La dApp no permite operar sin leer y aceptar los disclaimers D1–D5.
• Cada operación se simula antes de pedir la firma. Las operaciones se bloquean si el precio tiene más de diez minutos o si el sistema está pausado.
• Los errores del contrato se traducen a mensajes comprensibles.
• Los cinco disclaimers son textualmente idénticos en tech_spec.md, en el NatSpec del contrato del token, en la aplicación y en este documento. La integración continua lo verifica en cada cambio y bloquea cualquier diferencia.
• Las limitaciones de esta sección se publican con números reproducibles, en lugar de omitirse.

#7. Disclaimers y marco regulatorio

Los cinco disclaimers siguientes son el texto cerrado del proyecto. No se traducen, no se parafrasean y no se abrevian. Cada uno va seguido de un comentario que no forma parte del texto vinculante.

#Disclaimer 1 — No es moneda de curso legal

rCOP (Representative Colombian Peso) no es moneda de curso legal en la República de Colombia. El único medio de pago con poder liberatorio pleno dentro del territorio colombiano es el peso colombiano emitido por el Banco de la República, de conformidad con el artículo 371 de la Constitución Política de Colombia.

Comentario: distingue a rCOP de la moneda cuya emisión corresponde en exclusiva al Banco de la República.

#Disclaimer 2 — No garantía estatal

rCOP no está garantizado por Fogafín (Fondo de Garantías de Instituciones Financieras), ni por el Banco de la República, ni por ninguna entidad pública colombiana. No existe seguro de depósito aplicable a rCOP ni a las reservas en USDC que lo respaldan.

Comentario: evita expectativas de seguro de depósito o de respaldo público.

#Disclaimer 3 — Redención por mejor esfuerzo

La redención de rCOP por USDC se ejecuta por mejor esfuerzo, sujeta a la disponibilidad de reservas en tesorería al momento de la solicitud. En escenarios de sub-colateralización por debajo del 75%, el sistema entra en pausa automática que puede bloquear redenciones hasta que la gobernanza evalúe la situación. Los tenedores de rCOP asumen el riesgo de no poder redimir la totalidad de su tenencia al valor nominal en situaciones adversas.

Comentario: describe el comportamiento real del contrato: fees escalonados, auto-pausa y redención limitada por las reservas (sección 6.1).

#Disclaimer 4 — Ausencia de rendimiento

El emisor de rCOP no paga intereses, rendimientos, dividendos ni ninguna forma de retorno financiero sobre la tenencia del token. rCOP no constituye un instrumento de inversión ni un valor en el sentido de la Ley 964 de 2005. La mera tenencia de rCOP no genera derecho a distribución alguna.

Comentario: el contrato no tiene ninguna función que distribuya rendimiento, y los fees permanecen en las reservas.

#Disclaimer 5 — Uso experimental académico

Durante la Fase 1 del proyecto, rCOP opera como Minimum Viable Product con fines estrictamente académicos en el marco de una tesis de maestría. Los caps operativos están limitados a USD 2.000 en supply global y USD 200 por dirección. El despliegue se realiza únicamente en Celo Sepolia (testnet) y en Celo mainnet con caps reducidos. rCOP no se ofrece al público general como instrumento financiero ni como medio de pago, y no sustituye medios de pago regulados.

Comentario: los montos en dólares suponen una TRM cercana a 4.000. En la cadena, los topes están fijados en rCOP (sección 3.4).

#8. Aseguramiento de calidad

• Pruebas. Hay 170 pruebas de Foundry: unitarias, de integración, de fuzzing y de invariantes. Entre ellas están las que caracterizan las limitaciones del oráculo y las que ensayan el traspaso de gobernanza de la Fase 2.

• Invariantes. Se prueban con fuzzing con estado, con al menos 10.000 corridas y profundidad 128:

  • I1: conservación del supply;
  • I2: solvencia por operación a precio fijo;
  • I3: tope global;
  • I4: tope por dirección;
  • I5: auto-pausa;
  • I6: el Engine es el único acuñador.

• Zonas rojas. Hay pruebas obligatorias para las cinco rutas de mayor riesgo: la autorización de upgrades, la auto-pausa antes de mutar el estado, la separación entre pausar y despausar, la administración de roles con timelock y la ejecución pública del timelock.

• Cobertura de ramas por archivo. La integración continua la exige con un mínimo que solo puede subir (ADR-029). El objetivo del plan era 95 %, y la excepción está documentada.

  Archivo	Cobertura de ramas
  RCopEngine	100 %
  RCop	100 %
  RCopOracleWrapper	88,89 %
  ReserveMath	80 %

• Análisis estático. Slither y Aderyn corren en la integración continua.

• Prueba de punta a punta. Mint y burn se probaron a través de la aplicación publicada (sección 3.5).

• Revisión interna. El código tuvo una revisión interna, asistida por herramientas automáticas y agentes de IA. De los hallazgos confirmados, ninguno resultó crítico ni alto después de verificarlo. Los que afectan a los contratos están documentados en este documento y no se corrigieron, porque los contratos están congelados hasta la defensa.

• Auditoría externa. No se ha hecho. Es condición para la Fase 2.

#9. Hoja de ruta

Fase 1 (actual) — Operar en la testnet, documentar la evidencia y defender la tesis. Los contratos desplegados no cambian hasta la defensa (ADR-028).

Condiciones para una eventual Fase 2:

1. Auditoría externa de los contratos.
2. Un oráculo que no se pueda caminar ni se trabe tras una caída (por ejemplo la v3 de la sección 4.6), combinado con un precio protector en el Engine.
3. Un tratamiento explícito del descalce cambiario. Una línea de estudio es simular el RR con la TRM histórica bajo distintos niveles de cobertura.
4. Gobernanza con Safe 3-de-5 con mayoría de terceros independientes (sección 5.4) y timelocks de 48 y 24 horas.
5. Monitoreo en la cadena con alertas sobre eventos reales, y verificación pública del código.
6. Un análisis jurídico previo de las obligaciones aplicables a una operación con valor real.

Fase 3 — Escalamiento, fuera del alcance de la tesis y sujeto a los resultados de la Fase 2.

#Glosario

#Referencias

• Angle Protocol, Transmuter (código fuente): https://github.com/AngleProtocol/angle-transmuter
• Celo, documentación para desarrolladores: https://docs.celo.org/
• Circle, direcciones de contrato de USDC: https://developers.circle.com/stablecoins/usdc-contract-addresses
• Datos Abiertos Colombia, Tasa de Cambio Representativa del Mercado – Histórico: https://www.datos.gov.co/Econom-a-y-Finanzas/Tasa-de-Cambio-Representativa-del-Mercado-Historic/32sa-8pi3
• ExchangeRate-API, API abierta: https://www.exchangerate-api.com/docs/free
• Chainlink, L2 Sequencer Uptime Feeds: https://docs.chain.link/data-feeds/l2-sequencer-feeds
• OpenZeppelin Contracts 5.x: https://docs.openzeppelin.com/contracts/5.x/
• EIP-2612 (permit): https://eips.ethereum.org/EIPS/eip-2612
• ERC-1822 (UUPS): https://eips.ethereum.org/EIPS/eip-1822 · ERC-1967: https://eips.ethereum.org/EIPS/eip-1967
• ERC-7201 (almacenamiento con espacio de nombres): https://eips.ethereum.org/EIPS/eip-7201
• Constitución Política de Colombia: http://www.secretariasenado.gov.co/senado/basedoc/constitucion_politica_1991.html
• Ley 964 de 2005: http://www.secretariasenado.gov.co/senado/basedoc/ley_0964_2005.html
• Superintendencia Financiera de Colombia, normas de captación ilegal: https://www.superfinanciera.gov.co/publicaciones/10115318/normas-de-captacion-ilegal/

Las decisiones de arquitectura citadas (ADR-007 a ADR-035), la especificación técnica (tech_spec.md) y las pruebas están en el repositorio del proyecto.

#Cómo citar

Grupo New Way SAS (2026). rCOP — Libro blanco técnico (Fase 1), versión 1.0. https://www.rcop.lat/libro-blanco. Licencia CC BY-NC-SA 4.0.