Exchange Cripto P2P en Polygon — Caso de Estudio

Este es el caso de estudio del exchange peer-to-peer de cripto que construí sobre Polygon con un contrato de escrow en Solidity por debajo. Los usuarios pueden intercambiar fiat por cripto (y cripto por cripto) directamente entre ellos, con el contrato de la plataforma sosteniendo los activos en escrow hasta que ambas partes confirmen — o hasta que una disputa se resuelva. El contrato de Solidity del escrow es open-source y fue adoptado por otros proyectos del mismo espacio. Nacido en España, radicado en Paraguay, trabajando a través de las capas on-chain y off-chain.

¿Cuál era el problema?

Los exchanges centralizados funcionan bien en la cima del mercado, pero dejan regiones enteras desatendidas — lugares donde los rieles de pago locales no se conectan con la liquidez global, donde los requerimientos de KYC dejan fuera a usuarios legítimos, o donde el modelo de confianza de un exchange custodial es en sí mismo el problema. La respuesta tradicional era usar grupos de Telegram y confiar en la contraparte, lo cual falla apenas la operación supera el monto que la gente puede permitirse perder.

El producto era un marketplace donde compradores y vendedores se encontraban, acordaban condiciones y dejaban que un smart contract sostuviera la pierna cripto del intercambio en escrow mientras la pierna fiat se movía por cualquier riel local que tuviera sentido. La capa on-chain existía para hacer la suposición de confianza explícita y pequeña: nadie se va con los fondos porque el contrato no se lo permite.

Las restricciones:

• Costo de gas lo suficientemente bajo como para que las operaciones pequeñas fueran viables.
• Resolución de disputas que funcionara cuando las dos partes discordaran.
• Soporte multi-moneda para que distintos mercados pudieran usar distintas monedas locales en la pierna fiat.
• Un contrato lo suficientemente simple como para auditar y reutilizar.

¿Cuál fue el enfoque?

La construcción separó preocupaciones en dos capas con una interfaz clara entre ellas.

On-chain (Solidity, Polygon). El contrato de escrow sostenía los fondos, aplicaba las reglas de resolución y era la fuente de verdad de cualquier movimiento de valor. Era deliberadamente pequeño — menos líneas, menos superficies de ataque, menos motivos para una re-auditoría con cada cambio de producto. El código on-chain sabía de escrows, liberaciones, reembolsos y disputas; no sabía de mensajes de chat, métodos de pago ni KYC.

Off-chain (Node.js + Postgres + React). Todo lo que no necesitaba consenso vivía acá — cuentas de usuario, artefactos de KYC, metadata de métodos de pago, listings, evidencia de disputas, flujos de soporte. El sistema off-chain podía redesplegarse, reescribirse, incluso reescribirse en otro lenguaje sin tocar el contrato on-chain. Esa separación es todo el punto.

La construcción por fases fue:

1. Contrato primero. Lógica de escrow, depósito, liberación, reembolso, disputa, rol de árbitro. Suite de tests en Hardhat cubriendo cada camino, incluidos los infelices. La documentación de Hardhat cubre el harness de testing en el que me apoyé.
2. Esqueleto off-chain. Listings, matching, chat, KYC, UI de disputas. Slice vertical de extremo a extremo conectado con el contrato en una testnet.
3. Expansión multi-moneda. El contrato no cambiaba para nuevas monedas fiat — solo cambiaba la metadata off-chain. Esa fue la razón completa de mantener las monedas off-chain en primer lugar.
4. Despliegue en mainnet y endurecimiento. Pase de auditoría, gestión de claves, monitoreo sobre la dirección del contrato, runbook para el rol de árbitro.

Lo que hizo funcionar esto fue negarse a dejar entrar scope creep en on-chain. Cada vez que aparecía una nueva funcionalidad la primera pregunta era "¿esto necesita estar on-chain?". La mayoría de las veces la respuesta era no.

¿Qué incluye el stack?

