Smartcontracts Libro PDF

Carlos Tur Faúndez
La cadena de bloques y los smart contracts se hallan hoy en boca de todos y,

en nuestra opinión, son muchos los motivos para ello por cuanto constituyen,
ciertamente, una tecnología disruptiva y con un extraordinario potencial. Sin
embargo, se hace necesario conocer en profundidad sus fundamentos tecnoló-
gicos, su verdadero alcance y su posible integración en el mundo jurídico, para
lo que es preciso poner los pies en el suelo y aceptar de una vez por todas que,
en este asunto, el Derecho y la Informática están condenados a entenderse.
Los smart contracts son “código y nada más que código”, no obstante lo cual,
la mayoría de ellos son creados con la finalidad de ejecutar automáticamente
los acuerdos alcanzados por las partes. Para ello, se requiere una nueva
categoría, el contrato legal inteligente, que existirá única y exclusivamente en
el instante en que las partes acepten los términos y condiciones previamente
acordados.
El contrato legal inteligente se construye sobre la estructura de un smart contract
subyacente, pero su alcance va mucho más allá, por lo que es imprescindible el
análisis de su formación y de los elementos que imperativamente lo componen.
SMART CONTRACTS
SMART CONTRACTS. Análisis jurídico

El incumplimiento de los requisitos legales conducirá, inevitablemente, a
los smart contracts ante los órganos jurisdiccionales, e irrogará perjuicios
absolutamente innecesarios. Análisis jurídico
Carlos Tur Fáundez, abogado con una dilatada trayectoria profesional, está
especializado en Litigación, Derecho Civil y Mercantil, Protección de Datos Carlos Tur Faúndez
y Privacidad, Sociedad de la Información y Comercio Electrónico. Tiene un
Abogado
Máster en Abogacía Digital y Nuevas Tecnologías por la Universidad de Sa- Profesor Asociado en la Universidad de las Islas Baleares
lamanca, es Profesor Asociado de la Universidad de las Islas Baleares desde
hace 18 años, actualmente en el área de conocimiento de Derecho Procesal.
e incluye libro electrónico
este ejemplar pertenece a: jpvalencia2012@gmail.com - 2019-03-18 20:36:21

COLECCIÓN DE DERECHO
DE LAS NUEVAS TECNOLOGÍAS
TÍTULOS PUBLICADOS
La firma electrónica, Jesús Ignacio Fernández Domingo (2006).
La interconexión de redes de telecomunicaciones, Olga Lucía Alfonso
Velásquez (2006).
Sociedad de la información en Europa, Luis M. González de la Garza
(2008).
Agricultura transgénica y medio ambiente. Perspectiva legal, Ramón He-
rrera Campos y María José Cazorla (Coord.) (2009).
(2010).
E-Learning y Derecho, Pablo Gallego Rodríguez
El contrato de servicio telefónico, Olga Lucía
Alfonso Velásquez
(2010).
La protección judicial de los derechos en Internet en la jurisprudencia
europea, David Ordóñez Solís (2014).
Casos y cuestiones sobre Derecho Civil. Materiales para el estudio con-
forme al Plan Bolonia y ante las nuevas tecnologías, Guillermo
Cerdeira Bravo de Mansilla (Dir.) y Mª Carmen Fernández de
Villavicencio Álvarez-Ossorio (Coord.) (2014).
Casos y cuestiones sobre Derecho Internacional Privado, nacionalidad y
extranjería. Materiales para el estudio conforme al Plan Bolonia y ante
las nuevas tecnologías, Fernando Moreno Mozo (Coord.), María
Ascensión Martín Huertas y Ana Moreno Sánchez Moraleda
(2014).
El documento jurídico y su electronificación, José Antonio Vega Vega
(2014).
Derecho al olvido en Internet: el nuevo paradigma de la privacidad en la
era digital, María Álvarez Caro (2015).
Protección de datos personales e innovación: ¿(in)compatibles?, Miguel
Recio Gayo (2016).
Contratación electrónica y protección de los consumidores –una visión
panorámica–, Leonardo B. Pérez Gallardo (Coord.) (2017).
Smart Contracts. Análisis jurídico, Carlos Tur Faúndez (2018).

COLECCIÓN DE DERECHO
DE LAS NUEVAS TECNOLOGÍAS
Directores:
Guillermo Cerdeira Bravo de Mansilla
Catedrático de Derecho civil
de la Universidad de Sevilla
Moisés Barrio Andrés

Letrado del Consejo de Estado
Doctor en Derecho. Abogado
SMART CONTRACTS
Análisis jurídico
Carlos Tur Faúndez
Abogado
Profesor Asociado en la Universidad de las Islas Baleares
Madrid, 2018

© Carlos Tur Faúndez
© Editorial Reus, S. A., para la presente edición
C/ Rafael Calvo, 18, 2º C – 28010 Madrid
Tfno: (34) 91 521 36 19 – (34) 91 522 30 54
Fax: (34) 91 445 11 26
reus@editorialreus.es
www.editorialreus.es
1.ª edición REUS, S.A. (2018)

ISBN: 978-84-290-2027-4
Depósito Legal: M 3136-2018
Diseño de portada: María Lapor
Impreso en España
Printed in Spain
Imprime: ULZAMA Digital
Ni Editorial Reus ni los Directores de Colección de ésta responden del

contenido de los textos impresos, cuya originalidad garantizan los au-
tores de los mismos. Cualquier forma de reproducción, distribución,
comunicación pública o transformación de esta obra sólo puede ser
realizada con la autorización expresa de Editorial Reus, salvo excepción
prevista por la ley.
Fotocopiar o reproducir ilegalmente la presente obra es un delito casti-
gado con cárcel en el vigente Código penal español.

A mi familia, siempre tan cerca…

ABREVIATURAS EMPLEADAS....................... 11
PRÓLOGO............................................................ 15
INTRODUCCIÓN................................................ 21
SECCIÓN I LA TECNOLOGÍA......................... 29
1. “BITCOIN”. EL ORIGEN.......................................... 29
2. LA CADENA DE BLOQUES O BLOCKCHAIN... 33
2.1. CONCEPTO...................................................... 33
2.2. FUNCIONAMIENTO...................................... 34
2.3. CLASIFICACIÓN DE LAS CADENAS DE
BLOQUES.......................................................... 38
2.4. ETHEREUM EN PARTICULAR.................... 41
2.5. OTRAS TECNOLOGÍAS DE RED
DISTRIBUIDA................................................... 44
3. LA CADENA DE BLOQUES COMO MECANISMO
DE ALMACENAMIENTO DE ARCHIVOS........ 45
SECCIÓN II - EL DERECHO............................ 51
1.
L OS SMART CONTRACTS: CONCEPTO Y
TRASCENDENCIA JURÍDICA.............................. 51
1.1. CONCEPTO...................................................... 51
7
Carlos Tur Faúndez
1.2. TRASCENDENCIA JURÍDICA DE LOS

SMART CONTRACTS.................................... 56
2. LOS CONTRATOS LEGALES INTELIGENTES.... 59
3. LOS CONTRATOS LEGALES INTELIGENTES A
LA LUZ DE LOS PRINCIPIOS Y ELEMENTOS
DEL DERECHO DE LA CONTRATACIÓN
ELECTRÓNICA....................................................... 63
4.
L A FORMACIÓN DE LOS CONTRATOS
LEGALES INTELIGENTES.................................... 71
4.1. OBLIGACIONES DE INFORMACIÓN
ANTERIORES Y POSTERIORES A LA
CELEBRACIÓN DEL CONTRATO............... 71
4.2. MOMENTO DE PERFECCIÓN DEL
CONTRATO...................................................... 73
4.3. EL LUGAR DE LA PERFECCIÓN DEL
CONTRATO...................................................... 76
4.4. CONTRATOS LEGALES INTELIGENTES
CELEBRADOS ENTRE UN EMPRESARIO
Y UN CONSUMIDOR. EL DERECHO DE
DESISTIMIENTO EN LOS CONTRATOS
LEGALES INTELIGENTES............................ 77
4.5. ELEMENTOS DE LOS CONTRATOS
LEGALES INTELIGENTES............................ 79
4.5.1. E L CONSENTIMIENTO
“PRECONSTITUIDO” EN
LOS CONTRATOS LEGALES
INTELIGENTES. EL ERROR VICIO... 80
4.5.2.
EL OBJETO Y LA CAUSA EN
LOS CONTRATOS LEGALES
INTELIGENTES..................................... 84
8
Smart Contracts
4.5.3. LA FORMA EN LOS CONTRATOS

LEGALES INTELIGENTES.................. 87
5.
VALOR PROBATORIO DE LA CADENA
DE BLOQUES. ACREDITACIÓN DE LOS
CONTRATOS LEGALES INTELIGENTES.......... 95
6. EJECUCIÓN DE LOS CONTRATOS LEGALES
INTELIGENTES. CUMPLIMIENTO..................... 107
7.
LAS OBLIGACIONES CONDICIONALES EN
LOS CONTRATOS LEGALES INTELIGENTES.
LOS ORÁCULOS (ORACLES).............................. 111
8.
E NTREGA O PUESTA A DISPOSICIÓN.
“INTERNET DE LAS COSAS” (IoT).................... 115
9. LAS PRESTACIONES PECUNIARIAS EN LOS
CONTRATOS LEGALES INTELIGENTES.......... 120
CONCLUSIONES................................................. 139
ÍNDICE BIBLIOGRÁFICO................................ 147
ANEXO 1 - UN CONTRATO LEGAL

INTELIGENTE PA R A J U R I S TA S
INTERESADOS EN LA PROGRAMACIÓN
INFORMÁTICA................................................... 165
1.Introducción ............................................................... 165
2. La estructura............................................................... 168
3. Procedimiento para la formación y ejecución del
172
4. 176
5.Descripción detallada de cada una de las líneas
180
9
ABREVIATURAS EMPLEADAS
API: Application Programming Interface

(interfaz de programación de
aplicaciones)
APP: Application (aplicación)
DEVCON: Developers conference (conferencia de
desarrolladores/programadores)
B2B: Business to business (de negocio a
negocio, entre empresarios)
B2C: Business to consumer (de negocio/
empresario a consumidor)
BOE: Boletín Oficial del Estado
B-SC-B: Business-smart contract-business
(empresario-smart contract-
empresario)
B-SC-C: Business-smart contract-consumer
(empresario-smart contract-
consumidor)
BTC: Bitcoin
CC: Código civil
C.co.: Código de Comercio
11
Carlos Tur Faúndez
CENDOJ: Centro de documentación judicial

CEO: Chief Executive Officer (director
general)
CNUDMI: Comisión de Naciones Unidas para
el Derecho Mercantil Internacional
DM: Data message (mensaje de datos)
DNIe: Documento nacional de identidad
electrónico
EDI: Electronic data interchange
(intercambio electrónico de datos)
EOA: External Owned Accounts (cuentas de
titulares externos)
ETH: Ether
EVM: Ethereum Virtual Machine (máquina
virtual de Ethereum)
Inc.: Incorporation (corporación/sociedad)
IoT: Internet of things (Internet de las
Cosas)
ISO: International Organization for
Standardization (organización
internacional para la normalización)
KYC: Know your customer (conozca su
cliente)
LCGC: Ley sobre condiciones generales de
la contratación
LEC: Ley de Enjuiciamiento Civil
LOPD: Ley orgánica de protección de datos
LSSICE: Ley de servicios de la sociedad
de la información y del comercio
electrónico
Msg: Message (mensaje)
12
Smart Contracts
MOOC: Massive Open Online Course (Curso

online masivo y abierto)
P2P: Peer to peer (de igual a igual)
Pág.: Página
Pdf: Portable document format (formato de
documento portátil)
RAE: Real Academia Española
RFID: Radio Frecuency Identification
(identificación por radiofrecuencia)
ss.: siguientes
STS: Sentencia del Tribunal Supremo
TS: Tribunal Supremo
TRLGDCU: Texto refundido de la ley general
para la defensa de los consumidores
y usuarios
TSA: Time Stamp Authority (autoridad de
sellado de tiempo)
Uint: Unsigned integer (entero sin signo)
UNCITRAL: United Nations Commission on
International Trade Law (Comisión de
las Naciones Unidas para el Derecho
Mercantil Internacional)
URL: Uniform Resource Locator (localizador
uniforme de recursos)
V.g.: Verbigracia
Vid.: Videre (véase)
13
PRÓLOGO
El hecho de haber empezado a estudiar la

contratación electrónica a principios de los años
noventa me concede, al menos, la virtud de la
perspectiva de un fenómeno que no ha cesado de
crecer y desarrollarse de manera espectacular.
Si descartamos el fax como verdadero medio de
comunicación por vía electrónica, podemos decir
que todo empezó con el correo electrónico, una
herramienta disponible con carácter general en los
años ochenta. Como tal, permite la comunicación
asíncrona de dos partes que pueden transmitirse
mediante mensajes de correo electrónico cualquiera
de las declaraciones que forman parte del proceso de
formación, ejecución y terminación de un contrato.
Dilaciones temporales y errores (de transmisión
o en la introducción “manual” de los datos), su
contenido no automatizable (sólo y progresivamente
por el emisor) y la falta de acreditación fehaciente
de las identidades de las partes, el contenido de
15
Carlos Tur Faúndez
los mensajes y su recepción por el destinatario

constituían sus principales limitaciones como
herramienta a emplear en la contratación masiva
que la economía iba imponiendo.
El primer intento reseñable de superar las limi-
taciones del correo electrónico es el sistema EDI
(Electronic Data Interchange), que emerge a media-
dos de los ochenta. El sistema se basa en la adop-
ción de una “estructura gramatical” estandarizada
para breves mensajes de texto (las comunicaciones
de la época no disfrutaban del ancho de banda de
las actuales), que, al estar estructurados, podían ser
tratados automáticamente tanto por el emisor como
por el receptor. Los estándares son establecidos por
instituciones externas (básicamente, UN/EDIFACT
y ANSI ASC X12) y ambos sistemas informáticos,
los del emisor y los del receptor, deben ajustarse a
la “gramática” así estandarizada de los mensajes.
Por ello y por ser un sistema basado en mensajes
repetitivos y poco sofisticados, su campo de actua-
ción se ha restringido a las relaciones B2B, básica-
mente en entornos de relaciones de suministro.
Acto seguido, con la celeridad propia del mundo
tecnológico (Amazon se abre en 1995), se suceden
dos revoluciones, más que meras evoluciones: la
de la contratación en webs o comercio electrónico
y la de los terceros de confianza.
La contratación web extiende la contratación
electrónica al territorio B2C, es decir, a los contratos
entre empresas y consumidores. Permite, además,
16
Smart Contracts
utilizar todas las ventajas visuales y textuales de

la web para presentar los productos o servicios
al consumidor y guiar al usuario en el proceso
de compra; y, de otro lado, permite tratar
electrónicamente todos los datos proporcionados
y acciones realizadas por el consumidor, de
manera que los procesos que siguen al pedido
se automatizan en los sistemas informáticos del
proveedor (y en los de los terceros, como los
transportistas, que participan en la prestación del
producto o servicio).
Los terceros de confianza se han erigido en
intermediarios esenciales en los contratos y las
notificaciones en un doble plano. En primer lugar,
constituyen y diseñan la plataforma tecnológica (y su
marco jurídico) en la que se produce el intercambio
de declaraciones contractuales entre las partes
(que pueden ser también particulares, territorio,
entonces, C2C): centrales de reservas, marketplaces
(como EBay) o los recientes intermediarios de la
llamada economía colaborativa (como Airbnb o
Uber). En segundo lugar, otros terceros de confianza
se han ido especializando en facilitar, a instancia
de parte, prueba del contenido y recepción de los
distintos mensajes que pueden producirse en la
celebración de un contrato o a lo largo de su vida.
La normativa de que disponemos actualmente
está dirigida a regular la contratación electrónica
resultante de las dos revoluciones aludidas, pero,
pese a la neutralidad tecnológica pretendida,
17
Carlos Tur Faúndez
puede resultar inapropiada, en algunos aspectos,

para regular las relaciones contractuales basadas
en smart contracts. Éstas, como explica con detalle
este libro, se caracterizan por: a) la adopción de
una tecnología distribuida, al modo P2P, tanto a
efectos de fehaciencia (con aparente sustitución
de los terceros de confianza “clásicos”) como de
funcionamiento del contrato (medios de pago
incluidos); b) la autoejecución del contrato de
acuerdo con la programación preestablecida (de
forma negociada o no); y c) la aparición de nuevos
terceros, los “oráculos”, que permiten introducir
hechos incontestados que actúan como condiciones
del contrato.
La autonomía de la voluntad, que
(prácticamente) todo lo puede en el campo B2B,
autoriza la utilización de esta tecnología, sin
aparentes problemas, en las relaciones entre
empresarios. No puede afirmarse lo mismo,
en cambio, en el campo B2C, pues es necesario
proveer al consumidor de un nivel equivalente de
protección al que dispone en el “mundo físico”
o cuando emplea las tecnologías “primitivas”.
En una primera aproximación, dos aspectos
preocupan primordialmente. En primer lugar, cabe
preguntarse, sobre todo en las fases más tempranas
del desarrollo de la tecnología smart contracts,
si y cómo se puede informar suficientemente
al consumidor de las complejidades de estos
contratos autoejecutables y de algunos de sus
18
Smart Contracts
riesgos propios, entre los que destaca el que es

intrínseco a la criptomoneda que se emplea como
medio de pago. En segundo lugar, superados
o amortiguados en beneficio del consumidor la
sumariedad de los procedimientos ejecutivos o
la abstracción que permite a la entidad financiera
desentenderse, gracias a la relatividad contractual,
de los problemas surgidos en el contrato cuyo precio
ha financiado, uno se pregunta si la autoejecución
del contrato basado en smart contracts no coloca
al consumidor de nuevo en la débil posición de
quien se ve, de momento, ejecutado, sin perjuicio
de que pueda, en un momento posterior, apelar al
“contrato real”, que, como explica el autor, corre
paralelo al recogido en el código smart contract pero
sin llegar a confundirse con él.
Este libro presenta varias virtudes que lo hacen
muy útil para afrontar estos y otros problemas de
esta nueva forma de contratación.
Es, en primer lugar, un libro didáctico, en el que
el autor, pese a la dificultad propia de toda materia
“tecnojurídica”, acierta a encontrar el punto exacto
de explicación de sus componentes tecnológicos y
jurídicos.
En segundo lugar, Carlos Tur es abogado con
un largo recorrido profesional, lo que le sirve
para atacar prestamente el núcleo práctico de
los problemas, sin enredarse, como tanto ocurre
entre académicos, en divagaciones no demasiado
significantes sobre la naturaleza de las cosas.
19
Carlos Tur Faúndez
Finalmente, el libro nos ofrece, a lo largo de

sus apartados y, sobre todo, en un apéndice final,
código comentado sobre el funcionamiento de los
smart contracts. Con él, uno confirma, parafraseando
a LESSIG, que el código no solamente es ley, en el
sentido de norma con eficacia social reguladora,
sino que también puede ser contractus lex, la ley
entre las partes contratantes.
Santiago Cavanillas Múgica

Catedrático de Derecho Civil de la Universidad de las Islas Baleares
20
INTRODUCCIÓN
Desde hace una década, los smart contracts1 han

sido observados por el mundo de la Informática
y el Derecho como un desiderátum generador
de una ingente expectación ante la ausencia
de un paradigma que resolviera los problemas
tecnológicos existentes.
Fue el 15 de julio de 2015 (hace apenas dos
años) cuando, gracias a la iniciativa de Vitalik Bute-
rin2, y del Ethereum Project´s Solidity Team liderado
por Christian Reitwiessner3, vio la luz la plataforma
Ethereum cuyos pilares fundamentales son: una
cadena de bloques4 propia, pública y descentrali-
1
El significado del concepto smart contract se expone de
forma detallada en la página 51 del presente trabajo.
2
Vid. Sitio web: https://es.wikipedia.org/wiki/Vitalik_Buterin.
3
El perfil de Christian Reitwiessner puede verificarse
en su página de Linkedin, sitio Web: https://de.linkedin.com/in/
dr-christian-reitwiessner-594b0982.
4
Vid. Sección I, apartado 2.4.
21
Carlos Tur Faúndez
zada, una criptomoneda5(el Ether6) y un lenguaje de

programación, Solidity7, que permite el desarrollo
de programas complejos para su posterior intro-
ducción y ejecución en la cadena de bloques.
Las ventas al por menor desarrolladas a través
de comercio electrónico alcanzaron la espectacular
cifra de 1.915 trillones de dólares en el año 2016. Se
especula que para el año 2020 dichas ventas pue-
den alcanzar los 4.058 trillones de dólares, lo que
supondrá más del 14,6 % del total de las ventas a
consumidores8.
La cadena de bloques y los smart contracts for-
man parte de una nueva tecnología que tiene un
incuestionable potencial en el futuro del comercio
electrónico9. Sin embargo, puede constatarse cómo
con demasiada frecuencia algunos informáticos
5
Para una explicación técnica del concepto Vid. Sitio web:
https://es.wikipedia.org/wiki/Criptomoneda.
6
El Ether (ETH) es la criptomoneda que constituye el medio
de pago en la red descentralizada Ethereum.
7
Solidity es un lenguaje de programación informática, orien-
tado a objetos y especialmente diseñado para la creación de smart
contracts y su ejecución en la Ethereum Virtual Machine. Vid. Sitio
web: https://solidity.readthedocs.io/en/develop/.
8
Fuente eMarketer, Sitio web:
https://www.emarketer.com/Article/Worldwide-Retail-Ecommerce-
Sales. Se excluye de dichos cálculos el volumen de ventas que
se desarrolla en el mercado mayorista y en las prestaciones de
servicios entre empresas.
9
Una relación de los principales miembros que, con sus
fondos, están contribuyendo hoy al desarrollo de la tecnología
Ethereum, puede verse en el siguiente Sitio web: https://entetha-
lliance.org/members/.
22
Smart Contracts
hacen públicos “pretendidos” contratos (smart

contract) que, en realidad, son simples programas
sin ninguna perspectiva jurídica, llegando incluso
a imaginar una suerte de “arcadia feliz” en la que
los expertos en Derecho son prescindibles10.
Pese a quien pese, la presencia del Derecho será
absolutamente necesaria en el correcto desarrollo
de las aplicaciones basadas en smart contracts. De
lo contrario, se desencadenarán pérdidas millona-
rias como consecuencia de la ulterior declaración
de nulidad o, en su caso, anulación ante los tri-
bunales de todos aquellos negocios jurídicos que
no cumplan con los requisitos que sean legalmente
exigibles en cada caso11.
Consecuentemente, los juristas no debemos
bajar la guardia. En la web se cuentan por doce-
nas los artículos jurídicos que, bien se limitan a
traducir, “copiar y pegar” contenidos escritos en
En noviembre del año 2015, se celebró la primera confe-

10
rencia para desarrolladores de la plataforma Ethereum a la que

se denominó DEVCON 1. La intervención de Nick Szabo que
puede verse en el siguiente Sitio web: https://www.youtube.com/
watch?v=YpSeOU1VVj4, tuvo una entusiasta acogida y en el minuto
10:25 de su intervención, expuso una comparativa, bastante des-
afortunada, a nuestro juicio, entre los contratos basados en soft-
ware y los basados en la ley. Ello dio pie a múltiples artículos que
preconizaban la “sustitución de un ejército de abogados”. Un
ejemplo de los mismos puede verse en el Sitio web: http://www.ibti-
mes.co.uk/devcon1-nick-szabo-says-smart-contracts-substitute-army-lawyers-
accountants-1528604.
Sin perjuicio de las sanciones administrativas que, en su
11
caso, pudieran imponerse.
23
Carlos Tur Faúndez
inglés por desarrolladores de software, bien a ana-

lizar jurídicamente conceptos informáticos que, o
se conocen superficialmente, o no se conocen en
absoluto.
Es imprescindible que tanto los investigadores
como los profesionales del Derecho de las nuevas
tecnologías hagamos el esfuerzo (tal vez ímprobo)
de conocer con el máximo detalle posible las par-
ticularidades del mundo de la informática si anhe-
lamos ocupar la posición que nos corresponde en
el devenir de la contratación electrónica.
Nuestro objetivo ha sido, desde el inicio del
presente trabajo, el análisis interdisciplinar de las
cuestiones técnico-jurídicas que se plantean en
torno a los smart contracts y a lo que más adelante
definiremos como contratos legales inteligentes12
12
Como se expondrá de forma detallada en la sección II, en
el presente trabajo, se traza una línea de distinción clara entre
los smart contracts, como simples programas y los contratos legales
inteligentes, como verdaderos contratos autoejecutables. Somos
conscientes de que la expresión contrato legal inteligente (smart
legal contract) es redundante y ello, por cuanto que, el calificativo
-legal-, está implícitamente incluido en el sustantivo -contrato-.
Sin perjuicio de lo expuesto, nos mostramos partidarios del
uso de dicho pleonasmo, pues presenta, a nuestro juicio, más
ventajas que inconvenientes. La expresión smart contract o, en
castellano, contrato inteligente, incluye, erróneamente, el vocablo
-contrato-, cuando no hay tal. La adición del calificativo -legal-,
a la expresión -contrato inteligente- nos permite establecer una
clara diferenciación entre el software subyacente en el back end y
el verdadero contrato electrónico, con eficacia obligacional entre
las partes y de cuya estructura informática y formal, es parte el
smart contract.
24
Smart Contracts
(smart legal contracts) en busca de la integración de

dos disciplinas, el Derecho y la Informática, que,
inexcusablemente, “están condenadas” a la concor-
dancia futura.
Es éste un trabajo fundamentalmente conce-
bido para juristas, si bien en cuestiones como la
que nos ocupa, la disociación entre la Tecnología
y el Derecho ni es simple ni es aconsejable, puesto
que, como se verá, los contratos legales inteligentes
requieren por su propia naturaleza un cambio de
mentalidad jurídica que debe proyectarse fun-
damentalmente sobre dos de sus características
principales:
Los smart contracts que los integran cobran
especial sentido en el IoT13 (Internet de las cosas), por
lo que pueden interactuar con cualesquiera obje-
tos que estén conectados a Internet (edificaciones,
vehículos, aeronaves, embarcaciones, maquinaria
industrial, etc.) en tanto dispongan de un disposi-
tivo electrónico que lo permita.
Los contratos legales inteligentes son14 autoejecu-
tables, es decir, que las prestaciones a realizar por
las partes una vez otorgado el consentimiento que-
dan fuera de su alcance volitivo dado que es el
propio programa el que, de forma autónoma, las
lleva a efecto de forma automática. Así, a título
meramente enunciativo, podemos decir que el pro-
13
Vid. Sitio web: https://es.wikipedia.org/wiki/Internet_de_las_cosas.
14
Cuando menos parcialmente.
25
Carlos Tur Faúndez
grama (smart contract), en función de su contenido,

podrá: “cobrar” de cuentas vinculadas a otros smart
contracts e ingresar fondos en la cuenta propia15,
transferir fondos a las cuentas de las partes y remi-
tir órdenes a dispositivos electrónicos externos a
través de redes de telecomunicaciones, de forma
que éstos puedan provocar que un objeto determi-
nado se encienda o apague, se bloquee o desblo-
quee, se abra o cierre, etc.
Hoy, más que nunca, debemos reivindicar la
vigencia de la reflexión realizada por CAVANILAS
MÚGICA en el año 2001: Ojalá sirva nuestro trabajo
para evitar la existencia de dos provincias encastilladas:
¡la de los juristas teóricos, en torno a la bandera de los
inconmensurables peligros de la informática y el de los
prácticos en torno a los “obstáculos legales” que anti-
cuados “abogados” se empeñan en colocar ante el paso
de la imparable locomotora del progreso!16.
Debe tomarse en consideración que un contrato
legal inteligente solamente podrá existir en tanto que
previamente exista un smart contract que constituya
el instrumento de su ejecución automática y una
cadena de bloques en la que aquél se haya inser-
tado. Consideramos que se requiere una mínima
comprensión de los medios tecnológicos impres-
El programa, actúa como un ente autónomo con cuenta

15
propia.
16
CAVANILLAS MÚGICA, S, TUR FÁUNDEZ, N, BENITO
ROSER y T; SUINAGA ROMERO DE TERREROS, C; Turismo y
comercio electrónico, Comares, 2001. Pág. 2.
26
Smart Contracts
cindibles para la creación de contratos legales inteli-

gentes si se pretende abordar posteriormente el aná-
lisis jurídico de las innovaciones que tales medios
aportan al mundo del Derecho.
Los smart contracts han iniciado su andadura
hace apenas dos años y la tecnología informática
sobre la que se desarrollan no ha sido difundida ni
explicada suficientemente. Atendidas tales circuns-
tancias, hemos considerado absolutamente necesa-
rio iniciar la exposición del presente estudio con la
sección I, que constituye una breve introducción al
mundo de los smart contracts y blockchain, si bien
orientada al Derecho. El objetivo perseguido es
facilitar la comprensión de los análisis y observa-
ciones que se llevan a efecto en la sección II, que
aborda con mayor profundidad las cuestiones de
naturaleza jurídica que envuelven a los contratos
legales inteligentes.
No podemos ser ajenos a la realidad, puesto
que tales contratos se construyen y se ejecutan,
como se verá, mediante programas informáticos,
aun cuando el usuario, no perciba, a primera vista,
todo cuanto se desarrolla, tras la pantalla de su
ordenador o de su teléfono móvil.
27
SECCIÓN I
LA TECNOLOGÍA
1. “BITCOIN”. EL ORIGEN
La tecnología Blockchain constituye la base sobre

la que se construyó Bitcoin y fue introducida por
primera vez por su autor Satoshi Nakamoto17 en
su white paper18: “Bitcoin: A Peer-to-Peer Electronic Cash
System”19 publicado en 2008. Fue varios años más
tarde cuando se comenzó a analizar la posibilidad
de hacer uso de dicha tecnología para algo más
17
La identidad de Satoshi Nakamoto, sigue siendo absolu-
tamente desconocida a día de hoy.
18
Utilizamos el término anglosajón, pues no existe un equi-
valente exacto en español. Podría ser traducido como “guía
de inicio”. No vemos coincidencia exacta en el término “libro
blanco”
19
Vid. “White paper de Bitcoin” en Sitio web: https://bitcoin.
org/bitcoin.pdf.
29
Carlos Tur Faúndez
que el mero registro de transacciones económicas

(transferencia de “bitcoins” de una cuenta a otra).
La idea originaria consistía en la creación de
una moneda virtual contenida en un archivo infor-
mático y que podía ser transferida por su titular,
mediante firma electrónica reconocida, a un ter-
cero, quien a su vez podría transferirla del mismo
modo. En definitiva, una sucesión o cadena de
transmisiones similar al endoso de títulos valores
regulado en el Título I, Capítulo II de la LCCH
al que estamos habituados, pero con dos diferen-
cias fundamentales: la primera, que la firma del
“endosante” y sucesivos “endosatarios” siempre
será verificable y la segunda: al no tratarse de un
título al portador, en el sentido físico conocido, no
cabe hablar de tenedor, pues no puede asegurarse
que un título digital idéntico haya sido remitido a
múltiples destinatarios.
El valor inicial no era, ni es, objeto de preocu-
pación puesto que, como por todos es bien sabido
a día de hoy, el “valor de las cosas” lo determina la
ley de la oferta y la demanda20. No existe una dife-
20
¿Por qué surgió la idea de la tecnología Blockchain? El
objetivo del creador de “Bitcoin”, Satoshi Nakamoto, era dar
carta de naturaleza a una moneda confiable y descentralizada,
cuyo valor dependiera exclusivamente de la oferta y la demanda
y por ende sin injerencias de terceros que pudieran influir en su
cotización. En la página 2 de su “white paper” Nakamoto, define
su moneda electrónica en los siguientes términos: “We define an
electronic coin as a chain of digital signatures. Each owner transfers
the coin to the next by digitally signing a hash of the previous tran-
30
Smart Contracts
rencia fundamental en el sistema de valoración21

del Bitcoin y el del resto de bienes o valores22.
Teniendo en cuenta que, como se ha indicado,
el “documento” en el que se consigna la criptomo-
neda no puede ser una pieza de papel, ¿cómo puede
asegurarse el destinatario de los fondos de que el
transmitente o pagador no ha transmitido antes su
criptomoneda a un tercero23? Son dos las posibilida-
des existentes:
a) La existencia de una autoridad central de
control que pueda comprobar todas las
transacciones económicas que se realizan.
En especial, deberá determinar, de entre
varias transmisiones posibles, cuál fue la
transacción realizada en primer lugar, que
saction and the public key of the next owner and adding these to the
end of the coin. A payee can verify the signatures to verify the chain
of ownership”.
21
El precio de cotización del Bitcoin (BTC), se halla hoy 13
de agosto de 2017 en 3.397,28 €. Sitio web: http://www.eleconomista.
es/cruce/BTCEUR. Por su parte, el Ether (ETH), cotiza en la misma
fecha a 247,90 €. Sitio web: https://es.investing.com/currencies/eth-eur.
Se pueden adquirir ambas criptomonedas en múltiples páginas
web, Coinbase, es una de las plataformas más seguras y mejor
valoradas. Sitio web: https://www.coinbase.com/.
22
Una explicación bastante convincente sobre el modo en
el que se determina el valor de cotización de “Bitcoin”, puede
hallarse en el artículo publicado en el Sitio web http://blog.bit2me.
com/es/precio-bitcoin/.
23
Es el conocido “double spending problem” o problema del
doble gasto. Las cadenas de bloques nacieron con la finalidad
de darle una solución definitiva.
31
Carlos Tur Faúndez
será la única válida, siendo nulas todas las

posteriores;
b) La concurrencia de un número muy elevado
de participantes en una red de computación
en la que se hagan públicas todas las tran-
sacciones y la existencia de consenso entre
los mismos en la determinación de la tran-
sacción más temprana24.
Pues bien, tal y como se ha expuesto, la solu-
ción, basada en la segunda de las opciones se halló
en el año 2008, con el nacimiento de la tecnología
Blockchain a la que se hará referencia a continuación.
Si A, dispone de 1 BTC y lo transmite a B a las 10.15

24
am, todos y cada uno de los ordenadores conectados a la red,

