¿Qué es el riesgo de smart contract?

Avanzado28 oct 2026 · 8 min de lectura

El riesgo de smart contract es la probabilidad de que usted pierda valor — o pierda el acceso usable a ese valor — porque el comportamiento de un programa on-chain, sus dependencias, sus oracles o su autoridad de admin / upgrade produce un resultado que usted no pretendía cuando depositó, aprobó o interactuó. El riesgo de smart contract no es «la cadena olvidó sus coins».

Definición

El riesgo de smart contract es la probabilidad de que usted pierda valor — o pierda el acceso usable a ese valor — porque el comportamiento de un programa on-chain, sus dependencias, sus oracles o su autoridad de admin / upgrade produce un resultado que usted no pretendía cuando depositó, aprobó o interactuó.

En palabras simples:

El riesgo de smart contract no es «la cadena olvidó sus coins». Es el riesgo de que código que usted autorizó — o código que puede reescribir las reglas después de que usted depositó — mueva, congele, malprecie o drene valor bajo su propia lógica.

La custodia pregunta quién puede gastar. El riesgo de smart contract pregunta qué pueden hacer los programas que usted toca, qué asumen del mundo y quién puede cambiar esas reglas después.

En trading

La verdadera pregunta de trading

Para esta exposición, ¿puedo nombrar los contratos, las superficies de confianza (oracles, upgrades, admins) y una forma de pérdida que aún pueda sobrevivir si esas superficies fallan — o estoy tratando «auditado / TVL alto / logo familiar» como un sustituto de la medición?

Responda por depósito y por superficie de aprobación. Vuelva a responder después de upgrades, después de cambios de oracle y después de saltos de tamaño. Un solo eslogan para cada interacción DeFi es la trampa de solo reconocimiento que esta página deja atrás.

Dos indicadores que la gente colapsa en uno

	Titulares de «hack» a escala de mercado	Exposiciones de protocolo DeFi
Qué suele dominar las pérdidas en dólares	Claves, signers, infra de wallet, front-ends, compromiso de admin	Lógica de protocolo y supuestos económicos
Qué suele dominar el conteo de incidentes	Mixto; los bugs de código siguen siendo frecuentes	Lógica, control de acceso, oracle, rutas contables
Error del trader	Tratar cada historia de pérdida como «los contratos son inseguros, así que evite DeFi»	Tratar cada insignia de auditoría como «el riesgo de código está cerrado»
Respuesta útil	Mantener un indicador de custodia para venues y claves	Mantener un indicador de contrato / oracle / upgrade para depósitos

Ambos indicadores son reales. Mezclarlos produce el hedge equivocado: o usted subdimensiona cada protocolo porque los robos de claves CeFi llenaron las noticias, o confía de más en un vault porque «la mayor parte del valor robado este año fueron claves».

Lectura acotada de conteos recientes de la industria: en todo el mercado, la infraestructura y el compromiso de claves suelen concentrar la mayor parte del valor; dentro de las pérdidas de protocolos DeFi, la lógica suele concentrar la mayor parte de la masa de pérdida. Use ambos hechos. No elija uno y descarte el otro.

Taxonomía (clases, no una sola bandera de «hackeado»)

Clase	Qué se rompe	Cómo aparece la pérdida
Control de acceso	Funciones privilegiadas invocables por la parte equivocada	Se abre ruta de mint, pause, upgrade, set-price o drenaje
Lógica de negocio	Reglas pretendidas ≠ reglas codificadas	Rewards incorrectos, matemática de colateral incorrecta, liquidación o mint/redeem rotos
Reentrancy / llamadas externas	El control se entrega antes de que el estado sea final	Retiros repetidos, reentrada entre funciones, callbacks de hooks
Aritmética / redondeo / shares	La matemática de punto fijo, fee, share o reserva se desvía	Fuga silenciosa de valor; estados extremos amplifican errores de un wei
Oracle / liquidez delgada	La lógica de seguridad confía en un precio movible o stale	Préstamos underwater, liquidaciones injustas, colateral inflado
Amplificación flashloan	Capital same-tx empuja un supuesto débil hasta romperlo	El bug raíz ya estaba; el capital temporal lo hizo rentable
Proxy / upgradeability	La implementación o la ruta de initializer / admin es débil	Reescritura de lógica, claim no inicializado, corrupción de storage
Griefing / DoS	Disponibilidad o salidas bloqueadas sin un «robo» limpio	Retiros atascados, liquidaciones trabadas, distribuciones que hacen revert