• Polygon. Compatible con EVM, costo de gas bajo por transacción, herramientas maduras. La documentación de Polygon fue la referencia que envié al equipo cuando hicimos el onboarding.
• Solidity + Hardhat. Solidity para el contrato de escrow, Hardhat para tests, scripts de despliegue y la red local. Las herramientas de cobertura atraparon algunas ramas que los unit tests pasaron por alto.
• Librerías OpenZeppelin. Implementaciones estándar para control de acceso, reentrancy guards y la interacción con ERC-20. Hacer las propias es un error de categoría para código de contrato en producción; OpenZeppelin es la elección aburrida que previene clases enteras de bugs.
• React en el frontend. Conexión de wallet a través de adaptadores EVM estándar, llamadas a contrato vía ethers.js, UI optimista para las acciones off-chain y UI que requería confirmación para las on-chain.
• Node.js + Express en el backend. API REST, auth JWT, sesiones respaldadas en postgres, capa de integración entre la base de datos off-chain y los eventos del contrato emitidos por la cadena.
• PostgreSQL. Listings, usuarios, artefactos de KYC, historial de disputas, logs de auditoría para las partes off-chain del flujo.
• The Graph o indexación directa de eventos. Para consultar el estado del contrato de forma eficiente en vez de pegarle a un nodo en cada carga de página. Patrón estándar en el ecosistema EVM.

La superficie del contrato se mantuvo deliberadamente pequeña. La superficie off-chain cargaba la complejidad del producto. Esa es la división de trabajo correcta para casi cualquier producto DeFi que no necesite estar completamente on-chain.

¿Cuál fue el resultado?

El exchange salió a producción. El contrato de escrow es open-source y fue retomado por otros proyectos del espacio P2P — esa es la señal más honesta de calidad de código que tengo, y en ella me apoyo en lugar de cifras de uso que no puedo verificar de forma independiente. Los nombres específicos de los proyectos que lo adoptaron no están en esta página porque publicarlos no me corresponde a mí.

Notas cualitativas a destacar:

• El sistema de disputas funcionó sin convertirse en un agujero negro de tiempo del operador. La mayoría de las operaciones se resolvían sin disputa; las disputas que sucedían tenían evidencia estructurada suficiente — logs de chat, capturas de pago, artefactos de KYC — como para que la decisión del árbitro fuera, por lo general, obvia.
• La expansión multi-moneda fue indolora porque las monedas vivían off-chain. Agregar un nuevo mercado local significaba filas en la base de datos y strings de UI, no un nuevo despliegue de contrato.
• El pase de auditoría encontró problemas pequeños y ninguno grande, que es el objetivo — los arreglos pequeños son baratos, los grandes requieren rediseño.
• El equipo continuó operando y extendiendo el producto después del cierre de mi contrato.

¿Qué aprendí?

Negarse a dejar crecer el alcance on-chain. Toda conversación "esto también debería estar on-chain" debe empezar con "¿qué bug prevenimos al ponerlo on-chain?". Si la respuesta no es una violación específica de confianza, la funcionalidad pertenece off-chain, donde es más barata de enviar y más fácil de cambiar.

Abrir el código del contrato a propósito, temprano. Los otros proyectos que retomaron el contrato de escrow lo hicieron porque era legible, auditado y con licencia permisiva. Ese open-sourcing fue una decisión de marketing tanto como técnica. Construye confianza más rápido de lo que puede hacerlo cualquier landing page.

OpenZeppelin y Hardhat no son opcionales. El patrón de "escribimos nuestra propia librería de control de acceso" es cómo se explotan los contratos en Solidity. Las herramientas aburridas — librerías de OpenZeppelin, suite de tests de Hardhat, análisis estático con slither — son lo que evita que los caminos infelices se vuelvan incidentes.

Los hallazgos de auditoría deben ser pequeños. Entrar a una auditoría con un contrato que ya tiene 95 % de cobertura de tests y usa librerías estándar significa que la auditoría devuelve problemas pequeños. Entrar con un contrato hecho a mano significa que la auditoría devuelve un rediseño. Planificá para el primer resultado trabajando así desde el día uno.

Para las contrapartidas de cadena, Solana vs Polygon es el artículo que envío a quien esté decidiendo. La página del servicio de desarrollo blockchain cubre alcance y precios para compromisos similares. Para el enfoque más amplio de secuenciación, crear MVP rápido con IA describe cómo divido trabajo entre capas de la misma forma que describí arriba.

Escribime a [email protected] si estás trabajando en un producto respaldado por contrato y querés discutir la arquitectura antes de comprometerte con un stack. El estilo de repositorio está en github.com/ignaxdev.