serán partícipes simultáneos de la transferencia de fondos y de
todos los detalles de la misma, en consecuencia, si ulteriormente
intenta transferir ese mismo BTC a C, dicha transacción inten-
tará ser incluida en la cadena de bloques, pero no será posible,
porque la red, ya habrá validado el bloque en el que se incluía
la primera transacción y en consecuencia, se hallarán afectos
todos los bloques encadenados al mismo. “Prior in tempore potior
in iure”. Se requeriría la conformidad de más del 50 % de los
nodos de la red, para validar la transacción A-C, lo que se prác-
ticamente imposible.
32
Smart Contracts
2. LA CADENA DE BLOQUES O BLOCKCHAIN
2.1. CONCEPTO
La aproximación al concepto de smart contract,
requiere, en primer lugar, el estudio y análisis por-
menorizado de la cadena de bloques25. La cadena de
bloques es una base de datos apoyada en tecnología
peer to peer26 y por tanto compartida por múltiples
nodos27, en la que se registran bloques de informa-
ción. El término nodo se refiere a cualquier ordena-
dor que, previa descarga y ejecución en el mismo
de uno o varios programas, se convierte en parte
integrante de la red descentralizada de la cadena
de bloques e inmediatamente pasa a conservar una
réplica exacta de todos los registros integrantes de
la misma. La “copia completa del libro de regis-
25
Sin duda, resulta más conocido el vocablo anglosajón
“blockchain” pero según nuestro parecer, nada obsta la utiliza-
ción de nuestro idioma para referirnos a conceptos que permiten
una fácil traducción.
26
Peer to peer, puede ser traducido como “de igual a igual”.
Hablamos de redes peer to peer o P2P, para referirnos a aquellas
que están compuestas por múltiples nodos iguales y en las que
no existen servidores o clientes. Para más detalles, Vid. Wikipe-
dia. Sitio web: https://es.wikipedia.org/wiki/peer-to-peer
27
Para conectarse a la cadena de bloques Ethereum, a la que
nos referiremos más adelante, es preciso descargar y ejecutar las
aplicaciones Mist o Ethereum wallet en su última versión v0.8.10
(también pueden descargarse ambas, pues sirven diferentes pro-
pósitos) en el repositorio Github que puede consultarse en este
Sitio web: https://github.com/ethereum/mist/releases
33
Carlos Tur Faúndez
tro” se actualizará, en lo sucesivo, cada vez que el

nodo se conecte a Internet. La cadena de bloques
presenta las siguientes características:
a) Consenso: Para que la información contenida
en un bloque sea considerada como válida,
todos los participantes deben de estar de
acuerdo;
b) Origen: Todos los nodos pueden verificar el
momento en que determinado activo se ha
registrado en la cadena de bloques, quién
fue su primer titular y todos los ulteriores
cambios de titularidad producidos hasta el
presente;
c) Inmutabilidad: Ningún participante en la
cadena de bloques puede manipular la
información, una vez ha sido registrada.
2.2. FUNCIONAMIENTO
La denominación cadena de bloques fue acu-
ñada para referirse a la forma en la que se almacena
la información. Cada transacción (que puede ser
una simple transferencia de fondos, la inserción de
un programa –smart contract- o la asignación de un
valor a una variable del mismo28) se inserta, auto-
En alguna medida, los programas informáticos presentan

28
ciertas similitudes con los formularios, a los que tan habituados

estamos los profesionales del Derecho. Las variables equivalen
a “espacios en blanco” que deben ser rellenados en el mismo.
34
Smart Contracts
máticamente, en un bloque de información. Según

va creciendo el número de transacciones, crece la
cadena de bloques. En cada uno de los bloques
(que puede contener una o múltiples transaccio-
nes) se registra la hora (horas/minutos/segundos)
y la secuencia de las transacciones, según las nor-
mas consensuadas por los participantes de la red.
Cada bloque contiene un hash29 o huella digi-
tal30 del conjunto de transacciones que en el mismo
se almacenan, así como el hash del bloque anterior,
lo que impide que un bloque pueda ser alterado o
pueda ser insertado entre dos bloques preexistentes.
Con este sistema, cada bloque refuerza la veri-
ficación de la información contenida en el bloque
anterior y, por ende, de toda la cadena de bloques.
Algunas de estas variables en un smart contract, podrían ser: el

precio, la penalización, el plazo, etc.
29
Según la definición que proporciona la propia “Wikipe-
dia” de “Bitcoin” en el Sitio web: https://es.bitcoin.it/wiki/Hash. “Un
algoritmo de hash convierte una cantidad arbitrariamente grande de
datos en un hash de longitud fija. El mismo hash siempre será el
resultado de los mismos datos, pero la modificación de la información,
aunque sea un solo bit dará como resultado un hash distinto. Los has-
hes son números grandes y se escriben normalmente en hexadecimal”.
30
Se puede obtener el hash o huella digital, de cualquier
conjunto de datos, bien sea una cadena de texto, una secuencia
numérica o un archivo en cualquier formato. En el Sitio web:
https://www.toolsley.com/hash.html puede llevarse a efecto la prueba.
Si incorporamos cualquier archivo de texto, obtendremos un
hash consistente en una secuencia alfanumérica (en numeración
hexadecimal). La mínima modificación del mismo (v.g. añadir
un espacio entre caracteres) nos proporcionará un hash absolu-
tamente diferente.
35
Carlos Tur Faúndez
Este método hace que la cadena de bloques sea

inviolable, lo que le confiere una de sus principales
características, esto es, la inmutabilidad31.
Con el objetivo de alcanzar la máxima seguri-
dad posible, los creadores de Bitcoin idearon un
nuevo sistema que añade una gran dificultad a la
inserción de un bloque falso en la cadena de blo-
ques. Se trata del proceso de “minado”. Los “mine-
ros” son, en realidad, múltiples ordenadores que
forman parte de la cadena y que van a desarrollar
un trabajo computacional muy exigente para vali-
dar cada bloque de información. Dicho esfuerzo
matemático recibe el nombre de “proof of work.”
Aquel “minero” (ordenador) que consiga en pri-
mer lugar resolver el bloque pendiente de valida-
31
En el Sitio web: https://anders.com/blockchain/hash.html puede
hallarse una interesante aplicación que nos permite experimen-
tar el funcionamiento de la cadena de bloques. Asimismo, puede
verse una explicación en castellano basada en dicha aplicación
en el Sitio web: https://www.youtube.com/watch?v=NjW6nyEhFkA.
Para comprender los conceptos de criptografía de doble
clave sobre los que se asientan las cadenas de bloques, resulta
de gran ayuda el MOOC (Massive Open Online Course), que de
forma autónoma puede seguirse en el Aula Virtual de Seguri-
dad Informática y Criptografía CRYPT4YOU de la Universidad
Politécnica de Madrid en el Sitio web: http://www.criptored.upm.es/
crypt4you/portada.html.
Si se desea, una exposición audiovisual más didáctica y ase-
quible, podemos hallarla en los vídeos: 1,2,3 y 14 de la página
web INTYPEDIA (otro proyecto de criptored) Sitio web: http://
www.intypedia.com/.
36
Smart Contracts
ción32 recibirá una recompensa en “criptomonedas”

que a día de hoy se halla fijada en 12,5 BTC o 5
ETH, en función de la cadena de la que hablemos.
Ello, además de incentivar a los “mineros”, es el
instrumento de creación de la nueva moneda que
entrará en circulación33.
32
Cada bloque, contiene, un número correlativo propio,
el denominado “nonce”, la información correspondiente a las
transacciones realizadas y el hash del bloque. Para minar, o resol-
ver un bloque, y obtener la recompensa, se tiene que conseguir
un hash del bloque válido pero que empiece por 4 ceros. Como
sabemos, una misma información, siempre tendrá el mismo
hash. El minero solo tiene la posibilidad de alterar el nonce y
su computador, ira probando números, desde el 0, en adelante,
hasta conseguir un hash válido para el bloque El esfuerzo de
cálculo necesario para validar el bloque, es muy elevado y el
“minero” que primero obtenga la respuesta, será recompensado
económicamente.
33
Para minar bloques, existen dos sistemas posibles: El
primero, consiste en descargarse los programas necesarios para
constituir un nodo de la cadena de bloques, abrir una cuenta
en la misma y hacer uso de los mecanismos que la aplicación
facilita para el “minado”. Si se consigue la resolución de algún
bloque, la cadena remitirá inmediatamente a la cuenta del
“minero” la recompensa correspondiente. No obstante, lo ante-
rior, la competencia es alta y la posibilidad real de que un solo
“minero” sea el “vencedor” es prácticamente nula. El segundo
mecanismo consiste en ser partícipe de un mining pool (pozo de
minería) Tras entrar en su página web y descargase la aplicación
se cede (se “vierte en el pozo”) la capacidad computacional del
ordenador al colectivo. El funcionamiento es parecido al de los
antiguos “clubes de quinielas”, de forma que la posibilidad de
resolver un bloque y obtener la recompensa, se multiplica expo-
nencialmente, pero los premios repartidos entre los miembros
del “club” son muy bajos (aunque siempre proporcionales al
poder computacional aportado). Uno de los mining pools, “mul-
37
Carlos Tur Faúndez
2.3. CLASIFICACIÓN DE LAS CADENAS DE

BLOQUES
En función de los permisos requeridos para for-
mar parte en cada una de las cadenas de bloques y
validar las transacciones realizadas, podemos dis-
tinguir, actualmente, tres categorías:
a) Públicas: En ellas cualquiera puede des-
cargar en su ordenador los programas necesa-
rios y constituir un nodo que forma parte de la
red descentralizada a partir de ese momento, así
como participar en el proceso de consenso. Cual-
quiera que forme parte de la cadena de bloques
(nodo) podrá enviar transacciones a través de
Internet, que se incluirán en la cadena de blo-
ques, y examinar la transacción en la página web
que cada plataforma tenga habilitada para ello.
Los ejemplos más relevantes son Bitcoin34 y Ethe-
reum35. Otros ejemplos son Monero36, Dash37, Litecoin38,
Dodgecoin39, etc.
tidivisa” más populares podemos encontrarla en el Sitio web:

https://es.minergate.com/.
Una exposición clara y detallada sobre el funcionamiento de
la minería en las cadenas de bloques, podemos encontrarla en
el siguiente Sitio web: http://blog.bit2me.com/es/que-es-minar-bitcoins/.
34
Sitio web: https://bitcoin.org/es/.
35
Sitio web: https://www.ethereum.org/.
36
Sitio web: https://getmonero.org/.
37
Sitio web: https://www.dash.org/es/.
38
Sitio web: https://litecoin.com/es/.
39
Sitio web: http://dogecoin.com/.
38
Smart Contracts
b) Federadas o de consorcio: A diferencia de lo

que ocurre con las cadenas de bloques públicas
no permiten que cualquier persona pueda confi-
gurar un nodo en su PC y participar en el proceso
de validación de las transacciones. En este caso se
requieren determinados permisos de acceso que
suelen concederse a los miembros de un deter-
minado colectivo40 (v.g. entidades financieras). La
validación de las transacciones se controla por un
grupo preseleccionado de miembros (por ejemplo,
se establece una comisión de 15 entidades financie-
ras cada una de las cuales opera un nodo, siendo
necesario que al menos diez firmen cada bloque
de transacciones para que se considere válido). El
derecho de acceso y lectura de los bloques puede
ser público, o hallarse restringido a los miembros
de la cadena. Los ejemplos más significativos son:
R341 (colectivo de entidades financieras con más de
80 asociados de los cuatro continentes, entre ellas
BBVA), ENERGY WEB FOUNDATION42 (sector energé-
tico) y B3i43 (sector asegurador);
40
Una cadena de bloques federada o de consorcio, puede
estar integrada por un colectivo muy numeroso o por un grupo
muy reducido. Serán los creadores de la misma los que establez-
can los permisos de acceso y la cantidad de nodos que deben
suscribir la validez de los bloques.
41
Sitio web: https://www.r3.com/.
42
Sito Web: http://energyweb.org/.
43
No nos consta que a día de hoy tenga disponga de una
web públicamente accesible, pero puede constatarse su existen-
cia en el siguiente Sitio web: http://www.insurancejournal.com/news/
39
Carlos Tur Faúndez
c) Privadas: Haciendo uso de la tecnología que

proporcionan las grandes cadenas públicas, entre
las que destaca Ethereum, se pueden crear cadenas
de bloques privadas.
En estas cadenas de bloques, las autorizacio-
nes para poder realizar transacciones o en su caso
insertar programas ejecutables, son concedidas por
organizaciones privadas, del mismo modo que
serán estas las que determinarán a quién y en qué
condiciones se le permitirá la lectura de las tran-
sacciones realizadas.
Existen diversas plataformas que permiten
la creación de cadenas de bloques federadas y
privadas, entre ellas cabe destacar MONAX44 e
HYPERLEDGER45.
2.4. ETHEREUM EN PARTICULAR

Ethereum es una plataforma descentralizada
en cuya cadena de bloques se ejecutan programas
escritos en Solidity46. Dicho lenguaje, a diferencia de
lo que ocurre con el sistema de scripts que opera en
international/2017/02/06/440629.htm. En fecha 6 de febrero de 2017,

contaba con 15 compañías asociadas especialmente destacadas
en el sector asegurador internacional
44
Sito Web: https://monax.io/.
45
Sitio web: https://www.hyperledger.org/.
46
Solidity, es un lenguaje de programación informática, orientado
a objetos y especialmente diseñado para la creación de smart contracts
y su ejecución en la Ethereum Virtual Machine.
40
Smart Contracts
la cadena de bloques de Bitcoin, es Turing completo47,

o lo que es lo mismo, puede expresar cualquier
tarea realizable por el computador que lo interpreta
y ejecuta.
Precisamente por ello, en la actualidad la única
cadena de bloques pública que permite la creación
de verdaderos smart contracts es Ethereum, mediante
su integración en la Ethereum Virtual Machine48. En
dicha plataforma, existen dos tipos de cuentas o
direcciones:
a) Las cuentas externas, denominadas EOA
(External Owned Accounts), que se identifi-
can con un código alfanumérico hexadeci-
mal49 al que se denomina address y permi-
47
Mas detalles sobre la cuestión pueden hallarse en Wikipe-
dia. Sitio web: https://es.wikipedia.org/wiki/Turing_completo.
48
La máquina virtual Ethereum (EVM) es el entorno de
ejecución para smart contracts en Ethereum. Está completamente
aislada, lo que significa que el código que se ejecuta dentro del
EVM no tiene acceso a red, y permite la ejecución de los pro-
gramas en modo de pruebas. Los contratos viven en la cadena
de bloques en un formato binario específico Ethereum (bytecode
EVM). Sin embargo, los smart contracts se escriben típicamente
en Solidity.
49
En código binario, solo existen dos cifras, 0 y 1, en el sis-
tema decimal, por todos conocido, existen 10 cifras, numeradas
del 0 al 9, en el sistema hexadecimal, existen 16 cifras, las 10
primeras se numeran del 0 al 9 y las seis restantes, de la A, hasta
la F. Un conversor que nos permite transformar una cifra en
base 10, a hexadecimal, binario, octal, etc., lo podemos hallar en
el Sitio web: http://wims.unice.fr/wims/es_tool~number~baseconv.es.html.
Los hashes siempre se corresponden con un número muy alto,
en base hexadecimal.
41
Carlos Tur Faúndez
ten: el depósito de fondos en la criptomoneda

Ether, la transferencia50 de fondos a otras
cuentas EOA y a cuentas de smart contract,
la recepción de fondos desde todos los tipos
de cuentas y la remisión de mensajes (msg.)
a smart contracts.
b) Las cuentas de smart contract (contract
accounts). Dichas cuentas se hallan
vinculadas al propio smart contract pues se
trata de un programa “capaz de hacerse
cobro y pagar” automáticamente y sin que
intervengan terceros.
Dichas cuentas, que igualmente se identifi-
can con un código alfanumérico (address), pueden
ejecutar todas las acciones propias de las EOA y,
además: el anclado de programas autoejecutables
desarrollados en Solidity, la interacción del pro-
grama (smart contract) mediante múltiples funcio-
nes con otros smart contracts y cualesquiera cuentas
de la cadena de bloques y la interacción del pro-
grama (smart contract) a través de Web 3 JavaScript
app API con aplicaciones externas a la cadena de
bloques (páginas web interactivas que incluyen
código javaScript). Las contract accounts pertenecen
50
Todas las transacciones, que se realizan en Ethereum, al
margen de la clase a la que pertenezcan, tienen un coste en Ether,
puesto que, al integrarse en un bloque de la cadena, exigen que
los mineros pongan a disposición de la EVM sus ordenadores a
fin de resolver la denominada “proof of work” (prueba de trabajo).
42
Smart Contracts
ab initio a su creador, pero los fondos que en ellas

se depositen sólo podrán ser recuperados por éste
si así se ha programado el smart contract al que
están vinculadas.
Para la creación de un contrato legal inteligente51
se requerirá, como mínimo, que cada una de las
partes disponga de una cuenta EOA desde la que
se puedan remitir mensajes y fondos a la cuenta
del smart contract en la que se habrá desplegado el
programa.
2.5. OTRAS TECNOLOGÍAS DE RED DISTRI-

BUIDA
Si bien es cierto que su grado de desarrollo se
sitúa hoy en fase alfa52, existen dos plataformas idea-
das para el almacenamiento de archivos de gran
tamaño denominadas SWARM53 e IPFS54. Su cons-
trucción es similar a la de las cadenas de bloques,
en tanto que se trata de redes descentralizadas
compuestas por múltiples nodos. Sin embargo, a
51
El término contrato legal inteligente, como se verá en el epí-
grafe 6, implica la existencia de un acuerdo jurídicamente vinculante
que se sirve de un programa (smart contract) para su ejecución.
52
En la ingeniería del software el término fases de desa-
rrollo expresa cómo ha progresado el desarrollo de un soft-
ware y cuánto desarrollo puede requerir, Alfa, es la primera
versión del programa, la cual es enviada a los verificadores
para probarla. Véase el Sitio web: https://es.wikipedia.org/wiki/
Fases_del_desarrollo_de_software.
53
Sitio web: http://swarm-gateways.net/bzz:/theswarm.eth/.
54
Sitio web: https://ipfs.io/.
43
Carlos Tur Faúndez
diferencia de éstas, no disponen de un “mecanismo

de minado55. En Bitcoin y Ethereum los costes de
almacenamiento de grandes archivos son extrema-
damente elevados, puesto que se requiere su inte-
gración en varios bloques de información y el tra-
bajo computacional desarrollado por los mineros
debe ser recompensado. Precisamente por ello, sólo
se almacena la información esencial, es decir las
transferencias de fondos, el hash de determinados
archivos y las variables de los programas.
SWARM e IPFS brindan la oportunidad de
almacenar en una red distribuida inmutable, archi-
vos de texto, de imagen, de vídeo, e incluso pági-
nas web completas. Por ello, constituyen (o cons-
tituirán cuando estén plenamente operativas) un
complemento idóneo a las cadenas de bloques, por
cuanto las direcciones de localización que propo-
nen se corresponden con un hash del archivo alma-
cenado. De este modo, se incrementa la seguridad
y se puede facilitar al prestatario del servicio (sea
consumidor o no) una dirección segura en la que
podrá localizar, permanente e indefinidamente,
los archivos asociados a su contrato legal inteli-
gente. Entre tales archivos pueden hallarse, como
se expondrá más adelante, el documento pdf con
firma electrónica reconocida en el que se consignan
las condiciones generales y particulares de su con-
trato y la grabación audiovisual, en su caso, en la
55
Vid. Supra, sección I, apartado 2.3, nota a pie de página.
44
Smart Contracts
que quede constancia de la identidad del aceptante

y de su consentimiento expreso.
3. LA CADENA DE BLOQUES COMO MECA-

NISMO DE ALMACENAMIENTO DE ARCHIVOS
La cadena de bloques del sistema Bitcoin pre-

senta ciertas limitaciones, puesto que fue con-
ceptuada originalmente como un registro para el
almacenamiento de cuentas o direcciones (es decir,
códigos alfanuméricos atribuidos a los usuarios
que tienen un determinado saldo en bitcoins) y
transferencia de sumas de unas cuentas a otras, lo
que lógicamente supondrá el incremento y decre-
mento de los saldos respectivos. Sin embargo, en el
año 2013, ARAOZ y ORDANO consiguieron hallar
en el sistema de scripting de Bitcoin una puerta tra-
sera56 que permitía el almacenamiento de archivos
anexos57 para crear posteriormente la primera apli-
Vid. Infra, nota a pie de página 61.

56
Cualesquiera archivos, sean de texto, de imagen o de

57
cualquier otra naturaleza, no son más que una mera represen-

tación inteligible de una secuencia ordenada de ceros y unos
(código binario) debidamente interpretados por el ordenador.
En este Sitio web: https://codebeautify.org/string-binary-converter puede
transformarse cualquier cadena de texto en su correspondiente
código binario.
45
Carlos Tur Faúndez
cación de almacenamiento seguro en la cadena de

bloques Proof of Existence58.
En cualquier caso, debe dejarse constancia de
que Proof of Existence no almacena los archivos. Lo
que verdaderamente se incorpora a la cadena de
bloques es el hash o huella digital de los mismos.
Los ficheros no pueden ser incorporados direc-
tamente a un bloque de Bitcoin, y el motivo fun-
damental es que el sistema no lo permite y, en el
hipotético caso de que lo permitiera, el tamaño de
los archivos dispararía los costes de la transacción
de almacenamiento.
No obstante lo anterior, con aplicaciones como
Proof of Existence, Stampery u OpenTimeStamps (entre
otras) se pueden conseguir los siguientes objetivos:
En primer lugar, la inmutabilidad del documento
o archivo: Una vez anclado el hash del documento
58
Bitcoin, no se articula sobre un verdadero lenguaje de pro-
gramación, sino sobre un sistema de scripts, básico que puede
ser consultado en el siguiente Sitio web: https://en.bitcoin.it/wiki/
Script. Lo que limita de forma considerable sus posibilidades, sin
embargo, Araoz y Ordano, descubrieron la forma de generar
una transacción especial que permite adjuntar el hash de un con-
junto de datos a través del comando OP_RETURN. Puede verse
al respecto el Sitio web: https://proofofexistence.com/about. En reali-
dad Proof of Existence, no almacena los archivos, lo que verdade-
ramente se incorpora a la cadena de bloques, es el hash o huella
digital de los mismos. Los ficheros, no pueden ser incorporados
directamente a un bloque de Bitcoin y el motivo fundamental es
que el sistema no lo permite y en el hipotético caso de que lo
permitiera, el tamaño de los archivos dispararía los costes de la
transacción de almacenamiento.
46
Smart Contracts
a la cadena de bloques, es inalterable, pues ni los

miembros de la cadena de bloques ni los terceros
ajenos a la misma pueden manipular en modo
alguno su contenido alfanumérico. Cualquiera
puede verificar si el documento o archivo ha sido
manipulado aplicando la correspondiente función
hash y comprobando si la clave alfanumérica es la
misma que la del documento original.
En segundo lugar, sellado de tiempo del archivo:
Cada bloque de la cadena (en dicha información
va anclado nuestro hash) va a disponer de un sello
de tiempo que gozará del mismo nivel de seguri-
dad proporcionado por la plataforma y se incor-
porará al bloque de datos correspondiente, con la
ulterior validación de todos los nodos. Ello eviden-
cia, incuestionablemente, que el documento existía
antes de su incorporación a la cadena de bloques.
Y en tercer lugar, testimonio múltiple respecto
a la existencia del archivo: La red Bitcoin cuenta
hoy con 8.090 nodos59 y la red de la plataforma
Ethereum, dispone de 25.52360. Todos ellos dispo-
nen de una copia idéntica de la totalidad de los
bloques y existe consenso en cuanto a la validez
de los mismos, por lo que su eficacia probatoria es
incuestionable.
La blockchain Ethereum sí permite el almacena-
miento directo del hash de un archivo sin necesi-
59
Vid. Sitio web: https://bitnodes.21.co/.
60
Vid. Sitio web: https://www.ethernodes.org/network/1.
47
Carlos Tur Faúndez
dad de utilizar “puertas traseras61, como ocurre en

Bitcoin. Bastaría para ello con incorporar al pro-
grama smart contract una simple variable de estado
similar a la siguiente:
uint public HashContratoPdf = 47b0acf82f4789

2f7b0d9d2c7c0a68577730495bda4975f89fe3141b9ead
cdf5; //el hash es un mero ejemplo.
Ahora bien, si lo que se desea es obtener un

almacenamiento digital que además de ser inmuta-
ble goce de plena accesibilidad62 (de tal modo que
pueda verificarse el íntegro contenido de cualquier
archivo: de texto, de sonido, de imagen, de vídeo e
incluso la combinación de todos ellos, tal podría ser
una página web interactiva) debe recurrirse a las
redes de tecnología distribuida IPFS o SWARM63.
Una vez se haya subido el archivo a alguna de
dichas redes, se obtendrá una dirección de acceso,
compuesta también por una cadena alfanumérica
similar a la siguiente:
61
El comando “OP RETURN”, propio del lenguaje de scrip-
ting del sistema BITCOIN no estaba previsto para el anexado de
ningún tipo de datos adicionales, sino para marcar operaciones
de salida (gasto de bitcoins) como inválidas. Para más informa-
ción Vid. Sitio web: https://en.bitcoin.it/wiki/OP_RETURN.
62
Como es sabido, el hash de un archivo, permite verificar
que este no ha sido modificado, siempre y cuando se disponga
de una imagen exacta del documento original.
63
Vid. Supra Sección I, apartado 2.5.
48
Smart Contracts
QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnP
bdG/
Siguiendo con el ejemplo anterior, obtendría-

mos, pues, un almacenamiento completo e inmu-
table si incorporamos al smart contract una nueva
variable de estado verificable por las partes:
uint public hashContratoPdf= 47b0acf82f47892

f7b0d9d2c7c0a68577730495bda4975f89fe3141b9ead
cdf5;
string public direccionArchivoIPFS=QmYwAPJzv5C
ZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
/*los hashes son un mero ejemplo.
uint es el identificador que se usa en Solidity
para referirse a números enteros
string es el identificador que se usa en Solidity
para referirse a cadenas de texto/números.
public identifica una variable como visible
desde la interfaz de Ethereum.*/
49
SECCIÓN II
EL DERECHO
1. LOS SMART CONTRACTS: CONCEPTO Y

TRASCENDENCIA JURÍDICA
1.1. CONCEPTO
Los smart contracts son secuencias de código y
datos que se almacenan en una determinada direc-
ción de la cadena de bloques (address64).
Aun cuando la utilización de la expresión con-
tract puede inducir a error, debemos subrayar que
la categoría jurídica de contrato no existirá en tanto
no se cumplan los requisitos que la Ley exige para
su validez y ello con independencia de la mayor
64
Vid. Supra, sección I, apartado 2.4.
51
Carlos Tur Faúndez
o menor complejidad del programa que pueda, en

su caso, formar parte del mismo.
La finalidad práctica perseguida por los desa-
rrolladores de smart contracts consiste en la creación
de aplicaciones que permitan aproximarse al con-
cepto original acuñado por el informático y jurista
Nick Szabo el 1 de septiembre de 199765 o, lo que
es lo mismo, al desarrollo digital mediante aplica-
ciones informáticas del concepto de la máquina de
vending66, que ejecuta de forma automática el cum-
plimiento de la entrega y puesta a disposición del
bien objeto de la venta sobre el que se proyecta el
consentimiento del comprador, con la introducción
del importe correspondiente al precio y el acciona-
miento de un botón o palanca67.
65
Nick Szabo, Formalizing and Securing Relationships on
Public Networks “…The basic idea behind smart contracts is that
many kinds of contractual clauses (such as collateral, bonding,
delineation of property rights, etc.) can be embedded in the
hardware and software we deal with, in such a way as to make
breach of contract expensive (if desired, sometimes prohibitively
so) for the breacher. …. Smart contracts go beyond the vending
machine in proposing to embed contracts in all sorts of property
that is valuable and controlled by digital means. Smart contracts
reference that property in a dynamic, often proactively enfor-
ced form, and provide much better observation and verification
where proactive measures must fall short.
66
Hoy la venta automática, se halla regulada en los artículos
49 y siguientes de la Ley 7/1996, de 15 de enero, de Ordenación
del Comercio Minorista.
67
Nick Szabo proponía, además, como puede leerse en su
brillante y premonitorio trabajo, la construcción de aplicacio-
nes que permitieran el control sobre la posesión de los bienes
52
Smart Contracts
En el año 2015, la idea de smart contract de

Nick Szabo, se hace realidad con el nacimiento de
Ethereum68.
Según la definición facilitada por Christian
Reitwiessner, en Solidity, un smart contract es una
colección de código (sus funciones) y datos (su estado)
que reside en una dirección específica en la cadena de
bloques Ethereum69.
Algunos autores españoles se han pronunciado
con acierto respecto a la naturaleza de los smart
contract. Entre ellos, cabe destacar a PUYOL MON-
TERO70, quien opina que los smart contracts, también
denominados como “contratos digitales” o “contratos
inteligentes” son protocolos informáticos que facilitan,
mediante el uso de claves criptográficas seguras. Así, en uno de

los ejemplos que en el mismo se describen, se plantea la posibi-
lidad de crear un contrato de préstamo con garantía real sobre
un vehículo cuya puesta en marcha y funcionamiento se acciona
con firma digital. En caso de impago del préstamo por parte del
deudor el acreedor, recupera las claves criptográficas de control
y con ellas la libre posesión del vehículo
68
Si bien es cierto que el proceso de lanzamiento de la pla-
taforma fue gradual, su desarrollo se inició en el año 2013, tal y
como puede verse en el Sitio web: https://blog.ethereum.org/2015/03/14/
ethereum-the-first-year/. En la actualidad, los fundadores de Ethe-
reum, siguen considerando que se halla en fase “beta”
69
Traducido de la versión original en inglés “A contract in
the sense of Solidity is a collection of code (its functions) and
data (its state) that resides at a specific address on the Ethereum
blockchain”. Ob. Cit. Sitio web: http://solidity.readthedocs.io/en/deve-
lop/introduction-to-smart-contracts.html.
70
PUYOL, J. (3 de abril de 2016) ¿Qué son los “smart con-
tracts” o contratos digitales? Confilegal. Sitio web: https://confilegal.
com/20160403-los-smart-contrats-contratos-digitales/.
53
Carlos Tur Faúndez
verifican y hacen cumplir la negociación de un contrato

sin necesidad de tener una cláusula contractual.
En términos similares, PRENAFETA RODRÍ-
GUEZ71 considera que la mayoría de los artículos
que abordan este tema suelen definir los smart contracts
como aquellos contratos que pueden ejecutarse por sí
mismos, de forma automatizada y autónoma respecto a
las partes. Lo anterior no es una definición, ni muestra
sus notas características, ni mucho menos su naturaleza
jurídica, así que no sirve de mucho.
Los «contratos inteligentes» son secuencias de ins-
trucciones o indicaciones destinadas a ser utilizadas,
directa o indirectamente, en un sistema informático.
En la misma línea, MORELL RAMOS72 apunta
que un smart contract o contrato inteligente se refiere al
uso de código informático para articular, verificar y eje-
cutar un acuerdo entre las partes. Mientras que un con-
trato habitual está redactado mediante lenguaje natural,
los términos de un contrato inteligente se expresan en
código informático, como si de un script se tratara. De
ahí que digamos que es software.
PRENAFETA RODRÍGUEZ, J. (15 de septiembre de 2016)

71
Smart contracts: aproximación al concepto y problemática legal básica.

Diario la Ley. Sitio web: http://diariolaley.laley.es/Content/Documento.
aspx?params=H4sIAAAAAAAEAMtMSbF1CTEAAiNjM0sjQ7Wy1KLizPw8
WyMDQzMDC2OwQGZapUt-ckhlQaptWmJOcapack5qYpFLYkmqc2JOal5K
YpFtSFFpKgAq0AikTAAAAA==WKE.
MORELL RAMOS, J. (21 de Septiembre de 2016) Cómo
72
crear un smart contract con términos y condiciones. Legaltech, térmi-

nos y condiciones. Sitio web: https://terminosycondiciones.es/2016/09/21/
como-crear-smart-contract-mediante-terminos-condiciones/.
54
Smart Contracts
Ciertamente, el software no puede “eo ipso”

ostentar la condición de contrato, por lo que cabe
inferir que los primeros desarrolladores, con el fin
de rendir homenaje a la idea de smart contract pro-
puesta por Nick Szabo en 1998, decidieron hacer
uso de tal vocablo anglosajón, para referirse a cual-
quier secuencia de código informático que pudiera
ejecutar automáticamente alguna de las prestacio-
nes de un verdadero contrato.
Ya en el año 2015, los creadores de Ethereum y
Solidity decidieron que cualquier programa desa-
rrollado en Solidity, debe denominarse contract aun
cuando nada tenga que ver con un contrato con
significado y trascendencia jurídica real.
Véase el siguiente ejemplo73:
pragma solidity^0.4.13;
contract holaMundo {
string public frase= “¡Hola Mundo!”;
}
73
La secuencia de código consta de tres líneas: en la primera
se indica la versión del lenguaje de programación utilizado, en la
segunda, se da nombre al contrato y en la tercera se declara una
variable de tipo string (cadena de texto) con el nombre “frase” a
la que se atribuye la condición de pública, lo que significa que
será visible para todos aquellos que “llamen” (soliciten la eje-
cución) del programa. A dicha variable, se le atribuye un valor
que puede ser cualquier cadena de texto. En este caso “¡Hola
Mundo!”
55
Carlos Tur Faúndez
El programa es verdaderamente simple74 y

carece de cualquier utilidad práctica. Sin embargo,
se trata de un smart contract (concepto que nada
tiene que ver con el de contrato jurídicamente vin-
culante) y puede ser v, con éxito, en la cadena de
bloques de la EVM75 y lo es, simplemente, porque el
creador de Solidity decidió denominar de ese modo
a cualquier programa desarrollado en el lenguaje
mencionado sin tomar en consideración su propó-
sito o su alcance.
1.2. TRASCENDENCIA JURÍDICA DE LOS