Las listas tipo OWASP Top 10 rotan rangos año a año. Control de acceso, lógica de negocio y oracles se mantienen cerca del tope; las rutas facilitadas por flashloan y las categorías proxy/upgrade subieron como superficies prácticas. Trate la lista como un menú de monitoreo, no como un cartón de bingo.

Superficies de segundo orden (donde el tamaño experimentado realmente muere)

La reentrancy de libro de texto no es el único indicador. Estas rutas de segundo orden suelen importar más cuando usted deja el tamaño de juguete:

Composabilidad — su vault está bien hasta que valora shares a partir de un pool peer, wrapper o bridge que usted nunca revisó.
Huecos de scope de auditoría — muchos post-mortems de protocolos «auditados» muestran que la ruta de ataque quedó fuera de todo scope público de auditoría, o en una dependencia / keeper / forwarder que el informe nunca cubrió.
Bytecode no verificado o desalineado — el nombre en la UI ≠ la dirección en el explorer ≠ la implementación a la que el proxy apunta ahora.
Upgrade sin ventana de revisión — sin timelock, un solo upgrader EOA, o un swap silencioso de implementación después de que usted depositó.
Emergency pause como confianza — un pause puede salvar un drenaje y también puede atrapar salidas; quién sostiene el interruptor forma parte del precio del riesgo.
Drenaje parcial vs total — algunos bugs hacen skim de redondeo; algunos vacían el pool; algunos congelan fondos sin transferirlos. Dimensionar para la peor forma creíble, no para el titular promedio.
Contratos «seguros» stale — despliegues viejos se revisitan; la edad no es un halo de seguridad si los incentivos siguen en la dirección.

Superficies residuales en venues wallet-first

El trading wallet-first (incluidos venues como edgeX) reduce el riesgo de «IOU del balance de la compañía» cuando su autorización mueve fondos. El riesgo de contrato sigue apareciendo cuando:

usted aprueba un spender que puede retirar tokens después
usted deposita en un vault, bridge o producto estructurado
el matching o el settlement depende de contratos cuya ruta de upgrade u oracle usted no ha mapeado
un frontend clonado le pide firmar contra una dirección distinta de la que usted verificó

Si su checklist solo pregunta «¿es non-custodial?», usted sigue en el indicador viejo.

Escenas trabajadas (juicio, no eslóganes)

A — Redondeo bajo presión de flashloan.

La matemática de withdraw de un pool redondea del lado equivocado en un tick extremo. El flujo normal se ve bien. Capital prestado same-transaction empuja el pool a ese estado, extrae la brecha, repaga el préstamo y deja a los LP cortos. El flashloan fue el amplificador. El bug fue contabilidad.

B — «Hack de oracle» que era control de acceso.

Se supone que las actualizaciones de precio viajan por una ruta keeper / forwarder. Un forwarder débil deja que un atacante alcance `setPrices`. Imprimen una marca mala, abren y cierran contra ella, y se van. La marca del feed no era la raíz; quién podía escribir el feed sí lo era.

C — Vault auditado, dependencia fuera de scope.

Tres PDF de auditoría están en el sitio de docs. El drenaje usa un helper de librería o un verificador de bridge que esos informes nunca acotaron. «Estábamos auditados» era verdad e incompleto. Pregunte qué commit, qué archivos, qué rutas económicas, y qué cambió desde entonces.

D — Proxy día uno vs año dos.

Usted dimensionó un depósito cuando la implementación estaba congelada y el multisig + timelock eran públicos. Seis meses después aterriza un upgrade con una ventana corta y un rol nuevo. Misma dirección de proxy; distinta superficie de confianza. Reevalúe o salga — no herede la tesis del año pasado.

Monitoreo (qué falsificar)

Califique cada exposición material de contrato contra hechos que usted pueda verificar — no contra insignias.

