10.18601/16923960.v21n1.04
El régimen de la oferta y la aceptación en los contratos inteligentes embebidos en el blockchain1
The offer and acceptance regime in smart contracts embedded in the blockchain
José Joaquin Rondón Rubiano2
1 Fecha de recepción: 25 de enero de 2022. Fecha de aceptación: 25 de junio 2022. Para citar el artículo: Rondon J. "La oferta y la aceptación en los contratos inteligentes embebidos en el Blockchain". Revist@ E-Mercatoria, vol. 21, N° 1, enero-junio 2022. DOI: https://doi.org/10.18601/16923960.v21n1.04
2 Estudiante de la universidad Externado de Colombia. Jose.rondon01@est.uexternado.edu.co
RESUMEN
En este artículo buscamos analizar los posibles problemas de la oferta y la aceptación de los contratos inteligentes en la cadena de bloques. De esta manera, explicaremos brevemente qué es blockchain y cuál es su relación con los contratos inteligentes. A continuación explicaremos las diferencias entre los contratos electrónicos y los contratos inteligentes en cuanto a la oferta y la aceptación. Adyacentemente, profundizaremos en las diferentes interpretaciones jurídicas del Código de Comercio de Colombia. Finalmente, brindaremos algunas soluciones utilizando una combinación de implemen-taciones tecnológicas y legales.
Palabras clave: Oferta, aceptación, contratos inteligentes, blockchain.
ABSTRACT
In this article, we seek to analyze the possible problems of the offer and the acceptance of the smart contracts on the blockchain. In this manner, we will explain briefly what is blockchain and what is its relationship with the smart contracts. Thenwe will explain the differences between the electronic contracts and the smart contracts regarding the offer and the acceptance. Adjacently, we will delve into the different legal interpretations of the Commercial Code of Colombia. Finally, we will provide some solutions using a combination of technological and law implementations.
Key words: Offer, acceptance, smart contracts, blockchain.
INTRODUCCIÓN
En el siguiente artículo veremos la oferta y la aceptación de los contratos inteligentes. Debido a que buscamos esclarecer las inimaginables confusiones quele pueden surgir al abogado del siglo XXI al momento de hablar de las nuevas tecnologías.
La causa de esta investigación no es la dificultad de entender los tiempos modernossino la necesidad de converger con ellos. En el mundo tecnológico, cuando llega una nueva realidad, siempre parece estar a punto de derribar los cimientos del ordenjurídico preestablecido. Por ejemplo, con la llegada del internet, se decía que seríaun lugar donde el imperio de la ley no tendría lugar. Aunque pareciera que se impuso una sentencia inapelable, la tecnología y la ley se juntaron. La necesidad de acceso por parte de los usuarios, los llevo a necesitar de intermediarios que los conectaran a la red. Entonces, los prestadores de servicios de internet pusieron susconocimientos tecnológicos para hacer cumplir la ley a través de ellos3.
Sin embargo, el paradigma del blockchain es diferente al del internet, puesto que nohay entes que permitan su control mediante la centralización, ya que el sistema porsu naturaleza es descentralizado y cualquiera puede acceder a él. Por esto, los contratos inteligentes embebidos en el blockchain parecería que llegaron para sacudir aquellos cimientos. Debido a que su diseño imposibilita que algunas figuras tradicionales del derecho como la terminación, extinción o interpretación del contrato sean aplicables4.
El sistema de la formación del negocio jurídico en los contratos inteligentes es el problema que hoy nos incumbe, pues el blockchain choca principalmente con el sistema de la oferta y la aceptación en el orden jurídico colombiano. Por mucho que tratemos de aplicar este régimen, todos nuestros intentos serán fútiles, la manera como están programados y el sistema en el cual están integrados les permite encapsularse a sí mismos en una burbuja, en su mundo ideal fuera del alcance derecho.
En nuestro artículo, el método investigativo nos permitirá ver la interacción del derecho y la tecnología. Viendo el recorrido de la oferta y la aceptación, en los contratos inteligentes. Analizando diferentes casos y finalmente, dando solucionesa partir de la combinación del derecho y las nuevas tecnologías.
1. LOS CONTRATOS INTELIGENTES EMBEBIDOS EN EL BLOCKCHAIN
La humanidad siempre ha querido deshacerse de las tareas insignificantes a través de la automatización. Digo desde siempre ya que, la automatización de las tareas no nace con la modernidad, por ejemplo, Herón de Alejandría en el siglo I d.C., inventó una máquina que dispensaba agua sagrada a cambio de insertar una moneda5, instrumento que modernizado en forma de mundana máquina expendedora hoy vemos aparcada en casi todas las esquinas de las diferentes ciudades. Este invento del ingenio lo traigo ya que, es la manera más sencilla de explicar que es un contrato inteligente y su funcionamiento.
Entonces cuando se quiere obtener algún elemento de la máquina expendedora, almomento de adquirir un producto sólo dispensará dicho producto si se cumple la condición de satisfacer un pago. No considerará la buena fe del comprador, los deberes de información, menos contraofertas u otros aspectos en derecho. Sólo ejecutará su prestación, si se cumple con esa condición predeterminada que es el pago. Cómo un buen hombre avaro sólo efectuará su prestación si el precio es el que dispuso.
Los contratos inteligentes son programas de computadora; cuya prestación será ejecutada automáticamente, con la finalidad de crear, modificar u extinguir obligaciones. A la manera de la máquina expendedora sólo se ejecutarán los diferentes códigos de computadora que lo componen si se cumplen las condicionescontenidas dentro de ellos. Nick Szabo, acuñó este término por primera vez en los 90's, su idea era una simple, las diferentes cláusulas, objetos contractuales y obligaciones pueden ser traducidos e insertados en el software y hardware que tenemos a nuestra disposición6. Se les llama a inteligentes ya que, a diferencia delpapel, son mucho más funcionales, permitiendo a las partes ver su ejecución y cumplimiento en todo momento (observabilidad); probar ante un juez los incumplimientos de las partes de una manera más sencilla (verificabilidad objetiva); impedir la intervención de terceros ajenos al contrato, como una manifestación reforzada del principio de relatividad (privacidad) y, la posibilidad de auto ejecutar las diferentes prestaciones programadas en el contrato inteligente7.
1.1. ¿Cuál es la relación de los contratos inteligentes con el blockchain??
Cuando Nick Szabo conceptualizó los contratos inteligentes se preocupó por la seguridad de estos ya que, al estar desmaterializados, podían ser objeto de ataquesde terceros. Para esto concibió el uso de llaves públicas y privadas que serían usadas por los contratantes. Finalmente, dicha preocupación se puede traducir como un problema de confianza, entre más seguro el sistema, más confianza tendrán en que dicho contrato es la representación exacta de lo que se proponían lograr. El blockchain viene a suplir la función de reforzar la confianza que cumplíanlas llaves públicas y privadas.
El blockchain, simplificándolo, es un libro de contabilidad donde se registran todas las transacciones que llevan sus usuarios. Lo innovador es que todos los usuarios (de aquí en adelante nodos) tienen una copia de este libro y, cuando se ejecuta unatransacción entre nodos cada libro se actualizará8. Pero, no todos los nodos, pueden añadir esas transacciones a sus partidas de cuenta, esto sólo lo podrán realizar unos nodos especiales llamados mineros.
Los mineros son los que organizan las diferentes transacciones dentro de un bloqueque estará encadenado con el anterior que contiene las transacciones precedentes (de ahí su nombre cadena de bloques blockchain). Para lograr esto tienen que cumplir con un proceso llamado "prueba de trabajo", el cual consiste en encontrar el número que identificará al bloque y, por lo tanto, las transacciones contenidas dentro de este. Para esto los mineros tienen que encontrar dicho número, este proceso es un trabajo de fuerza bruta, ya que se harán operaciones matemáticas sucesivamente hasta encontrar el indicado. Una vez encontrado ese número, se lepondrá el "timestamp" o la hora en la cual fue añadido el bloque al blockchain. Para luego, ser verificada por los otros nodos si esa solución es satisfactoria y se le recompensará por su trabajo con un pago en criptomonedas. Cada nodo de mineríaescoge cuales transacciones incluir al bloque, esto dependiendo del tiempo de llegada, los costes de transacción, el tamaño de la transacción, etc.
Este sistema permite la transparencia, trazabilidad y la seguridad de todas las transacciones que se efectúan. Transparencia, debido a que es casi imposible modificar las transacciones que los mineros han añadido al libro de cuentas9, lo queda seguridad acerca de la legitimidad de las transacciones. Trazabilidad, ya que todo nodo de la red puede ver todas las transacciones que se realicen. Seguridad, ya que, si, por ejemplo, un minero quiere falsificar una transacción, tendría que competir contra todos los otros mineros de la red, y si llegara a tener la suerte de acertar el número antes de los otros crearía una bifurcación del blockchain. Por lo cual ahora habría dos cadenas de bloques compitiendo paralelamente para ver cuáles la correcta, pero el sistema esta creado para que los mineros trabajen en la cadena más larga, por lo cual quien haya iniciado la bifurcación necesitaría tener más poder computacional que el resto de la red combinada para alcanzarlos (de esta manera, 51%)10 y así hacer que esta nueva bifurcación sea vista como la cadenacorrecta. Puesto que, los otros mineros seguirán minando y validando nuevas transacciones.
El sistema que acabamos de explicar es el blockcahin 1.0, pero el que nos interesaes el blockchain 2.0. Este nos permite crear aplicaciones descentralizadas ("DAPPS")11, que son programas de computadora, entre las cuales encontraremos alos contratos inteligentes como una especie de ellas12. Es decir, cada nodo en vez de solamente recibir una transacción podrá ejecutar dicho programa. Una plataforma que permite esto es "Ethereum", si existe un contrato inteligente dentro de ella ese contrato que ha sido desplegado no pueden ser modificado sólo"removido"13. Esto es un cambio gigantesco, puesto que ahora se puede ejecutar esos contratos inteligentes con la seguridad, transparencia y trazabilidad que da el sistema del blockchain, reforzando así las inquietudes de que alguna vez tuvo NickSzabo.
2. LA OFERTA Y LA ACEPTACIÓN EN LOS CONTRATOS ELECTRÓNICOS Y EN LOS CONTRATOS INTELIGENTES EMBEBIDOS EN EL BLOCKCHAIN
La oferta es aquel acto unilateral, donde se hace una propuesta a un tercero con lafinalidad de celebrar un contrato bajo ciertas condiciones14-15 comunicación de adhesión a esa propuesta inicial16. Su reglamentación se encuentra consagrada entre los artículos 845 a 864 del Código de Comercio. Además, son prerrequisitos para que se entienda celebrado un contrato17. Sabiendo esto veamos cómo interactúa la oferta y la aceptación en los contratos electrónicos y en los contratos inteligentes dentro del blockchain.
2.1. La oferta y aceptación del contrato electrónico
El contrato electrónico también requiere de una oferta y aceptación para ser-formado, la diferencia es que dichas manifestaciones unilaterales se llevarán por medios electrónicos18. Es decir, los futuros contratantes han escogido como mediode expresión un programa de computadora que transmite sus voluntades convergentes a través de mensajes de datos que puede traducirse o no a caracteresalfanuméricos, es decir a un contrato en "lenguaje natural" leíble por las partes. Aldarse la oferta mediante un "escrito", a pesar de que su oferta- aceptación pueda ser instantánea y automatizada, se debe regular el término supletorio de seis días a la duración de la oferta (art 851 Código de Comercio) si las partes no acordaron un término y estas son determinadas. En cambio, si es una oferta al público (personas indeterminadas) deberá verse el término aplicable según el Código de Comercio y las leyes especiales al acto jurídico. Por ejemplo, una "oferta" en un panfleto que llega a mi correo electrónico, ni siquiera es una oferta y, por lo tanto, esta desprovista de término. Esta es una policitación, que por regla general esta desprovista de eficacia19. Mientras tanto, un contrato celebrado con un consumidor obligatoriamente debe estar provisto de un plazo e informar sobre la disponibilidad de los productos (art. 50.b Ley 1480 de 2011). Por otro lado, la revocación y el retirode la oferta se puede hacer a través de una adenda que invalide el mensaje de datos anteriormente enviado.
Otro elemento que se debe considerar a lo largo del recorrido de la formación contractual es el "acuse de recibo". Esto es un concepto tomado por la CNUDMI, para la ley modelo de comercio electrónico, de los servicios postales20 donde el acuse de recibo era un formulario firmado por el destinatario del paquete, el cual erareenviado al que envió dicha paquetería. Este eufemismo etéreo se utiliza para describir prácticamente cualquier procedimiento tecnológico, ya sea el recibo de un mensaje no individualizado hasta la manifestación expresa de estar de acuerdo con el mensaje21. Dicho acuse de recibo se positivizó en el artículo 20 de la Ley 527 de1999. Soto (2002) dice que el acuse de recibo es un sistema automático que puedeactivarse en los correos electrónicos y mediante el cual se puede conocer cuando un mensaje está siendo abierto por el destinatario22. El Consejo de Estado, en el mismo sentido, ha entendido que se acusa recibo cuando el mensaje de datos llegaal servidor de destino. Este servidor de manera automática remitirá esa comunicación al destinatario23.
Su importancia reside en que si el oferente- iniciador del mensaje ha dicho que necesita recibir el acuse de recibido para que se entienda que el mensaje de datos-aceptación se recibió satisfactoriamente, deberá enviarse el acuse de recibo. Para algunos esto constituye una formalidad requerida para la formación del contrato que modifica las reglas generales de la oferta y aceptación24. Sin embargo, esto es algo mal enfocado, ya que, es diferente el momento en que la oferta-aceptación producen efectos, a la forma a través de la cual se entiende remitida la aceptación,que puede ser determinada a través de indicios, como si se utilizó un medio idóneo o la distancia (art 845 Código de Comercio y 851 Código de Comercio)25 o el mismo acuse de recibido. Puesto que la oferta es eficaz desde la recepción de esta26 y su aceptación puede ser tácita o expresa a través del mensaje de datos. Incluso si condicionáramos la formación del contrato a esta solemnidad por disposición particular, el contrato podría celebrarse aún por conducta concluyente de las partes, suprimiendo la formalidad inicial27 y obviando el mensaje de datos-aceptación condicionado por el acuse de recibo.
Por lo cual, la aceptación ya sea tácita o expresa tiene la virtualidad para formar elcontrato si se hace dentro del plazo de la oferta. El momento exacto, de lacoincidencia entre la oferta y la aceptación del contrato dependerá de la teoría de laformación del contrato que se escoja28 para interpretar el artículo que describa la situación aplicable al caso. En la teoría de la emisión basta que el destinatario envíeel mensaje de datos desde su ordenador para que se entienda celebrado el contrato. En la del conocimiento, bastaría que el oferente supiera de la aceptación, incluso sin que medie ningún sistema electrónico. Y finalmente, en el sistema de larecepción el contrato se entendería celebrado con la recepción del mensaje de datos al ordenador del oferente29.
2.2. La oferta y aceptación de los contratos inteligentes embebidos en el blockchain
Una definición más técnica del blockchain sería la de un estado en transición hacia otro estado30. Por lo cual podemos decir que existirá un estado A en el cual se encuentran la oferta (enviada a través de un contrato inteligente) y la aceptación (enviada a través de una transacción o un contrato inteligente que se refiera al primero) y un estado B posterior en el cual se encuentra el contrato perfeccionado y con sus prestaciones automáticamente ejecutadas31. El que permite esa transición es el minero que ordena las transacciones y las añade a un bloque que contiene las instrucciones del contrato inteligente que se ejecutará posteriormente en el blockchain, añadiéndose así a ese libro descentralizado.
La oferta y la aceptación tienen exactamente los mismos efectos jurídicos antes descritos para los contratos electrónicos. Algunos autores dicen que las ofertas publicadas en el blockchain son invitaciones a ofrecer o policitaciones por parte deloferente, ya que este pública el código del contrato en la cadena de bloques a la espera de la aceptación de un destinatario32. Tal vez en ciertos casos esto pueda ser así, mientras que, en otros, el contrato inteligente será desplegado a la cadena de bloques luego de una etapa precontractual donde las partes habrán definido las condiciones bajo las cuales quieren celebrar dicho contrato.
Aunque el código que este contenido en el contrato es inmodificable, la revocación del contrato, aunque más difícil, no es imposible y puede realizarse con la función selfdestruct si es programada33. Para las modificaciones subsecuentes de la oferta,sólo se requiere subir un nuevo contrato inteligente con las nuevas condiciones de esta. Sin embargo, esto sólo impide que no se pueda interactuar con el contrato, ya que puede devolverle los criptoactivos a las partes, pero no anularlo en el estricto sentido legal34 ya que seguiría existiendo en la cadena de bloques, además no es una regla general que los criptoactivos sean devueltos a cada una de las partes que han interactuado con el contrato. Por otro lado, la conducta concluyente tampoco se excluye del todo, por ejemplo, si el destinatario provee una contraseña para ejecutar la transacción35. En este instante podríamos afirmar que las reglas generales de la oferta-aceptación aplicarían con toda su extensión. Pero como siempre, el diablo está en los detalles.
3. PROBLEMÁTICA CON LA TRADICIÓN JURÍDICA DE LA OFERTA Y ACEPTACIÓN EN EL BLOCKCHAIN
A diferencia de un contrato electrónico (si bien también se consideraría como una oferta escrita regulada bajo el art. 851 del Código de Comercio) su celebración no se da de manera automática, como vimos depende de un tercero, el minero. Dicha limitación técnica trae consecuencias de tipo jurídico. Analizaremos esto a través dedos casos, que si bien no son los únicos que podrían presentarse, estos están bien documentados como problemas a la hora de usar los contratos inteligentes.
Nuestro primer caso de referencia será el siguiente:
Beto es un comerciante que sube una oferta a través de un contrato inteligente; al blockchain. Dicha oferta estará programada para ejecutar las prestaciones tan pronto un infortunado envié el pago establecido en el contrato a través de una transacción hacia la dirección que identifica dicho contrato. Por qué infortunado, puesto que él no sabe que horas antes Beto había enviado una transacción para revocar la oferta dentro del contrato inteligente. Por lo cual esas transacciones deberán ser organizadas por un minero, entonces existe incertidumbre de qué pasará cuando el blockchain pase a ese estado B36. ¿Se celebrará y ejecutará el contrato, aunque la revocación haya sido temporánea o se le privará al destinatario de su aceptación así haya cumplido con las condiciones de la oferta?
Entonces, por un lado, el art 857 del Código de Comercio diría a favor del destinatario que, su aceptación fue temporánea, por lo cual estaba encaminada la celebración del contrato37. A favor del oferente diría que la revocación se hizo antesde la aceptación del destinatario y que, por lo tanto, era válida38. Además, que esto sería comparable a retirar una carta mientras aún está en la oficina postal.
También es de considerar, por ejemplo, una modificación por parte del oferente de la oferta primigenia, que se envía en un tiempo relativamente cercano a la aceptación de esa primera oferta por parte de un destinatario. Entonces también setendrá la incertidumbre si se da la celebración de ese contrato inteligente nuevo o si por el contrario se celebrará el contrato inteligente primigenio, como vimos dependerá de cómo se organicen las transacciones. En todo caso una parte se verá obligada a celebrar un contrato bajo unas condiciones que no deseaba.
Nuestro segundo caso de referencia es el siguiente:
Ana, quien es una comerciante, hace una oferta al público (es decir a personas indeterminadas) a través de un contrato inteligente. Dice que, con el pago de un bitcoin, se le enviará al aceptante una computadora nueva. Este es el estado A del contrato.
Pedro, Juan y Blanca cada uno y por aparte envían una transacción a la dirección del contrato.
Aunque todos cumplieron las condiciones del contrato, el minero organizó la oferta de Blanca, quién fue la última en enviar su transacción, como la primera transacción que fue integrada al blockhain, celebrándose así el contrato. Entonces cabe la posibilidad de que el primero que envía la aceptación, en el estado B del blockchain, no sea el primero en ser integrado al él39.
Como vemos aquí hay varias personas que están en la capacidad de aceptar la oferta. No obstante, debe ser el primero que la comunica aquel que termina siendo el contratante40 y si esto no fuera posible, se le dará a quien mejor haya cumplido las condiciones de la oferta o si es divisible la prestación se dividirá (art. 858 Código de Comercio). Acá, todos cumplen la oferta en iguales condiciones, y las transacciones son exactamente iguales. Además, todas estas deben pasar por el sistema del blockchain y obligatoriamente por un minero, si quieren celebrar dicho contrato. Entonces ¿Se le debe permitir a la última persona que comunicó su transacción ser la única que pueda celebrar el contrato por un capricho del minero?
Ya que en los dos casos sólo hay una realidad que será posible desde el punto de vista técnico, el factor diferenciador será la teoría de la formación del contrato que escojamos.
4. INFLUENCIA DE LAS DIFERENTES TEORÍAS EN EL CASO DEL BLOCKCHAIN
El nudo gordiano jurídico al que nos lleva la realidad tecnológica es uno que trataremos de desenredar viendo cada una de las diferentes teorías que explican el momento de formación del contrato. En este sentido, veremos a través de ellas si, se formó el contrato o por el contrario la revocación fue temporánea.
4.1. Teoría de la emisión
La teoría de la emisión nos dice que los efectos del respectivo acto jurídico se desencadenarán con sólo expresarlo41. Por ejemplo, la del destinatario para perfeccionar el contrato, le basta con la manifestación de su voluntad de aceptarla. El artículo 845 del Código de Comercio le da valor a la oferta desde su emisión, ya que supedita su eficacia a la utilización de un "medio adecuado", no requiere que esta llegue a conocimiento del destinatario. Por otro lado, el artículo 864, en su segundo inciso, presume que la aceptación ha llegado al oferente si el destinatario puede probar que la remitió, otra vez sólo requiere la manifestación de esa voluntad y prueba que haya sido emitida42. Usando esta solución diríamos que simplemente se debe ir al juez y determinar el momento en que se formó el contrato para solucionar nuestro problema.
Pero los problemas que trae esta teoría sólo agudizan con su propia inaplicabilidad si lo usamos en el contexto de los contratos inteligentes. En primer lugar, esta teoría siempre ha llevado a problemas judiciales, ya que es bastante difícil determinar ese momento del perfeccionamiento43. Esto es incluso, peor en el blockchain ya que sibien, por ejemplo, en Ethereum, puede poner la fecha como información adicional,que probaría su comunicación por un oferente, esto no es lo usual44. Por lo cual, esbastante dificultoso, al menos de manera clara y dentro del sistema, conocer el momento de esa declaración (expedición del mensaje).
En segundo lugar, en el caso de la conducta concluyente, incluso si la conducta del destinatario nos pudiese indicar sin ambigüedad que empezó a ejecutar las prestaciones del contrato, el contrato inteligente en sí no tendría ni la menor conmiseración por este. El código de programación es aquella ley para las partes donde no cabe ninguna consideración exterior diferente a lo programado. Así se pudiese probar que la revocación de la oferta fue anterior a la aceptación, si el minero organiza primero la última, no queda sino desesperanza para un oferente- contratante que no quería vincularse. Esta teoría no satisface las realidades técnicas del blockchain.
4.2. Teoría de la información o conocimiento
En esta teoría es el oferente el que debe enterarse de la aceptación del destinatario para que se entienda celebrado el contrato45. El principal problema, con esta teoría es que el aceptante queda virtualmente obligado, sin saber realmente cuando se celebró el contrato46. El artículo 854 del Código de Comercio, condiciona la aceptación tácita del destinatario al conocimiento del oferente. Si siguiéramos esta teoría, además de los inconvenientes jurídicos, desde el punto de vista técnico, en qué momento podemos afirmar que realmente el oferente puede conocer de la aceptación. La respuesta más natural, que podríamos decir es cuando dicha transacción le sea transmitida por un minero, siendo el nodo que es y así actualizándose su libro de cuentas. Sin embargo, como dijimos si fueran varios los que aceptan no se podría saber a ciencia cierta quien fue el primero en comunicar su aceptación.
Pero, qué pasaría si este oferente a la vez fuera un nodo minero, este podría virtualmente enterarse de la transacción antes que esta fuera transmitida. Conociendo así quien fue el primero en enviar su transacción o si su contraparte aceptó efectivamente su propuesta. Entonces, ¿Bastaría eso para formar el contrato? Tal vez jurídicamente sí, pero como dijimos el contrato inteligente seguirá en ese estado A y sólo el procesamiento por los mineros de esa transacción permitirán que las prestaciones contenidas en el contrato se ejecuten. Esta teoría tampoco satisface las realidades técnicas del blockchain.
4.3. Teoría de la recepción
Lo que dice esta teoría es que el contrato se celebra con la recepción de la oferta al domicilio del oferente o el mejor lugar para recibirla47. Esta se encuentra en el artículo 864 del Código de Comercio en su primer inciso. Si hablásemos de contratos electrónicos, esta sería la teoría perfecta para el comercio electrónico, esdecir con la llegada de la aceptación al computador del destinatario48. Pero en los contratos inteligentes embebidos en el blockchain, como dijimos esta información es trasmitida a todos los nodos de la cadena, entonces no podríamos decir propiamente computador del destinatario, sino más bien que el mejor lugar vendría siendo el nodo y que el momento sería cuando se le transmita la transacción y ejecución del contrato a su nodo. Además, la aceptación del destinatario que le llegaa su nodo, en el segundo caso de referencia, podría no ser la primera aceptación que fue enviada.
Aunque, se nos da una solución jurídica medianamente aceptable, esto sólo nos lleva a la encrucijada en la que comenzamos. Para empezar, como dijimos sería ridículo vincular al oferente a una oferta que quería revocar y que le era dable hacerlo ya que no había recibido ninguna aceptación del destinatario a su "domicilio"49. Posteriormente, no sabe si la transacción- aceptación del destinatario ha sido añadida al blockchain y en cambio se le deja bajo la zozobra de cuál transacción se ejecutará primero y, por lo tanto, qué pasará con el contrato inteligente ¿se extinguirá o autoejecutará las prestaciones?
Seguidamente, del lado del destinatario, supongamos que el oferente ha modificado el contrato inteligente a través de una transacción que es organizada primero por los mineros, entonces debe el destinatario conformarse con celebrar un contrato inteligente con el que no estaba de acuerdo inicialmente. Tanto el oferente como el destinatario están atados a competir en una carrera de la cual no quisieron participar.
Por otro lado, existe otra competencia entre destinatarios. Ya que sin importar que tan diligentes hayan sido en comunicar su aceptación, la formación del contrato depende de la transacción que primero llegue al nodo del destinatario por haber sido organizada como la primera por el minero. Así, la transacción que este organiza es la que primero le será comunicada al oferente y, por lo tanto, será esa la que se tomará para la celebración del contrato.
Debido a esto tal vez se cumple con la ley, y podría funcionar, pero no se satisfacen verdaderamente las necesidades jurídicas de las partes, ni se hace frente a la realidad técnica de la plataforma. Al parecer este nudo jurídico se acabó de entrelazar con otro de tipo técnico. Pero las soluciones finalmente son tan proverbiales como simplemente cortar ese enredo.
5. SOLUCIONES
Como las teorías e interpretaciones se han quedado cortas (o más bien, han querido abarcarlo todo) veremos las posibilidades para solucionar las necesidades jurídicas de los futuros contratantes sin recurrir a ellas. Ya que las soluciones alrededor de los contratos inteligentes requerirán una programación explícita a través de la cual se programe las figuras del derecho tradicional y no a través de interpretaciones apegadas a la realidad de los contratos inteligentes50. Por lo cual daremos soluciones tentativas, a través de las cuales el ordenamiento jurídico puede integrarse a este tipo de contratos sin que la funcionalidad de estos se vea afectada. Para el primer caso de referencia, veremos las soluciones desde las dos caras de la moneda, es decir desde el punto de vista del oferente y del destinatario. Mientras que para el segundo seremos más breves al dar una solución conjunta para ambos.
5.1. Para el destinatario en el primer caso de referencia
5.1.1. La condición guardiana: Oferta y contraoferta
¿Qué es una condición guardiana? Esto es una línea de código que permitiría al destinatario aceptar la oferta del contrato inteligente, si esta corresponde a lo que esperaba como contraprestación. De esta manera se podrán evitar disconformidades si la transacción del oferente es organizada en primer lugar por el minero. Lo cual provoca que se modifique el contrato inteligente (oferta) cambiando la prestación inicial prometida.
La condición guardiana verifica el estado (la fotografía de ese momento) en el que se encuentra el contrato inteligente. Este código tiene que verificarse antes que se pueda ejecutar la transacción del destinatario. Debido a que, el valor programado en la condición guardiana y la prestación inicialmente prometida por el oferente tienen que ser las mismas. De esta manera si el destinatario envió su transacción esperando un bitcoin, la condición guardiana verificaría que esta prestación siga siendo la misma en el contrato inteligente antes de transferir los fondos a la cuenta del oferente51. Por lo cual sería una simple aceptación de la propuesta inicial.
Por otro lado, si el estado del contrato actual no corresponde con lo inicialmente esperado, la transacción del destinatario sería una nueva oferta que se le realiza aloferente en los términos del art. 855 del Código de Comercio. Pero, dicha contraoferta, al ser protegida por la condición guardiana, jamás será enviada, ya que el contrato inteligente fue modificado o revocado por el oferente y no corresponde con la prestación inicial que esperaba el destinatario. Por lo cual no seenviará la aceptación al oferente.
Esto resolvería el caso guía dado desde la posición del destinatario. En primer lugar, ya no importaría si el minero organiza esta o la otra transacción antes o después. El destinatario tendría la seguridad que se va a celebrar el contrato bajo los términos bajo los cuales quería obligarse y que en el peor de los casos no perderá su dinero y no quedará atado a un contrato bajo unos términos que no quería.
5.1.2. Plazo implícito
Un plazo implícito permitiría el destinatario saber durante cuánto tiempo el contrato inteligente (oferta) permanecerá inmutable. Se debe considerar este plazo debido a la asimetría de la información entre el oferente y el destinario.
Esto ya que se requiere un alto formalismo y conocimiento para invitar a contratar en línea (mucho más aún dentro del blockchain)52. El oferente es quien tiene toda la información de cómo funcionará el contrato y los algoritmos programados dentro de él. Se puede utilizar "timestamp" como un plazo53 o mejor aún como se puede saber en promedio cuando se añade un bloque al blockchain se puede convertir este dato en una medida de tiempo54. De esta manera, una oferta puede ser válida durante los próximos 7,200 bloques que sería traducido a 24 horas55.
Esto es incluso mandatorio cuando lo vemos bajo la óptica de una relación de consumo. Siendo la parte fuerte del contrato, el oferente ubicado en Colombia, según el artículo 50.b del estatuto del consumidor (Ley 1480 del 2011) tiene la obligación de establecer el plazo de validez de su oferta.
Mientras dure este plazo implícito, la oferta quedaría en firme y no podría ser retiradade manera discrecional57. Dicha seguridad se podría encontrar reforzada con la misma programación del contrato. Ya que, durante, este plazo el destinatario tendría la libertad de aceptarla enviando una transacción al contrato con la seguridad que esta no cambiará y con la posibilidad de celebrarlo si esta aceptación es enviada tempestivamente.
Aunque no es mala solución, sigue estando presente la posibilidad que la oferta se envié tempestivamente, pero que sólo sea agregada al blockchain por los mineros después de que el plazo implícito se venza, dejando al destinatario sin la posibilidad de celebrar el contrato. Esto si bien es una opción por la cual podría optar el legislador y los diferentes reguladores, sólo combate a la problemática indirectamente y sigue sometida parcialmente al caso de referencia.
5.2. Para el Oferente en el primer caso de referencia
5.2.1. Oferta bajo reserva de confirmación
Si un oferente quiere protegerse de las consecuencias indeseadas que le puede traer el blockchain al revocar o modificar su oferta debe programar esta figura. En este caso la transacción del destinatario no implicaría la celebración del contrato, esta quedaría sujeta a que el oferente esté de acuerdo con ella58. De este modo, en una oferta se utilizarían una combinación entre la función selfdestruct (autodestruir) para el retiro de esta y retardar la ejecución del contrato inteligente (en términos jurídicos celebración) para que este pueda modificar dicha propuesta o la acepte definitivamente como destinatario final.
La función selfdestruct es la única manera de remover el código del blockchain59. La utilización de esta función provoca que el contrato se convierta en uno suicida (ocodicioso "greedy")60. Aquello quiere decir que las futuras transacciones de criptomonedas que se dirijan a esa dirección quedarán bloqueadas en el contrato sin ninguna posibilidad de recuperarlas. Al utilizar esta función el dinero que esté almacenado en el contrato puede ser enviada a una cuenta predeterminada por el oferente61.
Además, cómo dijimos, la transacción (orden para autodestruir) que envía eloferente podría llegar después que la transacción-aceptación del destinatario haya sido validada por los mineros y, por lo tanto, el contrato que se quería revocar seríacelebrado. Para resolver estos problemas se necesita demorar la ejecución del contrato inteligente hasta una confirmación posterior por parte del oferente.
El oferente programaría su contrato para que una transacción posterior proveniente de él dé pasó a una modificación o ejecución del contrato. De esta manera el oferente dubitativo puede modificar su oferta o revocar su oferta, sin estar sujeto a un minero que organizaría su transacción, ni a la fuerza vinculatoria de una oferta que se acepta. Así, la transacción posterior del oferente serviría como confirmación para celebrar el contrato y el contrato inteligente sería una simple invitación a ofrecer. El destinatario inicial, en este caso actuaría como proponente final, pero notendría más opción que adherirse a las condiciones que ha propuesto el oferente inicial62.
Tal cual, los problemas planteados en el primer caso de referencia quedarían solucionados al programar una oferta bajo reserva de confirmación. Sin embargo, el destinatario inicial quedaría sometido totalmente a los designios del oferente inicial. Esto puesto que, es su transacción la que termina permitiendo la celebración del contrato. Además, si nos salimos del marco de la buena fe, es posible que el oferente al usar la función de autodestrucción desvíe los fondos que el destinatario ya ha enviado a su propia cuenta sin que se celebre el contrato.
5.3. Para el oferente y para el destinatario en el segundo caso de referencia
Este caso que también parece insondable puede ser fácilmente solucionado si mezclamos el derecho y la tecnología. En este caso tanto el oferente como el destinatario debe programar su oferta y aceptación según lo que dice el artículo 858 del Código de Comercio. Pero ¿Cómo se haría esto?
Solidity permite programar diferentes sentencias de programación como condiciones. Así, es de interés del destinatario programar en su transacción la fecha y hora en la cual se envía su mensaje. Esto con el fin que el oferente pueda verificar cuál es la oferta que primero se le comunica. Para evitar que el destinatario ponga cualquier fecha, se podría usar una librería (un conjunto de algoritmos que tienen como función ser utilizadas por otros programas) que añada la hora actual en la cualse envía el mensaje.
En cambio, el oferente en su contrato tendría que hacer dos cosas. Primero que sucontrato verifique cual es la transacción del destinatario que primero se ha enviado. Si el destinatario no ha integrado esta información a su transacción entonces que se coja el valor del timestamp del bloque al cual fue integrada. Así, se aseguraría que está cumpliendo la ley al celebrar el contrato con la primera persona que le comunicó su aceptación. En un segundo lugar si por alguna razón hay dos o más aceptantes que hicieron esa comunicación al tiempo, deberá hacer divisible la prestación del contrato si se puede o, por ejemplo, si no es divisible como una obra de arte, crear derechos de propiedad sobre la misma y dividirlo en cuotas como sepuede hacer con los NFTS (non-fungible Tokens)63.
Así se programaría el artículo del 858 del Código de Comercio. Satisfaciendo las necesidades jurídicas de los destinatarios, ya que ahora sí dependerá de su diligencia la celebración del contrato inteligente para con ellos.
6. CONCLUSIONES
Hemos desarrollado en el artículo las diferencias en el régimen de la oferta y la aceptación de los contratos electrónicos y los contratos inteligentes embebidos en el blockchain. Encontramos que la falta de una formación instantánea y la intervención de los mineros ajenos al contrato cambiaban las reglas de juego en materia de oferta y aceptación tratándose de los contratos inteligentes embebidos en el blockchain.
Así, trajimos dos casos concretos en los cuales podrían darse problemas en la oferta y la aceptación. Para luego tratar de dar soluciones a través de las diferentes teorías de la formación contractual. Sin embargo, llegamos a conclusiones insatisfactorias, ya que si bien la normativa vigente podía fácilmente solucionar los problemas que presentamos, no resolvía las necesidades jurídicas de los interesados.
Las interpretaciones no nos dieron las soluciones que requeríamos. Por eso, acudimos a mezclar el ordenamiento jurídico con la programación de los contratos inteligentes. De esta manera vimos que el lenguaje jurídico puede ser fácilmente traducido y acoplado al lenguaje de computadora.
Finalmente, como pudimos ver la convergencia del derecho y la tecnología es una mezcolanza nueva pero necesaria. Es cierto que el derecho a veces se basa en prácticas desuetas, pero es deber del abogado acoplar las reglas existentes a las necesidades del hoy. Ya que no son las nuevas realidades las que toman el presente, sino los actores detrás de ellas. Entonces pues actuemos para crear un futuro donde el derecho tenga un papel preponderante como agentes y sabios consejeros del cambio.
NOTAS
3 De Filipi, Primavera; Wright, Aaron. Blockchain and the law: the rule of code Harvard University press, 2018 London, England ISBN: 9780674976429, p. 206.
4 Farshad Ghodoosi, Contracting in the Age of Smart Contracts, 96 Washington Law Review 51(2021), p. 60.
5 Herón de Alejandría (trad. En 1851) pneumatica: La pneumatica de Herón de Alejandría trad. Woodcroft, Bennet al inglés, p. 18.
6 Szabo, Nick Building blocks for digital markets. [en línea] 1996 [fecha de consulta: 27 de agosto de 2021] disponible en: https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html
7 Ibidem.
8 Nakamoto, S. Bitcoin: A peer-to-peer Electronic Cash System. [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://bitcoin.org/bitcoin.pdf
9 De Filipi, Primavera; Wright, Aaron. Blockchain and the law : the rule of code Harvard Universitypress, 2018, London, England ISBN: 9780674976429, p. 37.
10 Butterin Vitalik, Ethereum White Paper: a next generation smart contracts and descentralize dapplication platform [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf.
11 Academy binance [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en https://academy.binance.com/blockchain/what-is-ethereum#ethereum-fundamentals
12 Algunos autores diferencian entre contratos inteligentes y contratos legales inteligentes. Lo que vendrían siendo en nuestro caso las "DAPPS" y los contratos inteligentes. Tur Faúndez, C. (2018). Smart contracts. Análisis jurídico. Madrid: editorial Reus.
13 si su creador incluye una función llamada SELFDESTRUCT en el código, puede "eliminar" el contrato inteligente en el futuro, y reemplazarlo por uno nuevo. Academy binance [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en. https://academy.binance.com/es/blockchain/what-are-smart-contracts
14 Hinestrosa, Fernando Tratado de las obligaciones II, De las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 758.
15 Ospina Fernández G, Ospina Acosta E. Teoría General Del Contrato y Del Negocio Jurídico. 7a. edición actualizada. Editorial Temis; 2019, p. 146.
16 Idem, p. 161.
17 Hinestrosa, Fernando Tratado de las obligaciones II, De las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 759.
18 Silvana Fortich. Una nota sobre formación y formalismo del contrato electrónico. Revista de Derecho Privado (Bogota 1997). 2011; (20), p. 350.
19 Starck, B., Roland, H., & Boyer, L. (n.d.). Droit civil: obligations (2a. ed.). Editions Litec; Librairies Techniques, p.17.
20 CNUDMI Ley modelo de la CNUDMI sobre Comercio Electrónico con la guía para su incorporación al derecho interno 1996. Publicación de las naciones unidas Nueva York, 1999. ISBN: 92-1-333278-5. p. 54.
21 Ibidem.
22 Soto Coaguila, C. (2002). La Contratación Electrónica: Los Supuestos Contratos Informáticos los Contratos Celebrados a Través de Medios Electrónicos. Derecho PUCP, 55, 181-222, p. 32. Es de anotar que la mayoría de los correos no permiten saber el momento en el que se abrió el correo sino si este fue recibido o no. Para esto en esos correos es necesario utilizar programas externos al servidor del correo electrónico.
23 Consejo de Estado, Sección segunda (19 de febrero de 2020) [MP: Sandra Lisset Ibarra Vélez] Lo cual es francamente risible y miope, ya que sólo considera un sistema de información que es el correo electrónico.
24 Fortich Silvana. Una nota sobre formación y formalismo del contrato electrónico. Revista de Derecho Privado (Bogotá 1997). 2011,(20), p. 6.
25 Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 775.
26 Ibidem.
27 Corte Suprema de Justicia, Sala de casación civil (16 de octubre de 1986) Centro Coltejer vs. Otis [MP: Ricardo Uribe Holguín.
28 Decimos que escoja porque se discute cual teoría quiso establecer el legislador frente a la oferta escrita y frente a los diferentes artículos del C.Co. Aunque es de notar que el legislador quiso propender por la teoría de la recepción, pero falló en su tarea. Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 817 || Ospina Fernández G, Ospina Acosta E. Teoría General del Contrato y del Negocio Jurídico. 7a. edición actualizada. Editorial Temis; 2019, p. 170.
29 Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, pp. 823-824.
30 Butterin Vitalik, Ethereum White Paper: a next generation smart contracts and descentralized application platform [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf, p. 8.
31 Loi Luu et al Making smart contracts smarter [en línea] octubre de 2016 [fecha de consulta: 27 de agosto de 2021] disponible en: https://dl.acm.org/doi/abs/10.1145/2976749.2978309, p. 4.
32 Janssen, André, Durovic Mateja the formation of smart contracts and beyond: Shaking the fundamentals of Contract Law? [en línea] 2018 [fecha de consulta: 27 de agosto de 2021] disponible en: https://www.researchgate.net/publication/327732779_The_Formation_of_Smart_Contracts_and_Beyond_Shaking_the_Fundamentals_of_Contract_Law, p. 11.
33 Jaichi Chen et al., why do smart contacts self-destruct? Investigating the self destruct function on Ethereum [en línea] 16 de mayo de 2020 [fecha de consulta: 27 de agosto de 2021] Disponible en: https://www.researchgate.net/publication/327732779_The_Formation_of_Smart_Contracts_and_Beyond_Shaking_the_Fundamentals_of_Contract_Law
34 Janssen, André, Durovic Mateja the formation of smart contracts and beyond: Shaking the fundamentals of Contract Law? [en línea] 2018 [fecha de consulta: 27 de agosto de 2021]. p. 17.
35 Ibidem, p. 12.
36 Loi Luu et al Making smart contracts smarter [en línea] octubre de 2016 [fecha de consulta: 27 de agosto de 2021] disponible en: https://dl.acm.org/doi/abs/10.1145/2976749.2978309 disponible en: https://arxiv.org/abs/2005.07908, p. 2.
37 Ospina Fernández G, Ospina Acosta E. Teoría General Del Contrato y Del Negocio Jurídico. 7a. edición actualizada. Editorial Temis; 2019, p. 164.
38 Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 783.
39 Cook, Victor, Painter Zachary, Peterson Christina, Devchev Damian Read-uncommitted transactions for Smart Contract performance [en línea] 29 de mayo de 2019. Computer Science Department University of Central Florida [fecha de consulta: 27 de agosto de 2021] Disponible en: https://arxiv.org/abs/1905.12351, p. 3.
40 Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 766.
41 Ibidem, p. 815.
42 Ospina Fernández G, Ospina Acosta E. Teoría General Del Contrato y Del Negocio Jurídico. 7a. edición actualizada. Editorial Temis; 2019, pp. 167-169.
43 Ibidem, p. 167.
44 Documentación Ethereum [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://ethereum.org/en/developers/docs/transactions/
45 Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 816.
46 Ospina Fernández G, Ospina Acosta E. Teoría General Del Contrato y Del Negocio Jurídico. 7a. edición actualizada. Editorial Temis; 2019, p. 168.
47 Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 816.
48 Ibidem, pp. 823-824.
49 Ibidem, p. 783.
50 Janssen, André, Durovic Mateja the formation of smart contracts and beyond: Shaking the fundamentals of Contract Law? [en línea] 2018 [fecha de consulta: 27 de agosto de 2021], p. 18, disponible en: https://www.researchgate.net/publication/327732779_The_Formation_of_Smart_Contracts_and_Beyond_Shaking_the_Fundamentals_of_Contract_Law
51 Loi Luu et al Making smart contracts smarter [en línea] octubre de 2016 [fecha de consulta: 21 de febrero de 2021] disponible en: https://dl.acm.org/doi/abs/10.1145/2976749.2978309, pp. 7-8.
52 Ibánez Jiménez, Javier W. Derecho de Blockchain y de la tecnología de registros distribuido Pamplona Thomson Reuters (legal) limited, 2018. ISBN: 978-84-917 7- 916-2, p. 103.
53 También pueden utilizarse grandes cantidades de variables del bloque como "Timestamp", "coinbase", "number", "difficulty" y "gaslimit" los cuales pueden ser utilizados para generar aleatoriedad. Karla, Surkrit; Goel, Seep; Mohan, Dhawan; Sharma, Subbodh zeuz: analyzing safety of smart contracts [en línea] febrero del 2018 [fecha de consulta: 27 de agosto de 2021] disponible en: https://subodhvsharma.github.io/publication/ndss18/
54 Documentación Ethereum [en línea][fecha de consulta: 27 de agosto de 2021] disponible en: https://ethereum.org/en/developers/docs/blocks/ Por ejemplo, en Ethereum un nuevo bloque es añadido cada 15 segundos.
55 Ibidem.
56 Documentación Solidity [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://docs.soliditylang.org/en/v0.8.7/units-and-global-variables.html?highlight=time#time-units
57 Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 789.
58 Ibidem, p. 768.
59 Documentación solidity [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://docs.soliditylang.org/en/v0.8.7/introduction-to-smart-contracts.html
60 Jaichi Chen et al., Defining smart contacts defects on Ethereum [en línea] 17 de Abril de 2020[fecha de consulta: 27 de agosto de 2021] disponible en: https://arxiv.org/abs/1905.0146,7 p. 8.
61 Documentación solidity [en línea][fecha de consulta: 27 de agosto de 2021] disponible en: https://docs.soliditylang.org/en/v0.8.7/introduction-to-smart-contracts.html
62 Hinestrosa, Fernando Tratado de las obligaciones II, De las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482, p. 769.
63 IAMA COIN [en línea][fecha de consulta] disponible en: https://www.iamacoin.com/about.html
7. BIBLIOGRAFÍA
Academy binance [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en https://academy.binance.com/blockchain/what-is-ethereum#ethereum-fundamentals
Academy binance [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en https://academy.binance.com/es/blockchain/what-are-smart-contracts
Butterin Vitalik, Ethereum White Paper: a next generation smart contracts and descentralized application platform [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf
CNUDMI Ley modelo de la CNUDMI sobre Comercio Electrónico con la guía para su incorporación al derecho interno 1996 Publicación de las naciones unidas Nueva York, 1999. ISBN: 92-1-333278-5.
Consejo de estado, sección segunda (19 de febrero de 2020) [MP: Sandra Lisset Ibarra Vélez].
Cook, Victor, Painter Zachary, Peterson Christina, Devchev Damian Read- uncommitted transactions for Smart Contract performance [en línea] 29 de mayo de 2019 Computer Science Department University of Central Florida [fecha de consulta: 27 de agosto de 2021] Disponible en: https://arxiv.org/abs/1905.12351
Corte Suprema de Justicia, sala de casación civil (16 de octubre de 1986) centro coltejer vs. Otis [MP: Ricardo Uribe Holguín].
De Filipi, Primavera; Wright, Aaron. Blockchain and the law: the rule of code Harvard University press, 2018 London, England ISBN: 9780674976429.
Documentación Ethereum [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://ethereum.org/en/developers/docs/transactions/
Documentación Solidity [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://docs.soliditylang.org/en/v0.8.7/units-and-global-variables.html?highlight=time#time-units
Farshad Ghodoosi, Contracting in the Age of Smart Contracts, 96 Washington Law Review 51 (2021).
Herón de Alejandría (trad. En 1851) pneumática: la pneumatica de herón de alejandría trad. Woodcroft, Bennet al inglés.
Hinestrosa, Fernando Tratado de las obligaciones II, de las fuentes de las obligaciones: el negocio jurídico. Vol. I. Bogotá D.C.: Universidad Externado de Colombia, 2017. ISBN: 9789587722482.
IAMA COIN [en línea] [fecha de consulta] disponible en: https://www.iamacoin.com/about.html
Ibánez Jiménez, Javier W. Derecho de Blockchain y de la tecnología de registros distribuido Pamplona Thomson Reuters (legal) limited, 2018. ISBN: 978-849177-916-2.
Jaichi Chen et al, why do smart contacts self-destruct? Investigating the self destruct function on Ethereum [en línea] 16 de mayo de 2020 [fecha de consulta: 27 de agosto de 2021] disponible en: https://arxiv.org/abs/2005.07908
Janssen, André, Durovic Mateja the formation of smart contracts and beyond: Shaking the fundamentals of Contract Law? [en línea] 2018 [fecha de consulta: 27 de agosto de 2021] disponible en: https://www.researchgate.net/publication/327732779_The_Formation_of_Smart_Contracts_and_Beyond_Shaking_the_Fundamentals_of_Contract_Law
Karla, Surkrit; Goel, Seep; Mohan, Dhawan; Sharma, Subbodh zeuz: analyzing safety of smart contracts [en línea] febrero del 2018 [fecha de consulta: 27 de agosto de 2021] disponible en: https://subodhvsharma.github.io/publication/ndss18/
Loi Luu et al Making smart contracts smarter [en línea] octubre de 2016 [fecha de consulta: 27 de agosto de 2021] disponible en: https://dl.acm.org/doi/abs/10.1145/2976749.2978309
Nakamoto, S. Bitcoin: A peer-to-peer Electronic Cash System. [en línea] [fecha de consulta: 27 de agosto de 2021] disponible en: https://bitcoin.org/bitcoin.pdf
Ospina Fernández G, Ospina Acosta E. Teoría General del Contrato y del Negocio Jurídico. 7a. edición actualizada. Editorial Temis; 2019.
Silvana Fortich. Una nota sobre formación y formalismo del contrato electrónico. Revista de Derecho Privado (Bogota 1997). 2011; (20).
Soto Coaguila, C. (2002). La Contratacion Electrónica: Los Supuestos Contratos Informáticos los Contratos Celebrados a Través de Medios Electrónicos. Derecho PUCP, 55, 181-222.
Starck, B., Roland, H., & Boyer, L. (n.d.). Droit civil: obligations (2a. ed.). Editions Litec; Librairies Techniques.
Szabo, Nick Building blocks for digital markets. [en línea] 1996 [fecha de consulta: 27 de Agosto de 2021] disponible en: https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html
Tur Faúndez, C. (2018). Smart contracts. Análisis jurídico. Madrid: editorial Reus.