SMART CONTRACTS
Sin perjuicio de lo expuesto anteriormente, debe
aclararse que los smart contracts se crean habitual-
mente con el objetivo de producir efectos jurídicos,
siempre y cuando se den las condiciones necesarias
para su ejecución automática.
Podemos distinguir, en consecuencia, entre
smart contracts jurídicamente irrelevantes, como
contract holaMundo referido en la página prece-
dente, y aquellos otros jurídicamente relevantes
como es el caso de contract arrendamientoVehiculo76
74
Conseguir que un programa se ejecute imprimiendo en
pantalla “Hola Mundo” o “Hello World”, es el primer obje-
tivo de un estudiante que se inicia en cualquier lenguaje de
programación.
75
EVM, son las siglas de Ethereum Virtual Machine
76
Este smart contract fue subido al repositorio GitHub, por
el creador de Solidity Christian Reitwiessner (“nickname” chri-
56
Smart Contracts
que proponemos en el Anexo 1, en el que se detalla

el código fuente del mismo y se explica de forma
detallada cada una de las instrucciones que lo com-
ponen, así como los efectos que se producen en
caso de ejecución.
El programa contract arrendamientoVehículo
una vez concluido su desarrollo, puede ser des-
plegado77 en el Sistema Ethereum (EVM), y desde
ese momento “residirá” en una dirección o cuenta
(address) específica de la cadena de bloques y dis-
pondrá de una cuenta propia (address), en la que
recibirá fondos y desde la cual los remitirá a terce-
ros cuando proceda.
“Con algo de imaginación” podríamos decir
que se asemeja, en cierta medida, a un formulario
de contrato y que, una vez completados los espacios
vacíos (lo que en programación sería atribuir un
seth) y puede verse el código en su versión original (inglés) así

como los comentarios y propuestas de otros creadores para su
mejora. El que consta en el anexo nº 1, es básicamente el mismo
programa, pero para una mejor comprensión de su contenido,
hemos traducido al castellano todas aquellas palabras, que no
son “tipos específicos” del lenguaje de programación y que por
ende no pueden ser traducidos, sin generar errores insalvables
de funcionamiento.
77
Traducción del vocablo anglosajón “deployed”. En pro-
gramación se utiliza el término “software deployment” para
referirse a cada una de las actividades necesarias para que un
programa a puesta se ponga en funcionamiento. Una explicación
del concepto puede hallarse en Wikipedia (lamentablemente
no disponible, en español) Sitio web: https://en.wikipedia.org/wiki/
Software_deployment.
57
Carlos Tur Faúndez
valor a las variables), se auto ejecutará tan pronto

como las partes proyecten su consentimiento sobre
el mismo, dando cumplimiento a las previsiones
legales que en cada caso correspondan.
Cualquier smart contract debidamente anclado a
la cadena de bloques está conceptuado para residir
en el back end78. Es cierto que existe una interfaz que
permite a los programadores acceder a la cadena
de bloques79, sin embargo, resulta ininteligible para
todos aquellos que desconocen el software y el par-
ticular funcionamiento de la plataforma.
De un modo u otro, es obvio que programas
como contract arrendamientoVehículo no son ni pue-
den ser contratos, pues están escritos para ser
“comprendidos” por un computador y no por un
ser humano. Sin embargo, como se expondrá a con-
tinuación, han sido creados para formar parte de
los mismos.
78
El front end, es la parte del software que interactúa con los
usuarios, dicho software es utilizado, fundamentalmente, para
la creación de páginas web que permiten el acceso a la infor-
mación de forma fácil mediante la construcción de una interfaz
gráfica. El back end, es el programa o conjunto de programas que
procesan la información que se proporciona a través del front
end. Para más información puede consultarse el Sitio web: https://
es.wikipedia.org/wiki/Front-end_y_back-end.
79
Dicha interfaz, recibe el nombre de Remix y puede acce-
derse a la misma en el siguiente sitio Web: https://remix.ethereum.
org/#version=soljson-v0.4.13+commit.fb4cb1a.js
58
Smart Contracts
2. LOS CONTRATOS LEGALES INTELIGENTES80
Al hilo de cuanto antecede es preciso indicar

que gracias a la biblioteca (API81) denominada
Web 3 JavaScript app API82, pueden desarrollarse
aplicaciones web perfectamente accesibles para
cualquier ciudadano medio83, y en cuya parte no
visible (back end) existe un smart contract84 que se
ejecuta de forma automática. Con ello queremos
80
El concepto de “smart legal contracts” lo propone Josh
Stark, abogado y jefe de operaciones de Ledger Labs, una firma
con sede en Toronto (Canadá) dedicada al desarrollo de soft-
ware para cadenas de bloques. STARK, considera que los “smart
legal contracts” deben asemejarse a una combinación de código infor-
mático y un lenguaje legal más tradicional. Traducido del artículo
original “Making Sense of Blockchain Smart Contracts”. Coin-
desk. 4 de junio de 2016. Sitio web: https://www.coindesk.com/
making-sense-smart-contracts/.
81
Sobre el significado del término API, véase
el siguiente sitio Web: https://es.wikipedia.org/wiki/
Interfaz_de_programaci%C3%B3n_de_aplicaciones.
82
El contenido íntegro de dicha API, con explicacio-
nes exhaustivas sobre su funcionamiento, puede hallarse
en el siguiente sitio Web: https://github.com/ethereum/wiki/wiki/
JavaScript-API#web3-javascript-app-api.
83
Aunque la aplicación no es operativa a día de hoy, en
el Sitio web: http://insureth.mkvd.net/ podemos hallar un ejemplo
ideado para la generación de contratos de seguro a corto plazo
que cubren los riesgos inherentes al retraso de los vuelos. El con-
tenido íntegro del código fuente escrito en Solidity que residirá
en el “back end” de la aplicación puede verse en el Sitio web:
https://github.com/bertani/insurETH/blob/master/contract/insurance.sol.
84
E incluso, en ocasiones, es necesaria la existencia de varios
smart contracts que interactúan entre sí y a su vez con el software
que compone el front end.
59
Carlos Tur Faúndez
significar que el contrato como concepto jurídico

no se circunscribe al smart contract, que es, como
se ha expuesto, un programa informático, sino que
alcanza a los mecanismos de interacción estableci-
dos por los desarrolladores de la interfaz y a través
de los cuales el usuario recibe y envía información.
Podemos definir, por tanto, los contratos legales
inteligentes como aquellos contratos celebrados a través
de una página web accesible para las partes cuya forma
está constituida por la interfaz de usuario de la aplica-
ción externa y uno o varios programas autoejecutables
(smart contracts) residentes en la cadena de bloques con
capacidad para interactuar recíprocamente y con dicha
interfaz85.
La interfaz de usuario, que puede asentarse
sobre una “aplicación web” o una “app” compatible
con dispositivos móviles, habilitará la interacción
de las partes con el software, y por tanto permitirá,
como se verá, la emisión válida del consentimiento
mediante mensajes de datos emitidos por las partes
a través de la aplicación front end86. Sin embargo,
la novedad de estos contratos consiste en que el
smart contract que reside en el back end, no es un
instrumento inerte del contrato legal inteligente, pues
85
Huelga decir, que el contrato, sólo será contrato, si cumple
con los requisitos esenciales exigidos por la Ley, por lo que en
caso contrario, su ineficacia podrá ser ulteriormente declarada
por los tribunales ordinarios.
86
Vid. Supra sección II, apartado 1.2.
60
Smart Contracts
ha sido programado para “actuar” siempre que se

den determinadas condiciones.
El smart contract jurídicamente relevante es el
instrumento creado para la ejecución automática
del contrato legal inteligente e intervendrá, normal-
mente, como un tercero inexorable que, de produ-
cirse un evento para el que esté programado87:
a) Podrá recibir fondos de la cuenta de un
deudor;
b) Podrá cobrar automáticamente de la cuenta
de un deudor88 y transferir los fondos a su
propia cuenta o a la del acreedor, con o sin
intereses (siempre y cuando haya fondos en
la cuenta del deudor);
c) Podrá retener fondos en su propia cuenta;
d) Podrá recibir información sobre cualquier
hecho constatable en el mundo exterior y
actuar en consecuencia.
e) Podrá ordenar que cualquier mecanismo
electrónico exterior interconectado al
programa:
e.i. Se inicie o detenga;
e.ii. Se encienda o se apague;
e.iii. Se bloquee o desbloquee;
87
Se trata de una relación meramente enunciativa, que no
exhaustiva.
88
Siempre y cuando se trate de una contract account y el
smart contract al que está vinculada haya sido programado a tal
efecto. La interacción de las EOA (cuentas externas) con los smart
contracts está limitada al envío o recepción de fondos.
61
Carlos Tur Faúndez
f) Podrá ordenar la detención de su propia

autoejecución;
g) Podrá ordenar su autodestrucción, en cuyo
caso jamás volverá a estar operativo en la
cadena de bloques.
Se constata, por tanto, que la relación existente
entre las partes de un contrato legal inteligente, no es
una relación directa e inmediata, sino que se ins-
trumenta siempre a través de un smart contract, de
modo que:
—— En fase de formación, el consentimiento
de las partes es el hecho determinante que
desencadena el inicio de la ejecución auto-
mática, por lo que el smart contract, debe
permanecer en estado latente, hasta que
reciba un mensaje de datos indicador de su
aceptación.
—— En fase de ejecución, en tanto las contra-
prestaciones se hallan automatizadas, las
partes permanecen expectantes, a la espera
de que el cumplimiento se produzca sin el
concurso de sus voluntades.
Si hacemos uso de la nomenclatura habitual en
el mundo del ecommerce podemos afirmar que no
estamos ante una relación B2B o B2C pura sino,
más bien, ante un nuevo concepto de relación jurí-
dica B-SC-B, o en su caso B-SC-C, donde las inicia-
62
Smart Contracts
les SC, corresponderían al smart contract sobre el

que se estructura el contrato legal inteligente.
Debemos hacer especial hincapié en un hecho
extremadamente relevante. Tal y como se ha ade-
lantado al conceptuar el contrato legal inteligente,
pueden ser varios los smart contracts residentes en
el back end los que constituyan el instrumento de la
ejecución automática de las contraprestaciones. En
lo sucesivo, nos referiremos al smart contract subya-
cente, sea uno o sean varios interrelacionados, los
que concurran en cada caso.
3. LOS CONTRATOS LEGALES INTELIGENTES

A LA LUZ DE LOS PRINCIPIOS Y ELEMEN-
TOS DEL DERECHO DE LA CONTRATACIÓN
ELECTRÓNICA
En sesión plenaria de 16 de diciembre de 1996, la

Asamblea General de las Naciones Unidas aprobó
la Ley Modelo de Comercio Electrónico de CNUDMI/UNCI-
TRAL89, que determinaría, en lo sucesivo, la estruc-
tura del Derecho del comercio electrónico.
ILLESCAS ORTIZ enumera los cinco principios
esenciales que se derivan de dicho texto legal y los
califica como líneas maestras a través de las cuales
89
Vid. Sitio web: https://www.uncitral.org/pdf/spanish/texts/
electcom/05-89453_S_Ebook.pdf.
63
Carlos Tur Faúndez
su disciplina –convencional, judicial y legal- ha de ser

establecida (…)90. Son los siguientes:
a) Equivalencia de los actos electrónicos respecto
de los autógrafos o manuales. (art. 5 de la Ley
Modelo de Comercio Electrónico) Dicho
principio se halla reflejado en nuestra nor-
mativa interna, fundamentalmente en el artí-
culo 23 de la Ley 34/2002 de 11 de julio, de servicios
de la sociedad de la información y de comercio elec-
trónico, y en el artículo 3 de la Ley 59/2003, de 19
de diciembre, de firma electrónica.
b) Neutralidad tecnológica de las disposiciones
reguladoras del comercio electrónico. Se pre-
tende con ello que las normas sean cons-
truidas de tal modo que su vigencia no se
vea comprometida cada vez que se produce
un avance tecnológico.
c) Inalterabilidad del Derecho preexistente en
materia de obligaciones y contratos. La contra-
tación electrónica es un mero instrumento a
través del cual se canalizan las voluntades
negociales y ello no tiene por qué significar
la modificación del Derecho que regula las
mismas.
d) Exigencia de buena fe (consagrado en el artí-
culo 3.1 de la Ley Modelo de Comercio
Electrónico).
ILLESCAS ORTIZ, Rafael. Derecho de la Contratación Elec-

90
trónica, 2ª edición, Civitas, Madrid, 2009, pág. 35.
64
Smart Contracts
e) Reiteración del principio de libertad de pacto

(art. 4.1 de la Ley Modelo de Comercio
Electrónico).
Por otra parte, la Ley Modelo distingue dos
tipos de elementos, los objetivos y los subjetivos.
Los elementos objetivos son tres:
a) Los mensajes de datos o data message (DM),
entendiéndose por éstos la información
enviada, recibida o archivada o comunicada
por medios electrónicos, ópticos o simila-
res, como pudieran ser, entre otros, el inter-
cambio electrónico de datos (EDI), el correo
electrónico, el telegrama, el télex o el telefax.
b) La firma electrónica, regulada hoy en España
mediante la Ley 59/2003, de 19 de diciembre de
firma electrónica.
c) Los sistemas de información. Se entenderán
como tales cualesquiera sistemas utiliza-
dos para generar, enviar, recibir, archivar o
procesar de alguna otra forma mensajes de
datos.
Asimismo, la Ley Modelo de Comercio Electró-
nico define los elementos subjetivos del siguiente
modo:
a) Por iniciador de un mensaje de datos se
entenderá toda persona que, a tenor del
mensaje, haya actuado por su cuenta o en
cuyo nombre se haya actuado para enviar o
65
Carlos Tur Faúndez
generar ese mensaje antes de ser archivado,

si éste es el caso, pero que no haya actuado
a título de intermediario con respecto a él;
b) Por destinatario de un mensaje de datos se
entenderá la persona designada por el ini-
ciador para recibir el mensaje, pero que no
esté actuando a título de intermediario con
respecto a él;
c) Por intermediario, en relación con un deter-
minado mensaje de datos, se entenderá toda
persona que, actuando por cuenta de otra,
envíe, reciba o archive dicho mensaje o
preste algún otro servicio con respecto a él.
El artículo 13 regula la atribución de los mensa-
jes de datos, entendiendo que el mensaje de datos,
provendrá del iniciador si ha sido enviado por éste,
o también:
a) Por alguna persona facultada para actuar
en nombre del iniciador respecto de ese
mensaje;
b) Por un sistema de información programado
por el iniciador o en su nombre para que
opere automáticamente.
Es obvio que los elementos objetivos y subjeti-
vos antes aludidos han sido diseñados sobre la idea
de que la contratación electrónica se asienta sobre
una relación bilateral (B2B o B2C). Sin embargo los
66
Smart Contracts
contratos legales inteligentes introducen un nuevo

reto tecnológico, como es el smart contract.
El smart contract carece de personalidad y, por
ende, no ostenta ni puede ostentar la condición
de parte, puesto que es un instrumento creado
para su servicio. Por idénticos motivos, no puede
ser un árbitro con facultades resolutorias. Ahora
bien, desde una perspectiva práctica y al margen
del debate filosófico existente respecto al alcance
del pensamiento artificial91 y la posible atribución a
los computadores de acciones humanas (entre las
que se encuentran la comunicación y recepción de
información, la toma de decisiones y el desarrollo
de acciones consecuentes), es incuestionable que el
smart contract92(si así ha sido programado) puede:
a) Recibir mensajes, puesto que el consenti-
miento debidamente manifestado por las
partes deberá ser “comunicado” al smart con-
tract para que se desencadene su ejecución.
b) Remitir mensajes a las partes, en tanto
comunica a éstas sus acciones.
91
En la filosofía moderna, permanece sin respuesta la
siguiente pregunta: ¿Pueden pensar los ordenadores? La Uni-
versidad de Stanford ha publicado un mapa conceptual sobre la
historia y el estado del debate que puede observarse en el Sitio
web: https://web.stanford.edu/~rhorn/a/topic/phil/artclISSAFigure1.pdf.
92
Vid. Supra sección II apartado 1 sobre el concepto de smart
contract.
67
Carlos Tur Faúndez
c) Decidir si se dan las condiciones adecua-

das y actuar en consecuencia pagando,
cobrando, abriendo, cerrando, etc.…
d) Resolver de forma automática en caso de
incumplimiento (por falta de transferencia
de fondos o en su caso, por falta de saldo
en la cuenta de deudora) impidiendo la
continuidad de la prestación pactada (V.g.
sistema de puesta en marcha de vehículo).
No es difícil concluir, por tanto, que en un con-
trato legal inteligente correctamente desarrollado, el
smart contract subyacente es la herramienta infor-
mática que determina cómo, cuándo y en qué
forma se llevará a efecto la ejecución de las con-
traprestaciones pactadas por las partes, por lo que
al amparo de lo dispuesto en el artículo 3.1 de la
Ley Modelo del Comercio Electrónico, y los artícu-
los 7 y 1.256 CC debe ser construido respetando el
principio general de la buena fe y justo equilibrio
de las contraprestaciones, toda vez que la validez
y el cumplimiento del contrato legal inteligente, no
puede quedar al arbitrio de uno de los contratantes.
Sentado lo anterior, aún en el supuesto de que
la relación habida entre las partes, sea B2C o B2B,
pero basada en cláusulas predispuestas, para inte-
grar un contrato legal inteligente plenamente eficaz,
el smart contract deberá contar con las siguientes
características:
68
Smart Contracts
a) Imparcialidad. El smart contract debe ser pro-

gramado sin favorecer la posición domi-
nante de una de las partes.
b) Independencia. El smart contract sirve o debe
servir por igual los intereses de ambas par-
tes, por lo que, una vez prestado el consen-
timiento sobre el mismo, su ejecución debe
llevarse a cabo sin que pueda ser dete-
nida o modificada en beneficio de la parte
dominante.
Atendido cuanto se ha expuesto, la realidad
práctica nos conduce a la necesidad de afirmar que
un smart contract:
a) Envía mensajes de datos, luego es iniciador
de los mismos;
b) Recibe mensajes de datos, luego es destina-
tario de los mismos;
c) Presta servicios comunes a ambas par-
tes, luego, en cierta medida, actúa como
intermediario.
d) Realiza las prestaciones sin ser parte.
e) Puede adoptar medidas ejecutivas en caso
de incumplimiento sin ostentar la condición
de árbitro o de Juez.
Como sistema de información, el smart contract
es, o debe ser, también, imparcial e independiente,
puesto que se halla inserto en una cadena de blo-
ques inmutable y descentralizada. No cabe pensar,
69
Carlos Tur Faúndez
en este caso, en un servidor perteneciente al pres-

tador de servicios en el que reside el software y en
consecuencia, puede ser manipulado por éste.
Constituye una característica absolutamente
necesaria de los smart contracts, en tanto determina
su confiabilidad, el hecho de que no se hallen bajo
la esfera de dominio de ninguna de las partes, de
forma que su ejecución se desarrolle según lo pac-
tado, de forma automática y sin posibles injerencias.
Es lo cierto que, el avance de las nuevas tecnolo-
gías se conduce a un ritmo vertiginoso, de tal modo
que, a día de hoy, resultan absolutamente imprede-
cibles los elementos con los que en el futuro contará
la contratación electrónica. Lamentablemente, nos
vemos obligados a afirmar que lo mismo ocurrió en
el año 1996, cuando entró en vigor la Ley Modelo
de Comercio Electrónico, sin duda con vocación de
permanencia.
Del mismo modo, si bien extremando la pru-
dencia, queremos significar que algunos de los
denominados principios de la contratación electrónica
en un futuro no muy lejano, o bien acusarán cierta
70
Smart Contracts
obsolescencia93 o bien quedarán como loables obje-

tivos de difícil cumplimiento94.
4. LA FORMACIÓN DE LOS CONTRATOS LEGA-

LES INTELIGENTES
4.1. OBLIGACIONES DE INFORMACIÓN ANTE-

RIORES Y POSTERIORES A LA CELEBRACIÓN
DEL CONTRATO
El artículo 23 de la Ley 34/2002, de 11 de julio, de servicios
de la sociedad de la información y de comercio electrónico
y de comercio electrónico, determina los requisi-
tos para la validez y eficacia de los contratos cele-
brados por vía electrónica, mediante una remisión
93
Es el caso del principio de equivalencia funcional, cuya
utilidad hasta el día de hoy es indudable, del mismo modo que
lo fue en el año 1900, la Real Orden publicada en la Gaceta de
Madrid de 19 de Febrero por la que se admitían en las oficinas
administrativas escritos e instancias redactados a máquina, con
el mismo valor que los manuscritos. Puede verse el documento
en el siguiente Sitio web: https://www.boe.es/datos/pdfs/BOE/1900/050/
A00607-00607.pdf.
94
Loable es, efectivamente, que el legislador redacte las
normas aplicables al comercio electrónico con previsión de los
avances tecnológicos predecibles a fin de evitar la inseguridad
jurídica que generan los constantes cambios legislativos. No
obstante lo anterior, consideramos que un excesivo inmovilismo
normativo, acabará por abrir una brecha entre la realidad tecno-
lógica y la Ley, lo que convertirá esta última en un instrumento
inútil.
71
Carlos Tur Faúndez
genérica a los contenidos del Código civil y Código

de Comercio, las restantes normas civiles y mer-
cantiles sobre contratos y las normas de protección
de consumidores y usuarios y de ordenación de
la actividad comercial. Es incuestionable que los
contratos legales inteligentes, en tanto se celebran a
través de aplicaciones web interconectadas electró-
nicamente con una cadena de bloques, entran en el
ámbito de aplicación del artículo 23 LSSICE y, en
su caso, en el de las normas de la Ley 7/1998, de 13 de
abril, sobre condiciones generales de la contratación95 y la
Ley General para la Defensa de los Consumidores y Usua-
rios96,
en las que se prevén requisitos específicos de
validez cuya ausencia pueden determinar la inefi-
cacia de determinadas cláusulas contractuales97y,
en su caso, la de todo el negocio jurídico.
Atendidas las singulares características de la
contratación electrónica, el legislador con el obje-
tivo de paliar, en cierta medida, la falta de con-
fianza que puede generar el uso de las nuevas
95
Vid. Art. 5.1 y ss. de la LCGC.
96
Vid. Arts. 60.1 y 97.1 del TRLGDCU.
97
La nulidad parcial, cabrá exclusivamente en aquellos
supuestos en los que la invalidez de una cláusula o acuerdo, no
afecte plenamente al contrato, de forma que este pueda seguir
subsistiendo, por aplicación del principio general de conserva-
ción de los contratos. Aunque el Código civil, no contiene una
norma general en la que se recoja tal principio, son múltiples los
preceptos en los que se establece que la nulidad de una cláusula,
no afecta a la validez del resto del contrato. Ejemplo de ello
son los artículos 1.155, 1.260, 1.476, 1608, 1691 y 1826 de dicho
Cuerpo Legal.
72
Smart Contracts
tecnologías, ha establecido una serie de garantías

extraordinarias en los artículos 10 y 12 bis, así como
en los artículos 27 y 28 de la LSSICE, pudiéndose cons-
tatar que el artículo 39 de dicha Ley prevé sanciones
que pueden alcanzar los 150.000 € para los casos
más severos98.
En supuestos de contratación B2C el empresa-
rio deberá cumplir, además, con los requisitos for-
males y de información previstos en el artículo 97 y 98
de la TRLGDCU, estableciéndose para el caso de que
no lo haga un régimen de sancionador especial-
mente agravado, puesto que de conformidad a lo
dispuesto en el artículo 51 (en relación con el 50.2 y
con el 49.2b) de la mencionada ley, el importe de la
sanción oscila entre los 3.005,07 y los 601.010,10 €.
4.2. MOMENTO DE PERFECCIÓN DEL CON-

TRATO
El artículo 1.262 CC, en su párrafo tercero, dis-
pone que en los contratos celebrados mediante dispo-
sitivos automáticos hay consentimiento desde que se
manifiesta la aceptación, siendo absolutamente idén-
tico el texto contenido en el artículo 54.2 del C.co.. No
requiere, pues, más consideraciones, la elemental
afirmación de que los contratos legales inteligentes
Los artículos 39 bis y 40 de la LSSICE, establecen los crite-

98
rios en los que debe basarse el órgano sancionador para graduar

la cuantía de las sanciones y la posibilidad de moderarla cuando
concurran determinadas circunstancias.
73
Carlos Tur Faúndez
son contratos electrónicos desarrollados a través de

dispositivos automáticos, resultando ser de aplica-
ción tales preceptos.
Nada obsta para que la formación de un contrato
legal inteligente pueda desarrollarse en una relación
B2B (es decir, entre empresarios y en el ámbito de
la contratación mercantil), en la que no existe una
parte predisponente, de tal forma que el smart
contract subyacente y en su caso, los restantes ele-
mentos informáticos de la aplicación, puede dise-
ñarse o adaptarse en función de los tratos y nego-
ciaciones preliminares habidas entre las partes99.
En tales casos no existirá una oferta predispuesta
por el prestador de servicios de la sociedad de la
información, del mismo modo que, como ocurre
en la contratación tradicional, no existirá un lapso
de tiempo significativo entre las declaraciones de
voluntad de las partes en las que se manifiesta el
consentimiento.
A consecuencia de lo anterior, la perfección del
contrato se producirá en el preciso instante en el
que cada una de las partes desarrolle los actos que,
previamente, se hayan programado como necesa-
Podría ser el caso de un contrato de leasing internacional

99
entre un fabricante de aeronaves comerciales y una línea aérea.

La cuantía económica de la operación justificaría “con creces”
la negociación de las partes y la participación de las mismas en
la configuración del contrato final.
74
Smart Contracts
rios en la aplicación residente en el front end100 para

considerar válidamente emitido el consentimiento
de las partes101. En todo caso, deben definirse en la
aplicación los concretos actos que, como manifes-
tación de consentimiento indubitado, generará la
remisión de un mensaje de datos al smart contract
residente en el back end102, a fin de que inicie auto-
máticamente el proceso de ejecución.
Sin perjuicio de lo expuesto anteriormente, no
existe duda de que en la mayoría de los contratos
legales inteligentes, el prestador de servicios de la
sociedad de la información será parte predispo-
nente, siendo múltiples las ocasiones en las que la
otra parte ostentará, además, la condición de con-
sumidor y usuario.
En estos supuestos adquiere especial significa-
ción y relevancia la oferta, entendida como toda la
información existente bien en la página web del
prestador de servicios de la sociedad de la infor-
100
Vid. Supra sección II, apartado 1.2, nota a pie de página
número 79
101
Los desarrolladores del software de la aplicación web,
pueden y deben, establecer una secuencia de actos exigibles al
contratante para que manifieste su consentimiento de modo
indubitado. Normalmente Los artículos 39 bis y 40 de la LSSICE,
establecen los criterios en los que debe basarse el órgano sancio-
nador para graduar la cuantía de las sanciones y la posibilidad
de moderarla cuando concurran determinadas circunstancias.
102
Vid. Supra sección II, apartado 1.2, nota a pie de página
número 79
75
Carlos Tur Faúndez
mación, bien en otros medios o sitios web103 que

puedan constituir una declaración de voluntad
dirigida a una o varias personas y proponiendo
la celebración de un contrato. El contenido de la
oferta es extremadamente relevante, pues deter-
mina y configura la representación mental que el
contratante se formula respecto al negocio jurí-
dico en cuestión y en base a la cual otorgará el
consentimiento.
Con respecto al tiempo de vigencia de las ofer-
tas realizadas por medios electrónicos, el párrafo
3 del artículo 27 de la LSSICE establece que serán
válidas durante el período que fije el oferente o,
en su defecto, durante todo el tiempo que perma-
nezcan accesibles a los destinatarios del servicio.
4.3. EL LUGAR DE LA PERFECCIÓN DEL CON-

TRATO
Según dispone el artículo 29 LSSICE, en aquellos
contratos en los que intervenga un consumidor el
contrato se entenderá celebrado en el lugar en que
éste tenga su residencia habitual. En los contratos
entre empresarios o profesionales, el pacto entre
103
Como es sabido, el alcance de la publicidad, especial-
mente en Internet, es extremadamente amplio. Con servicios
como Google Adsense, podemos encontrarnos con anuncios de
servicios en los que de algún modo hemos mostrado nuestro
interés en los lugares más insospechados. Más información
podemos hallarla en el Sitio web: https://support.google.com/adsense/
answer/6242051?hl=es.
76
Smart Contracts
las partes determinará el lugar de celebración del

contrato. A falta de pacto, el contrato se entenderá
celebrado en el lugar en que esté establecido el
prestador de servicios.
4.4. CONTRATOS LEGALES INTELIGENTES

CELEBRADOS ENTRE UN EMPRESARIO Y UN
CONSUMIDOR. EL DERECHO DE DESISTI-
MIENTO EN LOS CONTRATOS LEGALES INTE-
LIGENTES
La peculiar estructura de los “contratos lega-
les inteligentes” impide que el consumidor pueda
negociar su contenido obligacional, puesto que
a la habitual posición de desventaja que se hace
patente en los contratos tradicionales, se suma el
lógico desconocimiento de las tecnologías sobre las
que se construye. De tal premisa, se infiere como
indefectible consecuencia la calificación jurídica de
tales acuerdos de voluntades como contratos de
adhesión, de modo que resultarán aplicables a los
mismos las normas contenidas en la LCGC. Aun
así, cuando el destinatario final de los bienes o ser-
vicios sea una persona física o jurídica que actúa en
un ámbito ajeno a su actividad empresarial y sin
ánimo de lucro, el contrato legal inteligente entrará
en el ámbito de aplicación de la Ley General para
la Defensa de los Consumidores y Usuarios.
Especial relevancia cabe atribuir al derecho de
desistimiento en el contrato de compraventa, en
77
Carlos Tur Faúndez
el supuesto de que nos hallemos ante un “contrato

legal inteligente” en el que es parte un consumidor.
El artículo 71.2 del TRLGDCU establece un plazo
de 14 días para el ejercicio del derecho, cuyo cóm-
puto se inicia el día de la recepción del bien, no
obstante lo cual, en el caso de que el vendedor no
hubiera informado debidamente al consumidor de
la existencia del derecho al desistimiento, el plazo
se prorrogará durante 12 meses más104.
En los contratos legales inteligentes, el derecho
de desistimiento debe ser tomado en consideración
por el desarrollador del programa (“contract”) que
se integra en la cadena de bloques e incluir en el
mismo las instrucciones necesarias para que se
haga efectivo105.
104
Ejercido el derecho de desistimiento, el vendedor deberá
reembolsar al comprador todo lo pagado, antes de 14 días desde
la comunicación del ejercicio del derecho, pudiendo exigir el
pago del doble del importe adeudado, en caso de retraso injusti-
ficado. Serán nulas de pleno derecho cualesquiera cláusulas que
impongan penalizaciones al comprador en caso de desistimiento.
El artículo 103 del TRLGDCU, establece de forma detallada
todos los supuestos en los que no es aplicable el derecho de
desistimiento.
105
Un posible sistema para hacer efectivo el desistimiento
sería el siguiente:
El precio de la compraventa, quedaría depositado en la
cuenta del “contract” como mínimo 14 días computables desde
la fecha máxima prevista para la entrega.
El comprador, y sólo el comprador, a través de la oportuna
aplicación, podría remitir desde una cuenta vinculada a otro
smart contract (proxy contract), un mensaje al programa principal
78
Smart Contracts
4.5. ELEMENTOS DE LOS CONTRATOS LEGA-

LES INTELIGENTES
El artículo 1.261 del CC aplicable, pues, a todos
los contratos electrónicos, dispone lo siguiente:
No hay contrato sino cuando concurren los requisitos
siguientes:
1º Consentimiento de los contratantes.
2º Objeto cierto que sea materia del contrato.
3º Causa de la obligación que se establezca.
En las páginas sucesivas, analizaremos las

peculiaridades que en torno a dichos elementos
pueden presentar los contratos legales inteligentes,
para referirnos, más adelante, a la forma, por ser
especialmente relevante, para tales contratos, aún
cuando el artículo 1.278 del CC confiere plena liber-
tad en este aspecto.
(contract) comunicando su voluntad de desistir. Para ello debería

crearse una función (function) específica.
El precio de la compraventa, permanecería, en tal caso,
depositado en la cuenta del contrato, durante 72 horas más,
plazo razonable para que el vendedor pudiera recoger el bien
objeto de devolución.
Transcurridas 72 horas el programa (contract) ejecutaría,
automáticamente, otra función (function) a la que se podría deno-
minar restitucionPrecio, por virtud de la cual, la suma depositada,
sería remitida automáticamente a la cuenta del comprador.
79
Carlos Tur Faúndez
4.5.1. EL CONSENTIMIENTO “PRECONSTITUIDO”

EN LOS CONTRATOS LEGALES INTELIGENTES. EL
ERROR VICIO
Como bien es sabido, en el devenir de un

contrato cabe distinguir tres fases claramente
diferenciadas:
Una primera fase de generación, que comprende
las diversas acciones desarrolladas por las partes
con el fin de alcanzar un acuerdo futuro.
Una segunda fase de perfección, en la que se pro-
duce el consentimiento de ambas partes, quedando
obligadas desde ese momento al cumplimiento de
las contraprestaciones.
Una tercera fase de consumación, con el objetivo
de cumplir la finalidad del contrato, mediante la
realización de las contraprestaciones.
En los contratos tradicionales se suele pres-
tar atención a la concurrencia de la “voluntad de
obligarse” de las partes, que genera la perfección
del contrato. Existe, sin embargo, un segundo
momento en el que cada una de las partes tiene
que consentir, siquiera implícitamente, y éste es el
momento en el que cumple mediante la realización
de la prestación que le corresponde. Dicho consen-
timiento implícito en la realización de la acción,
aún siendo obvio, en la mayoría de los casos es
absolutamente trascendente, en la medida de que,
80
Smart Contracts
de no producirse106, podría derivar en la ineficacia

