Proyecto confirmado y análisis público
EXCOIN completó un encargo relativo a un contrato Ethereum para préstamos respaldados por criptoactivos. Los límites contractuales impiden publicar cliente, dirección, parámetros exactos, tokens, volúmenes o informe de auditoría. Explicamos el espacio de diseño seguro y decisiones típicas de estos sistemas, sin revelar código productivo. Los patrones descritos no pueden atribuirse automáticamente al cliente confidencial.
La cuestión comercial es cómo obtener liquidez sin vender activos digitales y explicar los riesgos al prestatario, prestamista y operador. Este estudio aborda el diseño de contratos en Ethereum y redes EVM. Los principios técnicos son generales; no revelan ni demuestran la implantación exacta del cliente confidencial.
Roles, promesas económicas y límites del contrato
Antes de escribir Solidity se definen prestatario, prestamista o fondo, administrador de parámetros, fuente de precios, liquidador y operador de la interfaz. Cada rol tiene acciones delimitadas. El acuerdo comercial decide cuándo nace el préstamo, moneda de devolución, comisiones y mora. El código solo automatiza reglas expresables y comprobables con información disponible en cadena.
El contrato no resuelve por sí mismo propiedad extrafinal, identidad del cliente ni ejecución jurídica. Esas áreas requieren acuerdos y operación fuera de cadena. La arquitectura describe la relación entre interfaz, transacción firmada, contrato, indexador, oráculo y cualquier registro externo. Sin estos límites aparece la peligrosa ilusión de que el contrato gobierna toda la relación.
Modelo de préstamo y estados
Solicitud, oferta, garantía depositada, principal dispuesto, interés acumulado, amortización y liberación de garantía son estados distintos. Las transiciones preservan invariantes: no liberar antes de pagar, no desembolsar dos veces, no aceptar una oferta cancelada y no liquidar después del cierre. Eventos y estado almacenado deben permitir reconstruir la secuencia.
Los pagos parciales requieren una regla de imputación entre comisiones, intereses y principal. La aritmética entera controla redondeo y residuos; los decimales de la interfaz no pueden ocultar unidades on-chain. El interés variable obliga a delimitar quién cambia parámetros y desde cuándo. Los timestamps de bloques sirven para ciertos cálculos, pero no son un reloj perfecto.
Activos, tokens y unidades
El contrato determina qué tokens sirven de garantía y cuáles financian el préstamo. Una interfaz ERC-20 no garantiza un comportamiento convencional: algunos tokens cobran comisión, restringen direcciones, modifican saldos o devuelven valores inusuales. Admitir un activo requiere lista autorizada, pruebas con la implementación real y regla para la cantidad efectivamente recibida. Enviar un token desconocido no debe convertirlo en garantía aceptada.
La precisión de cada activo y feed se obtiene del origen real. El valor de garantía usa una unidad contable definida y orden conservador de operaciones para no inflar capacidad por redondeo. Saldo nominal y valor económico disponible son diferentes. Una stablecoin puede perder su paridad y no equivale a dólares sin riesgo por llamarse estable.
Garantía y relación préstamo-valor
LTV inicial máximo, nivel de aviso y umbral de liquidación son parámetros separados. Sus cifras dependen de volatilidad, liquidez y mecanismo de liquidación; aquí no se divulgan valores del cliente. Añadir, retirar o sustituir garantía solo se permite si la posición resultante respeta el invariante de seguridad aprobado.
En una caída brusca quizá no se venda la garantía al precio del oráculo. El modelo contempla deslizamiento, comisiones y demora entre observación y ejecución. La interfaz separa aviso informativo de condición exigible por contrato. Las notificaciones ayudan al usuario, pero su entrega no puede ser el único control de seguridad.
Oráculos y fallos del precio
Un contrato de crédito no debería valorar activos mediante una operación spot fácilmente manipulable. La política de oráculo valida mercado, decimales, antigüedad, signo positivo y conducta ante caída. Si el dato es viejo o anómalo, no se debe permitir sin más nueva deuda ni liquidación. Las reglas para precios caducados forman parte de la especificación económica.
Un feed alternativo no es automáticamente seguro: puede diferir en precisión, definición y momento. Cambiar exige criterio explícito y pausa de acciones arriesgadas cuando hay discrepancia. Las pruebas incluyen volatilidad, datos viejos, poca liquidez y caídas del proveedor. La precisión se verifica para la fuente elegida, sin asumir un valor habitual.
Desembolso y orden seguro de operaciones
Disponer del préstamo mueve valor de forma irreversible. Se comprueba oferta, garantía, precio reciente, límite, permiso y liquidez antes del envío. El estado del contrato se actualiza en orden seguro respecto a llamadas externas para que reentradas o repeticiones no paguen dos veces. Una solicitud duplicada se rechaza claramente o recupera el resultado ya registrado.
Una transacción puede permanecer pendiente, entrar en un bloque, reorganizarse o alcanzar confirmación suficiente. El servicio no puede presentar desembolso definitivo porque la cartera envió una firma. Sigue hash, red y confirmaciones. Un error de interfaz no debe provocar una segunda firma económica sin consultar el estado on-chain.
Amortización, cierre anticipado y devolución
Cada pago calcula deuda en un momento preciso, acepta el activo permitido y lo imputa según el acuerdo. Un pago parcial reduce deuda pero no necesariamente libera garantía. El cierre temprano precisa tratamiento claro de intereses y cargos; un pago excesivo necesita vía explícita de devolución en lugar de perderse por redondeo.
Tras liquidar toda la deuda, el prestatario retira la garantía o el contrato la devuelve según el modelo. Un fallo de transferencia externa no debe dejar el préstamo incoherente. Evento y estado registran cantidad y destinatario. Recuperar una clave perdida es un asunto de producto y derecho; el contrato no identifica por sí mismo al nuevo dueño legítimo.
Liquidación y protección de ambas partes
Liquidar exige definir activador, precio, cantidad vendible, extinción de deuda, excedente y déficit. Una liquidación agresiva perjudica al prestatario; otra demasiado lenta deja al prestamista descubierto. Liquidación parcial, subasta y otras opciones requieren pruebas de mercado adverso.
Las simulaciones cubren caídas rápidas, falta de liquidez, gas alto, front-running y oráculo inactivo. Deben mostrar invariantes y pérdidas posibles. Una pausa de emergencia delimita funciones bloqueadas y si es posible pagar o retirar con seguridad. Congelar toda protección del usuario puede crear otro riesgo sistémico.
Permisos, mejoras y gobierno
Se separan privilegios para parámetros de riesgo, pausa, actualizaciones y retiro de comisiones. Titulares de claves, rotación y respuesta a compromiso importan tanto como Solidity. Pueden convenir multisig, retrasos y propuestas públicas. Cambiar el feed no debe conferir derecho a mover la garantía.
La actualización permite corregir, pero también cambiar reglas económicas tras iniciar un préstamo. Se decide si afecta solo contratos nuevos o existentes. Un contrato inmutable necesita migración y cierre; uno actualizable necesita aprobación, aviso, compatibilidad de almacenamiento, revisión independiente y plan de reversión cuando sea posible.
Revisión de seguridad y matriz de pruebas
Las pruebas cubren reentrancy, disposiciones indebidas, doble pago, redondeo, tokens atípicos, oráculo viejo, manipulación de precio y carrera entre devolución y liquidación. Tests de invariantes y fuzzing comprueban propiedades en secuencias variadas, no solo el camino feliz. Una revisión independiente añade protección pero no garantiza ausencia de defectos.
El entorno de pruebas debe usar versiones reales de tokens, feeds y red. Fork tests revelan diferencias frente a mocks; simulaciones económicas estresan liquidación. Cada hallazgo necesita gravedad, corrección, nueva prueba y decisión sobre riesgo residual. Al no publicarse el informe de este cliente, no afirmamos una auditoría externa o certificación concreta.
Indexación, operación e incidentes
Un indexador consume eventos para mostrar préstamos rápidamente. Procesa de forma idempotente y revierte reorganizaciones. El contrato es la fuente de verdad financiera; la base de datos puede retrasarse y debe indicar último bloque confirmado. La observabilidad cubre precios, edad del feed, RPC, transacciones pendientes, posiciones en riesgo y discrepancias.
El procedimiento de incidentes distingue bug de interfaz, caída RPC, clave comprometida, precio incorrecto y explotación del contrato. Una pausa tiene condiciones y responsables. No se afirma que los fondos están seguros antes de verificarlo. Una copia de datos externos no recupera activos on-chain; ambas responsabilidades se asignan por separado.
Acuerdo de préstamo y estado en cadena
El acuerdo del usuario y el contrato describen los mismos hechos económicos con lenguajes distintos. Ambos definen principal, vencimiento, interés, garantía, liquidación y caída del oráculo. Un mapa une cada cláusula con condición on-chain, prueba externa y responsable. Lo que no se automatiza tiene proceso manual explícito.
Antes de firmar, el prestatario ve parámetros reales del contrato, no solo un resumen comercial. Firmar no siempre implica desembolso inmediato ni bloqueo final. La interfaz muestra transiciones y cancelación posible. Asesoría del cliente evalúa validez jurídica y protección; ingeniería aporta datos exactos y auditoría.
Financiación y liquidez del prestamista
Liquidez ofrecida y fondos disponibles son distintos. Si el prestamista puede retirar, una oferta anulada no se acepta. Un fondo necesita participaciones, reservas, prioridad de salida y asignación de pérdidas. No se promete desembolso instantáneo si el capital aún se transfiere.
Las pruebas incluyen dos prestatarios disputando los últimos fondos, transferencia fallida y retirada durante liquidación. Saldo del contrato, obligaciones y liquidez cumplen un invariante definido. Su discrepancia es incidente de seguridad, no solo error de panel.
Matemática de intereses y tiempo
El interés puede ser simple, compuesto u otra fórmula pactada. Se definen unidad temporal, precisión, redondeo y periodos parciales. La aritmética entera de Solidity cambia según orden de multiplicación y división. Un cálculo externo sirve para pruebas, pero no sustituye el resultado del contrato.
Se prueban instantes antes, durante y después del vencimiento, préstamos largos y pagos parciales repetidos. Cambiar tasa exige indicar si afecta deuda anterior o solo periodo futuro. Si administra la tasa una persona, el acuerdo debe describir su potestad y el usuario conocer cambios antes de disponer más fondos.
Entrada de tokens y conductas atípicas
Recibir un token no es solo llamar transferFrom. Algunos ERC-20 cobran comisión, bloquean direcciones, alteran saldo o devuelven valores especiales. Se comparan saldos cuando corresponde y una lista permite solo activos revisados. Distintos decimales transforman el cálculo de garantía.
Una allowance permite gasto futuro aunque no mueva fondos de inmediato. La interfaz pide límite razonable, explica el destinatario y facilita revocación. Una versión nueva del token se prueba en depósito, desembolso, amortización, devolución de excedente y liquidación.
Parámetros de riesgo y estrés del mercado
Un único ratio de garantía no sirve para todos los tokens. Importan profundidad, concentración, volatilidad, oráculo y velocidad de liquidación. Los parámetros se aprueban con hipótesis y simulación. Un mercado deteriorado no puede evaluarse solo por precios pasados.
Los escenarios incluyen gaps, liquidación masiva, depeg, gas elevado y caída de mercado principal. El resultado presenta posibles pérdidas y condiciones de suspensión de nuevos préstamos, no una cifra promocional. Para posiciones abiertas se define si los umbrales cambian retroactivamente.
Incentivos del liquidador y subastas
Liquidadores necesitan incentivo suficiente para pagar gas y riesgo. Bonificación excesiva perjudica al prestatario; insuficiente deja deuda sin cubrir. El contrato calcula límite de venta, precio, prima y garantía restante. La liquidación parcial debe mejorar la posición.
Las subastas ayudan a encontrar precio, pero añaden tiempo y ataque. Se fijan inicio, fin, ofertas, anulación y ausencia de comprador. Las pruebas incluyen MEV, front-running y varios liquidadores. Enviar la transacción no demuestra que el prestamista recuperó valor suficiente.
Oráculo alternativo y emergencia
El feed se verifica por ronda, fecha, precio positivo y unidad. Dato viejo bloquea nueva deuda y liquidación riesgosa según regla acordada. Un feed alternativo puede representar otro mercado o precisión; cambiarlo exige comprobar desviación y permisos. Una clave que altere precio y umbral al instante concentra riesgo.
Emergencia restringe nuevos préstamos pero preserva pago seguro cuando sea posible. Las pruebas simulan caída del oráculo en vencimiento y desplome. El equipo sabe quién pausa, qué pruebas permiten reanudar y cómo informar. Precio manual es excepción muy privilegiada.
Actualización y préstamos abiertos
Una actualización corrige fallos pero también puede alterar economía de préstamos existentes. Se decide si el código rige solo posiciones nuevas o conserva términos previos. Almacenamiento, roles y migración se prueban con estados históricos realistas.
Revisión, aprobación, aviso y plan de fallo preceden el cambio. La reversión puede ser imposible tras movimientos económicos. Se prueban amortización y liquidación de posiciones abiertas entre versiones, no solo bytecode. Un proceso transparente reduce confianza ciega en administradores.
Firmas, carteras y usuario
Aprobar token, depositar garantía, aceptar préstamo y devolver son firmas diferentes. La interfaz comprueba chain ID y contrato. Ofertas externas usan nonce y caducidad para que firmas antiguas no se reutilicen tras cambiar condiciones.
Cartera perdida o clave robada son escenarios operativos. No se promete recuperar garantía sin procedimiento seguro y jurídicamente aceptado. Soporte no recibe poder general para mover fondos de clientes por comodidad. Los datos críticos aparecen antes de firmar y permanecen accesibles después.
Eventos e índice externo
El contrato emite eventos de apertura, disposición, cambio de garantía, pago, liquidación y cierre. Dan historia, pero no siempre estado completo; el indexador lee también almacenamiento. Bloque, hash y orden de log forman la clave. Las reorganizaciones exigen revertir y reproducir.
La vista operativa muestra último bloque confirmado y retraso. Si el índice se atrasa, la interfaz marca datos viejos y detiene acciones basadas en ellos. El contrato conserva la verdad financiera. Se ensaya reconstruir base desde cadena y checkpoints.
Auditoría y compilación reproducible
Fuente verificada, compilador, optimizador, librerías y direcciones dependientes forman el artefacto reproducible. Sin ello un repositorio no demuestra concordancia con bytecode. El release registra hashes, aprobaciones y parámetros. Cambiar proxy o implementación genera otro evento auditable.
La documentación enumera invariantes, confianza, excepciones y riesgo residual. Afirmar auditoría externa requiere informe y permiso; no lo hacemos para este cliente confidencial. Internamente un incidente debe reconstruir versión, precio, actuación administrativa y posición en un bloque.
Carga de red y coste
El gas puede hacer inviable un préstamo pequeño o impedir aportar garantía a tiempo. Se mide depósito, disposición, pago y liquidación en condiciones realistas. Agrupar ahorra coste pero añade complejidad y fallo conjunto. Elegir red o L2 considera activos, oráculos, usuarios y retirada.
Con comisiones altas una posición puede liquidarse antes de confirmar un aporte. No se promete un tiempo fijo que la red no garantice. Se vigilan pendientes y precio de ejecución. Operaciones puede reemplazar transacciones propias con procedimiento, pero no firma por usuarios sin mandato.
Ataques económicos e incentivos
Un atacante no necesita bug de Solidity. Puede manipular mercado pequeño, aprovechar precio temporal, abrir muchos préstamos o explotar bonificación de liquidación. El modelo incluye economía, MEV y transacciones coordinadas. Simulación compara beneficio y coste del ataque y descubre parámetros peligrosos.
También pueden fallar incentivos legítimos. Quizá convenga al prestamista esperar default o al liquidador empeorar precio. Un código correcto puede producir mal resultado. Producto y seguridad evalúan mecanismo completo, comisiones y destino de garantía sobrante.
Entrega y responsabilidad continua
La entrega incluye direcciones, ABI, fuente verificada, compilador, tests de invariantes, parámetros, titulares de roles, procedimientos e incidentes. Un equipo nuevo debe poder pausar funciones riesgosas y evaluar posiciones abiertas. Después se supervisan feeds, red, tokens y permisos.
Cada activo o préstamo nuevo recibe revisión económica y de seguridad. Las métricas observan edad de precios, posiciones en riesgo, pagos fallidos y liquidaciones pendientes, no solo transacciones. La confidencialidad impide publicar cifras del cliente, pero el estudio ofrece preguntas concretas para sistemas comparables.
Revisión jurídica y evolución
Crédito, custodia, cambio y operación de plataforma pueden recibir calificación distinta según país y rol. MiCA y otras reglas no se resuelven en una frase de marketing. Asesores competentes deben evaluar producto, acuerdos, identificación, protección del consumidor, impuestos y conflictos. El despliegue técnico no concede una licencia ni ejecutabilidad jurídica.
Nuevas garantías, intereses o prestamistas vuelven a abrir cuestiones de economía, oráculos, liquidez y seguridad. Los módulos bien delimitados permiten evolucionar sin ocultar riesgos. El valor del estudio está en poder explicar cada hecho económico, su prueba on-chain y responsable de excepciones, no en cifras de escala no verificables.
La aceptación de una ampliación requiere volver a probar las posiciones ya abiertas y las reglas de migración. Una modificación aparentemente pequeña, como permitir otro token de garantía, puede alterar la precisión, la fuente de precio y la capacidad de liquidación. Por eso se documentan el escenario anterior, la decisión nueva, el riesgo residual y el procedimiento para detener la función sin bloquear pagos legítimos. El equipo de producto y el responsable de seguridad deben aprobar la transición antes de habilitarla para todos los usuarios.
Referencias técnicas generales
Estos enlaces explican principios generales. No documentan la implantación confidencial del cliente.