Monitor	Un pass se ve así	Un fail se ve así
Mapa de direcciones	Usted puede nombrar proxy vs implementación vs spender	«El contrato del sitio», no verificado
Mapa de permisos	Se conocen los roles de upgrade, pause, mint, escritura de oracle	Una sola god-key «owner» que usted no puede describir
Ruta de upgrade	Cultura de timelock / multisig / diff publicado	Upgrades EOA silenciosos
Diseño de oracle	Agregado / TWAP / frescura / límites de desviación donde el tamaño los necesita	Spot same-tx de un pool delgado para liquidaciones
Higiene de auditoría	Scope, fecha, hash de commit; bounty aún viva	Muro de logos; sin scope; el código se movió después del informe
Composabilidad	Usted sabe de qué pools/bridges externos depende la exposición	Wrappers anidados que usted no puede nombrar
Superficie de allowance	Mínimo privilegio; revocación periódica	Unlimited approve para siempre a cada router
Ensayo de salida	Un withdraw pequeño funcionó recientemente	Memoria muscular solo de depositar
Postura ante incidentes	Pause acotado; monitoreo; hábito de post-mortem público	TVL como prueba de seguridad

Defaults condicionales (empiece aquí, luego ajuste)

Si usted no puede nombrar la dirección del contrato y quién puede hacerle upgrade → no escale la exposición.
Si el pricing crítico de seguridad lee un spot same-transaction de un pool delgado → trate las rutas de liquidación / mint / redeem como hostiles hasta demostrar lo contrario.
Si el único consuelo es «auditado» sin scope ni commit → precie la auditoría como marketing, no como indicador.
Si un upgrade aterrizó después de su depósito → reevalúe; no asuma continuidad.
Si capital del tamaño de un flashloan puede mover el oracle o la matemática de shares de la que usted depende → dimensione como si ese capital va a aparecer.
Si el trading hot y los depósitos de protocolo comparten aprobaciones unlimited → separe las superficies esa misma semana.
Si el tamaño subió con fuerza → rehaga el mapa aunque la UI no haya cambiado.

Movimientos de diseño

Separe las aprobaciones del float de trading de los depósitos de protocolo idle.
Prefiera direcciones verificadas que usted pega desde una fuente conocida antes que «Connect and hope».
Tope cada exposición de protocolo en una forma de pérdida que usted pueda sobrevivir (skim vs vaciar vs congelar).
Ensaye un withdraw pequeño antes de escalar.
Revogue allowances unlimited stale con un calendario.
Prefiera venues y protocolos que publiquen direcciones de contratos, política de upgrade y scope de auditoría — y aun así corra sus propios monitores.
Escriba un orden corto de estrés: qué exposición sale primero si se dispara una alerta de upgrade o de oracle.

Límites de este marco

Esta página no reemplaza una auditoría profesional, verificación formal ni respuesta a incidentes para builders. No precifica cada quirk de finality de chain, bridge o L2. No salvará una exposición si usted ignora el phishing y firma un spender malicioso. Los indicadores vecinos — custodia, aprobaciones, MEV, riesgo de protocolo vs plataforma vs usuario — siguen aplicando. Use esta taxonomía para dejar de colapsar cada pérdida on-chain en una sola palabra.

No lo confunda con

Riesgo de custodia — falla de autoridad de gasto / contraparte-vs-operador; se apila con depósitos de protocolo, no es el mismo indicador.
Riesgo de aprobación de tokens — allowance que puede habilitar un retiro posterior; a menudo es la puerta hacia el riesgo de contrato, no todo el árbol del exploit.
Riesgo de precio — el mark puede moverse mientras el comportamiento del código y el control permanecen intactos.
Riesgo de liquidez / slippage — no poder salir del tamaño en el mercado ≠ vault drenado, congelado o malpreciado por lógica de programa.
MEV / sandwich — ordenamiento y extracción alrededor de su transacción; puede tocar el diseño de oracle/swap, y aun así no es sinónimo de bug de lógica.

¿Listo para el siguiente paso?

Continúa al registro o al trading desde esta página usando los enlaces oficiales.

Empieza a operar en edgeX

Aviso legal

Este contenido tiene fines exclusivamente educativos y no constituye asesoramiento de inversión. Operar con activos digitales y derivados implica riesgos. Asegúrate de entender los productos y de considerar tu situación antes de operar.

Glosario

¿Qué es el riesgo de smart contract?

Avanzado28 oct 2026 · 8 min de lectura

Definición

En palabras simples:

La custodia pregunta quién puede gastar. El riesgo de smart contract pregunta qué pueden hacer los programas que usted toca, qué asumen del mundo y quién puede cambiar esas reglas después.