de la consumación contractual.
Como se ha indicado “ut supra”, en los contratos
legales inteligentes la realización de las prestaciones
y, por ende, la consumación del contrato, la lleva
a efecto el propio smart contract sin requerir, en
absoluto, el consentimiento de las partes en fase
de ejecución, puesto que dicha fase se desarrolla
de forma automática107.
A tenor de lo expuesto, en los contratos legales
inteligentes se requiere la concurrencia de un doble
consentimiento simultáneo:
a) El habitual consentimiento que determina
la perfección del contrato (las partes se obli-
gan a obligarse).
b) El consentimiento preconstituido sobre la
consumación automática. Es decir, cada una
de las partes debe aceptar, expresamente,
que la prestación objeto de su obligación
será realizada automáticamente por el smart
contract en las condiciones pactadas y sin
recabar para ello su autorización.
106
Imagínese un supuesto, en el que habiendo consentido
libremente, una de las partes es obligada, después, a cumplir la
prestación mediante violencia o intimidación.
107
En ocasiones, no todas las prestaciones se desarrollarán
de forma automática, por lo que, habrá que estar en cuanto a
ellas a los criterios generales que se mantienen para el resto de
supuestos de contratación electrónica.
81
Carlos Tur Faúndez
Las disposiciones generales reguladoras del

consentimiento, se contienen en los artículos 1.261 y
ss. del Código civil. En el caso que nos ocupa, por tra-
tarse de un contrato suscrito a través de dispositivos
automáticos, habrá consentimiento en el momento
en el que, concurriendo la oferta, se manifieste la
aceptación (qrt. 1.262.2 CC). En el mismo sentido
se regula la perfección del contrato en el artículo
54.2 del C.co..
Asimismo, según el artículo 1.266 CC, para que
el error invalide el consentimiento, deberá recaer sobre la
sustancia de la cosa que fuere objeto del contrato, o sobre
aquellas condiciones de la misma que principalmente
hubiesen dado motivo a celebrarlo.
El Tribunal Supremo se ha pronunciado sobre
la cuestión108 en la STS 354/2014, de 20 de enero de 2014
(más recientemente en STS de 30 de diciembre de
2015), en los siguientes términos:
“La regulación del error vicio del consentimiento
que puede conllevar la anulación del contrato se halla
contenida en el Código civil, en el art. 1.266 CC, en
relación con el art. 1.265 y los arts. 1.300 y ss. Sobre esta
normativa legal, esta Sala primera del Tribunal Supremo
ha elaborado una doctrina jurisprudencial, de la que nos
hemos hecho eco en las ocasiones anteriores en que nos
hemos tenido que pronunciar sobre el error vicio en la
Las sentencias aludidas hacen referencia al error vicio del

108
consentimiento sobre contratos SWAP, celebrados entre empre-

sarios y entidades bancarias.
82
Smart Contracts
contratación de un swap, en las Sentencias 683/2012,

de 21 de noviembre, y 626/2013, de 29 de octubre: Hay
error vicio cuando la voluntad del contratante se forma
a partir de una creencia inexacta. Es decir, cuando la
representación mental que sirve de presupuesto para la
realización del contrato es equivocada o errónea [...]”.
No nos consta que, a día de hoy, exista un pro-
nunciamiento expreso de un órgano jurisdiccio-
nal español en cuanto a las particularidades de la
ejecución automática de los contratos electrónicos
como cualidades o condiciones del objeto de los
mismos. Sin embargo, es incuestionable que el Tri-
bunal Supremo ha optado por configurar un con-
cepto subjetivo del “error vicio” consistente en una
representación ideal inexacta que ha conducido al
aceptante de la oferta a expresar su consentimiento.
Ello nos conduce a la ineludible conclusión de
que en los contratos legales inteligentes (con inde-
pendencia de la teoría doctrinal sobre el objeto109 y
la causa110 que se sostenga) el consentimiento debe
recaer sobre:
109
Respecto a las diversas posiciones doctrinales
sobre el objeto de los contratos Vid. AGUILERA SILVÁN,
F. J., El objeto como elemento esencial del contrato. Noticias
Jurídicas. Sitio web: http://noticias.juridicas.com/conocimiento/
articulos-doctrinales/4648-el-objeto-como-elemento-esencial-del-contrato/.
110
Sobre las diversas teorías causalistas y anticausalis-
tas, Vid. MELICH ORSINI, J., La causa en la teoría del contrato.
Anuario de derecho civil. Vol. 37, nº 1, 1984, págs. 3-62. Sitio web:
https://www.boe.es/publicaciones/anuarios_derecho/abrir_pdf.php?id=ANU-
83
Carlos Tur Faúndez
a) Qué prestaciones concretas se van a realizar.

b) Cómo, cuándo y por qué se van a realizar.
c) Cuáles son las consecuencias de su no reali-
zación (en la medida en que el deudor siem-
pre va a tener en su mano la posibilidad
de dejar en saldo 0 su cuenta de cargo, es
posible hablar de incumplimiento).
Cabe concluir, pues, que los contratos legales
inteligentes deben proporcionar a las partes infor-
mación clara, precisa, exhaustiva y comprensible
sobre los procedimientos mediante los que se va
a desarrollar la ejecución automática de las pres-
taciones y su alcance patrimonial, a fin de evitar
representaciones mentales inexactas que puedan
invocarse en el supuesto de que en el futuro se
ejercite la acción de anulabilidad prevista el artí-
culo 1.301 CC.
4.5.2. EL OBJETO Y LA CAUSA EN LOS CONTRATOS

LEGALES INTELIGENTES
Según el tenor literal del artículo 1.271 CC:

Pueden ser objeto de contrato todas las cosas que no están
fuera del comercio de los hombres, aun las futuras (…).
(…) Pueden ser igualmente objeto de contrato todos los
servicios que no sean contrarios a las leyes o a las buenas
costumbres.
C-1984-10000300062_ANUARIO_DE_DERECHO_CIVIL_La_causa_en_la_
teor%EDa_del_contrato_y_sus_diversas_funciones.
84
Smart Contracts
Asimismo, el artículo 1.272 CC, dispone que

no podrán ser objeto de contrato las cosas o servicios
imposibles.
Bajo nuestro punto de vista, el objeto no pre-
senta, por lo demás, especialidades significativas
en los contratos legales inteligentes.
El artículo 1.274 CC establece que en los contratos
onerosos se entiende por causa, para cada parte contra-
tante, la prestación o promesa de una cosa o servicio
por la otra parte; en los remuneratorios, el servicio o
beneficio que se remunera, y en los de pura beneficencia,
la mera liberalidad del bienhechor.
LACRUZ BERDEJO considera que, en los con-
tratos sinalagmáticos típicos, la causa de la atribución
-de derecho real o de crédito- es la contraprestación pac-
tada o la expectativa de obtenerla111. El mismo autor,
profundiza en la idea de la causa, analizando los
aspectos subjetivos de ésta y la eficacia jurídica del
motivo (o motivos) considerando como tal, cualquier
circunstancia cuya representación intelectual determina
al sujeto a querer el acto. Según su acertado punto de
vista, el motivo causalizado de la más reciente jurispru-
dencia se sitúa en la línea de la presuposición o la base del
negocio, siendo definido este último concepto como
aquellos motivos y representaciones que, aun siendo pro-
pios de una situación concreta y de la subjetividad de
unos determinados contratantes, son compartidos por
LACRUZ BERDEJO, J. L., Elementos de Derecho civil II.

111
Derecho de obligaciones, Dykinson, Madrid, 2003, pág. 421 y ss.
85
Carlos Tur Faúndez
todos y suponen para ellos un presupuesto y condición

de la efectividad de lo convenido.
LACRUZ BERDEJO no se muestra partidario
de considerar como “contratos sin causa” que con
arreglo a lo dispuesto en el artículo 1.275 CC “no
producen efecto alguno” a aquellos en los que falla
la base del negocio, considerando más apropiado
calificarlos como anulables.
Debe destacarse que en los contratos legales
inteligentes la ejecución se producirá (en todo o en
parte) de forma automática, en tanto en cuanto así
ha sido previsto en el programa (smart contract)
que reside en una determinada cuenta o dirección
(address) de la cadena de bloques y sobre el que se
ha construido íntegramente la aplicación a través
de la cual se forma el contrato. Siendo esto así, la
ejecución automática tal y como haya sido repre-
sentada mentalmente por los contratantes, forma
parte, a nuestro juicio, de la base del negocio en el
sentido antes apuntado, de modo que la ausencia
de ésta determinará el nacimiento de la acción de
anulabilidad prevista en el artículo 1.301 CC.
El artículo 1.262 CC identifica el objeto y la causa
como aquellos elementos del contrato sobre los que
se proyecta el consentimiento de las partes. La
aceptación de un concepto de causa por el que se
confiere eficacia jurídica a los motivos compartidos
por las partes como condición de efectividad de lo
convenido, puede explicar la concurrencia de error
por vicio del consentimiento. Así pues, en aquellos
86
Smart Contracts
contratos legales inteligentes en los que una de las

partes no haya manifestado su voluntad de acep-
tación sobre la particular naturaleza de la ejecución
de las prestaciones, existirá la posibilidad de que
ésta ejercite la acción de anulabilidad en términos
similares a los previstos en la página precedente.
4.5.3. LA FORMA EN LOS CONTRATOS LEGALES

INTELIGENTES
El artículo 1.278 CC, cuyo texto dispone que “Los

contratos serán obligatorios, cualquiera que sea la forma
en la que se hayan celebrado, siempre que en ellos con-
curran las condiciones esenciales para su validez”, con-
sagra el principio de libertad de forma aplicable a
todos los contratos.
Asimismo, el artículo 23.2 de la LSSICE indica
que “siempre que la Ley exija que el contrato o cualquier
información relacionada con el mismo conste por escrito,
este requisito se entenderá satisfecho si el contrato o la
información se contiene en un soporte electrónico”.
La forma en los contratos legales inteligentes
constituye un elemento trascendental, dado que las
nuevas tecnologías pueden y deben estar al ser-
vicio de una mayor transparencia, de forma que
las partes puedan participar en la formación del
contrato, con cumplido y exacto conocimiento del
objeto y la causa del mismo y puedan proyectar
su consentimiento sobre una representación mental
coincidente con la base del negocio jurídico.
87
Carlos Tur Faúndez
Como se ha expuesto “ut supra112”, el conte-

nido formal del contrato legal inteligente no abarca,
exclusivamente, al smart contract pues se extiende a
todo el compendio de elementos informáticos que
lo envuelven.
Siendo conscientes de que un programa (smart
contract) no se convierte en un contrato por el sim-
ple hecho de integrar en su código instrucciones o
funciones con trascendencia jurídica, algunos desa-
rrolladores de Solidity han llevado a cabo iniciativas
que permiten la integración de ambos conceptos.
BRAENDGAARD nos proporciona una solu-
ción verdaderamente útil113 para “transformar”
los smart contracts en contratos legales inteligentes,
consistente en:
a) Alojar el texto del contrato tradicional (o
las condiciones generales) en la plataforma
IPFS114;
b) Almacenar el hash correspondiente a la
dirección de IPFS en la que el documento
ha quedado depositado;
c) Implementar en el programa anclado a la
cadena de bloques (smart contract) la fun-
ción o funciones (function) correspondientes
112
Vid. Supra sección II, apartado 2.
113
BRAENDGAARD, P.. (29 de junio de 2016) Simple Conven-
tion for Human Readable Terms for Smart Contracts. Blog stakeventu-
res. Sitio web: https://blog.stakeventures.com/articles/smart-contract-terms.
114
Vid. Supra sección I, apartado 2.5.
88
Smart Contracts
al consentimiento o aceptación de los térmi-

nos del contrato115.
Una solución similar a la propuesta por
BRAENDGAARD, y a la que se denomina “dual
integration” (integración dual), podemos hallarla
en la plataforma MONAX116, aunque menos eficaz,
a nuestro juicio, puesto que no integra el almace-
namiento en IPFS.
Por otra parte, uno de los inconvenientes más
serios que, bajo nuestro punto de vista, presenta la
plataforma Ethereum, es la imposibilidad de conocer
la identidad de las personas que realizan actos con
trascendencia jurídica, puesto que tan sólo resulta
visible la cadena alfanumérica identificativa de la
cuenta (address) del titular. Dicho problema ha sido
bautizado en el ámbito del comercio electrónico
como “KYC” (know your customer117). A día de hoy,
son dos las compañías que han centrado sus esfuer-
zos en resolver esta cuestión: uPORT118, actualmente
115
El software original desarrollado por Pelle Braendga-
ard, puede hallarse en el repositorio Github. Sitio web: https://
github.com/pelle/solidterms.
116
El software original desarrollado por MONAX, puede
hallarse en el repositorio Github. Sitio web https://github.com/monax/
hello-doug/tree/master/deprecated_apps/dual_integration.
117
Traduc. “Conozca su cliente”
118
Vid. Sitio web: https://www.uport.me/.
89
Carlos Tur Faúndez
en fase alfa119, y el oráculo120 ORACLIZE a través de

una aplicación denominada Proof of Identity121.
Sin ánimo de desmerecer, en absoluto, tan
valiosas aportaciones, creemos que la legislación
europea (especialmente en materia de consumido-
res y usuarios) nos exige un esfuerzo superior en
la garantía de los derechos de información. Siendo
conscientes de que el contrato legal inteligente deberá
cumplir siempre con la legislación que le sea apli-
cable, proponemos, para el caso de que el contrato
se entendiera celebrado en España, las siguientes
recomendaciones:
a) La página web deberá disponer de infor-
mación clara, precisa y detallada, de los
contenidos de la misma y del producto que
se le está ofreciendo, será preferiblemente
multilingüe y deberá cumplir, con todos y
cada uno de los requisitos establecidos en
la LSSICE, así como los exigidos en la Ley
Orgánica de Protección de Datos122.
119
120
Vid. Infra, sección II, apartado 7.
121
En este caso, es un tercero de confianza ORACLIZE, quien
dispone de una base de datos en la que se interrelacionan los
datos obrantes en la id card que proporciona el estado de Esto-
nia a sus nacionales y residentes (muy similar a nuestro DNIe)
con una o varias direcciones (address) de la cadena de bloques
Ethereum. Más información en el Sitio web: http://dapps.oraclize.it/
proof-of-identity/.
122
Somos conscientes de que este apartado al igual que el
apuntado en la nota precedente, requieren un mayor desarrollo,
pero por evidentes razones de espacio, nos vemos obligados
90
Smart Contracts
b) La aplicación web a través de la cual las par-

tes van a participar en la formación del con-
trato debe tener una interfaz de usuario con
una presentación “amable”123, es decir, que
proporcione a las partes la información de
manera cómoda y que les permita interac-
tuar de forma sencilla.
c) Existirá un procedimiento secuencial guiado
en el front end, que obligará al usuario a:
a. Registrarse en la página, mediante uso
de firma electrónica reconocida u otro
sistema que acredite, suficientemente, la
identidad del usuario;
b. Informarse de forma exhaustiva y deta-
llada del producto que pretende contra-
tar. Se incluirá la emisión de una corta
grabación audiovisual en la que expli-
cará de forma sencilla y gráfica, qué se
va a contratar y cuál va a ser el proceso
de perfección, consumación y en su caso
resolución del contrato;
c. Escuchar y/o leer todas las adver-
tencias exigidas por la LOPD.
a aplazar su estudio, aun cuando constituye nuestra intención

abordarlos en ulteriores trabajos.
123
En este sentido, TUR FAÚNDEZ, M.N., Deberes de infor-
mación y documentación. Turismo y comercio electrónico. Santiago
Cavanillas Múgica, M. ª Nélida Tur Faúndez, M. ª Teresa
Benito Roser y Columba Zurinaga de Terreros. Comares,
Granada, 2009, pág. 59.
91
Carlos Tur Faúndez
Podría introducirse una grabación

audiovisual de cada una de las partes en
la que formulan verbalmente el consen-
timiento, tras dar lectura al contrato o a
las condiciones generales, con expresión
clara e inequívoca de la comprensión
de los conceptos y con manifestación
expresa de su aceptación124;
d. Completar el formulario del contrato
con todos y cada uno de sus datos
identificativos125;
124
El sistema se podría articular mediante una nueva ven-
tana de alerta, con el siguiente texto (¿Dispone su equipo de
cámara de grabación?)
(Opción SÍ), el programa entra en modo de grabación
(Opción NO) Un script de la aplicación ejecutará una “lla-
mada” (call back) al teléfono móvil o Tablet del usuario. Con
carácter previo deberá existir una aplicación programada a tal
efecto por los creadores del software descargable desde Google Play
o Apple Store.
125
Véase, a título de ejemplo, el proceso seguido para la con-
tratación online en IBERIA, BOOKING, etc. Una vez completado
el formulario y tras oprimir el botón “continuar”, aparecerá en
pantalla de alerta en la que se informará al usuario de que se ini-
cia el proceso de creación del contrato en formato “pdf”. El texto
del contrato, será transparente, claro y fácilmente comprensible,
con un lenguaje asequible al consumidor. Incluirá una explica-
ción exhaustiva que coincida con lo expuesto en la grabación
audiovisual previamente emitida y contendrá todos y cada uno
de los requerimientos legales expuestos a lo largo del presente
trabajo. A continuación aparecerá en pantalla el contrato “pdf”
aparecerá una nueva ventana de alerta, requiriendo al usuario
para que proceda a la firma electrónica del documento mediante
el uso de sus claves privadas.
92
Smart Contracts
e. F i r m a r el documento pdf,
preferiblemente, con firma electrónica
reconocida u otro mecanismo que
acredite la identidad del usuario. La
firma electrónica, en su caso, deberá
cumplir con el artículo 3 de la Ley 59/2003, de
19 de diciembre, de firma electrónica. A dichas
firmas se incorporará el sellado de tiempo
de tiempo a través de cualquiera de las
TSA (“Time Stamp Authority”) dando
cumplimiento a la norma internacional
ISO/IEC 18014126;
f. Aceptar, simultáneamente y con el
mismo mecanismo:
i. La generación de la huella digital o
hash del documento pdf más la firma
electrónica inserta en el mismo y el
sellado de tiempo;
ii. La inserción del documento pdf fir-
mado en alguna de las plataformas
descentralizadas de almacenamiento
existentes (SWARM o IPFS)127;
iii. La ejecución automática del smart
contract y la inserción en el mismo de:
126
La base legal sobre la que se articula el sellado de
tiempo, se explica se ha hecho pública por la Fábrica Nacional
de Moneda y Timbre en el siguiente Sitio web: http://www.cert.fnmt.
es/catalogo-de-servicios/sellado-de-tiempo.
127
93
Carlos Tur Faúndez
i. Los datos identificativos facilita-

dos en el formulario;
ii. La aceptación de la ejecución
automática;
iii. El hash del documento pdf
firmado;
iv. El hash, en su caso, de la graba-
ción audiovisual en la que consta
el consentimiento;
v. El hash o dirección en SWARM o
IPFS, donde de forma inmutable
y descentralizada ha sido almace-
nado el documento y, en su caso,
la grabación del consentimiento.
El procedimiento propuesto es extremadamente
garantista y exige que cada uno de los pasos de la
secuencia dependa de la debida cumplimentación
de lo exigido en el paso precedente. De actuar el
usuario en otro sentido, la aplicación web le reque-
rirá mediante el oportuno cuadro de diálogo128,
siendo imposible la ejecución automática del smart
contract, hasta tanto no se completen los actos en el
orden programado.
Ventana emergente que exige una respuesta (v.g: ¿Ha

128
comprendido? [SÍ/NO]; ¿Desea abandonar el proceso de con-

tratación? [SÍ/NO])
94
Smart Contracts
5. VALOR PROBATORIO DE LA CADENA DE

BLOQUES. ACREDITACIÓN DE LOS CONTRA-
TOS LEGALES INTELIGENTES
Como ya se ha apuntado ut supra129, la cadena

de bloques garantiza la inmutabilidad de los conte-
nidos que en la misma se almacenan, lo que le con-
fiere una alta fiabilidad probatoria ante los órganos
jurisdiccionales. Sin embargo, servicios como Proof
of Existence, Stampery u OpenTimeStamps han sido
extremadamente cuestionados por algunos notarios
españoles, en especial por la utilización que hacen
de la expresión “notarize” o notarizar. ROSALES
DE SALAMANCA130 sostiene lo siguiente:
“Mucho se ha explicado de los peligros de las dietas milagro y
pese a todo hay miles de idiotas que creen que van a tener un
cuerpo Danone si durante tres semanas solo comen alcachofas.
Igual sucede con los cientos de incautos que “notarizarán”
sus documentos usando blockchain, o terceros de confianza, o
prestadores de servicios de certificación (estos últimos inter-
pretando el reglamento eIDAS 910/2014 según les conviene
-tema sobre el que estoy elaborando un post-), sin embargo,
no por ello trataré de explicar en este post las consecuencias
de lo que hacen (en ocasiones, incluso, con mayores costes
que los del Notario)”.
Tales argumentos requieren, a nuestro enten-

der, algunas reflexiones y tal vez una visión más
129
Vid. Supra, sección I, apartado 2.1.d
130
ROSALES DE SALAMANCA RODRÍGUEZ, F. (26 de
abril de 2016) Notarizar con Blockchain. Sitio web: https://www.nota-
riofranciscorosales.com/notarizar-con-blockchain/.
95
Carlos Tur Faúndez
amplia de la cadena de bloques y sus posibilidades.

Coincidimos con ambos autores en la imperiosa
necesidad de evitar la confusión y el engaño. Los
prestadores de servicio a través de páginas web (así
se lo exige la Ley) son responsables de los conteni-
dos de las mismas y deben estar a las consecuencias
patrimoniales que pueda ocasionarles el recurso a
la publicidad engañosa, en caso de que se ejerci-
ten acciones resarcitorias frente a los mismos pero,
no por ello debe infravalorarse la magnitud de la
repercusión que en el mundo jurídico puede tener
(y está teniendo) la cadena de bloques, ni debe
sobrevalorarse el valor de la escritura pública que
no es, ni más ni menos, que el que le atribuye el
Estado a través del Poder Legislativo.
Mientras ROSALES DE SALAMANCA pro-
pone con “sorna y gracejo” la PACOCHAIN131 como
sustituto de la blockchain, LLOPIS132, con mejor cri-
terio, hace balance de los imparables avances de
la cadena de bloques y relaciona los países que
están desarrollando iniciativas públicas relevan-
tes para la creación de un registro de la propiedad
basado en dicho sistema de almacenamiento. Ya
131
ROSALES DE SALAMANCA, F., (26 de Junio de 2017)
Blockchain o Pacochain. Sitio web: https://www.notariofranciscorosales.
com/blockchain-o-pacochain/.
132
LLOPIS, J.C., (9 de agosto de 2016) Algunos ejemplos de la
aplicación de Blockchain a los registros de la propiedad inmobiliaria.
Sitio web: http://www.notariallopis.es/blog/i/1388/73/algunos-ejemplos-de-
la-aplicacion-de-blockchain-al-registro-de-la-propiedad-inmobiliaria-ii.
96
Smart Contracts
no se trata, simplemente, de Honduras, sino de la

República de Georgia, Ghana, Suecia133, así como
los recientemente incorporados Brasil134 y Japón135
(que aún no habían hecho públicas sus actuaciones
a la fecha de redacción de su artículo).
En el marco del Derecho mercantil estadouni-
dense, resulta especialmente relevante la firma el
pasado 21 de julio de 2017136 de dos enmiendas137
a la Ley de Sociedades del Estado de Delaware
(Delaware General Corporation Law), por virtud de
las cuales se permite que, en lo sucesivo, la conta-
bilización, registro y transmisión de las participa-
ciones sociales pueda llevarse a efecto a través de
la cadena de bloques.
Dada la incontestable solidez económica y
tecnológica de los últimos países involucrados en
tales proyectos, debe tomarse consciencia del mar-
133
Véase las conclusiones de las pruebas realizadas por
el Catastro y el Registro de la Propiedad de Suecia, junto con
algunas de las instituciones financieras más relevantes del país
escandinavo, en el siguiente sitio web: https://chromaway.com/papers/
Blockchain_Landregistry_Report_2017.pdf.
134
Vid. Sitio web: https://www.criptonoticias.com/adopcion/
registro-inmobiliario-brasil-realizara-prueba-blockchain-registrar-titulos-
propiedad/#axzz4pRDSTFAB.
135
Vid. Sitio web: https://www.criptonoticias.com/aplica-
ciones/gobierno-japones-reinventara-registro-propiedades-block-
chain/#axzz4pRDSTFAB.
136
Vid. Sitio web: https://www.coindesk.com/
delaware-governor-signs-blockchain-legislation-law/.
137
Las enmiendas pueden verse en el sitio web: https://legis-
can.com/DE/bill/SB69/2017.
97
Carlos Tur Faúndez
cado carácter transnacional de la tecnología que

envuelve la blockchain y los smart contracts. A nues-
tro juicio, es cada vez más palmaria la inexistencia
de fronteras en el comercio electrónico, por lo que
la perseverancia en el análisis de tales conceptos
bajo el exclusivo prisma de la legislación nacional
nos condenará al vagón de cola del avance tecno-
lógico legal, máxime si el Ordenamiento Jurídico es
observado como una institución aferrada a las tra-
diciones y por ello “perfecta”, estática e inmutable.
Efectivamente, la cadena de bloques “no nota-
riza”, puesto que no puede notarizarse aquello
que no es expresamente autorizado por notario.
Sin embargo, un uso adecuado de la misma puede
proporcionarnos una fuente de prueba138 extre-
madamente útil para el Juzgador. Analicemos el
siguiente ejemplo:
A (vendedor) y B (comprador) suscriben un
contrato de compraventa, por virtud del cual el
primero vende al segundo el inmueble I por un
precio de 200.000 € (satisfecho en efectivo metálico)
y tienen la posibilidad de instrumentarlo a través
de dos mecanismos:
138
BUENO DE MATA, F., considera que los medios de
prueba no tienen porqué reinventarse pero sí actualizarse con
el fin de introducir, dentro de ese abanico cerrado, unas adap-
taciones mínimas que nos hagan introducir a través de nue-
vos mecanismos fuentes de prueba electrónicas que gozan de
una naturaleza jurídica autónoma. Vid. BUENO DE MATA, F.,
Prueba electrónica y proceso 2.0. Tirant lo Blanch. Valencia. 2014.
Pág. 117.
98
Smart Contracts
a) Una escritura pública de compraventa auto-

rizada por notario en la que B confiesa haber
recibido el íntegro precio con anterioridad a
la firma de la misma.
b) Un contrato electrónico que dé cumpli-
miento a los requisitos formales propuestos
en el apartado precedente (por el momento,
excluimos de la comparativa el contrato legal
inteligente, por cuanto como se explicará
más adelante, exige un esfuerzo probatorio
superior por la parte que pretenda la acre-
ditación de su contenido y validez ante los
tribunales).
Si establecemos una comparación entre uno

y otro sistema podemos alcanzar las siguientes
conclusiones:
a) Efectivamente, sólo se atribuye la condición
de documento público a la escritura auto-
rizada por el notario, puesto que la Ley no
reconoce como tales los documentos que
no han sido autorizados por un funciona-
rio público en el ejercicio de sus funciones.
Del mismo modo, el legislador, ha decidido
(hasta el día de hoy) que sólo los instru-
mentos públicos pueden ser inscritos en el
Registro de la Propiedad. Nada obsta, en
cualquier caso, la posibilidad de elevar a
público un contrato electrónico.
99
Carlos Tur Faúndez
b) Ambos tienen idéntica validez y eficacia

obligacional puesto que así lo dispone el
artículo 1.278 del Código civil:
c) En ambos casos se identifica a los contra-
tantes (pues debemos entender que la firma
electrónica reconocida cumple plenamente
los requisitos de la firma manuscrita).
d) La existencia de la grabación audiovisual,
nos garantiza que la coincidencia entre los
datos identificativos de los firmantes y su
verdadera identidad personal.
e) En ambos casos existe un archivo docu-
mental inmutable, que garantiza la imposi-
bilidad de se manipule el contenido de los
contratos.
En cuanto a la eficacia probatoria de ambos
contratos, GONZÁLEZ GRANADO139 señala que
“la cadena de bloques es un medio descentralizado de
sellado de tiempo de archivos digitales, pero no añade
ningún valor adicional al documento verificado. Por el
contrario, en nuestro Ordenamiento Jurídico la Escri-
tura Pública autorizada por Notario goza legalmente de
las presunciones de veracidad, integridad y legalidad,
acredita la existencia del acto y su contenido; su valor
excede con mucho del valor probatorio”.
139
GONZÁLEZ GRANADO, J., (4 de abril de
2016) ¿Enviará blockchain de vacaciones a los notarios?
Notariabierta.com. Sitio web: https://www.notariabierta.es/
enviara-blockchain-vacaciones-los-notarios/.
100
Smart Contracts
Pues bien, es obvio que la Escritura Pública,

confiere un valor añadido al documento creado,
puesto que la presencia física del notario, además
de facilitar información sobre las particularida-
des del negocio jurídico que se celebra, permite
un cierto control sobre la legalidad del contrato,
la capacidad, legitimación y representación de las
partes. Sin embargo, deben hacerse algunas consi-
deraciones al respecto:
En cuanto a la información que el notario facilita
con carácter previo a la firma de la escritura pública
debemos decir que es, con frecuencia, insuficiente,
lo que se evidencia en los miles de sentencias que
han declarado la nulidad de cláusulas abusivas en
operaciones bancarias autorizadas notarialmente.
Por otra parte, ante la presencia de incapa-
ces (no menores de edad140), el Notario no tiene
mayores conocimientos médicos o psicológicos que
140
La mayoría de edad, se comprueba por el Notario
mediante la verificación del DNI o pasaporte de las partes. En
aquellos contratos a los que se incorpore la firma electrónica
avanzada de las partes mediante DNIe les será de aplicación el
artículo 1.4 del Real Decreto 1553/2005, de 23 de diciembre, que
regula la expedición del documento nacional de identidad y sus
certificados de firma electrónica y que permite a los españoles
mayores de edad y con plena capacidad de obrar, la identifica-
ción electrónica de su titular, así como realizar la firma electró-
nica de sus documentos. Para el caso de los españoles menores de
edad, o que no gocen de plena capacidad de obrar, establece que
el DNIe contendrá únicamente la utilidad de la identificación
electrónica, para lo que se emitirá con el respectivo certificado
de autenticación activado.
101
Carlos Tur Faúndez
los de un posible buen padre o madre de fami-

lia, por lo que la presunción de capacidad admite,
lógicamente, prueba en contrario ante los órganos
jurisdiccionales.
En cuanto al control de legalidad, debe signifi-
carse que el TS se ha pronunciado al respecto en STS
de fecha 20 de mayo de 2008 (Roj STS 2176/2008)141
y, más recientemente en STS de 7 de marzo de 2016
(Roj STS 782/2016)142 exigiendo reserva de Ley
para que el notario pueda ejercitar el mencionado
control. Es decir, que el notario podrá aconsejar,
advertir o sugerir, pero en ningún caso denegar la
autorización de una escritura pública aun cuando
considere que parte de su contenido es ilegal. En
cualquier caso, tales advertencias o consejos tan
sólo pueden extenderse sobre la apariencia del
contrato, pero no sobre la voluntad real de las par-
tes. Las partes pueden manifestar declaraciones de
voluntad erróneas o falsas ante el Notario, sin que,
Por lo tanto, con el DNIe el menor de edad podrá acreditar

su identidad por medios telemáticos, pero no tendrá capacidad
para realizar la firma electrónica.
141
Vid. (CENDOJ) Sitio web: http://www.poderjudicial.es/search/
contenidos.action?action=contentpdf&databasematch=TS&reference=70610&
links=&optimize=20080612&publicinterface=true.
142
Vid. (CENDOJ) Sitio web http://www.poderjudicial.es/search/
contenidos.action?action=contentpdf&databasematch=TS&reference=761762
7&links=&optimize=20160310&publicinterface=true.
102
Smart Contracts
en la mayoría de los casos, tenga posibilidad de

percatarse de ello143.
Según se desprende del artículo 23.4 de la LSSICE
en relación con el artículo 17 bis de la Ley del Notariado,
la escritura pública electrónica es ya una realidad,
si bien es cierto que, a día de hoy, sólo es posible
la elaboración de copias electrónicas, por cuanto
es preciso el desarrollo reglamentario para que la
matriz electrónica sea admitida como instrumento
público.
LLOPIS144 considera que la escritura pública ínte-
gramente electrónica sólo puede ser un documento
electrónico que se genera de manera exclusiva por
un Notario, que es firmada electrónicamente por
los comparecientes y por el Notario, que se alma-
cena en formato electrónico y de la que se pueden
expedir copias electrónicas o en papel. La suma
ordenada y sistematizada de las matrices digitales auto-
rizadas por cada Notaría conformaría el Protocolo,
que sería obviamente electrónico y que, por su con-
cepto, debería ser único y conjunto, y por supuesto
almacenado en el servidor seguro del Notariado.
Coincidimos plenamente con dicho punto de
vista, si bien nos vemos obligados a subrayar que
143
Es humanamente imposible conocer las intenciones rea-
les de las partes. ¿Cómo puede tener certeza el notario, de que el
precio que se declara haber recibido en una compraventa es real?
144
LLOPIS, J.C., (15 de noviembre de 2016) La matriz digital
de la escritura notarial: ¿sí o no? Sitio web: http://www.notariallopis.
es/blog/i/1400/73/la-matriz-digital-de-la-escritura-notarial-si-o-no-notartic.
103
Carlos Tur Faúndez
en tanto el sistema de identificación de los contra-

tantes es la firma electrónica reconocida (o en su
caso un mecanismo biométrico también posible en
cualquier contrato privado), la eficacia probatoria
real (y no la conferida por el legislador) de la escri-
tura pública electrónica vendrá determinada por la
presencia física de las partes y del Notario (como
experto imparcial en Derecho con facultades para
advertir a los comparecientes sobre la legalidad del
negocio jurídico) en el momento de la firma y la
posibilidad de interacción entre todos ellos145.
En lo que hace referencia a la fuerza probatoria
de los documentos notariales es cierto que el artí-
culo 319 LEC establece que hacen prueba plena del
hecho, acto y estado de cosas que documentan y
de las personas que intervengan en ellas, pero no
lo es menos que el artículo 326 de dicha ley procesal
confiere a los documentos privados, exactamente el
mismo valor probatorio cuando no sea impugnada
su autenticidad.
Con franqueza, debemos considerar condenada
al fracaso la impugnación de los documentos que
incorporan firma electrónica reconocida máxime
cuando el artículo 3 de la Ley de Firma Electrónica prevé,
además de irrogar al impugnante los gastos de
Ello exige el uso de aplicaciones que permitan el chat

