Hay dos formas de equivocarse con los contratos inteligentes. La primera es tratarlos como una curiosidad de criptomonedas sin aplicación empresarial. La segunda, más costosa, es creer que un programa en una cadena de bloques reemplaza a un contrato y ahorra al abogado. Ninguna resiste el contacto con un despliegue real: un smart contract es una pieza de ingeniería que ejecuta lo que un acuerdo dice, y el acuerdo sigue naciendo, interpretándose y discutiéndose fuera de la cadena. Este artículo recorre las dos caras —cómo funciona por dentro y cómo lo trata el ordenamiento peruano— y termina en tres implementaciones que hoy son viables en el Perú.
Qué es un contrato inteligente y qué no es
Un contrato inteligente es un programa determinista desplegado en un registro distribuido, que ejecuta una consecuencia cuando se verifica una condición prevista en su código. Su rasgo definitorio no es la automatización —eso lo hace cualquier script— sino la imposibilidad de impedir la ejecución: una vez desplegado en una red pública, ni las partes ni el desarrollador pueden detener la transferencia si se cumple la condición programada. Esa característica es exactamente la que aporta valor y la que genera todos los problemas jurídicos interesantes.
Lo que no es: un contrato en sentido jurídico. El artículo 1351 del Código Civil define el contrato como el acuerdo de dos o más partes para crear, regular, modificar o extinguir una relación jurídica patrimonial. Ese acuerdo es un fenómeno de voluntades, no de bytecode. El código no interpreta según la común intención de las partes, no aplica la buena fe del artículo 1362, no admite la excepción de incumplimiento del artículo 1426, no conoce la excesiva onerosidad de la prestación del artículo 1440 ni el caso fortuito del artículo 1315. Es el modo de ejecutar un acuerdo, no el acuerdo.
La consecuencia práctica es que casi todo despliegue serio tiene dos capas: un contrato marco escrito en lenguaje natural, que fija la relación jurídica, y uno o varios contratos inteligentes que ejecutan las prestaciones susceptibles de automatización. A esa figura se la llama a veces contrato híbrido, y es la única que resuelve qué ocurre cuando el código y el acuerdo divergen.
Cómo funciona por dentro
La pila que sostiene un contrato desplegado tiene cinco capas. Conviene conocerlas porque cada una traslada un riesgo distinto al contrato marco.
Un escrow mínimo ilustra la mecánica y sus límites. El siguiente contrato retiene un pago y lo libera cuando un tercero designado —el oráculo o árbitro— confirma la entrega:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
contract EscrowEntrega {
address public comprador;
address public vendedor;
address public verificador; // oráculo o árbitro designado
uint256 public plazoLimite; // marca de tiempo de vencimiento
bool public liberado;
constructor(address _vendedor, address _verificador, uint256 _dias) payable {
comprador = msg.sender;
vendedor = _vendedor;
verificador = _verificador;
plazoLimite = block.timestamp + (_dias * 1 days);
}
// El verificador confirma la entrega y el precio se libera al vendedor.
function confirmarEntrega() external {
require(msg.sender == verificador, "no autorizado");
require(!liberado, "ya liberado");
liberado = true;
payable(vendedor).transfer(address(this).balance);
}
// Vencido el plazo sin confirmacion, el comprador recupera el deposito.
function reembolsar() external {
require(block.timestamp > plazoLimite, "aun vigente");
require(!liberado, "ya liberado");
payable(comprador).transfer(address(this).balance);
}
}Veinticinco líneas bastan para automatizar una obligación de pago condicional. Lo que esas líneas no dicen es igual de importante: quién responde si el verificador se equivoca, qué ocurre si la entrega fue parcial o defectuosa, qué ley rige la relación, ante quién se reclama y qué pasa si el comprador pierde su clave privada. Todo eso vive en el contrato marco o no vive en ninguna parte.
El problema del oráculo
Es el punto crítico de cualquier implementación y, curiosamente, el menos tecnológico. Un contrato inteligente solo puede reaccionar a datos que estén en la cadena; cualquier hecho del mundo físico —una entrega, una temperatura, un tipo de cambio, la firma de un acta— debe ser introducido por un tercero.
Eso tiene tres consecuencias. Primera: la confianza no desaparece, se desplaza. Se deja de confiar en la contraparte para confiar en el oráculo. Segunda: el oráculo es, jurídicamente, un tercero cuya actuación determina el nacimiento o la exigibilidad de una obligación, de modo que su designación, su remuneración, su responsabilidad y su sustitución deben estar pactadas. Tercera: si el oráculo se equivoca o es manipulado, el contrato ejecutará una consecuencia sin que la condición se haya cumplido, y la reversión ya no es técnica sino judicial o arbitral.
La mitigación estándar combina fuentes redundantes —varias fuentes independientes cuyo valor se agrega—, un periodo de impugnación antes de que la ejecución sea definitiva, y un mecanismo de pausa activable por multifirma. Cada una de esas piezas técnicas necesita su cláusula correspondiente.
El puente al derecho peruano
El Perú no tiene una ley de contratos inteligentes. Eso no significa que estén en un vacío: significa que se les aplican las reglas generales. Cuatro pilares sostienen ese puente.
Desde la Ley N.° 27291 la manifestación de voluntad puede darse por medios electrónicos. El acuerdo se forma fuera de la cadena; el código lo ejecuta.
Una clave privada firma criptográficamente, pero no equivale a firma digital con valor legal salvo que provenga de la infraestructura oficial acreditada.
La cadena acredita qué se ejecutó y cuándo, con altísima fiabilidad. No acredita quién controlaba la dirección ni qué quisieron pactar las partes.
La ejecución automática no sustituye la tutela jurisdiccional. Hay que pactar ley aplicable y mecanismo de solución de controversias.
Voluntad y formación del contrato
La Ley N.° 27291, de junio de 2000, modificó el Código Civil precisamente para admitir la contratación electrónica. El artículo 141 admite la manifestación de voluntad expresa o tácita, y precisa que es expresa cuando se realiza en forma oral, escrita, a través de cualquier medio directo, manual, mecánico, electrónico u otro análogo. El artículo 141-A añade que, cuando la ley establezca la necesidad de una formalidad expresa o requiera de firma, esta puede ser generada o comunicada a través de medios electrónicos, ópticos o análogos.
De ahí se sigue algo importante: un acuerdo cuya oferta y aceptación se expresan mediante transacciones firmadas en una cadena de bloques es, en principio, un contrato válido. El problema no es la validez, sino la prueba de quién manifestó esa voluntad y con qué contenido. Para la formación entre ausentes siguen rigiendo los artículos 1373 y 1374: el contrato queda perfeccionado cuando la aceptación es conocida por el oferente, y se presume conocida cuando llega a su dirección, salvo prueba de imposibilidad sin culpa.
Forma y firma: el punto donde más gente se confunde
Firmar una transacción con una clave privada es una operación criptográfica robusta, pero no es lo mismo que la firma digital regulada por la Ley N.° 27269, Ley de Firmas y Certificados Digitales, y su reglamento. Aquella ley construye un régimen en el que la firma digital genera los efectos de una firma manuscrita cuando se emite dentro de la Infraestructura Oficial de Firma Electrónica, es decir, con un certificado emitido por una entidad de certificación acreditada ante el INDECOPI como autoridad administrativa competente.
Una billetera de autocustodia no cumple ese requisito. Su firma vale como firma electrónica —cualquier símbolo basado en medios electrónicos utilizado para identificar y vincular al firmante— y, por tanto, como principio de prueba sujeto a valoración, pero no goza de la presunción reforzada. La consecuencia de diseño es directa: cuando el acuerdo requiera certeza sobre la identidad de las partes, la vinculación entre la persona y la dirección debe establecerse por otro medio, típicamente el contrato marco firmado digitalmente dentro de la infraestructura oficial, donde se declara qué dirección corresponde a cada parte.
Prueba: qué acredita realmente la cadena
El registro distribuido es una prueba excelente de integridad y de secuencia temporal: acredita que una transacción con determinado contenido fue incluida en un bloque en un momento dado y que no ha sido alterada. Eso resuelve las discusiones sobre qué ocurrió. No resuelve, en cambio, las dos preguntas que suelen decidir un litigio: quién controlaba la clave que firmó y cuál era la causa del negocio. La primera se cubre con la vinculación identidad-dirección del contrato marco; la segunda, con la documentación del acuerdo.
Ejecución, autotutela y foro
La ejecución automática se parece a una autotutela: el acreedor obtiene satisfacción sin recurrir al juez. Nuestro sistema admite formas limitadas de autotutela pactada, pero no convierte al código en un título de ejecución ni excluye la revisión jurisdiccional. Si la ejecución fue indebida —porque el oráculo falló, porque hubo error o porque el contrato se resolvió antes—, el remedio es la repetición de lo indebidamente pagado o la indemnización, y para eso hace falta un foro.
Por eso el contrato marco debe pactar ley aplicable y mecanismo de solución de controversias. El arbitraje regulado por el Decreto Legislativo N.° 1071 suele ser la vía más razonable: permite designar árbitros con conocimiento técnico, fijar plazos breves y acordar medidas cautelares sobre las claves o los fondos. La cláusula debe prever, además, quién ejecuta materialmente una orden que obliga a revertir algo que la cadena ya consumó: normalmente, una obligación de hacer a cargo de la parte beneficiada, respaldada por una garantía.
Cuatro fricciones con el derecho peruano
Protección de datos personales
Es la fricción más seria y la peor entendida. Si una cadena de bloques pública almacena datos que permitan identificar a una persona, ese registro es un banco de datos personales sujeto a la Ley N.° 29733. Y la inmutabilidad choca de frente con el derecho de supresión o cancelación del artículo 20, con el plazo de conservación limitado y con la obligación de suprimir los datos cuando dejan de ser necesarios, hoy tipificada como infracción leve en el artículo 132.3 del Decreto Supremo N.° 016-2024-JUS.
La solución de diseño es conocida y hay que aplicarla desde el inicio: no poner datos personales en la cadena. Se almacena fuera el dato y dentro solo su huella criptográfica, de modo que la cadena permita verificar la integridad sin contener la información. Borrado el dato de origen, la huella queda inutilizable. Conviene además evaluar si el resultado califica como anonimización o como seudonimización, porque el reglamento regula el procedimiento de disociación en su artículo 41 y la diferencia decide si la norma sigue aplicándose. Desarrollé el régimen de seguridad aplicable en la Directiva de Seguridad para el tratamiento de datos personales.
Protección al consumidor
Cuando el contrato inteligente se ofrece a consumidores a través de una interfaz web, el Código de Protección y Defensa del Consumidor, Ley N.° 29571, se aplica íntegro: deber de información veraz y suficiente, control de cláusulas abusivas en la contratación por adhesión, y responsabilidad del proveedor por la idoneidad del servicio. Dos consecuencias concretas. Primera: una cláusula que excluya toda responsabilidad por fallos del código sería un candidato natural a cláusula abusiva. Segunda: la existencia de una función de actualización controlada por el proveedor —el patrón de proxy— reintroduce la asimetría que la inmutabilidad prometía eliminar, y debe declararse al consumidor con la misma claridad con que se declara una modificación unilateral de condiciones.
Prevención de lavado de activos
Aquí sí hay norma expresa y reciente. El Decreto Supremo N.° 006-2023-JUS, publicado el 27 de julio de 2023, incorporó a los Proveedores de Servicios de Activos Virtuales como sujetos obligados a informar a la Unidad de Inteligencia Financiera del Perú. Se consideran tales quienes, como negocio, realizan intercambio entre activos virtuales y moneda fiduciaria, intercambio entre activos virtuales, transferencia de activos virtuales, custodia o administración de activos virtuales o de instrumentos que permitan su control, y participación o prestación de servicios financieros relacionados con la oferta o venta de un activo virtual.
La Resolución SBS N.° 02648-2024, publicada el 1 de agosto de 2024, aprobó la norma de prevención del lavado de activos y del financiamiento del terrorismo aplicable a esos proveedores, con la obligación de implementar un sistema de prevención con enfoque basado en riesgos, debida diligencia del cliente y reporte de operaciones sospechosas. Quien diseñe una plataforma con custodia de activos, intercambio o transferencia debe asumir que está dentro de ese perímetro; quien despliegue un contrato inteligente que solo automatiza una relación entre dos empresas identificadas, no.
Tributación
No existe un régimen tributario específico para operaciones con activos virtuales ni para contratos inteligentes. Se aplican las reglas generales: la renta se determina según su fuente y su categoría, y la habitualidad de la enajenación es determinante para el tratamiento aplicable a personas naturales. Es un terreno donde conviene una consulta específica antes de estructurar una operación relevante, precisamente porque la ausencia de norma expresa aumenta el riesgo de contingencia.
Riesgo técnico y su traducción jurídica
La utilidad de mirar el problema con las dos lentes está en que cada fallo técnico tiene una consecuencia jurídica identificable, y anticiparla permite escribir la cláusula que la administra.
Casuística peruana: qué hay y qué no hay
Conviene ser preciso, porque en este terreno abunda el entusiasmo y escasea el dato verificable. En el Perú no existe un registro público de contratos inteligentes desplegados, ni una ley que los regule, ni jurisprudencia publicada que los haya interpretado. Lo que sí existe es un conjunto de hechos comprobables que delimitan el terreno.
- No hay marco legal específico y el que se propuso sigue detenido. El Proyecto de Ley N.° 1042/2021-CR, orientado a regular la comercialización de criptoactivos y a los proveedores de servicios de activos virtuales, fue devuelto a comisión en marzo de 2025 y no ha sido aprobado por el Pleno. Lo aplicable, por tanto, son las reglas generales del Código Civil y la normativa sectorial vigente.
- Sí hay regulación del perímetro. Desde 2023 los proveedores de servicios de activos virtuales son sujetos obligados ante la UIF-Perú, y desde 2024 cuentan con una norma de prevención propia emitida por la SBS. Es el único bloque regulatorio peruano que menciona expresamente esta tecnología.
- El experimento institucional más avanzado no usa contratos inteligentes. El Banco Central de Reserva del Perú desarrolla desde 2024 su Piloto de Innovación con Dinero Digital junto con Bitel, orientado a zonas de baja penetración de pagos electrónicos, y en 2026 amplió el periodo de evaluación. Es dinero digital emitido por el banco central distribuido por una billetera, no una aplicación descentralizada; pero define el terreno sobre el que cualquier automatización de pagos en el país deberá apoyarse.
- La adopción documentada se concentra en trazabilidad. La producción académica y profesional peruana sobre cadena de bloques se ha volcado a la trazabilidad agroexportadora —café, cacao, espárragos— por presión de los compradores europeos y de la normativa de sostenibilidad. Es adopción de registro compartido más que de contratos autoejecutables, pero es donde primero aparecerán las liquidaciones automáticas contra hitos verificados.
- Falta la pieza registral. Nada permite hoy inscribir un contrato inteligente ni sustituir por él la escritura pública donde la ley la exige. La transferencia de inmuebles, la constitución de garantías reales y los actos societarios inscribibles siguen requiriendo forma notarial e inscripción registral, y ninguna norma habilita a la SUNARP a recibir un despliegue en cadena como título.
Tres implementaciones viables hoy
1. Liberación automática de pagos B2B contra hito verificado
Problema. Un proveedor entrega mercadería y espera treinta o sesenta días el pago, con costo financiero y riesgo de disputa sobre la fecha de entrega.
Diseño. Red permisionada entre comprador, proveedor y entidad financiera. El oráculo es el sistema de gestión del comprador: cuando el área de recepción registra la conformidad, firma la transacción que confirma el hito. El contrato inteligente libera el pago o, mejor, emite la orden de pago que el banco ejecuta. La factura negociable inscrita en el registro centralizado a cargo de CAVALI sigue siendo el título valor con mérito ejecutivo; la cadena aporta certeza sobre el hito y trazabilidad, no sustituye el título.
Cláusulas imprescindibles. Designación del oráculo y consecuencia de su fallo; efecto de la conformidad automática respecto de la recepción con reserva; plazo de impugnación de la conformidad; y previsión expresa de que la ejecución en cadena no implica renuncia a las acciones por vicios ocultos.
2. Seguro paramétrico agrícola
Problema. El seguro agrícola tradicional exige peritaje en campo, lo que encarece y demora la indemnización en cultivos pequeños y dispersos.
Diseño. La póliza define un índice objetivo —milímetros de lluvia acumulados en una estación de referencia durante una ventana— y el contrato inteligente paga automáticamente cuando el índice cruza el umbral. El oráculo son los registros meteorológicos oficiales, agregados por al menos dos fuentes y publicados con retardo fijo. La ventaja es que elimina el peritaje y la discusión sobre el siniestro; la limitación, que la base es el índice y no el daño real, lo que debe informarse con claridad al asegurado.
Cláusulas imprescindibles. Definición del índice y de la estación de referencia, y qué ocurre si deja de operar; tratamiento de la divergencia entre fuentes; carácter paramétrico de la cobertura declarado en términos comprensibles para efectos del deber de información; y sujeción del producto a la regulación de seguros aplicable, que no desaparece por estar automatizado.
3. Escrow para operaciones entre desconocidos
Problema. Compraventa de bienes muebles registrables o contratación de servicios entre partes sin relación previa: quien paga primero asume el riesgo.
Diseño. El comprador deposita el precio en un contrato de depósito en garantía; el vendedor entrega; un verificador designado —notario, empresa de verificación o el propio comprador con plazo de silencio positivo— confirma, y el contrato libera. Si vence el plazo sin confirmación, reembolsa. Es el ejemplo de código mostrado antes, con dos añadidos indispensables: multifirma para la pausa de emergencia y una cláusula arbitral que permita revertir por vía de obligación de hacer.
Cláusulas imprescindibles. Vinculación entre cada parte y su dirección en cadena, firmada digitalmente dentro de la infraestructura oficial; designación y sustitución del verificador; efecto del silencio; y sometimiento a arbitraje con sede y ley peruanas.
Lista de verificación antes de desplegar
Conclusión
El contrato inteligente resuelve un problema muy concreto y lo resuelve bien: ejecutar sin fricción una obligación objetiva cuando un hecho verificable ocurre, entre partes que no confían entre sí. Fuera de ese perímetro —cuando la prestación exige valoración, cuando la ley impone forma notarial, cuando hay datos personales de por medio o cuando el volumen no paga la auditoría del código— la tecnología añade complejidad sin añadir valor.
Para el Perú, la conclusión práctica es que no hace falta esperar una ley para usarlos. Hace falta escribir el contrato marco que la ausencia de ley vuelve imprescindible: identificar a las partes con firma digital válida, designar y responsabilizar al oráculo, pactar el foro, declarar la facultad de actualización si existe y decidir qué prevalece cuando el texto y el código no dicen lo mismo. El código ejecuta; el contrato sigue siendo el que decide.
¿Te resultó útil este análisis o buscas asesoría en la materia?
Trabajo en la intersección de la ingeniería y el derecho: revisión de arquitectura y código de contratos inteligentes, diseño del contrato marco, cláusulas de oráculo y de solución de controversias, y evaluación de cumplimiento en protección de datos y prevención de lavado. Conversemos sobre tu caso.
Fuentes
- Código Civil peruano, artículos 141 y 141-A, modificados por la Ley N.° 27291, que autoriza el uso de medios electrónicos para la manifestación de voluntad y la utilización de la firma electrónica; artículos 1351, 1362, 1373 y 1374.
- Ley N.° 27269, Ley de Firmas y Certificados Digitales, y su reglamento, que regulan la Infraestructura Oficial de Firma Electrónica.
- Ley N.° 29733, Ley de Protección de Datos Personales, y su reglamento aprobado por Decreto Supremo N.° 016-2024-JUS (artículos 41 y 132.3, entre otros).
- Ley N.° 29571, Código de Protección y Defensa del Consumidor.
- Decreto Legislativo N.° 1071, que norma el arbitraje.
- Decreto Supremo N.° 006-2023-JUS, que incorpora a los Proveedores de Servicios de Activos Virtuales como sujetos obligados a informar a la UIF-Perú (publicado el 27 de julio de 2023).
- Resolución SBS N.° 02648-2024, que aprueba la norma para la prevención del lavado de activos y del financiamiento del terrorismo aplicable a los Proveedores de Servicios de Activos Virtuales bajo supervisión de la UIF-Perú (publicada el 1 de agosto de 2024). Texto en El Peruano.
- Proyecto de Ley N.° 1042/2021-CR, sobre el marco de comercialización de criptoactivos, devuelto a comisión en marzo de 2025 y pendiente de debate en el Pleno.
- Banco Central de Reserva del Perú, Pilotos de Innovación de Dinero Digital.
- CAVALI, Registro Centralizado de Facturas Negociables.
- Imagen de cabecera: «Code on computer monitor», de Markus Spiske, CC0 1.0, vía Wikimedia Commons.
Este artículo tiene finalidad informativa y no constituye asesoría legal ni recomendación de inversión. La normativa citada corresponde al estado vigente a la fecha de publicación; conviene verificar modificaciones posteriores antes de tomar decisiones.