145
interactivo o, incluso, el uso de videoconferencia, similares a

Skype Faceboook Messenger o FaceTime.
104
Smart Contracts
comprobación, una multa de 120 a 600 € cuando

la impugnación hubiera sido temeraria.
Desde la entrada en vigor de la vigente LEC, en
la Audiencia Previa, o en la vista, según los casos,
se nos confiere traslado de los documentos apor-
tados por la contraparte para su impugnación o
conformidad. A pesar de que la ley nada dice al
respecto, todos somos conscientes de que la vali-
dez del documento tiene dos posibles frentes: uno
formal, que concierne a una posible falsificación
de firma o de texto; y otro, de fondo, que atañe al
negocio jurídico mismo y a la voluntad subyacente
de las partes.
Ante el riesgo de que, de guardar silencio, se
nos tenga por conformes, no sólo con la validez
formal, sino también con el contenido del docu-
mento, desde la entrada en vigor de la LEC146, los
letrados adoptamos la precaución, cuando procede
(se trate de documentos públicos o privados) de
manifestar de forma expresa nuestra disconformi-
dad con las declaraciones de voluntad que incluye
el documento. De ese modo, no existe duda de que
146
Los más veteranos, adoptamos dichas precauciones
desde hace más de 17 años (pues la vigente LEC, entró en vigor
el 8 de enero de 2001) que han sido, siempre, bien recibidas por
los Órganos Jurisdiccionales, pues evitan que, sin más, se tengan
por admitidos los hechos relatados en la escritura pública. Si se
ha manifestado la disconformidad con respecto al contenido de
la escritura, podrá proponerse prueba para acreditar la nulidad
del mismo y podrá debatirse la cuestión en la vista oral.
105
Carlos Tur Faúndez
el Juzgador, las valorará libremente y en base a las

reglas de la sana crítica.
Si bien lo expuesto hasta el momento es válido
para todos los contratos electrónicos, los contratos
legales inteligentes son un conjunto inescindible de
software y Derecho que requiere, como indicamos
ut supra, un mayor esfuerzo probatorio. Conviene
recordar que los contratos legales inteligentes no se
limitan a documentar y almacenar de forma fiable
los acuerdos legales habidos entre las partes, sino
que los ejecutan de forma automática, por lo que la
prueba de tales contratos147 ante los órganos juris-
diccionales exigirá la acreditación:
a) De que las aplicaciones residentes en el front
end, han permitido a las partes formular
adecuadamente su consentimiento al haber
obtenido una representación mental exacta
del alcance obligacional del contrato148.
b) De que tales aplicaciones han permitido el
cumplimiento de los deberes de informa-
ción y requisitos de validez exigidos por
la legislación específicamente aplicable en
cada caso.
147
Exponemos lo que, con carácter general deberá, a nuestro
juicio, ser objeto de prueba. Obviamente, cada caso presentará
sus singularidades.
148
Vid. Supra, sección II, apartado 5.1.
106
Smart Contracts
c) De que el smart contract residente en el back

end desarrolla su ejecución de conformidad
con lo pactado por las partes.
Sin duda, será la prueba pericial el medio idó-
neo para canalizar la acreditación de los extremos
expuestos. Sin embargo, en la línea de lo apuntado
en la introducción del presente trabajo, conside-
ramos imprescindible una nueva generación de
peritos jurídico-informáticos cuya formación y cono-
cimientos deben de ser suficientes para interpretar
correctamente las interacciones existentes entre el
software y el Derecho y para traducir a lenguaje jurí-
dico, el lenguaje informático en el que se han desa-
rrollado los smart contracts149.
6. EJECUCIÓN DE LOS CONTRATOS LEGALES

INTELIGENTES. CUMPLIMIENTO.
La característica más destacada de los contratos

legales inteligentes es que proporcionan la ejecución
automática programada de las contraprestaciones,
149
A nuestro juicio, la formación del perito, deberá ser esen-
cialmente jurídica, por cuanto el análisis del contrato legal inteli-
gente, deberá proyectarse, fundamentalmente, sobre su eficacia
obligacional. Ahora bien, para abordar con éxito su informe, el
experto, deberá ser capaz de desarrollar software en el lenguaje
utilizado en el smart contract (fundamentalmente Solidity) y hacer
las verificaciones necesarias en el funcionamiento de las restan-
tes aplicaciones existentes en el front end y en el back end que
constituyen la forma del contrato.
107
Carlos Tur Faúndez
es decir que la consumación del contrato no siem-

pre depende de la voluntad de las partes, sino que
es el propio software (smart contract) el que, dán-
dose determinadas condiciones, la lleva a efecto
de forma automática.
El consentimiento de las partes se plantea
“ab initio” y desencadena, o puede desencadenar
inexorablemente, la ejecución automática de todas
las funciones programadas, por lo que, en lo que
hace referencia a las prestaciones automatizadas,
no cabe hablar de cumplimiento obligacional, en
el sentido jurídico conocido para los contratos
tradicionales.
Ahora bien, debe puntualizarse que, una vez
prestado el consentimiento sobre el contrato legal
inteligente y por ende sobre la ejecución del pro-
grama (smart contract) incluso en aquellos contratos
en los que los pagos están totalmente automatiza-
dos, la parte deudora de la prestación pecuniaria
debe cumplir voluntariamente con una obligación
consistente en mantener la cuenta (address) sobre
la que el programa “cobrará” con saldo suficiente
para atender los cargos. En estos supuestos, sólo
en este exclusivo aspecto, cabe hablar de incumpli-
miento desde una óptica tradicional, puesto que es
el deudor (pecuniario) quien decide si mantiene la
solvencia de su cuenta asociada al cumplimiento
del contrato o la deja en saldo 0, lo que, obvia-
mente, queda fuera del control del smart contract.
108
Smart Contracts
Por lo demás, como ya se ha expuesto ut supra150,

el programa pagará, recibirá fondos o hará cobros
automáticos sobre las cuentas que corresponda,
restituirá cuando proceda, si así se ha codificado,
los fondos depositados v.g. como precio de la com-
praventa, en caso de desistimiento unilateral del
consumidor151, etc..
Por otra parte, el programa podrá remitir una
orden de bloqueo a través de aplicaciones externas
a un inmovilizador automático de una máquina
industrial o de cualquier otro tipo de ingenio, lo
que imposibilitará su uso para el caso de no dis-
poner el deudor de fondos suficientes en su cuenta
EOA152 para atender a los cargos periódicos pacta-
dos. Observe el lector que, en este último caso, nos
hallaríamos ante una condición resolutoria expresa
verificable en la propia cadena de bloques (insufi-
ciencia de fondos en la cuenta EOA) que, de pro-
ducirse, operaría, automáticamente, la resolución
contractual153.
Como ya se ha indicado, la tecnología que
sustenta los smart contracts aún no ha alcanzado
un grado de desarrollo suficiente y, en cualquier
150
151
Lógicamente, si el desarrollador ha construido el soft-
ware adecuadamente.
152
Vid Supra, sección I, apartado 2.4.
153
En el apartado 7 de esta sección, nos referiremos a los
contratos legales inteligentes sujetos a condiciones, no verificables
en la propia cadena de bloques.
109
Carlos Tur Faúndez
caso, no puede descartarse un fallo del sistema que

conduzca a la imposible ejecución automática del
acuerdo de voluntades. Sin embargo, como se ha
explicado ut supra154 el contrato legal inteligente155
va más allá de las aplicaciones informáticas que
constituyen su forma y ello implica que el accipiens
mantendrá su derecho a exigir al solvens el cum-
plimiento de la prestación debida, aún cuando se
haya producido un error informático obstativo o
impeditivo.
El fallo informático no libera al deudor, que
seguirá obligado al cumplimiento (ahora ya depen-
diente de su exclusiva voluntad) de la obligación
que le es exigible. Por tal motivo, los contratos legales
inteligentes deberán prever canales alternativos para
la efectiva realización de las prestaciones pactadas
con los requisitos objetivos exigidos por la Ley:
a) Exactitud o identidad (art. 1.166 CC) entre la
cosa pactada y la verdaderamente entregada.
b) Integridad (art.1.157 CC). La deuda debe satis-
facerse en su totalidad.
c) Indivisibilidad (art.1.169 CC). No puede com-
pelerse al acreedor a recibir la prestación
por partes.
Vid Supra, sección II, apartado 2.

154
Precisamente porque es un contrato jurídicamente

155
vinculante.
110
Smart Contracts
7. LAS OBLIGACIONES CONDICIONALES EN

LOS CONTRATOS LEGALES INTELIGENTES.
LOS ORÁCULOS (ORACLES)
En los contratos legales inteligentes, como en

cualesquiera otros, las partes pueden pactar que
la relación obligatoria esté sometida a una determi-
nada condición. Dicha condición, según nos indica
el artículo 1.114 CC, puede ser suspensiva, en cuyo
caso la obligación no desplegará sus efectos hasta
el cumplimiento de aquélla, o resolutoria, y por
ende determinante del cese de los efectos de la obli-
gación tan pronto como la condición se produzca.
La determinación de la concurrencia de una
determinada condición se producirá siempre en la
fase de consumación del contrato y, como ya se
ha expuesto, la ejecución de las contraprestaciones
incumbe al smart contract. Sin embargo, la “inteli-
gencia” de los smart contracts es limitada. Con ello
queremos significar que tales programas pueden,
como se ha expuesto en el apartado precedente,
verificar la información que existe en la cadena de
bloques, pero no disponen de recursos para buscar
información en el mundo real y discernir cuál es
correcta y cuál no lo es. En consecuencia, tampoco
pueden determinar, sin la colaboración de agentes
externos, si una condición (sea esta suspensiva o
resolutoria) se ha cumplido.
En la página 59 nos referíamos a
http://insureth.mkvd.net/ como ejemplo ideado para la
111
Carlos Tur Faúndez
generación de contratos de seguro a corto plazo

que cubren los riesgos inherentes al retraso de los
vuelos. Para conocer si se ha producido el riesgo
indemnizable, es necesario conocer si el retraso se
ha producido realmente y el único modo posible
es mediante el acceso a una página web externa
(por ejemplo, la de la compañía aérea) en la que se
hagan públicas las incidencias de las aeronaves. El
smart contract no dispone de suficiente autonomía
para desarrollar tales tareas y para ello necesita de
la colaboración de un tercero confiable.
Los oráculos cumplen dicha función. Se trata de
empresas externas respecto a la cadena de bloques
que pueden facilitar al programa cualquier tipo de
información156, y que han creado un software propio
compatible con Solidity que les permite interaccio-
nar con el smart contract. El desarrollador del smart
contract deberá implementar en éste el código pro-
puesto por el oráculo y establecer, además, como
condiciones (if-then/ si-entonces) del programa el
resultado de las consultas (queries) efectuadas al
oráculo, de forma que la ejecución del mismo se
llevará a efecto en uno u otro sentido, en función
de la respuesta obtenida. El oráculo recibirá la con-
sulta, en la que se incluirá la página URL donde
V.g. cotización de divisas o acciones, rastreo de paquetes

156
en tránsito, tiempo atmosférico, retraso en vuelos o cualquier

otro evento verificable.
112
Smart Contracts
consta la información y devolverá al contrato una

respuesta rápida.
La actividad desarrollada por los oráculos en su
interacción con la cadena de bloques es, o debe ser,
en definitiva, la de un tercero confiable e imparcial.
Ahora bien, no debemos olvidar que tal y como se
expuso al inicio del presente trabajo157, la caracte-
rística más relevante de la cadena de bloques es
su inmutabilidad, en tanto que ni los participantes
en la propia cadena ni los terceros ajenos a ella
pueden manipular la información que se registra
en la misma. Pues bien, los oráculos son agentes
que, como se ha dicho, son ajenos a la cadena de
bloques y en consecuencia no se les puede atribuir
la inmutabilidad como característica definitoria. En
consecuencia, presentan el inconveniente de que
pueden ser manipulados y precisamente por ello
debe acentuarse la necesidad de que sean entes
imparciales y de reconocido prestigio los que rea-
licen dicha labor.
En cualquier caso, debe subrayarse que el con-
trato legal inteligente no se agota necesariamente con
su ejecución informática, por lo que, en el supuesto
de que el oráculo remitiese al smart contract un men-
saje de datos con información falsa desencade-
nando la ejecución automática en el sentido inade-
cuado, nada impediría que el perjudicado ejercitara
acciones ante los tribunales ordinarios, exigiendo
157
Vid. Supra sección I, apartado 2.1.
113
Carlos Tur Faúndez
el cumplimiento del contrato en los términos acor-

dados. Ello requeriría, lógicamente, la acreditación
de la información verdadera referida al evento que
constituye la condición.
Asimismo, la parte perjudicada podría ejercitar
acciones resarcitorias frente al oráculo en reclama-
ción de los daños y perjuicios que le hubieran sido
irrogados.
Actualmente, sólo nos consta la existencia de
dos plataformas que desarrollen esta actividad
para Ethereum. Por una parte, podemos encontrar
a SmartContract.com158 (cuya denominación es
bastante desafortunada pues induce a error), que
proporciona el servicio chainlink159 para proporcionar
datos externos al smart contract. Y por otra parte
ORACLIZE160, que hasta la fecha se ha venido
postulando como el oráculo de referencia. Sería muy
deseable la existencia de otras entidades confiables
que pudieran actuar como oráculos, puesto que
como es sabido, la libre competencia fomenta la
158
Sitio web: https://create.smartcontract.com/#/choose.
159
Sergey Nazarov, CEO de SmartContract.com: ChainLink
Network se enorgullece de ofrecer una solución al problema de
conectividad urgente entre contratos inteligentes y datos exter-
nos mediante la creación de un middleware de blockchain com-
pletamente descentralizado que sirve como un conducto entre
contratos inteligentes, fuentes de datos, API, pagos bancarios
y sistemas back office. Lo que lo hace accesible a los contra-
tos inteligentes que necesitan estos recursos a través de nuestro
token LINK
160
Sitio web: http://www.oraclize.it/.
114
Smart Contracts
imparcialidad y la mejora en la prestación de los

servicios161.
8. ENTREGA O PUESTA A DISPOSICIÓN. “INTER-

NET DE LAS COSAS” (IOT)162
Según relatan los responsables de Gartner

Inc. , a finales de 2017 habría 8.400 millones de
163
“cosas” conectadas a Internet, lo que supone un

incremento del 31% respecto a 2016, y se alcanzaría
la cifra de 20.400 millones en el año 2020164.
El Internet de las Cosas ha sido denominado “La
siguiente Revolución Industrial”. El estado actual de
las nuevas tecnologías nos permite pensar en que
cualquier elemento con conexión a Internet puede
ser controlado de forma remota haciendo uso del
software adecuado.
La revolución se plantea, asimismo, en el
mundo jurídico y en especial en todo cuanto hace
161
Bajo nuestro criterio, la intervención de los oráculos, sólo
puede venir determinada por la existencia de un contrato de
arrendamiento de servicios, sobre el que las partes del contrato
legal inteligente, deben haber prestado su consentimiento. Y al
que le serán aplicables todos y cada uno de los requisitos de
validez expresados a lo largo del presente trabajo.
162
Se hace referencia a Internet de las Cosas mediante las
siglas IoT (Internet of things) Vid. Sitio web: https://es.wikipedia.org/
wiki/Internet_de_las_cosas.
163
Vid. Sitio web: https://es.wikipedia.org/wiki/Gartner_(empresa).
164
Vid. Sitio web: http://www.gartner.com/newsroom/id/3598917.
115
Carlos Tur Faúndez
referencia a la puesta a disposición de los bienes

y servicios.
Según opina LACRUZ165, tradición166, en el sen-
tido del artículo 609 CC, equivale a entrega, al despla-
zamiento de la posesión que se va a transmitir hasta la
persona del adquirente y ello con independencia de
la eficacia real o no de la transmisión. Pues bien,
la traditio, entendida como puesta a disposición del
control sobre la cosa o como entrega de llaves, va a
ser el mecanismo del que habitualmente se servirán
los smart contracts para la ejecución automática de
las prestaciones en los contratos legales inteligentes.
Como se ha expuesto, el smart contract subya-
cente puede ser programado para que asuma la
entrega o puesta a disposición del bien o servicio
que constituya el objeto de la obligación sin que
para ello sea necesario ningún desplazamiento gra-
cias a la tecnología proporcionada por el IoT.
El IoT supone, en definitiva, la interconexión a
través de Internet de cualesquiera objetos a los que se
haya incorporado un dispositivo emisor y/o recep-
tor de información mediante radiofrecuencia167.
165
LACRUZ BERDEJO, J., Elementos de Derecho Civil III.
Volum. 1º. 1ª parte. Posesión y Propiedad. Librería Bosch. 1988.
Barcelona. Pág. 227.
166
Entiéndase que nos referimos a la “traditio” en su sentido
más amplio (como cumplimiento de los contratos en aquellos de
naturaleza no dispositiva) y no exclusivamente determinante del
traspaso de la titularidad real.
167
Dichos dispositivos, pueden ser en ocasiones muy livia-
nos y de bajo coste, tal es el caso de las etiquetas RFID autoad-
116
Smart Contracts
Disponemos pues de los siguientes elementos:

a) Un objeto externo, con capacidad tecno-
lógica de comunicación bidireccional que
puede estar provisto de múltiples sensores y
de un dispositivo de geolocalización. Dicho
objeto remite información que puede ser
procesada por el smart contract como evento
determinante de la forma en que llevará a
efecto su ejecución automática.
b) Una red de comunicaciones (en este caso
Internet) a través de la cual se interconectan
los dispositivos.
c) Un smart contract inserto en una red descen-
tralizada (la cadena de bloques) que, al veri-
ficar la concurrencia de una determinada
condición (evento comunicado por el dispo-
sitivo remoto), ejecuta automáticamente una
prestación (u ordena su detención) y para
ello remite un mensaje de datos a través de
la red de comunicación antes indicada por
virtud del cual transmite una determinada
orden168 a un dispositivo externo que reac-
ciona en consecuencia (encendido-apagado,
abierto cerrado, etc.).
hesivas que con frecuencia vemos en los supermercados. Vid.

Sitio web: https://es.wikipedia.org/wiki/Etiqueta_RFID.
168
Para ello será necesaria la ejecución de software interco-
nectado con la cadena de bloques, pero ajeno a la misma.
117
Carlos Tur Faúndez
Si a lo anteriormente expuesto añadimos que

el conjunto de aplicaciones que integran el contrato
legal inteligente puede, tras la recepción de una lla-
mada (mensaje de datos) del smart contract subya-
cente, generar nuevas claves de apertura169, bloqueo
o encendido del dispositivo remoto, y facilitárselas
a las partes o privarles de ellas, deducimos, necesa-
riamente, la capacidad del mismo para resolver de
forma autónoma y automática la entrega o puesta
a disposición de las partes de cualquier objeto
imaginable170.
En conclusión, el contrato legal inteligente a tra-
vés del software que se integra en el front end y en
el back end, tiene la capacidad autónoma de entre-
gar la posesión a una de las partes, mediante la
entrega de llaves (en este caso claves criptográfi-
cas), de forma que ostentará el inmediato poder
169
En vehículos y grandes máquinas móviles, resulta extre-
madamente útil el inmovilizador automático de motor, en tanto
será este instrumento el que, en definitiva, atribuya a una u
otra parte el control sobre los mismos. El dispositivo inmoviliza-
dor, deberá ser reprogramable, mediante conexión inalámbrica
externa e ir unido a un elemento de geolocalización a fin de
que la detención del motor se produzca, únicamente, cuando
el elemento esté detenido y fuera de peligro. Mas información
sobre dispositivos de inmovilización (en inglés) en Sitio web:
https://en.wikipedia.org/wiki/Immobiliser.
170
Es obvio que no se puede automatizar la entrega remota
de un martillo mediante claves, pero si la de cualesquiera vehícu-
los, buques, aeronaves, maquinaria industrial e incluso edificios
que hayan sido dotados de tecnología que permita el control
automático de bloqueo, apertura y cierre y de los suministros
de agua, gas y electricidad.
118
Smart Contracts
de disposición y control sobre el objeto171, en los

términos previstos en el artículo 1.462 y ss. CC.
La tecnología que acabamos de exponer existe
y está en funcionamiento. Los proyectos más des-
tacados que han sido desarrollados sobre la cadena
de bloques Ethereum puede apreciarse en la página
web de Slock.it172 y de Project Oaken173.
En el ámbito de las cadenas de bloques priva-
das, IBM, a través de su plataforma Watson Inter-
net of Things174, propone la implementación del IoT,
con IBM Blockchain, una cadena de bloques privada
basada en Hyperledger175.
9. LAS PRESTACIONES PECUNIARIAS EN LOS

CONTRATOS LEGALES INTELIGENTES
Los contratos legales inteligentes, del mismo modo

que los ordinarios, incorporan un sinalagma en el
que, al menos, una de las prestaciones puede ser
calificada como pecuniaria. Ahora bien, la peculiar
171
La tecnología a la que se ha hecho referencia, debe con-
siderarse, igualmente útil, para la configuración de nuevas cate-
gorías contractuales de garantía en las que el incumplimiento de
la obligación de pago por parte del deudor, pueda generar el
desplazamiento posesorio en favor del acreedor, con un simple
cambio de claves criptográficas.
172
Sitio web: https://slock.it/.
173
Sitio web: https://projectoaken.com/.
174
Sitio web: https://www.ibm.com/internet-of-things/platform/
private-blockchain/.
175
119
Carlos Tur Faúndez
naturaleza de dichos contratos exige que el pago,

entendido como cumplimiento de la obligación176,
se lleve a efecto en el interior de la cadena de blo-
ques, mediante la transmisión de una determinada
suma de criptomonedas de una cuenta a otra177.
El problema radica en que las diversas cadenas
de bloques existentes exigen que las transacciones
económicas se efectúen en su propia criptodivisa178.
De este modo, si tomamos como ejemplo la plata-
forma Ethereum, constatamos que todos los pagos
deben realizarse en Ether179, resultando de todo
punto imposible utilizar dinero de curso legal180
en la mencionada red distribuida.
En opinión de LACRUZ, y en la de la práctica
totalidad de la doctrina, las prestaciones pecunia-
rias son aquellas que consisten en la entrega de una
cantidad de dinero181. Procede, pues, analizar en qué
consiste el dinero a fin de determinar si las crip-
tomonedas (Bitcoin, Ether, etc.) pueden ajustarse a tal
176
Ob. Cit. LACRUZ BERDEJO, J.L., pág. 125.
177
Sobre los mecanismos de transmisión de criptomoneda en
la cadena de bloques Ethereum vid. apartado 2.4 del presente
trabajo.
178
Criptomoneda y criptodivisa son sinónimos.
179
Véase la introducción del presente trabajo.
180
Lo mismo ocurre, como es sabido, en el resto de cadenas
de bloques, en las que es posible la realización de transacciones
y que han emitido su propia criptodivisa. Vid. sección I, apartado
2.3.
181
Ob. Cit. LACRUZ BERDEJO, J.L., pág. 87.
120
Smart Contracts
concepto o si, por el contrario, deben quedar fuera de

tal consideración.
El primero en proporcionar una definición
ampliamente difundida fue MENGER182, quien
consideraba que el dinero es el medio de intercambio
generalmente aceptado.
Según NUSSBAUM183, el dinero son aquellas cosas
que en el comercio se entregan y se reciben como fracción,
equivalente o múltiplo de la unidad.
Más adelante HAYEK184 suscribiría la defini-
ción de MENGER, si bien con las siguientes mati-
zaciones: es más bien una desgracia que describamos
el dinero por un sustantivo, pues sería más útil para la
explicación de los fenómenos monetarios si el «dinero»
fuera un adjetivo que describiera una propiedad que dife-
rentes cosas pudieran poseer en diferentes grados. La
182
MENGER, C., Principles of Economics [1871], The Free
Press, Glencoe, Ill., 1950. (Traducción del texto original del autor:
Money is the generally acceptable medium of Exchange).
183
NUSSBAUM, A., Teoría general del dinero. Traducción
de Luis Sancho Seral. Revista de Derecho Privado. Madrid 1929.
Pág. 32
184
HAYEK, F.A. Denationalisation of Money. Third edition.
Institute of Economic Affairs. 1990. (Texto original: It has been
rather a misfortune that we describe money by a noun, and that
it would be more helpful for the explanation of monetary pheno-
mena if ‘money’ were an adjective describing a property which
different things could possess to varying degrees. ‘Currency’
is, for this reason, more appropriate, since objects can ‘have
currency’ to varying degrees and through different regions or
sectors of the population.)
121
Carlos Tur Faúndez
aceptación185 (en inglés currency) es, por esta razón, más

apropiada, ya que los objetos pueden tener aceptación
(currency) ‹en diferentes grados y a través de diferentes
regiones o sectores de la población.
En nuestra opinión, el dinero, entendido como
medio generalmente aceptado para el intercambio
y para el pago de las obligaciones pecuniarias, ni
puede ni debe de asociarse exclusivamente a la
moneda de curso legal, por los siguientes motivos:
En primer lugar, porque a lo largo de la histo-
ria, se ha hecho patente un persistente abuso de la
prerrogativa gubernamental de “fabricar dinero”186 sin
representación real en oro en las arcas del Tesoro,
lo que ha acabado por generar en no pocas oca-
siones desconfianza entre los comerciantes, con
la consiguiente deriva en imparables procesos
inflacionarios.
En segundo lugar porque, como lógica conse-
cuencia de lo anterior, durante diversos periodos
y en diferentes localizaciones han circulado, junto
al dinero de curso legal, otros medios de pago. Así
ocurrió a principios del S. XVI con la moneda emi-
tida por el Banco de Amsterdam (Amsterdamsche
Wisselbank), que tomó el ejemplo del Banco della
Piassa di Rialto establecido en Venecia en 1587.
185
Lo cierto es que, en español, no disponemos de un voca-
blo equivalente que signifique, “aceptación” o “uso comúnmente
aceptado” y al mismo tiempo divisa o dinero.
186
Ob. Cit. HAYEK, F.A., pág. 33 y ss. (The persistent abuse
of the government prerogative)
122
Smart Contracts
Y en tercer lugar porque, como suele decirse,

la realidad de los mercados financieros es tozuda
y el dinero, aprensivo y receloso. Precisamente
por tal motivo, en aquellos países con porcenta-
jes de inflación superiores al 18%, entre los que se
encuentran Venezuela (148%) y Argentina (40%)187,
incluso los pequeños ahorradores buscan refugio
en monedas electrónicas cuyo valor es reconocido
internacionalmente y que pueden conservarse en
“monederos virtuales” mucho más confiables que
cualquier banco o caja de seguridad situada en el
territorio nacional.
¿Podemos decir entonces que las monedas vir-
tuales son dinero?
FERNÁNDEZ BURGUEÑO188 definió el bitcoin,
en el año 2013, como un bien patrimonial inmaterial,
documento electrónico, objeto de derecho real, en forma
de unidad de cuenta, definida mediante la tecnología
187
Vid. Sitio web: BITCOIN.COM https://news.bitcoin.com/
one-of-these-5-hyperinflating-economies-could-adopt-bitcoin-in-2017/.
FERNÁNDEZ BURGUEÑO, P., 12 cosas que deberías saber
188
antes de usar bitcoins (La Ley y el Bitcoin). Sitio web: ABANLEX.

COM (23 de noviembre de 2013) https://www.abanlex.com/2013/11/12-
cosas-que-deberias-saber-antes-de-usar-bitcoins/. Hemos querido dejar
expresa constancia de la fecha de publicación del artículo puesto
que, es de justicia indicar, que la posición del autor citado con
respecto a la naturaleza jurídica del Bitcoin, ha evolucionado con
los años, a tenor de las posturas adoptadas por las distintas auto-
ridades e internacionales. El despacho ABANLEX, recomienda
la lectura de su página web dedicada por entero al Bitcoin y
que proporciona amplia información sobre la actual situación
jurídica de la criptomoneda.
123
Carlos Tur Faúndez
informática y criptográfica denominada “Bitcoin”, que

permite ser utilizada como contraprestación en tran-
sacciones de todo tipo. Dichas unidades de cuenta son
irrepetibles, no son susceptibles de copia y no necesitan
intermediarios para su uso y disposición”.
A pesar del tiempo transcurrido, consideramos
que, en esencia, la definición sigue siendo válida
para el bitcoin y el resto de las criptodivisas, con la
salvedad de que, a nuestro juicio, no puede serle
atribuida, dada su existencia virtual en una red dis-
tribuida, la condición de documento electrónico y,
si bien es cierto que puede ser objeto de derecho
real, no es esa su única finalidad.
GONZÁLEZ GRANADO189 hace propia la defi-
nición facilitada por FERNÁNDEZ BURGUEÑO,
si bien pone de manifiesto la necesidad de tomar
en consideración la funcionalidad derivada de la
aceptación de la criptodivisa como medio de inter-
cambio económico de los usuarios. Y así define el
bitcoin como un bien patrimonial, privado, incorporal,
digital, en forma de unidad de cuenta y creado mediante
un sistema informático utilizado como medida común de
valor por acuerdo de los usuarios del sistema190. Señala,
asimismo, dicho autor que la consideración del
189
GONZÁLEZ GRANADO, J., (25 de octubre de 2015) Con-
cepto y naturaleza jurídica del BitCoin. Taller de derechos. Sitio web:
https://tallerdederechos.com/concepto-y-naturaleza-juridica-del-bitcoin/.
190
En términos similares ANDRÉS, I., (11 de octubre 2017)
quien subraya, además, las diferencias entre el bitcoin y el dinero
de curso legal. Vid. Sitio web: http://peniafort.es/el-fin-del-papel/.
124
Smart Contracts
bitcoin como dinero191 o moneda electrónica, no es

acertada jurídicamente192.
GÓMEZ DE LA CRUZ y RAMOS193 insisten en
definir las monedas virtuales como bienes mue-
bles fungibles, no susceptibles de copia, haciendo
especial incidencia, además en “lo que no son” las
monedas virtuales y así exponen que:
a) No son dinero electrónico, por cuanto el
artículo 1.2 de la Ley 21/2011, de 26 de julio, de
dinero electrónico atribuye dicha condición
al valor monetario almacenado por medios
electrónicos o magnéticos que represente un
crédito sobre el emisor, que se emita al recibo de
fondos con el propósito de efectuar operaciones
de pago según se definen en el artículo 2.5
de la Ley 16/2009, de 13 de noviembre, de
servicios de pago, y que sea aceptado por una
191
No hemos hallado en la página de ABANLEX una posi-
ción clara y definida en cuanto a esta cuestión. En su artículo de
23 de noviembre de 2013, FERNANDEZ BURGUEÑO, manifestó
de forma expresa que el bitcoin no es dinero. No obstante lo cual,
es posible que su posición actual sea diferente, atendidos los aconteci-
mientos producidos durante los últimos años.
192
A raíz de la publicación de la STJUE de 22 de Octubre
de 2015, GONZÁLEZ GRANADO modifica parcialmente su
postura, sin embargo, no hace ninguna manifestación de la que
pueda deducirse que considera que el bitcoin es, efectivamente,
dinero y por ende, algo más que un bien mueble fungible y
consumible, irrepetible y no susceptible de copia.
193
GÓMEZ DE LA CRUZ, A. y RAMOS SUÁREZ, F., Bitcoin
y su naturaleza jurídica. Sitio web: Law & Bitcoin. (30 de abril de
2015) http://lawandbitcoin.com/bitcoin-y-su-naturaleza-juridica/.
125
Carlos Tur Faúndez
persona física o jurídica distinta del emisor

de dinero electrónico. Luego al no existir
emisor, no existe crédito frente al mismo.
Coincidimos plenamente con lo expuesto
por los autores mencionados. No obstante
lo anterior, debe advertirse que la definición
del dinero electrónico se formuló por el
Parlamento y el Consejo en la Directiva 2000/46/
CE del Parlamento Europeo y del Consejo, de 18 de
septiembre de 2000, sobre el acceso a la actividad de las
entidades de dinero electrónico y su ejercicio así como
la supervisión cautelar de dichas entidades, en cuyo
considerando tercero se decía lo siguiente:
A efectos de la presente Directiva, se considerará
el dinero electrónico como un substitutivo
electrónico de las monedas y los billetes de banco,
almacenado en un soporte electrónico como, por
ejemplo, una tarjeta inteligente o la memoria de
un ordenador y que, en general, está pensado para
efectuar pagos electrónicos de cuantía limitada.
Constátese que el bitcoin nació en el año
2008194 por lo que, al tiempo de la publicación
de la Directiva antes mencionada, ni tan
siquiera podía sospecharse el ulterior
nacimiento de las monedas virtuales.
El uso del término genérico “dinero
electrónico”, por la Directiva 2000/46/CE
fue, probablemente, fruto del “statu quo”
194
Vid. sección I, apartado 1.
126
Smart Contracts
tecnológico del momento, sin embargo

consideramos desafortunada la utilización
de dicho término en la posterior Directiva
2009/110/CE y la Ley 21/2011, de 26 de junio,
que es transposición de la anterior, puesto
que, a la fecha de su entrada en vigor, el
bitcoin circulaba ya con cierta fluidez en las
redes electrónicas.
b) No son dinero de curso legal. Efectivamente
así es, en tanto que en la Unión Europea el
BCE en colaboración con los bancos centra-
les de la eurozona posee el monopolio de la
emisión del Euro. Ahora bien, como ya se
ha indicado al inicio del presente apartado,
el dinero de curso legal195 no siempre es un
medio generalmente aceptado para el inter-
cambio y para el pago de las obligaciones
pecuniarias.
195
El Reglamento (CE) nº 974/98 del Consejo de 3 de mayo
de 1998 sobre la introducción del euro dispone en su artículo 4
que el euro será la unidad de cuenta del Banco Central Europeo (BCE)
y de los bancos centrales de los Estados miembros participantes. Más
recientemente, la Directiva 2014/62/UE del Parlamento Europeo
y del Consejo, de 15 de mayo de 2014 , relativa a la protección
penal del euro y otras monedas frente a la falsificación, y por
la que se sustituye la Decisión marco 2000/383/JAI del Consejo
ha establecido en su artículo 4 que se entenderá por «moneda»: los
billetes y monedas cuya circulación está legalmente autorizada, inclui-
dos los billetes y las monedas de euro cuya circulación está legalmente
autorizada en virtud del Reglamento (CE) no 974/98.
127
Carlos Tur Faúndez
El TSJUE en Sentencia de 22 de octubre de 2015

ha elaborado una doctrina que, según nuestro
parecer, es sumamente esclarecedora y que citamos
literalmente:
(24) Procede indicar, en primer lugar, que la divisa virtual de
flujo bidireccional «bitcoin», que se intercambiará por divisas
tradicionales en las operaciones de cambio, no puede califi-
carse de «bien corporal» en el sentido del artículo 14 de la
Directiva del IVA, puesto que, como puso de manifiesto la
Abogado General en el punto 17 de sus conclusiones, no tiene
ninguna finalidad distinta de la de ser un medio de pago.
(25) Lo mismo ocurre con las divisas tradicionales, dado que
se trata de monedas que son medios de pago legales (véase,
en este sentido, la sentencia First National Bank of Chicago,
C‑172/96, EU:C:1998:354, apartado 25)196.
(26) En consecuencia, las operaciones controvertidas en el
litigio principal, que consisten en un intercambio de distin-
tos medios de pago, no están comprendidas en el concepto de
«entrega de bienes» definido en el artículo 14 de la Directiva.
Por lo tanto, estas operaciones constituyen prestaciones de
servicios, en el sentido del artículo 24 de la Directiva del IVA.
(42) Al ser la divisa virtual «bitcoin» un medio de pago
contractual, por una parte, no es posible considerarla ni una
cuenta corriente ni un depósito de fondos, un pago o un giro.
Por otra parte, a diferencia de los créditos, cheques y otros
efectos comerciales mencionados en el artículo 135, apartado
196
La sentencia First National Bank of Chicago, C‑172/96,
EU:C:1998:354, en su apartado 25, dispone que las divisas que se
intercambian a cambio de otras divisas en el marco de una operación
de cambio no pueden ser calificadas como «bienes corporales» en
el sentido del artículo 5 de la Sexta Directiva, dado que se trata de
monedas que son medios de pago legales. Las operaciones de cambio
constituyen, pues, prestaciones de servicios en el sentido del artículo
6 de la Directiva.
128
Smart Contracts
1, letra d), de la Directiva del IVA, constituye un medio de

pago directo entre los operadores que la aceptan.
(54) En lo que respecta, por último, a las exenciones estable-
cidas en el artículo 135, apartado 1, letra f), de la Directiva
del IVA, basta con recordar que esta disposición menciona,
en particular, las operaciones relativas a «acciones, parti-
cipaciones en sociedades o asociaciones [y] obligaciones», a
saber, títulos que confieren un derecho de propiedad sobre
personas jurídicas, y las operaciones relativas a los «demás
títulos-valores», de los que debe considerarse que tienen una
naturaleza comparable a la de los títulos-valores específica-
mente mencionados en dicha disposición (sentencia Granton
Advertising, C‑461/12, EU:C:2014:1745, apartado 27).
(55) Pues bien, consta que la divisa virtual «bitcoin» no es ni
un título que confiera un derecho de propiedad sobre personas
jurídicas ni un título que tenga una naturaleza comparable197.
COSÍN pone en cuestión la argumentación del TSJUE

197
que determina que las monedas virtuales son un medio de pago

puro, pues su posesión no incorpora otros derechos (como ocu-
rre en acciones y otros títulos valores). Así, expone dicho autor,
en el caso de Ethereum, además de ser un medio de pago, que lo
es, lleva aparejados derechos de participación en comunidades
autónomas descentralizadas. Vid. Sitio web: Territorio Bicoin.
(14 de octubre de 2016) Naturaleza jurídica del Bitcoin. https://
www.territoriobitcoin.com/naturaleza-juridica-del-bitcoin/.
Discrepamos del punto de vista de dicho autor puesto
que, el Ether, no tiene otra finalidad, en la cadena de bloques
Ethereum, distinta a la de constituir un medio de pago si bien
es cierto que la creación de 5 unidades monetarias se produce
automáticamente por el sistema, para pagar “la recompensa”,
cada vez que un minero resuelve un bloque (15-17 segundos). El
Ether, no lleva aparejado derecho accesorio alguno. No obstante
lo anterior, en la cadena de bloques Ethereum, cabe la posibilidad
de que una “startup”, decida financiarse a través del mecanismo
denominado “crowdfunding” regulado parcialmente en la Ley
5/2015, de 27 de abril, de fomento de la financiación empresa-
rial (pues no contempla la financiación participativa sin ánimo
129
Carlos Tur Faúndez
A la vista de los argumentos expuestos en la

Sentencia del TSJUE, de 22 de octubre de 2015, lle-
gamos a las siguientes conclusiones:
1. Las monedas virtuales no son un simple
bien corporal, es decir, no pueden ser redu-
cidas a la categoría de bien mueble o bien
patrimonial198.
2. Las monedas virtuales no son dinero de
curso legal pero sí son un medio de pago
legal en tanto que son admitidas como
tal por el propio TSJUE. Debe ponerse de
relieve que como se ha expuesto, la dicción
literal de la Sentencia aludida, en su apar-
tado 25 es la siguiente: Lo mismo ocurre con
las divisas tradicionales, dado que se trata de
monedas que son medios de pago legales, por lo
que sensu contrario, podría interpretarse que
las monedas virtuales son medios de pago
de lucro). El mecanismo habitual, es la puesta a la venta de un

número determinado de tokens (palabra anglosajona polisémica
que puede ser traducida como, ficha, muestra, señal, represen-
tación, bono, testigo, etc.). Los mecanismos necesarios para ello,
están ampliamente explicados en la página web de “Ethereum
Create a crowdsale” que podemos hallar en el Sitio web: https://
ethereum.org/crowdsale. A diferencia de lo que ocurre con el Ether,
dichos tokens, no cumplen, en principio, finalidad de pago
alguna e incorporan o pueden incorporar derechos de diversa
índole sobre las empresas que los emiten.
198
También el dinero de curso legal es un bien mueble, fun-
gible y sin embargo su naturaleza jurídica difiere, considerable-
mente de la de los restantes bienes muebles.
130
Smart Contracts
ilegales o “no legales”. Sorprendidos por el

texto de la Sentencia, hemos decidido revi-
sar su versión original en inglés199, pudiendo
constatar que su tenor literal es el siguiente:
(25) The same is true for traditional currencies,
since it involves money which is legal tender.
A la vista del contenido, se detecta un incues-
tionable error en la traducción, puesto que
el término anglosajón legal tender debe ser
traducido como dinero de curso legal y en
ningún caso como “medio de pago legal200”.
3. Las monedas virtuales son un medio de
pago contractual y carecen de otra finalidad
distinta al pago.
4. Las monedas virtuales no son:
a) Cuentas corrientes;
b) Depósitos de fondos;
c) Créditos;
d) Cheques;
e) Efectos comerciales201.
199
Texto original en inglés en el sitio web: http://curia.europa.
eu/juris/document/document.jsf;jsessionid=9ea7d0f130d52fccf31329534c5a93f
b850b25d19b91.e34KaxiLc3eQc40LaxqMbN4Oc34Oe0?text=&docid=170305&
pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=80864.
200
No existe en el Reino Unido una institución similar a la
RAE que publique un Diccionario Oficial. Hemos recurrido a
uno de los diccionarios más prestigiosos, el Cambrige Dictionary
y los resultados pueden verificarse en el sitio web: http://dictionary.
cambridge.org/dictionary/english-spanish/legal-tender.
201
La Agencia Tributaria en sus tres últimas consultas vincu-
lantes (V1028-15, V1029-15 y V2846-15) en materia de fiscalidad
del bitcoin, ha atribuido a dicha criptomoneda la condición de
131
Carlos Tur Faúndez
5. Las monedas virtuales no son un título

valor.
Llegados a este punto, cabe concluir que ni
tan siquiera el Tribunal Superior de Justicia de la
Unión Europea ha dado respuesta a la pregunta
que formulábamos al inicio del presente apartado:
¿Podemos considerar que las monedas virtuales
son dinero? La respuesta es, bajo nuestra óptica,
sencilla. Las monedas virtuales son apuntes en
cuenta digitales e inmutables que constituyen un
medio generalmente aceptado para el intercambio
y para el pago de las obligaciones pecuniarias que
se generan a través de una determinada cadena de
bloques.
Si bien es cierto que, obviamente, no pueden
tener la consideración de dinero de curso legal, pues
quedan fuera de la prerrogativa gubernamental de
emitir moneda, nada obsta que puedan y deban
ser consideradas como dinero privado. Se trata,
curiosamente, de un concepto antiguo en el que,
sin embargo, encajan a la perfección las modernas
criptomonedas. Según HAYEK (en el apartado titu-
lado private money preferred), ciertamente puede haber
y ha habido dinero, incluso dinero muy satisfactorio, sin
efecto comercial. En cualquier caso, debe tomarse en considera-

ción que la última de las consultas fue resuelta el 1 de octubre de
2015, es decir 21 días antes que la STSJUE, tantas veces aludida)
Puede verificarse el contenido de las referidas consultas en el
sitio web: http://petete.minhafp.gob.es/consultas/
132
Smart Contracts
que el gobierno haga nada al respecto, aunque rara vez

se ha permitido que exista por mucho tiempo202.
El dinero privado es dinero y tan sólo presenta
una diferencia respecto al dinero de curso legal y
es que éste último no puede ser rechazado por un
acreedor como pago de una deuda contraída en
dicha moneda203.
La legislación española no prohíbe en absoluto
el uso de dinero privado en las transacciones eco-
nómicas. Antes todo lo contrario. El artículo 1.170 CC
dispone que el pago de las deudas de dinero deberá
hacerse en la especie pactada y, no siendo posible entre-
gar la especie, en la moneda de plata u oro que tenga
curso legal en España.
Constátese pues, que sólo en el caso de que
una deuda contraída en Ether o Bitcoin no pueda
ser satisfecha en dicha especie, cumplirá el acree-
dor, si paga al accipiens o consigna judicialmente el
importe debido en Euros.
El artículo 312 del C.co. dispone que consistiendo
el préstamo en dinero, pagará el deudor devolviendo una
cantidad igual a la recibida, con arreglo al valor legal
que tuviere la moneda al tiempo de la devolución, salvo
202
Ob. Cit. HAYEK, F.A., pág. 38. (Private money preferred)
(Texto original: certainly can be and has been money, even very
satisfactory money, without government doing anything about
it)
203
En este sentido NUSSBAUM, A., In the Law. National
and International Foundation Press, Brooklyn, 1950 así como
MANN, F.A. The Legal Aspects of Money. 3rd Edition. Oxford
University Press. London, 1971.
133
Carlos Tur Faúndez
si se hubiere pactado la especie de moneda en que había

de hacerse el pago, en cuyo caso la alteración que hubiese
experimentado su valor será en daño o en beneficio del
prestador, luego permite el uso de cualquier moneda
(física o virtual) sin hacer consideración respecto a
la exigencia de que el dinero sea de curso legal204.
El artículo 1.445 CC resulta aún más claro si
cabe, pues dispone que por el contrato de compra y
venta uno de los contratantes se obliga a entregar una
cosa determinada y el otro a pagar por ella un precio
cierto, en dinero o signo que lo represente. Si no cabe
duda alguna de que la moneda virtual es dinero (si
bien no lo es de curso legal), la representación de
dinero que cabe atribuirle resulta, de todo punto,
irrefutable.
La conceptuación de la moneda virtual como
dinero (sea este privado o de curso legal), no des-
cansa en el ámbito de la mera elucubración teórica,
sino que tiene una trascendencia práctica tangible,
en tanto que proporciona certidumbre y seguridad
jurídica. Sabido es que el artículo 1.255 CC proclama
el principio de la autonomía de la voluntad y que,
según expone su dicción literal, los contratantes pue-
den establecer los pactos, cláusulas y condiciones que
tengan por conveniente, siempre que no sean contrarios
a las leyes, a la moral ni al orden público. Por lo tanto,
dentro del ámbito definido por la ley, las partes
Constátese, en todo caso que, en Europa, el Euro es dinero

204
de curso legal, pero no lo es ninguna otra moneda extranjera.
134
Smart Contracts
pueden obligarse mediante contratos atípicos en

los que regulen, de forma novedosa y desconocida
por el Ordenamiento Jurídico, sus relaciones nego-
ciales. Sin embargo, los contratos típicos proporcio-
nan un marco normativo claro, definido y apoyado,
además, por una extensa doctrina jurisprudencial
que los interpreta.
Entre los contratos sinalagmáticos regulados
en nuestro Código civil, en los que se produce el
intercambio de “cosa por precio cierto” hallamos
la compraventa (art. 1.445 CC y ss.) el arrendamiento
de cosas (art. 1.543 CC) y el arrendamiento de obras
o servicios (art. 1.544 CC). Todos ellos integran una
obligación pecuniaria consistente en el pago del
precio de la cosa, o lo que es lo mismo, la entrega
de una determinada cantidad de dinero. Aquellos
contratos legales inteligentes en los que exista una
prestación consistente en el pago de una determi-
nada suma de monedas virtuales podrán ser cali-
ficados, según el caso, como compraventa, arren-
damiento de cosas, obras o servicios, siempre que
sean subsumibles en el supuesto de hecho de la
norma, sin que sea necesario recurrir a artificiosos
contratos atípicos, huérfanos de regulación legal
y de interpretación doctrinal y jurisprudencial205.
En otras ocasiones, la consideración de las monedas vir-

205
tuales como simples bienes muebles, ha conducido a algunos

autores, a interpretar que un contrato de compraventa en el que
el precio debe satisfacerse en bitcoins debe ser calificado como
permuta, al no existir precio cierto, sino una mera obligación
135
Carlos Tur Faúndez
Deseamos subrayar, por último, que las mone-

das virtuales no son hoy dinero de curso legal,
pero nada obsta que, en el futuro, puedan llegar a
serlo. El ejemplo más relevante, a día de hoy, es el
denominado Project Ubin206, liderado por la Auto-
ridad Monetaria de Singapur (MAS) y Deloitte con
la colaboración de las siguientes organizaciones:
Bank of America Merrill Lynch, BCS Information
Systems, Credit Suisse, DBS Bank Ltd, The Hon-
gkong and Shanghai Banking Corporation Limited,
J.P. Morgan, Mitsubishi UFJ Financial Group, OCBC
Bank, R3, Singapore Exchange y United Overseas
Bank. El objetivo perseguido es la creación de una
cadena de bloques (o DLT, esto es, distributed ledger
tecnology207) de naturaleza consorcial208 y la “toke-
nización” del dólar de Singapur (SGD). Ello sig-
nificaría, en el caso de que el proyecto alcanzara
el éxito, que la Autoridad Monetaria de Singapur,
como miembro de la cadena de bloques emitiría
dólares de Singapur virtuales, transmisibles en el
de dar. Obsérvese, como mero ejemplo, la trascendencia de la

cuestión en materia tributaria. En una permuta, si ambas partes
son sujeto pasivo de IVA, ambas vendrán obligadas a liquidarlo,
mientras que si se trata de una compraventa, sólo el vendedor
deberá hacerlo.
206
DELOITTE, MONETARY AUTHORITY OF SINGAPORE
(2017) The future is here Project Ubin: SGD on Distributed Led-
ger. Sitio web: http://www.mas.gov.sg/~/media/ProjectUbin/Project%20
Ubin%20%20SGD%20on%20Distributed%20Ledger.pdf.
207
Tecnología de libros de registro distribuidos.
208
Vid. sección I, apartado 2.3.
136
Smart Contracts
interior de la cadena e intercambiables en el exte-

rior de la misma por dinero efectivo, lo que, de
facto, implicaría la transformación del SGD “toke-
nizado” en dinero de curso legal.
No queremos dejar de insistir en que la cadena
de bloques Ethereum, a pesar de ser la única DLT
pública que en la actualidad permite la creación de
smart contracts, como instrumento de ejecución de
contratos legales inteligentes no constituye, según
nuestro parecer, un fin en sí misma, sino un
medio para construir, en el futuro, una cadena de
bloques en cuyo proceso de consenso participen209
los gobiernos de los diferentes estados y las
autoridades monetarias de los mismos.
209
La participación en el proceso de consenso de los gobier-
nos debe servir a la transparencia y la seguridad jurídica. La
posibilidad de que los Estados ostenten un derecho ilimitado a
alterar la inmutabilidad de la cadena de bloques generará, ine-
vitablemente, abusos indeseados con la consecuente pérdida de
confianza de los ciudadanos en la misma. En tal caso, deberemos
citar, como tantas veces, a Ambrose Bierce: There’s nothing new
under the sun…(Trad. “no hay nada nuevo bajo el sol…”).
137
CONCLUSIONES
1. Los smart contracts no son contratos. Son

secuencias de código y datos que se alma-
cenan en una determinada dirección de una
concreta cadena de bloques. No obstante
lo anterior, en la mayoría de los casos, los
smart contracts son creados con vocación de
relevancia jurídica y, por ende, como instru-
mento para desarrollar la ejecución auto-
mática de las prestaciones de un contrato
electrónico.
2. La tecnología permite, actualmente, cons-
truir aplicaciones web cómodamente acce-
sibles para cualquier ciudadano medio, en
cuya parte no visible (back end) existe un
smart contract que se ejecuta de forma auto-
mática. Con ello queremos significar que el
contrato, como concepto jurídico, no se cir-
cunscribe al smart contract, que es, como se
ha expuesto, un programa informático, sino
139
Carlos Tur Faúndez
que alcanza a los mecanismos de interacción

establecidos por los desarrolladores de la
interfaz y a través de los cuales el usuario
recibe y envía información.
3. Podemos definir, por tanto, los contratos
legales inteligentes como aquellos contra-
tos celebrados a través de una página web
accesible para las partes (o una aplicación
móvil) cuya forma está constituida por la
interfaz de usuario de la aplicación externa
y uno o varios programas autoejecutables
(smart contracts) residentes en la cadena de
bloques con capacidad para interactuar recí-
procamente y con dicha interfaz.
Somos conscientes de que la expresión
contrato legal inteligente (smart legal contract)
es redundante y ello, por cuanto que, el cali-
ficativo –legal-, está implícitamente incluido
en el sustantivo -contrato-. Sin perjuicio de
lo expuesto, nos mostramos partidarios del
uso de dicho pleonasmo, pues presenta, a
nuestro juicio, más ventajas que inconve-
nientes. La expresión smart contract o, en
castellano, contrato inteligente, incluye, erró-
neamente, el vocablo -contrato-, cuando no
hay tal. La adición del calificativo legal a la
expresión contrato inteligente, nos permite
establecer una clara diferenciación entre el
software subyacente en el back end y el verda-
dero contrato electrónico con eficacia obli-
140
Smart Contracts
gacional entre las partes y de cuya estruc-

tura informática y formal es parte el smart
contract.
4. Los contratos legales inteligentes son contratos
electrónicos, puesto que se celebran través
de aplicaciones web interconectadas electró-
nicamente con una cadena de bloques, por
lo que entran, de lleno, en el ámbito de apli-
cación del artículo 23 de la da Ley 34/2002,
de 11 de julio, de servicios de la sociedad
de la información y de comercio electrónico
y, en su caso, en el de las normas de la Ley
7/1998, de 13 de abril, sobre condiciones
generales de la contratación y la Ley Gene-
ral para la Defensa de los Consumidores y
Usuarios, en las que se prevén requisitos
específicos de validez cuya ausencia pue-
den determinar la ineficacia de determina-
das cláusulas contractuales y, en su caso, la
de todo el negocio jurídico.
5. En los contratos legales inteligentes la reali-
zación de las prestaciones (o al menos una
parte de ellas) y, por ende, la consumación
del contrato, la lleva a efecto el propio smart
contract sin requerir, en absoluto, el consen-
timiento de las partes en fase de ejecución,
puesto que dicha fase se desarrolla de forma
automática. En dichos contratos, se requiere
la concurrencia de un doble consentimiento
simultáneo:
141
Carlos Tur Faúndez
a. El habitual consentimiento que deter-

mina la perfección del contrato (las par-
tes se obligan a obligarse).
b. El consentimiento preconstituido sobre la
consumación automática. Es decir, cada
una de las partes debe aceptar, expre-
samente, que la prestación objeto de su
obligación será realizada automática-
mente por el smart contract en las condi-
ciones pactadas y sin recabar para ello
su autorización. De lo contrario, existe el
riesgo de que la voluntad del contratante
se forme a través de una representación
mental inexacta.
Cabe concluir, pues que los contratos
legales inteligentes deben proporcionar a las
partes información clara, precisa, exhaustiva
y comprensible sobre los procedimientos
mediante los que se va a desarrollar la eje-
cución automática de las prestaciones y su
alcance patrimonial.
6. La eficacia probatoria de los contratos legales
inteligentes resulta, a nuestro juicio, incues-
tionable, puesto que se hallan integrados
en una cadena de bloques que garantiza,
plenamente:
a. La identidad de los contratantes, si se
hace uso de la firma electrónica recono-
cida y de otros elementos tecnológicos
disponibles para ello.
142
Smart Contracts
b. El momento de la prestación del consen-

timiento contractual a través del meca-
nismo de sellado de tiempo o timestamp
de la propia cadena de bloques.
c. La absoluta inmutabilidad de cuanto se
contenga en la cadena de bloques, en
tanto que se trata de un registro distri-
buido entre miles de nodos con copias
idénticas.
7. Los contratos legales inteligentes proporcio-
nan la ejecución automática y programada
de las contraprestaciones contractuales (la
totalidad o una parte de ellas) por lo que
la consumación del contrato no siempre
depende de la voluntad de las partes, sino
que es el propio software (smart contract) el
que la lleva a efecto si se dan las condicio-
nes pactadas. A tenor de lo expuesto, en lo
que hace referencia a las prestaciones auto-
matizadas, no cabe hablar, por lo general,
de cumplimiento o incumplimiento obliga-
cional en el sentido jurídico conocido para
los contratos tradicionales. Sin embargo, el
contrato legal inteligente va más allá de las
aplicaciones informáticas que lo estructuran
y ello implica que el accipiens mantendrá su
derecho a exigir al solvens el cumplimiento
de la prestación debida, aún cuando se haya
producido un error informático obstativo o
impeditivo.
143
Carlos Tur Faúndez
8. En los contratos legales inteligentes, como en

cualesquiera otros, las partes pueden pactar
que la relación obligatoria esté sometida a
una determinada condición, sea ésta suspen-
siva o resolutoria. La “inteligencia” de los
smart contracts es limitada y, si bien es cierto
que éstos pueden verificar cualquier infor-
mación existente en la cadena de bloques, no
disponen de recursos para la comprobación
de datos en el mundo real y, menos aún,
para discernir cuáles de ellos son ciertos. En
consecuencia, tampoco pueden determinar
sin la colaboración de agentes externos, si
una condición (sea ésta suspensiva o reso-
lutoria) se ha cumplido. Los oráculos (oracles)
cumplen dicha función. Se trata de empresas
externas respecto a la cadena de bloques que
pueden facilitar al programa cualquier tipo
de información y que han creado un soft-
ware propio que les permite interaccionar
con el smart contract. Los datos remitidos por
el oráculo permiten al programa evaluar la
posible concurrencia de las condiciones y,
en función del resultado, “actuar” en uno u
otro sentido.
9. El smart contract que subyace en el back end
de todo contrato legal inteligente puede ser
programado para que asuma la entrega o
puesta a disposición del bien o servicio que
constituya el objeto de la obligación sin que
144
Smart Contracts
para ello sea necesario ningún desplaza-

miento, gracias a la tecnología proporcio-
nada por IoT. (Internet of Things) Pues bien,
la traditio, entendida como puesta a disposi-
ción del control sobre la cosa o como entrega
de llaves, va a ser el mecanismo del que habi-
tualmente se servirán los smart contracts para
la ejecución automática de las prestaciones
en los contratos legales inteligentes.
10. Las monedas virtuales son dinero, aunque
privado. La ley no impide que las presta-
ciones pecuniarias puedan consistir en el
pago de un precio fijado en una determi-
nada moneda virtual. Tal consideración con-
tribuye a la seguridad jurídica de los con-
tratos legales inteligentes pues nos permite
calificarlos como contratos típicos, siempre
y cuando sean subsumibles en el supuesto
fáctico de la norma que los regula.
145
ÍNDICE BIBLIOGRÁFICO
A.A.V.V. (s.f.) Aula Virtual de Seguridad Infor-

mática y Criptografía CRYPT4YOU de la Universi-
dad Politécnica de Madrid en el sitio web:
http://www.criptored.upm.es/crypt4you/portada.html.
A.A.V.V. Notariado y contratación electrónica.
Colegios Notariales de España. Madrid. 2001.
A.A.V.V. (s.f.) Bitcoin.
Sitio web: https://bitcoin.org/es/.
A.A.V.V. (s.f.) codebeautify.com.
Sitio web: https://codebeautify.org/string-binary-converter
A.A.V.V. (s.f.) Dash.
Sitio web: https://www.dash.org/es/.
A.A.V.V. (s.f.) Dogecoin.
Sitio web: http://dogecoin.com/.
A.A.V.V. (s.f.) Ethereum.
Sitio web: https://www.ethereum.org/.
A.A.V.V. (s.f.) ethernodes.org.
Sitio web: https://www.ethernodes.org/network/1.
A.A.V.V. (s.f.) Facebook Messenger.
147
Carlos Tur Faúndez
Sitio web: https://es-es.messenger.com/.

A.A.V.V. (s.f.) Facetime.
Sitio web: https://support.apple.com/es-es/HT204380.
A.A.V.V. (s.f.) Hyperledger. Sitio web:
https://www.hyperledger.org/.
A.A.V.V. (s.f.) INTYPEDIA information security
encyclopedia (Vídeos 1,2,3 y 14).
Sitio web: http://www.intypedia.com/.
A.A.V.V. (s.f.) IPFS. Sitio web: https://ipfs.io/.
A.A.V.V. (s.f.) Litecoin.
Sitio web: https://litecoin.com/es/.
A.A.V.V. (s.f) Monax. Sitio Web: https://monax.io/.
A.A.V.V. (s.f.) Monero.
Sitio web: https://getmonero.org/.
A.A.V.V. (s.f.) r3.
Sitio web: https://www.r3.com/.
A.A.V.V. (s.f.) Remix.ethereum. Sitio web:
https://remix.ethereum.org/#version=soljson-v0.4.13+commit.
fb4cb1a.js.
A.A.V.V. (s.f.) Skype.
Sitio web: https://www.skype.com/es/.
A.A.V.V. (s.f.) Solidity.readthedocs.io
Sitio web: https://solidity.readthedocs.io/en/develop/.
A.A.V.V. (s.f.) Swarm.
Sitio web: http://swarm-gateways.net/bzz:/theswarm.eth/.
A.A.V.V. (s.f.) Toolsey.
Sitio web: https://www.toolsley.com/hash.html.
A.A.V.V. (s.f.) Uport.
Sitio web: https://www.uport.me/.
148
Smart Contracts
Abanlex.com (s.f.) Servicios legales sobre

bitcoins y otras criptomonedas.
Sitio web: https://www.abanlex.com/areas-de-practica/
derecho-de-internet/bitcoin-y-otras-criptomonedas/.
Agencia Española de Protección de datos
(7 de junio de 2017) Blockchain y protección de datos.
Blog AGPD.
Sitio web: http://www.agpd.es/blog/blockchain-y-protec-
cion-de-datos-ides-idPhp.php.
Aguilera Silván, F, J., (1 de abril de 2011) “El
objeto como elemento esencial del contrato”. Noti-
cias Jurídicas.
Sitio web: http://noticias.juridicas.com/conocimiento/arti-
culos-doctrinales/4648-el-objeto-como-elemento-esencial-del-
contrato/.
Albaladejo, M., Derecho civil II. Derecho de
obligaciones, Ed. Bosch, Barcelona, 2002, Undécima
edición.
Alisie, M., (14 de marzo de 2015) “Mihai´s
Ethereum Project Update. The First Year”. Ethereum
blog. Sitio web:
https://blog.ethereum.org/2015/03/14/ethereum-the-first-year/.
Alison, I., (13 de noviembre de 2015) DevCon1:
“Nick Szabo says smart contracts substitute an army
of lawyers and accountants”. International Business
Times.
Sitio web: http://www.ibtimes.co.uk/devcon1-nick-szabo-
says-smart-contracts-substitute-army-lawyers-accoun-
tants-1528604.
149
Carlos Tur Faúndez
Andrés, I., (11 de octubre 2017) Peniafort.es.

Sitio web: http://peniafort.es/el-fin-del-papel/.
Araoz, M. y Ordano, E., (s.f.) Proof of Existence.
Sitio web: https://proofofexistence.com/about.
Arias Pou, M. Manual práctico de comercio elec-
trónico. La Ley. Madrid.2006.
Bakshi, V.A., Braine, L. y Clack, C.D., (15 de
marzo de 2017) Smart Contract Templates: founda-
tions, design landscape and research directions. Sitio
web: https://arxiv.org/pdf/1608.00771.pdf.
Barrdear, J. y Kumhof, M., (BANK OF
ENGLAND/julio de 2016) The macroeconomics of
central bank issued digital currencies.
Sitio web: http://www.bankofengland.co.uk/research/Docu-
ments/workingpapers/2016/swp605.pdf.
Barriuso Ruiz, C., La contratación electrónica.
Editorial Dykinson. Madrid.2006.
Berger, N., (s.f.) “Web3 JavaScript app
API. Ethereum/wiki”. Repositorio GitHub.
Sitio web: https://github.com/ethereum/wiki/wiki/
Bertani, T., (s.f.) Insureth.
Sitio web: http://insureth.mkvd.net/.
Bertani, T., (2015) Insureth. Repositorio Github.
Sitio web: https://github.com/bertani/insurETH.
Bitcoin.com (2017)
Sitio web: https://news.bitcoin.com/one-of-these-5-hyperin-
flating-economies-could-adopt-bitcoin-in-2017/.
150
Smart Contracts
Braengaard, P., (29 de junio de 2016) “Simple

Convention for Human Readable Terms for Smart
Contracts”. Blog stakeventures.
Sitio web: https://blog.stakeventures.com/articles/
smart-contract-terms.
Braengaard, P. (29 de junio de 2016) “Adding
human readable terms to Solidity contracts”. Repo-
sitorio Github.
Sitio web: https://github.com/pelle/solidterms.
Berning Prieto, A.D., (1 de junio de 2008)
“Derecho de la contratación electrónica”. Noticias
Jurídicas.
Sitio web: http://noticias.juridicas.com/conocimiento/articu-
los-doctrinales/4382-derecho-de-la-contratacion-electronica/.
Bit2me, “¿Cuánto vale un Bitcoin? ¿Cómo y
quién determina su precio?” (s.f) blog.bit2me.
Sitio web: http://blog.bit2me.com/es/precio-Bitcoin/.
Bit2me, (s.f) “¿Qué es minar bitcoins?”
Blog.bit2me. Sitio web: http://blog.bit2me.com/es/
que-es-minar-bitcoins/.
Bloomberg News, “China Is Developing its
Own Digital Currency” (23 de febrero de 2017)
Bloomberg. Sitio web: https://www.bloomberg.com/news/
articles/2017-02-23/pboc-is-going-digital-as-mobile-pay-
ments-boom-transforms-economy.
Breckinridge, S. P., Legal Tender. University of
Chicago Press. Chicago. 1903.
Brownworth, A., (s.f.) anders.com.
Sitio web: https://anders.com/blockchain/hash.html.
151
Carlos Tur Faúndez
Bueno de Mata, F., Prueba electrónica y proceso

2.0. Tirant lo Blanch. Valencia. 2014.
Camacho Clavijo, S., Partes intervinientes,
formación y prueba del contrato electrónico. Editorial
Reus. Madrid. 2005.
Cant, B., Khadikar, A., Ruiter, A., Brone-
bakk, J.B., Coumaros, J., Buvat, J. y Gupta, A.,
“Smart Contracts in Financial Services: Getting
from Hype to Reality”. Capgemini Consulting.
Sitio web: https://www.capgemini-consulting.com/resou-
rce-file-access/resource/pdf/smart-contracts.pdf.
Cavanillas múgica, S., Tur Faúndez, N.,
Benito Roser y T., Suinaga Romero de Terreros,
C.; Turismo y comercio electrónico, Comares, 2001
Cosín, J., (14 de Octubre de 2016)
“Naturaleza jurídica del Bitcoin”. Territorio
Bitcoin. Sitio web: https://www.territoriobitcoin.com/
naturaleza-juridica-del-bitcoin/
Cremades, J., Fernández Ordóñez, J. e Illes-
cas ortiz, R.. (Coordinadores) Régimen jurídico de
Internet. La ley. Madrid. 2002.
De Castro y Bravo, F., El negocio jurídico. Cívi-
tas. Madrid. 2016.
Deloitte, Monetary Authority Of Singa-
pore (2017) “The future is here”, Project Ubin: SGD
on Distributed Ledger. Sitio web: http://www.mas.gov.
sg/~/media/ProjectUbin/Project%20Ubin%20%20SGD%20
on%20Distributed%20Ledger.pdf.
De Miguel Asensio, P. A., Derecho Privado e
Internet. Ed. Civitas. Madrid.2001.
152
Smart Contracts
Díez-Picazo, L. y Gullón, A., Sistema de Dere-

cho civil. Vol II. Ed. Tecnos. Novena edición. Madrid
Emarketer.com, (22 de agosto de 2016).
“Worldwide Retail Ecommerce Sales Will Reach
$1.915 Trillion this Year”. Emarketer.com. Sales and
Finances. Sitio web: https://www.emarketer.com/Article/
Worldwide-Retail-Ecommerce-Sales-Will-Reach-1915-trillion-
This-Year/1014369.
Energy Web Foundation (s.f.)
Sitio web: http://energyweb.org/.
Entethalliance (s.f.)
Sitio web: https://entethalliance.org/members/.
Escobar, V., (23 de junio de 2017)
“Gobierno japonés reinventará su registro de
propiedades con blockchain”. Criptonoticias.
Sitio web: https://criptonoticias.com/aplicaciones/
gobierno-japones-reinventara-registro-propiedades-
blockchain/#axzz4pRDSTFAB.
Esparragoza, L., (6 de abril de 2017) “Regis-
tro inmobiliario de Brasil realizará prueba con
blockchain para registrar títulos de propiedad”.
Criptonoticias. Sitio web: https://www.criptonoticias.
com/adopcion/registro-inmobiliario-brasil-realizara-prueba-
blockchain-registrar-titulos-propiedad/#axzz4pRDSTFAB.
Ethereum.nz, (30 de Abril de 2016), “Smart
Contracts and why lawyers should care” Ethe-
reum.nz. Sitio web: http://www.ethereum.nz/blog/
smart-contracts-and-why-lawyers-should-care.
153
Carlos Tur Faúndez
Fernández Fernández, R., El contrato electró-

nico: formación y cumplimiento, J.M Bosch Editor.
Barcelona 2013.
García Más, F.J., El documento electrónico. Un
reto a la seguridad jurídica. Dykinson. Madrid. 2015.
Gartner, LTD. (7 de febrero de 2017) Gartner
newsroom. Sitio web: http://www.gartner.com/newsroom/
id/3598917.
Gerryts, J., Johnson, J., Jameson, H.,
Liang, S. y Fisher, L., (s.f.) Oaken Innova-
tions. Sitio web: http://www.ethereum.nz/blog/
smart-contracts-and-why-lawyers-should-care.
Gómez de la Cruz, A. y Ramos suárez, F.,
(30 de abril de 2015) “Bitcoin y su naturaleza jurí-
dica”. Law & Bitcoin. Sitio web: http://lawandbitcoin.
com/bitcoin-y-su-naturaleza-juridica/.
González Granado, J., (25 de octubre de 2015)
“Concepto y naturaleza jurídica del BitCoin”. Taller
de Derechos. Sitio web: https://tallerdederechos.com/
concepto-y-naturaleza-juridica-del-bitcoin/.
González Granado J., (4 de abril de 2016)
“¿Enviará blockchain de vacaciones a los notarios?”
Notaría abierta. Sitio web: https://www.notariabierta.es/
enviara-blockchain-vacaciones-los-notarios/.
González Segade, J.A., Comercio electrónico en
Internet. Madrid. Marcial Pons. 2001
Google, (s.f.) Ayuda de Adsense.
Sitio web: https://support.google.com/adsense/
answer/6242051?hl=es.
154
Smart Contracts
Grigg, I., (s.f.) “The Ricardian Contract”. Iang.

org Sitio web: http://iang.org/papers/ricardian_contract.
html.
Gupta, M., Blockchain for dummies. IBM limited
edition. John Wiley & Sons, Inc. Hoboken. 2017.
Gupta, V., (28 de febrero de 2017) “A Brief His-
tory of Blockchain”. Harvard Business Review. Sitio
web: https://hbr.org/2017/02/a-brief-history-of-blockchain.
Gupta, V., (6 de marzo de 2017) “The Promise
of Blockchain is a World without Middlemen”. Har-
vard Business Review. Sitio web: https://hbr.org/2017/03/
the-promise-of-blockchain-is-a-world-without-middlemen.
Gupta, V. y Consensys LL.C., (febrero 2017)
“Building the hyperconnected future on blockcha-
ins”. Internet Of Agreements.
Sitio web: http://internetofagreements.com/files/
WorldGovernmentSummit-Dubai2017.pdf.
Gupta, V. y Knight, R., (17 de mayo de
2017) “How Blockchain Could Help Emer-
ging Markets Leap Ahead”. Harvard Busi-
ness Review. Sitio web: https://hbr.org/2017/05/
how-blockchain-could-help-emerging-markets-leap-ahead.
Gupta, V., Knight, R., Wray, C., Grigg, I.,
Kuhlman, C., Cimpoesu, M., Mainelli, M., (2017)
“Mattereum (White paper) Smart Contracts. Real
Property”. Internet Of Agreements.
Sitio web: http://internetofagreements.com/assets/
MattereumDraftforPublicComment.pdf.
Hijas Cid, E., (s.f) “Bitcoins: algunas cuestiones
jurídicas”. Revista Notario del Siglo XXI, número 66.
155
Carlos Tur Faúndez
Sitio web: http://www.elnotario.es/index.php/hemeroteca/

revista-54?id=6525:bitcoins-algunas-cuestiones-juridicas.
Horn, R., (2002) “The Turing Test Debate”. Stan-
dford University. Sitio web: http://stanford.edu/~rhorn/a/
kmap/arg/artclTheTuringTstDebate.1.pdf.
Horn, R., (s.f) “An Argumentation Map. Can
computers think?” Standford University. Sitio web:
https://web.stanford.edu/~rhorn/a/topic/phil/artclISSAFi-
gure1.pdf.
Howard, L.S., (6 de febrero de 2017) “Block-
chain Insurance Industry Initiative B3i Grows to
15 Members”. Insurance Journal.
Sitio web: http://www.insurancejournal.com/news/
international/2017/02/06/440629.htm.
Ibm (s.f.) Watson Internet of Things. Sitio
web: https://www.ibm.com/internet-of-things/spotlight/
blockchain.
Illescas Ortiz, R., Derecho de la contratación
electrónica. 2ª ed., Civitas, Madrid, 2009.
Illescas Ortiz, R., Derecho mercantil y globaliza-
ción. Anuario de la Facultad de Derecho de Univer-
sidad Autónoma de Madrid, nº 9, págs. 79-94. 2005.
Internet of agreements ltd., (s.f) Internet of
agreements. Sitio web: http://internetofagreements.com/.
Jameson, H., (25 abril 2017) “IoT Blink Demo
using Pi + Ethereum. Oaken-Innovations/IoT-
Blink”. Repositorio GitHub. Sitio web: https://github.
com/Oaken-Innovations/IoT-Blink.
Juliá Barceló, R., Comercio electrónico entre
empresarios. Tirant lo Blanch. Valencia. 2000.
156
Smart Contracts
Keyrus Spain, (24 de mayo de 2017) “¿Cómo la

nueva regulación de protección de datos (RGPD)
y el Blockchain conducen al futuro de la identidad
soberana?”. Keyrus Spain. Sitio web: https://keyrusspain.
wordpress.com/2017/05/24/como-la-nueva-regulacion-de-
proteccion-de-datos-rgpd-y-el-blockchain-conducen-al-
futuro-de-la-identidad-soberana/.
Knight, R., (2 de mayo de 2017) “Technology
for making agreements”. Medium.
Sitio web: https://medium.com/humanizing-the-singularity/
technology-for-making-agreements-47613e458ffa.
Lantmäteriet, Chromaway, Sbab,
Landshypotek Bank, Telia company, Kairos
Future, (marzo de 2017) The Land Registry in the
blockchain – testbed. Sitio web: https://chromaway.com/
papers/Blockchain_Landregistry_Report_2017.pdf.
Legiscan (21 de julio de 2017) Delaware Senate
Bill 69. Signed by Governor.
Sitio web: https://legiscan.com/DE/bill/SB69/2017.
Llopis, J.C., (9 de agosto de 2016), “Algunos
ejemplos de la aplicación de Blockchain a los
registros de la propiedad inmobiliaria”. Notaría
Llopis. Sitio web: http://www.notariallopis.es/blog/i/1388/73/
algunos-ejemplos-de-la-aplicacion-de-blockchain-al-registro-
de-la-propiedad-inmobiliaria-ii.
Llopis, J.C., (22 de noviembre de
2016), “El notario ante la identidad y la
capacidad digital”. Notaría Llopis. Sitio
web: http://www.notariallopis.es/blog/i/1401/73/
el-notario-ante-la-identidad-y-la-capacidad-digital-notartic.
157
Carlos Tur Faúndez
Llopis, J.C., (15 de noviembre de 2016) “La matriz

digital de la escritura notarial: ¿sí o no?”. Notaría Llo-
pis. Sitio web: http://www.notariallopis.es/blog/i/1400/73/
la-matriz-digital-de-la-escritura-notarial-si-o-no-notartic.
Mann, F.A., The Legal Aspects of Money. 3rd Edi-
tion. Oxford University Press. Londres 1971.
Marino, B., (14 de febrero de 2016) “Unpacking
the term ‘Smart Contract. ’The word ‘contract’ and
Ethereum”. Medium. Sitio web: https://medium.com/@
ConsenSys/unpacking-the-term-smart-contract-e63238f7db65.
Martínez Nadal, A., La ley de firma electrónica,
2ª edición actualizada. Civitas. Madrid. 2001.
Mattheu, H., (30 de noviembre de 2015) Intel®
SGX for Dummies, Intel® SGX Design Objectives.
Sitio web: https://software.intel.com/en-us/blogs/2013/09/26/
protecting-application-secrets-with-intel-sgx.
Melich Orsini, J., “La causa en la teoría
del contrato”. Anuario de derecho civil. Vol. 37,
nº 1, 1984, págs. 3-62. Sitio web: https://www.
boe.es/publicaciones/anuarios_derecho/abrir_pdf.
php?id=ANU-C-1984-10000300062_ANUARIO_DE_
DERECHO_CIVIL_La_causa_en_la_teor%EDa_del_
contrato_y_sus_diversas_funciones.
Morell Ramos, J., (21 de Septiembre de
2016) “Cómo crear un smart contract con térmi-
nos y condiciones”. Legaltech, términos y condicio-
nes. Sitio web: https://terminosycondiciones.es/2016/09/21/
como-crear-smart-contract-mediante-terminos-condiciones/.
158
Smart Contracts
Nakamoto, S., (31 de octubre de 2008) “Bitcoin:

A Peer-to-Peer Electronic Cash System. (Bitcoin
Whitepaper)”. Bitcoin.com.
Sitio web: https://bitcoin.org/bitcoin.pdf.
Norton rose fullbright, Llp., (s.f.) “Can smart
contracts be legally binding contracts?”. Norton Rose
Fullbright Sitio web: http://www.nortonrosefulbright.com/
files/norton-rose-fulbright--r3-smart-contracts-white-paper-
key-findings-nov-2016-144554.pdf.
Norton rose partner, Sean Murphy, on Bloc-
kchain and Smart Contracts (28 de octubre de 2016)
“Artificial Lawyer”. Sitio web: https://www.artificia-
llawyer.com/2016/10/28/norton-rose-partner-sean-murphy-on-
blockchain-and-smart-contracts/.
Nussbaum, A., Teoría general del dinero. Tra-
ducción de Luis Sancho Seral. Madrid. Revista de
Derecho Privado. 1929. Pág. 32
Nussbaum, A., Money in the Law. National and
International Foundation Press, Brooklyn, 1950.
O’callagham Muñoz, X., Compendio de Dere-
cho Civil tomo II: Derecho de obligaciones. Madrid.
DIJUSA. 2009
O’callagham Muñoz, X., Cumplimiento e
incumplimiento del contrato. Madrid. Ramón Areces.
2012.
Op_return (7 de mayo de 2017) Bitcoin.wiki.
Sitio web: https://en.bitcoin.it/wiki/OP_RETURN.
Oraclize Ltd., (s.f) Oraclize.
Sitio web: http://www.oraclize.it/.
159
Carlos Tur Faúndez
Oraclize ltd., (s.f.) Proof of Identity. Sitio web:

http://dapps.oraclize.it/proof-of-identity/.
Pardo Gato, J.R., “Momento y lugar de per-
fección de los contratos electrónicos: elementos
jurídicos de conflicto en el derecho civil del nuevo
milenio”. UNED. Boletín de la Facultad de Derecho,
núm. 25. 2004. Sitio web: http://e-spacio.uned.es/fez/
eserv/bibliuned:BFD-2004-25-3010/PDF.
Pendón Meléndez, M.A., La perfección del con-
trato en Derecho Privado (Reflexiones sobre su régimen
legal a la luz de las nuevas formas de distribución y
contratación) TIRANT LO BLANCH, Valencia, 2009,
págs. 275 a 388.
Pérez Burgos, R., (4 de mayo de 2016) “DNI
electrónico y autenticación en la web”. Blog: Pen-
sando bajo la lluvia. Sitio web: https://rodrigopb.wordpress.
com/2016/05/04/dni-electronico-y-autenticacion-en-la-web/.
Prenafeta Rodríguez, J., (15 de septiembre de
2016) “Smart contracts: aproximación al concepto y
problemática legal básica”. Diario la Ley. Sitio web:
http://diariolaley.laley.es/Content/Documento.aspx?params=
H4sIAAAAAAAEAMtMSbF1CTEAAiNjM0sjQ7Wy1KLizPw
8WyMDQzMDC2OwQGZapUt-ckhlQaptWmJOcapack5qYp
FLYkmqc2JOal5KYpFtSFFpKgAq0AikTAAAAA==WKE.
Puyol, J., (3 de abril de 2016), “¿Qué
son los “smart contracts” o contratos digita-
les?”. Confilegal. Sitio web: https://confilegal.
com/20160403-los-smart-contrats-contratos-digitales/.
Ramos Medina, I., (17 de diciembre de
2016) “Smart contracts. Pinceladas jurídicas”.
160
Smart Contracts
Notariabierta.es. Sitio web: https://www.notariabierta.es/

smart-contracts-pinceladas-juridicas/.
Randolph, K., (13 de agosto de 2017, última
revisión) “Ethereum Whitepaper. A Next-Genera-
tion Smart Contract and Decentralized Application
Platform”. Github.com. Sitio web:
https://github.com/ethereum/wiki/wiki/White-Paper.
Raspberry PI Foundation, (2017) Raspberry
PI. Sitio web: https://www.raspberrypi.org/.
Rizzo, P., (24 de julio de 2017) “Delaware
Governor Signs Blockchain Bill Into Law”.
Coindesk. Sitio web: https://www.coindesk.com/
delaware-governor-signs-blockchain-legislation-law/.
Ros Cerezo, R. y Cendoya Méndez de Vigo,
M., Derecho de Internet. Contratación Electrónica y
Firma Digital. Editorial Aranzadi, 2000
Rosales de Salamanca Rodríguez, F., (26
de abril de 2016) “Notarizar con Blockchain”.
Sitio web: https://www.notariofranciscorosales.com/
notarizar-con-blockchain/.
Rosales de Salamanca Rodríguez, F., (26
de Junio de 2017) “Blockchain o Pacochain”.
Sitio web: https://www.notariofranciscorosales.com/
blockchain-o-pacochain/.
Ryan, D., (23 de agosto de 2017) “Cal-
culating Costs in Ethereum Contracts”. Hac-
kernoon.com. Sitio web: https://hackernoon.com/
ether-purchase-power-df40a38c5a2f.
Sebastián Cermeño, J., (27 de octubre de 2015)
“Smart Contracts: ¿lo último en automatización
161
Carlos Tur Faúndez
de la confianza? Situación económica digital

2015”. Revista Situación. BBVA Research. Sitio web:
https://www.bbvaresearch.com/wp-content/uploads/2015/10/
Situacion_Ec_Digital_Oct15_Cap1.pdf.
Serrano Segarra, M., “La formación del
contrato electrónico”. Revista de la facultad de Ciencias
Sociales y Jurídicas de Elche. Volumen I. Núm. 1. Julio
de 2006. Págs. 302 a 315.
Sitio web: https://revistasocialesyjuridicas.files.wordpress.
com/2010/09/01-tl-04.pdf.
Slock.it, (s.f.) Slock.it. Sitio web: https://slock.it/
Slock.it, (s.f.) Slock.it. Repositorio GitHub.
Sitio web: https://github.com/slockit/.
SmartContract.com (s.f.)
Sitio web: https://smartcontract.com/.
Solana Berengué, A., (s.f) “Autenticación web
con DNIe”. AUIes.
Sitio web: http://aui.es/IMG/pdf_ponencia2328.pdf.
Stark, J., (4 de junio de 2016) “Making Sense of
Blockchain Smart Contracts”. Coindesk. Sitio web:
https://www.coindesk.com/making-sense-smart-contracts/.
Szabo, N., (1 de septiembre de 1997) “Forma-
lizing and Securing Relationships on Public Net-
works”. First Monday. Sitio web:
http://ojphi.org/ojs/index.php/fm/article/view/548/469#*.
Szabo, N., (14 de noviembre de 2015) “History
of the Blockchain”. Devcon1 - Ethereum Developer
Conference - DAY5. Sitio web: https://www.youtube.com/
watch?v=YpSeOU1VVj4.
162
Smart Contracts
Tinianov, A. & Long, C., (16 de marzo de

20147] Delaware Blockchain Initiative: Transforming
the Foundational Infrastructure of Corporate Finance.
Sitio web: https://corpgov.law.harvard.edu/2017/03/16/
delaware-blockchain-initiative-transforming-the-
foundational-infrastructure-of-corporate-finance/.
Town Crier, (s.f.)
Sitio web: http://www.town-crier.org/.
Town Crier, (s.f). Repositorio Github bl4ck5un/
Town-Crier.
Sitio web: https://github.com/bl4ck5un/Town-Crier.
Vázquez Iruzubieta, C., Código civil Comentado.
[Recurso electrónico]. Editorial VLex. Barcelona.
2016.
Villarino Marzo, J., (16 de marzo de 2016)
“La regulación del crowfunding y el modelo de
negocio digital”. Abogacía Española.
Sitio web: http://www.abogacia.es/2016/03/16/la-regulacion-
del-crowdfunding-y-el-modelo-de-negocio-digital/.
Wild, J., (2 de noviembre de 2016) “Central
banks explore blockchain to create digital curren-
cies”. Finantial Times. Sitio web: https://www.ft.com/
content/f15d3ab6-750d-11e6-bf48-b372cdb1043a.
Xiao, G., (s.f.). wims.unice.fr (Université Nice
Sophia Antipolis) Sitio web: http://wims.unice.fr/wims/
es_tool~number~baseconv.es.html.
Yeow, A., (s.f.) bitnodes.
Sitio web: https://bitnodes.21.co/.
163
ANEXO 1
UN CONTRATO LEGAL INTELIGENTE
PARA JURISTAS INTERESADOS EN LA
PROGRAMACIÓN INFORMÁTICA
1. INTRODUCCIÓN
El objetivo que perseguimos con los contenidos

que a continuación se exponen es esclarecer desde
una perspectiva práctica orientada a los juristas en
qué consiste, realmente, un smart contract y dónde
debe situarse en el sistema informático y físico que
constituye la forma del contrato legal inteligente. Tal
y como se ha expuesto en la sección II) del presente
trabajo, cabe diferenciar los smart contracts jurídica-
mente relevantes de aquellos otros que no lo son,
contándose entre los primeros, exclusivamente, los
que han sido creados con la finalidad de produ-
165
Carlos Tur Faúndez
cir efectos jurídicos cuando se den las condiciones

requeridas para ello.
En las páginas 178 y ss. puede leerse el íntegro
código escrito en Solidity del programa arrenda-
mientoVehiculo. Se trata de un smart contract jurí-
dicamente relevante, puesto que ha sido creado:
a. Para integrarse en la cadena de bloques de
Ethereum;
b. Para residir en el back end de un conjunto
de aplicaciones, que determinarán la forma
final a través de la cual se configurará el con-
trato legal inteligente;
c. Para llevar a efecto, la ejecución automática
de algunas de las contraprestaciones del con-
trato legal inteligente.
2. LA ESTRUCTURA
Como puede observarse, el smart contract arren-

damientoVehiculo no es más que una secuencia de
instrucciones escritas en Solidity, por lo que, des-
provisto de otros elementos, carece de eficacia
práctica alguna.
Sin embargo, la idea que proponemos consiste
en que, una vez anclado (deployed) en la cadena
de bloques Ethereum, constituya la “cimentación
básica” de una sistema informático completo,
creado con la finalidad de dar forma a un contrato
legal inteligente para el arrendamiento de vehícu-
166
Smart Contracts
los eléctricos urbanos. Dichos vehículos se halla-

rán estacionados en aparcamientos situados en las
zonas más relevantes de la ciudad, que incluirían
estaciones de carga y postes fijos para el anclado y
bloqueo electrónico de los mismos.
Los vehículos, deberán estar provistos de:
a. Un dispositivo de geolocalización GPS;
b. Un dispositivo de inmovilización electrónica
(bloqueo de motor);
c. Un dispositivo de apertura/cierre, bloqueo/
desbloqueo y encendido/apagado mediante
claves criptográficas convertibles a código
QR210 y un scanner que permitiera la lectura
de tales códigos;
d. Un navegador que, asimismo, podrá comu-
nicar mensajes de voz al usuario.
210
Puede observarse la simple generación de un código QR,
en el Sitio web: http://es.qr-code-generator.com/. Si se verifica mediante
un lector, se verá que el código QR para el texto CONTRATOS
LEGALES INTELIGENTES es:
167
Carlos Tur Faúndez
e. Una antena wifi conectada a los sistemas

electrónicos que permite la intercomunica-
ción con las restantes aplicaciones del con-
trato legal inteligente.
Todos los dispositivos deberán estar conecta-
dos a una placa electrónica de control (Arduino211,
Raspberry Pi212, Nanode213, etc.) imprescindible para la
intercomunicación con el servidor web.
La estación de carga (que deberá contar con
una placa electrónica de control similar a las ante-
riormente mencionadas) deberá estar conectada a
la red y dispondrá de un sistema de anclado elec-
trónico del vehículo y de un lector de códigos QR.
El front end214 del contrato legal inteligente debe-
ría estar constituido por:
a. Una página web con características similares
a las propuestas en la sección II del presente
trabajo, y en la que previamente se prestará
el consentimiento a las condiciones gene-
rales del arriendo sin perjuicio de que pos-
teriormente se haga uso o no del servicio.
Dicha Web estará desarrollada en HTML5 y
JavaScript. Para poder interaccionar con el
smart contract directamente desde la interfaz
211
Vid. Sitio web: https://www.arduino.cc/.
212
Vid. Sitio web: https://www.raspberrypi.org/.
213
Vid. Sitio web: http://www.nanode.eu/.
214
Vid. Sección II, apartado 1.2.
168
Smart Contracts
se hará uso de la librería Web 3 JavaScript app

API215.
b. Una aplicación (Android o IOS) que necesa-
riamente deberá ser descargada en el termi-
nal móvil del usuario (arrendatario) y que
permitirá el arriendo efectivo del vehículo
con el prepago por el periodo de tiempo que
corresponda mediante transferencia desde
su cuenta en Ether a la del smart contract.
Al tiempo del pago, el usuario prestará su
consentimiento sobre la causa y el objeto del
contrato y, en especial, sobre la forma en la
que se va a llevar a efecto la ejecución de las
prestaciones pactadas. Una vez transferidos
los fondos, la aplicación proporcionará un
código QR para el desbloqueo del anclaje y
la apertura y encendido del vehículo.
El smart contract ha sido desarrollado para que
el vehículo pueda ser arrendado por minutos y,
como se ha indicado, para que el prepago se lleve
a efecto por adelantado mediante la terminal móvil
del usuario. Tan pronto como el smart contract sub-
yacente reciba un mensaje exterior indicativo de
que un usuario (que previamente había aceptado
las condiciones generales a través de la web) ha
formulado un prepago a través de la aplicación
215
Vid. Sitio web: https://github.com/ethereum/wiki/wiki/
169
Carlos Tur Faúndez
móvil, se desencadenará la ejecución automática

del contrato.
Podría establecerse un sistema de pago simultá-
neo, es decir, que el smart contract cobrara de forma
directa y sin el permiso del arrendatario, efectuando
cargos sucesivos sobre su cuenta (address), pero ello
requeriría que dicha cuenta estuviera vinculada a
otro smart contract debidamente programado a tal
efecto. No es el caso de arrendamientoVehículo.
Para el pleno y eficaz funcionamiento del con-
trato legal inteligente, el back end216 de su estructura
informática debería disponer al menos de:
a. Nuestro smart contract arrendamientoVehi-
culo debidamente almacenado en la cadena
de bloques y por tanto completamente
operativo.
b. De un servidor web217 en el que se haría uso de
Node.Js218 (interprete de JavaScript) para pro-
gramar los mecanismos de intercomunica-
ción de eventos219 entre las placas inteligentes
de los vehículos, las aplicaciones residentes
en el front end y el propio smart contract.
216
Vid. Sección II, apartado 2.1.
217
Vid. Sitio web: https://es.wikipedia.org/wiki/Servidor_web.
218
Vid. Sitio web: https://es.wikipedia.org/wiki/Node.js
219
¿Ha consentido? (SÍ/NO) ¿Ha pagado? (SÍ/NO) Envío de
código QR con claves criptográficas a la terminal móvil del usua-
rio y a la placa del poste de anclado del vehículo. ¿Ha abierto?
(SÍ/NO) ¿Ha desbloqueado el motor? (SI/NO) ¿Está en marcha?
(SÍ/NO) ¿Cuál es su posición GPS? etc.
170
Smart Contracts
Evidentemente, el desarrollo íntegro del soft-

ware en todas las capas del sistema informático
resulta extremadamente complejo. No obstante,
podemos acercarnos al concepto si damos lectura
al software que los autores de PROJECT OAKEN
han publicado en el repositorio GitHub220 y en el
que se han codificado todas las aplicaciones nece-
sarias para construir un smart contract operativo en
la cadena de bloques Ethereum, que puede inter-
comunicarse con una placa Raspberry Pi, situada a
distancia y dotada de un simple led.
Las aplicaciones desarrolladas por PROJECT
OAKEN permiten que el smart contract subyacente
pueda ordenar el encendido (parpadeo) del led,
tener constancia del evento y, en su caso, ordenar
el apagado.
Podríamos pensar que el mecanismo es poco
útil, si bien, a poco que profundicemos en la cues-
tión, seremos conscientes de que si somos capaces
de construir un interruptor controlable remota-
mente, podremos controlar, prácticamente, cual-
quier elemento situado a distancia, mediante men-
sajes que ordenen el:
— Bloqueo y desbloqueo de cerraduras;
— Bloqueo y desbloqueo automático de motor;
— Encendido y apagado de motor, etc..
220
Vid. Sitio web: https://github.com/Oaken-Innovations/IoT-Blink.
171
Carlos Tur Faúndez
3. PROCEDIMIENTO PARA LA FORMACIÓN Y

EJECUCIÓN DEL CONTRATO LEGAL INTELI-
GENTE
1. La entidad propietaria de los vehículos eléc-

tricos deberá ser, lógicamente, la generadora
del front end y del back end que integran la
estructura formal del contrato legal inteligente.
Sin embargo, ello no obsta el necesario cum-
plimiento de todas las exigencias previstas
en la sección II del presente trabajo, máxime
cuando el contrato de arrendamiento de
vehículo se celebrará siempre con concu-
rrencia de consumidores y usuarios y, en
consecuencia, requerirá la máxima claridad
y transparencia en la información que se
pondrá a disposición de quien pretenda con-
tratar y la absoluta imparcialidad del smart
contract subyacente.
2. Para poder acceder al servicio de arrenda-
miento de vehículos eléctricos, el usuario
deberá, con carácter previo, de haber entrado
en la web habilitada a tal efecto y aceptado
las condiciones del contrato221 con un cono-
cimiento exhaustivo del producto que se
contrata y de la forma en la que se llevará a
efecto la ejecución de las contraprestaciones.
221
Vid. Sección II, apartado 4.5.3.
172
Smart Contracts
3. La aceptación de las condiciones antes

expuestas no supondrá el consentimiento
inmediato prestado para el arrendamiento
de un vehículo. Para ello será preciso que el
usuario se descargue en su terminal móvil
una aplicación que podrá ser utilizada
cuando éste se sitúe junto a una estación de
carga con vehículos disponibles222.
Tras acceder con sus claves privadas a la apli-
cación, se iniciará la siguiente secuencia:
a. Si existe un vehículo disponible (evento del
que tendrá constancia el smart contract), apa-
recerá en la pantalla de la terminal el botón
“alquilar”.
b. Si el usuario pulsa dicho botón, se abrirá un
cuadro de diálogo con el texto siguiente:
(consentimiento sobre la ejecución)
“El vehículo con ID …………, y matrícula ….…está dis-
ponible para su uso. En el momento en el que Vd. transfiera,
desde su cuenta, una cantidad suficiente, estará consin-
tiendo y aceptando, expresamente, la automática ejecución
del contrato de arrendamiento del vehículo (ID…….), en
los términos que en su día ya aceptó y comprendió por
contrato de fecha….… ¿Desea Vd. continuar?
c. Sólo en caso de que se haya oprimido el

botón SÍ, aparecerá un nuevo cuadro de diá-
logo con el siguiente texto:
Cada vehículo, dispondrá de su propio identificador ID

222
y su propio smart contract subyacente.
173
Carlos Tur Faúndez
“El precio del alquiler es de 1 Finney223 por minuto,

¿Cuánto tiempo desea alquilar el vehículo?
d. Ante la respuesta, se formulará el siguiente

cuadro de diálogo:
¿Desea Vd. transferir …… Finney a la cuenta del smart
contract e iniciar el uso de su vehículo?
e. Sólo en caso de que se haya oprimido el botón

SÍ, el smart contract remitirá a los dispositivos
electrónicos del poste de anclaje y del vehí-
culo, las claves de apertura y desbloqueo de
motor. Al mismo tiempo ordenará la remis-
ión de los códigos QR, al dispositivo móvil e
indicará, al usuario, como debe hacer uso de
los mismos. Mediante el posicionamiento de
la pantalla del móvil sobre el scanner de la
torre de anclaje se desbloqueará el candado
de la misma y se abrirá la puerta del vehículo.
En el interior, un nuevo scanner, permitirá el
desbloqueo del motor y la puesta en marcha
del mismo. Se inicia la conducción.
f. Cuando resten menos de siete minutos
para la conclusión del periodo contratado,
el usuario debe recibir un mensaje de voz,
a través del navegador del vehículo, que
así se lo indique, requiriéndole para que lo
devuelva en la estación más cercana o, en su
Unidad fraccionaria del Ether. 1 Eth = 276 € =1.000. Fin-

223
ney; 1 Finney = 0,27 € (A día de 6 de septiembre de 2017)
174
Smart Contracts
caso, se detenga y pague un nuevo periodo

de uso. En ese preciso instante, la aplicación
abrirá un nuevo cuadro de diálogo:
“¿Desea alquilar el vehículo durante más tiempo?
Simultáneamente se mostrarán dos botones,

SÍ y NO.
g. En caso de respuesta positiva, se reiterará
la secuencia expuesta en el apartado b, per-
maneciendo el arrendatario en el uso del
vehículo hasta que finalice el nuevo periodo
contratado.
h. En el supuesto de que el usuario incum-
pliera su obligación de pago y no detuviera
el vehículo, se podría programar la remi-
sión de diversos mensajes de voz a través
del navegador exigiendo el estacionamiento
inmediato. De no obrar el usuario en tal sen-
tido, se comunicaría a la Autoridad Compe-
tente la posición GPS del vehículo, su ID y
su matrícula. En caso de ser necesario, se
transferirían telemáticamente las claves de
apertura y bloqueo a dicha autoridad a fin
de que llevase a término la inmovilización
del vehículo de forma segura, y su devolu-
ción a la estación de carga224.
Sería recomendable, probablemente, obligar al usuario a

224
consignar, en la cuenta del smart contract, un depósito suficiente

para asegurar la devolución del vehículo en el plazo, forma y condi-
ciones adecuadas.
175
Carlos Tur Faúndez
4. EL SMART CONTRACT ARRENDAMIENTO-

VEHICULO225
Las expresiones grafiadas en negrita identifican

palabras reservadas en el lenguaje de programación
Solídity y, en consecuencia, no pueden ser
utilizadas para propósitos diferentes a los
previstos por los creadores de dicho lenguaje.
Las expresiones grafiadas en cursiva corresponden
a denominaciones atribuidas por el desarrollador
a determinados elementos del programa, por
lo que no pueden utilizarse para elementos
diferentes, puesto que, el smart contract, no
sería capaz de diferenciarlos.
1. pragma solidity^0.4.0
2.
3. contract arrendamientoVehiculo {
4.
5. address public propietario;
6. address public arrendatario;
7. uint public plazo;
8. uint public precioUnitario;
9. uint public fechaCreacionSmartContract;
10. string public IDvehiculo;
11. string public matricula;
12.
13. enum Estado {Aceptado, Disponible}
14. Estado public estado;
15.
El programa “arrendamientoVehículo” se expone aquí

225
como ejemplo con fines meramente didácticos. El autor de la

presente obra declina cualquier responsabilidad en cuanto a la
posible falta de funcionalidad del mismo o los errores que, en
su caso, pudieran contener o generar.
176
Smart Contracts
16. function arrendamientoVehiculo(uint _

precioUnitario, uint _IDvehiculo, uint _
matricula) {
17. propietario = msg.sender;
18. arrendatario = 0x0;
19. plazo = now;
20. fechaCreacionSmartContract = now;
21. precioUnitario = _precioUnitario;
22. IDvehiculo =_IDvehículo;
23. matricula =_matricula
24.
25. }
26.
27. modifier soloPropietario() {
28. if (msg.sender != propietario) throw;
29. _;
30. }
31.
32. modifier soloArrendatario() {
33. if (msg.sender != arrendatario) throw;
34. _;
35. }
36.
37. modifier queEstado(Estado _estado) {
38. if (estado != _estado) throw;
39. _;
40. }
41.
42. function dimeID() constant returns (string) {
43. return IDvehiculo;
44. }
45.
46. function dimeMatricula() constant returns
(string) {
47. return matricula;
48. }
49.
177
Carlos Tur Faúndez
50. function dimeArrendatario() constant returns

(address) {
51. return arrendatario;
52. }
53.
54. function dimePrecioUnitario () constant returns
(uint) {
55. return precioUnitario;
56. }
57.
58. function dimeFechaCreacionSmartContract()
constant returns (uint) {
59. return fechaCreacionSmartContract;
60. }
61.
62. function dimeCuentaSmartContract() constant
returns (address) {
63. return this;
64. }
65.
66. function dimeEstado() constant returns (Estado)
{
67. return estado;
68. }
69.
70. event contratoAceptado();
71. event vehiculoDisponible();
72.
73. function alquilar() soloArrendatario payable
returns(bool)
74. queEstado(Estado.Aceptado)
75. require(msg.sender != propietario)
76. {
77. if(arrendatario != 0x0) return false;
78. else{
79. if( (msg.value/1 Finney) / precioUnitario
< 1) return false;
80. else{
178
Smart Contracts
81. plazo = now + (1 minutes * (msg.value/

precioUnitario));
82. fechaCreacionContrato= now;
83. arrendatario = msg.sender;
84. Estado = Estado.Aceptado
85. }
86. }
87. }
88.
89. function enUso(bool _quiereAlquilar) payable
returns(bool){
90. if( plazo > now ) return true;
91. else{
92. arrendatario = 0x0;
93. Estado = Estado.Disponible;
94. vehiculoDisponible();
95. if( quiereAlquilar == true) alquilar();
96. }
97. }
98.
99. function cobrar() soloPropietario {
100. propietario.send(this.balance) ;
101. }
102.
103. function destruir ()
104. q ueEstado(Estado.Disponible) { if (msg.
sender==propietario) selfdestruct(propietario);
105. }
106.
107. }
179
Carlos Tur Faúndez
5. DESCRIPCIÓN DETALLADA DE CADA UNA

DE LAS LÍNEAS DE CÓDIGO
Línea 1: Todo programa, en Solidity, debe ini-

ciarse indicando la versión del lenguaje utilizada.
En este caso: pragma solidity^0.4.13
Línea 2: Dejamos un espacio, simplemente, para
mayor claridad, o para separar elementos diversos
de un programa. En este caso por ambos motivos.
Línea 3: Utilizamos la palabra reservada, con-
tract, para referirnos al nombre del programa. En
este caso, arrendamientoVehiculo, sin separaciones
y sin acentos pues, Solidity, como la mayoría de
los lenguajes de programación, no los reconoce. A
continuación se sitúa la llave de apertura “{“ que
tiene gran importancia sintáctica en programación
y que, en este caso, significa que todo lo que se
comprende, a continuación de la misma y hasta la
llave de cierre “}” situada en la última línea, forma
parte de arrendamientoVehiculo.
Línea 4: (Espacio).
Línea 5: Definimos la primera variable. Una
variable es un “espacio en blanco” en la memoria
del programa. Si añadimos la palabra reservada
public, estamos haciendo “visible” la variable, en la
interfaz de la aplicación (si no lo hacemos, no será
visible) En este caso, este “espacio vacío” deberá
completarse con una address, palabra reservada,
exclusivamente, a cuentas en las que se deposita
180
Smart Contracts
Ether (pueden ser contract accounts o EOA226). La

variable address propietario, corresponderá a la
cuenta del propietario del vehículo y el concreto
número de cuenta se definirá más adelante.
Línea 6: Definimos la segunda variable y la
denominamos arrendatario. El sistema es el mismo
que el utilizado en la línea 5. En este caso, el “espa-
cio en blanco” se rellenará en su momento con el
número de la cuenta (address) del arrendatario.
Línea 7: Nueva variable. En este caso su nom-
bre es plazo, que será determinado más adelante
en función de la cantidad que haya satisfecho el
arrendatario.
Línea 8: Nueva variable, precioUnitario, que
será el precio en Ether o en unidad fraccionaria,
por cada media hora de uso. Sólo podrá ser defi-
nido por el propietario.
Línea 9: Nueva variable. Se corresponde con la
fecha de creación del contrato. Como se verá más
adelante el valor de la variable se determinará
automáticamente, por el programa, en el momento
en el que el arrendatario pague la cantidad corres-
pondiente y corresponderá al día, hora, minutos y
segundos en los que la transacción sea introducida
en un bloque válido de la cadena de bloques.
226
Vid. Sección I de la presente obra.
181
Carlos Tur Faúndez
Líneas 10 y 11: Nueva variables, las denomi-

namos IDvehiculo y matricula. Gracias a las pla-
cas electrónicas de los vehículos, puede conocerse
cuales de ellos están disponibles en la estación en
la que se encuentra el usuario. A través del ser-
vidor ubicado en el back end, se asignará al smart
contract el ID (un número visible en la carrocería)
y la matrícula del vehículo que corresponda. La
palabra reservada string se utiliza para designar
texto, números o ambas cosas. Los números no
son interpretados como tales por el programa, sino
como simples caracteres, por lo que no permiten
operaciones matemáticas.
Línea 13: Creación de una nueva variable. La
palabra reservada enum se utiliza para crear varia-
bles, que no están predeterminadas en Solidity,
(como si lo están address, uint, string, etc.). En este
caso, creamos la variable, Estado y, entre llaves, defi-
nimos dos posibilidades: Aceptado y Disponible.
La utilización de dichas “variables de estado”
es imprescindible, para definir el lapso temporal
en el que deben ejecutarse las funciones. De no
hacerse uso de las mismas, el arrendatario, podría
pagar su prestación pecuniaria, antes de que el
contrato estuviera vigente y, el propietario, podría
destruir el contrato, antes de que, el arrendatario,
hubiese concluido su periodo de uso.
182
Smart Contracts
Línea 14: Ahora que ya hemos creado un nuevo

tipo de variable, es preceptivo que la nominemos,
como hemos hecho en los casos anteriores. No
podemos denominarla Estado, puesto que, el pro-
grama, la interpreta, ya, como una palabra reser-
vada. Le conferimos el nombre de estado, para evi-
tar confusiones.
Línea 16: En esta línea, y en las cinco siguien-
tes, vamos a crear la primera función para lo que
hacemos uso de la palabra reservada function.
Una función, es una secuencia de código
que sirve para desarrollar tareas específicas. En
este caso, como vemos, la función tiene idén-
tico nombre al del propio smart contract, esto es
arrendamientoVehiculo.
A esta función se le conoce como método cons-
tructor y, necesariamente, debe recibir el mismo
nombre que el programa. Cumple una sola fina-
lidad, atribuir valores iniciales a cada una de las
variables.
A continuación del nombre de la función
observamos que se indica (uint _precioUnitario,
uint _IDvehiculo, string matricula) los valores entre
paréntesis, que se introducen en las funciones, sir-
ven para determinar parámetros. Lo que nos indica
el contenido del paréntesis es que el creador del
smart contract (que será el propietario de los vehí-
culos) deberá, en el momento de su anclado a la
183
Carlos Tur Faúndez
cadena de bloques, facilitar tres datos. En este caso

se tratará de dos números enteros (sin signo) uint
y una cadena alfanumérica string.
Los parámetros, sirven para proporcionar al
smart contract el valor correspondiente a una varia-
ble se identifican del mismo modo que ésta, pero
con un guion bajo delante _precioUnitario, IDve-
hiculo y _matricula con el fin de que el programa
no los confunda. A continuación, se abre una llave
“{“ que significa que todo lo que se incluya entre
la misma y la llave de cierre situada en la línea 22,
forma parte de la función arrendamientoVehiculo.
Línea 17: (Sigue función método constructor). La
variable propietario es una address, es decir, una
cuenta, en este caso, EOA, perteneciente al propie-
tario y creador del smart contract. Le atribuimos,
por tanto el valor msg.sender que en Solidity hace
referencia a la cuenta que, en este momento, está
enviando un mensaje o transacción, es decir, la del
propietario que ha anclado el smart contract a la
cadena de bloques.
Línea 18: (Sigue función método constructor).
Definimos el valor de la variable arrendatario en
0x0.
En otros lenguajes de programación, existe el
valor nulo (null) No es el caso de Solidity, por lo
que no podemos atribuir null como valor inicial.
Por el momento, conferimos, a la variable, el valor
0x0 (convencionalismo para 0, nada o ninguno)
184
Smart Contracts
Será más adelante (en el momento en el que,

el arrendatario, acepte el contrato y pague el pre-
cio establecido) cuando, el smart contract, interpre-
tará que, la cuenta EOA, que transfiere los fondos,
corresponde al arrendatario y le asignará dicha
address a la variable.
Línea 19 y 20: (Sigue función método cons-
tructor). Definimos las variables plazo y fecha-
CreacionSmartContract con el valor now, que el
programa interpreta, como momento actual de la
generación del bloque. Al igual que en el caso ante-
rior, lo cierto es que, por el momento, definimos
una fecha sin relevancia, puesto que estos valores,
como se verá, se redefinirán más adelante, en fun-
ción del momento en el que se comunique al pro-
grama la aceptación del contrato y por ende del
smart contract así como el importe satisfecho como
precio del arriendo.
Líneas 21, 22 y 23: (Sigue función método cons-
tructor). Al asignar, a la variable, precioUnitario,
el parámetro, _precioUnitario (no deben confun-
dirse) estamos indicando, al programa, que dicho
“espacio en blanco,” en la memoria del ordenador,
deberá ser “rellenado” con el valor que el creador
del smart contract (propietario) le indique a este
último, en el momento de su anclado a la cadena
185
Carlos Tur Faúndez
de bloques227. En las líneas 22 y 23 procedemos de

igual forma con IDvehiculo y matricula.
Línea 25: (Sigue función método constructor). Se
concluye la función y todo su contenido con la llave
de cierre “}”.
Líneas 27 a 40: (permisos/modifiers). En Solidity,
como en la mayoría de los lenguajes de programa-
ción, no es deseable que todas las funciones (que
como ya se ha expuesto sirven para desarrollar
determinadas tareas) estén a disposición de cua-
lesquiera usuarios del smart contract. Para conferir
permisos, a una u otra parte, se desarrollan, funcio-
nes especiales, denominadas modifiers. Como vere-
mos más adelante, al introducir un modifier en otra
función, sólo el titular de una cuenta autorizada,
podrá ser parte activa en aquella función228.
Para crear cada una de estas funciones, comen-
zamos por utilizar la palabra reservada modifier y,
227
De hecho, el programa no podrá operar en la cadena
de bloques hasta que el creador del mismo no facilite ese dato
concreto.
228
Resulta fácilmente comprensible, para un jurista, que sólo
pueda alquilar quien, previamente, ha aceptado las condiciones
del contrato de arrendamiento, del mismo modo que sólo puede
cobrar (salvo que delegue el cobro en un tercero) quien ostenta
la condición de propietario (o arrendador, términos que frecuen-
temente coinciden, como en este caso).
186
Smart Contracts
a continuación, le asignamos un nombre. En nues-

tro smart contract hemos definido los nombres en
la línea 27, soloPropietario, y en la línea 32, soloA-
rrendatario. Posteriormente, debe escribirse un
paréntesis ( ), que, como en todas las funciones,
tiene como objetivo determinar los parámetros que
deben facilitarse al programa para tal función. Las
funciones referidas, no requieren ningún paráme-
tro, por lo que, el paréntesis, debe quedar vacío.
Tras la llave de apertura de la función “{“ ini-
ciamos una condición, con la palabra reservada, if
que, en Solidity, como en el resto de los lenguajes de
programación, significa Si (condicional). Abrimos
un nuevo paréntesis, en el que introducimos la con-
dición y, a continuación, añadimos la palabra reser-
vada, throw, que significa, literalmente ,“tirar”. En
la línea 28, podemos observar el contenido de la
misma:
if (msg.sender != propietario) throw
El signo != en Solidity, se utiliza para comparar

elementos y significa distinto de. En consecuen-
cia, si aceptamos que msg.sender se corresponde
con la dirección alfanumérica de una determinada
cuenta EOA en Ethereum, y que la variable propie-
tario corresponde con la dirección de la cuenta del
propietario, alcanzamos la conclusión de que la
condición que se está evaluando es:
187
Carlos Tur Faúndez
“Si la cuenta de quien es parte activa en la fun-

ción, no pertenece al propietario tirar”.
Es decir, si no se cumple dicha condición, la

función será obviada por el programa que trans-
mitirá un mensaje de error.
Tras el “;” podemos observar un guión bajo “_”
que parece insignificante, pero no lo es en absoluto.
Dicho signo confiere a la función la orden de con-
tinuar en caso contrario.
La traducción del texto de la línea a un lenguaje
comprensible, podría ser la siguiente:
“Si la cuenta de quien es parte activa en la fun-
ción, no pertenece al propietario la función debe
ignorarse (tirar) y, en caso contrario, la función debe
continuar”.
El modifier establecido en la línea 32 funciona,

exactamente, del mismo modo, si bien, en este
caso, el permiso será solo para el arrendatario. Sin
embargo, en el de la línea 37, observamos algunas
diferencias, dado que la condición que se evalúa
no es la coincidencia entre la cuenta activa con la
de un determinado titular, sino entre un paráme-
tro de la función “_estado” y la variable estado de
la misma. En consecuencia, determinadas funcio-
nes para activarse requerirán que el contrato esté
Creado_Vigente, o que el vehículo esté Disponible.
188
Smart Contracts
Líneas 42 a 68 (Getters/informadores). Como

sabemos, el término anglosajón get se traduce al
español como “obtener”. Pues bien, para conferir
una mayor funcionalidad, podemos definir una
serie de funciones especiales denominadas get-
ters229 que, sin provocar modificación alguna, nos
informan a través de la interfaz de usuario de Ethe-
reum del valor de una u otra variable. Para ello
utilizamos la palabra reservada function, seguida
del nombre asignado (v.g. dimePrecioUnitario)
A continuación, deben incorporarse los térmi-
nos constant returns, cuya traducción, a un lenguaje
comprensible, podría ser “devuelve de forma cons-
tante”, es decir que, el valor del que se nos va a
informar en la interfaz, será el asignado para la
variable de que se trate, sin que quepa modifica-
ción posible sobre éste por el titular de la cuenta
activa (msg.sender).
Posteriormente, entre paréntesis, debe expre-
sarse el tipo de variable que será visible en la inter-
faz (address, string, uint…) para exponer, luego,
como en todas las funciones, entre llaves { } la tarea
a realizar por la función, en este caso será mostrar
(retornar/ return) el valor de una variable.
Algunas diferencias presenta, el getter de las
línea 62 y 63, en el que, como puede advertirse, apa-
recen las palabras reservadas return this. Obsérvese
Utilizando el castellano de forma correcta deberíamos

229
hablar de informadores.
189
Carlos Tur Faúndez
que la información que se solicita es la dirección

de la cuenta del propio smart contract {dimeCuen-
taSmartContract ( )} Pues bien, en este supuesto,
al utilizar el vocablo this, cuya traducción literal al
castellano es “ésta” le estamos indicando al smart
contract que la dirección (address) de la cuenta que
queremos conocer es, precisamente, la suya.
Líneas 70 a 71: (Eventos). Los eventos, son seña-
les que facilitan la comunicación, toda vez que pue-
den ser leídos en la interfaz de usuario y, asimismo,
pueden ser “oídos” por aplicaciones externas.
En el caso que nos ocupa, resulta especialmente
relevante la posibilidad de que, el servidor, resi-
dente en el back end, se aperciba de la producción
de un determinado evento (event) y reaccione en
consecuencia, remitiendo una orden remota, al dis-
positivo electrónico del vehículo.
Así pues, en las líneas 70 y 71, hemos gene-
rado 2 eventos, que se corresponden con 2 de los
posibles estados del smart contract y, al tiempo, del
contrato legal inteligente de cuya estructura formal
es parte.
Dichos eventos, fueron definidos en la línea 13
{event contratoAceptado( ); event vehiculoDisponi-
ble( ) } y, como su propio nombre indica, nos infor-
man o bien, de que el contrato ha sido aceptado y
está vigente o bien, de que el último contrato, del
190
Smart Contracts
vehículo, ha finalizado y, en consecuencia, de la

disponibilidad del mismo.
Línea 73: (Pago, consentimiento y aceptación del
arrendatario sobre la ejecución del contrato). En esta
línea, vamos a crear una función, determinante en
el plano jurídico y a la que vamos a denominar
function alquilar( ). Como hemos expuesto en la
página 170 del presente anexo, en un determinado
momento, el usuario observaría en su terminal
móvil, un cuadro de diálogo con el siguiente tenor
literal:
“El vehículo con ID …………, y matrícula ……
está disponible para su uso. En el momento en el que
Vd. transfiera de su cuenta una cantidad suficiente, Vd.
estará consintiendo y aceptando, expresamente, la auto-
mática ejecución del contrato de arrendamiento del vehí-
culo (ID..), en los términos que en su día ya aceptó y com-
prendió por contrato de fecha…… ¿Desea Vd. continuar?
A su vez se le mostrarían tan solo dos botones

con dos posibles opciones SÍ o NO.
En el caso de que pulsara SÍ, aparecería un
nuevo cuadro de diálogo con el siguiente texto:
El precio del alquiler es de 1 Finney230 por minuto,
¿Cuánto tiempo desea alquilar el vehículo? Ante la res-
puesta, se formulará el siguiente cuadro de diálogo ¿Desea
Unidad fraccionaria del Ether. 1 Eth = 276 € =1.000. Fin-

230
ney; 1 Finney = 0,27 € (A 6 de septiembre de 2017)
191
Carlos Tur Faúndez
Vd. transferir …… Finney a la cuenta del smart contract

e iniciar el uso de su vehículo?
Una vez más, las opciones serán SÍ o NO.

En caso de pulsar la opción SÍ, se iniciaría la
transferencia de los fondos (Ether) desde la cuenta
(address) del usuario a la cuenta (address) del smart
contract.
Continuamos con la expresión function alquilar
( ) seguida de payable returns (bool).
Los operadores booleanos (bool) son, en infor-
mática, aquellos que pueden representar exclusiva-
mente dos valores (SÍ/NO, VERDADERO/FALSO,
etc.). Al utilizar el término payable, estamos indi-
cando, al smart contract que, para activar la función,
debe transferirse, necesariamente, una cantidad en
cuyo caso el programa interpretará que se devuelve
el valor true (verdadero)
Introducimos, como requerimiento de activa-
ción de la función, un modificador (modifier) del
que ya hablamos en la línea 37 y ss.
Así pues, function alquilar ( ) sólo podrá operar
en Estado.Disponible que, como se verá, es el estado
existente, por defecto, cuando el vehículo no está
alquilado.
Línea 75: (Continúa la función alquilar( )). Al
hacer uso de la expresión reservada require, seguido
de un paréntesis, le estamos indicando al programa
que lo que se comprende en el interior de éste, es
192
Smart Contracts
un requerimiento imprescindible para que actúe la

función. En este caso tal requerimiento es:
(msg.sender != propietario)
Para que la función se active, el programa nos

exige que la cuenta del titular del mensaje, perte-
nezca a una persona distinta al propietario. Ello es
absolutamente lógico, por cuanto, el propietario, ni
tiene intención de alquilar, ni necesita aceptar un
contrato que el mismo ha predispuesto.
Línea 76: (Continúa la función alquilar( )). Llave
de apertura de la función “{“ que implica que entre
la misma y la llave de cierre de la línea 87, se expon-
drán las operaciones que realizará la función.
Línea 77: (Continúa la función alquilar( )) la fun-
ción exige una condición para activarse que se halla
dentro del paréntesis y establece una consecuencia.
if(arrendatario != 0x0) return false;
En la línea 18 de nuestro smart contract, atribui-

mos a la cuenta (address) del arrendatario, el valor
0x0 que, según expusimos, equivalía a nulo, nada
o ninguno.
En este caso, la expresión condicional podría ser
traducida a nuestro lenguaje del siguiente modo:
“Si la cuenta atribuida al arrendatario es distinta
a “ninguna” o, sensu contrario, si alguna cuenta ha
sido atribuida al arrendatario no ejecutes la función”.
193
Carlos Tur Faúndez
La expresión return false, que puede traducirse

literalmente como retorna o devuelve “falso”, sig-
nifica precisamente que, en caso de no cumplirse
las condiciones evaluadas, se detenga la ejecución
de la función.
Línea 78: (Continúa la función alquilar( )). La
palabra reservada, else, debe ser traducida como
“si no es así”
A continuación, abrimos una llave “{“ para
indicarle a la función, “que debe ocurrir si no es
así.” Dicha llave de apertura tendrá su correspon-
diente llave de cierre en la línea 86.
Línea 79: (Continúa la función alquilar( )). En
esta línea, se está anidando una nueva condición
al else, anterior.
La expresión reservada msg.value, se utiliza
para designar el importe transferido por msg.sender
(en este caso arrendatario).
En la página 196, propusimos, como posible
precio (unitario) por minuto, el de 1 Finney, que
equivale a 0,27 €. Sin embargo, este valor (1 Finney)
lo hemos propuesto como posible ejemplo, dado
que, precioUnitario es un parámetro que, necesaria-
mente, tiene que facilitarse con la creación de cada
contrato. Ello permite la reutilización de código
para el anclado de un nuevo smart contract bien,
con un precio diferente o bien, destinado a otro
vehículo.
194
Smart Contracts
En cualquier caso, la línea 79 nos proporciona

una nueva expresión:
if( (msg.value/1 Finney) / precioUnitario < 1) return
false;
En Solidity, El signo * equivale a “multiplicar”

y el signo / a dividir. Asimismo, se sigue el orden
habitual, de las operaciones matemáticas por lo
que, primero, debe resolverse el interior del parén-
tesis, continuando, posteriormente, con las multi-
plicaciones y las divisiones para concluir con las
sumas y las restas.
Una condición que incluye una fórmula mate-
mática, aparentemente, compleja tiene, en realidad,
una traducción muy sencilla a nuestro lenguaje:
“Si el importe remitido es inferior al establecido,
para una unidad de tiempo, (1 minuto) no ejecutes la
función”.
Línea 80: (Continúa la función alquilar( )). Se

utiliza, una vez más, else, para hacer referencia a
las tareas a desarrollar por la función, para el caso
de que, la condición expresada en la línea anterior,
sea cierta. A continuación, abrimos una llave “{“
que tendrá su correspondiente llave de cierre en
la línea 85.
Línea 81: (Continúa la función alquilar( )). Si
quien ha transferido fondos, lo ha hecho por un
valor superior al precio unitario (hemos convenido
195
Carlos Tur Faúndez
que se trata de 1 Finney) la función debe asignar,

un nuevo valor, a una serie de variables.
En esta línea, asigna un nuevo valor a la varia-
ble plazo:
plazo = now + (1 minutes * (msg.value/precioUnitario));
La traducción a nuestro lenguaje de la expre-

sión antes expuesta es el siguiente:
“El plazo del arriendo empieza ahora, y durará
tantos minutos como Finney (unidades de precio
unitario) haya satisfecho el remitente de los fondos”.
Línea 82: (Continúa la función alquilar( )). Se

asigna a la variable fechaCreacionContrato, el valor
definitivo, que corresponde (minutos y segundos
incluidos) a la del bloque en el que se valide la
transacción correspondiente al pago.
Línea 83: (Continúa la función alquilar( )).
Subsiguientemente, se asigna un nuevo valor a la
variable arrendatario:
arrendatario = msg.sender;
Le estamos indicando, al smart contract, que

desde el preciso instante en el que se ha producido
el pago y la aceptación (se ha apretado el botón
SÍ en la aplicación móvil) el titular de la cuenta
(address) asociada a dicha aplicación, ostenta la
condición de arrendatario.
196
Smart Contracts
Línea 84: (Continúa la función alquilar( )). Indi-

camos al programa, que en tanto detecte que se
ha producido el pago y la aceptación, la función
debe modificar el estado del smart contract y el del
contrato y definirlo como Estado.Aceptado.
Línea 85: (Continúa la función alquilar( )). El
signo “}” es la llave de cierre correspondiente al
último else abierto en la línea 80.
Línea 86: (Continúa la función alquilar( )). El
signo “}” es la llave de cierre correspondiente al
else abierto en la línea 78.
Línea 87: (Concluye la función alquilar( )). “}”
Llave de cierre de function alquilar( ).
Línea 88: (Espacio)
Línea 89: (La función enUso sirve para determi-
nar si el vehículo está disponible. Veremos, al final
de la misma que lleva anidada la function alquilar(
), lo que permite la interacción entre ambas).
function enUso requiere un parámetro o argu-
mento calificado como booleano (_quiereAlquilar)
y, por ende, con dos posibles respuestas (true/false)
(verdadero o falso). La función es payable, por lo que
sólo se activará, si msg.sender (que por el momento
es el arrendatario) remite fondos.
Concluye la línea con llave “{“, con su corres-
pondiente llave de cierre “}”en la línea 97.
197
Carlos Tur Faúndez
Línea 90: (Sigue función enUso). Se establece

una nueva condición, que sirve para evaluar si es
cierto, que el vehículo está en uso, o no lo es.
if( plazo > now ) return true;
La traducimos a nuestro lenguaje, del siguiente

modo:
“Si el plazo del contrato no ha finalizado, es
cierto que el vehículo está en uso”.
Línea 91: (Sigue función enUso). Escribimos else

y, a continuación “{“, con su correspondiente llave
de cierre “}” en la línea 96.
Línea 92: (Sigue función enUso). Si el plazo es
now (ahora), o bien nadie ha arrendado el vehículo,
aún, o bien, el último arrendatario, ha concluido
su periodo de arriendo, por lo que, al utilizar la
expresión, arrendatario = 0x0; se le está indicando
al programa que debe asignar a la variable corres-
pondiente a la cuenta (address) el valor 0x0, o lo que
es lo mismo, NADA.
Línea 93: (Sigue la función enUso). Indicamos
al programa que, tan pronto como constate que el
plazo es now, es decir, que no hay arrendatario, la
función debe modificar el estado del smart contract
y del contrato y definirlo como Estado.Disponible.
Línea 94: (Sigue la función enUso). Solicitamos al
programa que la función anuncie el evento (event)
formulado en la línea 71, esto es, VehiculoDisponible.
198
Smart Contracts
Dicho evento podrá ser “escuchado” por aplica-

ciones externas y remitir la información por vía
remota a los dispositivos electrónicos del vehículo
y de la torre de anclaje.
Línea 95: (Sigue la función enUso). Tal y como
expusimos en la página 171, el smart contract
debe prever la posibilidad de que, el arrendata-
rio que está en uso del vehículo, desee prorrogar
su contrato, por un periodo de tiempo superior.
Precisamente, por ello, solicitamos al contrato lo
siguiente:
if( quiereAlquilar == true) alquilar( )
Lo que puede ser traducido, a lenguaje com-

prensible, como:
“Si (el arrendatario actual) quiere alquilar (nue-
vamente) puede hacerlo del mismo modo que lo
hizo anteriormente”.
Lo que verdaderamente estamos estableciendo,

como elemento de evaluación para la función (que,
como indicamos en la línea 89, es payable, es decir,
requiere el envío de fondos para activarse) es, si
se han remitido, o no, tales fondos por el actual
arrendatario. Si el programa se apercibe de que se
han remitido fondos, dará paso, nuevamente, a la
function alquilar( ) iniciando la secuencia, nueva-
mente en la línea 73 y dicho bucle, se reiterará una
y otra vez, hasta que el arrendatario deje de pagar
199
Carlos Tur Faúndez
cantidades superiores a 1 Finney, valor que hemos

convenido por un minuto de arriendo.
Línea 96: (Sigue la función enUso). Llave “}” que
cierra el contenido del else, abierto en la línea 91.
Línea 97: (Concluye la función enUso). Llave “}”
que cierra el contenido de la function enUso, abierta
en la línea 89.
Línea 99: (Inicio de la función cobrar). El
importe de la renta arrendaticia, ha sido transfe-
rido desde la cuenta (address) del arrendatario, a la
cuenta del smart contract. Sin embargo, el propieta-
rio, tiene derecho al cobro de la contraprestación.
Para tal fin, se construye, function cobrar( ) y se
abre su contenido con la correspondiente llave “{“
Línea 100: (Continúa la función cobrar). Con-
signamos la siguiente instrucción:
propietario.send(this.balance);
El texto .send, se corresponde con un método

(una función preconstituida en Solídity) del objeto
address. Comoquiera que, propietario, es una
address, le estamos solicitando, al programa, que
remita fondos a dicha cuenta del propietario.
¿Cuáles son los fondos que debe remitir el
smart contract desde su cuenta hasta la cuenta del
propietario? El término balance, debe ser traducido
200
Smart Contracts
como “saldo” y, por consiguiente, es inherente a

una cuenta address.
Al introducir entre paréntesis la expresión this.
balance, sin indicación alguna de estado, que pueda
exigir un lapso temporal concreto, le estamos soli-
citando al smart contract que, siempre que exista
algún saldo disponible en su propia cuenta (this),
lo transfiera a la cuenta del propietario.
Línea 101: (Concluye la función cobrar). Llave
“}” que cierra el contenido de la function cobrar,
abierta en la línea 99.
Línea 103: (function destruir). Concluimos esta
exposición, deseando no haber cometido demasia-
dos errores y creando una última función (function)
en este smart contract, desarrollado en Solidity, a la
que asignamos la denominación destruir).
Sabemos que una de las características de Ethe-
reum, es la inmutabilidad y por tal motivo, si no
existiera la instrucción selfdestruct (autodestruc-
ción) no cabría la posibilidad de hacer desaparecer
un smart contract, ni siquiera, en el caso de que estu-
viera deficientemente construido o no cumpliera
ninguna utilidad.
Si nada lo remedia, el programa, permanecerá
“eternamente” en la cadena de bloques, ocupando
espacio de almacenamiento.
No es necesario proporcionar argumento o
parámetro alguno a la función.
201
Carlos Tur Faúndez
Línea 104: (Continúa function destruir). Añadi-

mos el modifier queEstado, configurado en las líneas
37 y siguientes.
La variable estado debe hallarse en situación
disponible (Estado.disponible) o, de lo contrario, corre-
ríamos el riesgo de que, el propietario, pudiera
intentar la destrucción del smart contract estando
vigente un arrendamiento del vehículo.
Posteriormente, situamos la llave de apertura
de la función “{“ que tendrá su correspondiente
llave de cierre “}”en la línea 105 e indicamos, al
programa, el requerimiento de una condición para
la ejecución de la función:
i f ( m s g . s e n d e r = = propietario)
selfdestruct(propietario);
La expresión puede ser traducida, a nuestro

lenguaje, del siguiente modo:
“Si la cuenta, (address) desde la que se remite el
mensaje, pertenece al propietario, remítele el íntegro
saldo remanente en tu propia cuenta, (address del
smart contract) destrúyete y desaparece”.
Una vez ejecutada la función, tanto el smart con-

tract como su propia cuenta (address) pasan a ser,
definitivamente inaccesibles, lo que no obsta que
quede registrada su existencia y actividad pasada
en los bloques correspondientes.
202
Smart Contracts
Línea 105: (Concluye la función destruir). Llave

“}” que cierra el contenido de la function destruir,
abierta en la línea 103.
Línea 107: (Final y cierre del smart contract).
Llave “}” que cierra el contenido del smart contract
arrendamientoVehiculo, abierto en la línea 3.
203

Smartcontracts Libro PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Smartcontracts Libro PDF

Caricato da

Copyright:

Formati disponibili

Carlos Tur Faúndez

La cadena de bloques y los smart contracts se hallan hoy en boca de todos y,

SMART CONTRACTS. Análisis jurídico

e incluye libro electrónico

este ejemplar pertenece a: jpvalencia2012@gmail.com - 2019-03-18 20:36:21

este ejemplar pertenece a: jpvalencia2012@gmail.com - 2019-03-18 20:36:21

Moisés Barrio Andrés

este ejemplar pertenece a: jpvalencia2012@gmail.com - 2019-03-18 20:36:21

1.ª edición REUS, S.A. (2018)

Imprime: ULZAMA Digital

Ni Editorial Reus ni los Directores de Colección de ésta responden del

este ejemplar pertenece a: jpvalencia2012@gmail.com - 2019-03-18 20:36:21

este ejemplar pertenece a: jpvalencia2012@gmail.com - 2019-03-18 20:36:21

1.2. TRASCENDENCIA JURÍDICA DE LOS

4.5.3. LA FORMA EN LOS CONTRATOS

ÍNDICE BIBLIOGRÁFICO................................ 147

ANEXO 1 - UN CONTRATO LEGAL

API: Application Programming Interface

CENDOJ: Centro de documentación judicial

MOOC: Massive Open Online Course (Curso

El hecho de haber empezado a estudiar la

los mensajes y su recepción por el destinatario

utilizar todas las ventajas visuales y textuales de

puede resultar inapropiada, en algunos aspectos,

riesgos propios, entre los que destaca el que es

Finalmente, el libro nos ofrece, a lo largo de

Santiago Cavanillas Múgica

Desde hace una década, los smart contracts1 han

zada, una criptomoneda5(el Ether6) y un lenguaje de

hacen públicos “pretendidos” contratos (smart

En noviembre del año 2015, se celebró la primera confe-

rencia para desarrolladores de la plataforma Ethereum a la que

caso, pudieran imponerse.

inglés por desarrolladores de software, bien a ana-

(smart legal contracts) en busca de la integración de

grama (smart contract), en función de su contenido,

El programa, actúa como un ente autónomo con cuenta

cindibles para la creación de contratos legales inteli-

La tecnología Blockchain constituye la base sobre

que el mero registro de transacciones económicas

rencia fundamental en el sistema de valoración21

será la única válida, siendo nulas todas las

Si A, dispone de 1 BTC y lo transmite a B a las 10.15

am, todos y cada uno de los ordenadores conectados a la red,

2. LA CADENA DE BLOQUES O BLOCKCHAIN

tro” se actualizará, en lo sucesivo, cada vez que el

En alguna medida, los programas informáticos presentan

ciertas similitudes con los formularios, a los que tan habituados

máticamente, en un bloque de información. Según

Algunas de estas variables en un smart contract, podrían ser: el

Este método hace que la cadena de bloques sea

ción32 recibirá una recompensa en “criptomonedas”

2.3. CLASIFICACIÓN DE LAS CADENAS DE

tidivisa” más populares podemos encontrarla en el Sitio web:

b) Federadas o de consorcio: A diferencia de lo

c) Privadas: Haciendo uso de la tecnología que

2.4. ETHEREUM EN PARTICULAR

international/2017/02/06/440629.htm. En fecha 6 de febrero de 2017,

la cadena de bloques de Bitcoin, es Turing completo47,

ten: el depósito de fondos en la criptomoneda

ab initio a su creador, pero los fondos que en ellas

2.5. OTRAS TECNOLOGÍAS DE RED DISTRI-

diferencia de éstas, no disponen de un “mecanismo