Smart Contracts: FAQs

Sebastián Heredia Querro

2.1 Algunas definiciones (fans vs. haters) [arriba] 

Entendidos los principales antecedentes, el funcionamiento, las virtudes y las limitaciones del género de tecnologías denominadas DLTs y, especialmente, de su especie más popular, la blockchain, se propone ahora en este segundo Capítulo ahondar en las aplicaciones que más llaman la atención en la denominada Blockchain 2.0: los Smarts Contracts.

Al igual que en el caso de blockchain, abundan las definiciones sobre qué es un Smart Contract. En este primer apartado se pasará revista a las definiciones más importantes –incluyendo especialmente las visiones más críticas–; en el segundo apartado se analizarán las cuatro características esenciales de los Smart Contracts; en el tercero se analizarán casos concretos de aplicación actual, y en el cuarto y último apartado de este Capítulo, se desmitificará a los “contratos inteligentes”, hasta casi demostrar que, en su estado actual de evolución, son más bien Dumb Contracts[1] que sirven para automatizar algunas limitadas funciones, pero no sirven para otras muchas. Pero, no dude el lector que, sin dudas, evolucionarán pari passu a la masificación de la blockchain y a medida que ésta tecnología avance de la niñez hacia la madurez, a partir de 2025 en adelante.

Se empezará por el inicio, y así como el inicio de blockchain es asociado al icónico y desconocido Satoshi Nakamoto, los Smart Contracts son linkeados directamente a un paper de Nick Szabo subido en 1997 en su blog[2], aunque se ha afirmado que la relevencia práctica de los Smart Contracts era muy limitada hasta que surgió Bitcoin[3]. Szabo tiene dos títulos, Licenciado en Computación y Abogado, de allí que pueda vincular con mucha fluidez la Tecnología y el Derecho[4].
En la mente de Szabo, los Smart Contracts eran esto:

“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. A canonical real-life example, which we might consider to be the primitive ancestor of Smart Contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and via a simple mechanism, which makes a freshman computer science problem in design with finite automata, dispense change and product according to the displayed price. The vending machine is a contract with bearer: anybody with coins can participate in an exchange with the vendor. The lockbox and other security mechanisms protect the stored coins and contents from attackers, sufficiently to allow profitable deployment of vending machines in a wide variety of areas. 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 enforced form, and provide much better observation and verification where proactive measures must fall short.” (el resaltado es mío) [5]

Y, acercándose a una definición, Szabo conceptualizaba los Smart Contracts a través de su función:

“Smart Contracts combine protocols, users interfaces, and promises expressed via those interfaces, to formalize and secure relationships over public networks[6]”

y los definía como:

“a computerised transaction protocol that executes the terms of a contract”[7] [y como] “a set of promises, specified in digital form, within which the parties perform on these promises.”[8]

Ahora bien, la doctrina más contemporánea ha criticado fuertemente a Szabo y su definición. En efecto, la Profesora Eliza Mik, de la prestigiosa Singapore Management University sostiene que muchos Smart Contracts no son, en realidad, contratos en un sentido legal[9], reinando mucha confusión en la materia[10], y afirma que lo único que en realidad sí son, es un programa que se ejecuta en la blockchain. Es más, sostiene Mik que las publicaciones de Szabo contienen muchos errores, y que es necesario distinguir entre Smart Contracts en sentido tecnológico, y Smart Contracts en sentido legal, debiéndose aceptar que ésta última definición –más amplia– puede incluir a aquélla –más escueta–[11].

Específicamente, Mik critica incluso el ejemplo de Szabo de la vending machine como antepasado de los Smart Contracts, cuando en realidad sólo es una oferta para contratar, dirigida a público indeterminado, y la máquina en sí automatiza la formación y el cumplimiento del contrato cuando el co-contratante inserta una moneda. Pero lo mismo puede decirse hoy de todos los e-commerce, o de Amazon, o de cualquier caso de venta digital, como Spotify o Netflix. Así, sostiene Mik que el solo hecho de que la lógica de negocio se programe dentro de un software o hardware determinado no convierte ipso facto a dicho hardware o software en un contrato. Ni una máquina dispensadora ni un website son contratos, solo entregan bienes (o autorizan el acceso) en caso de haberse pagado por ello. Automatizar una transacción, o ciertas partes de la misma, no implica que exista un contrato, ni vuelve a la transacción per se inteligente[12].

Desde esta percepción crítica, se afirma vigorosamente que los contratos inteligentes no son ni contratos, ni son inteligentes, y que además no resuelven los verdaderos problemas de la vida real, por varias razones: (i) al ser un programa, deben ser escritos en alguno de los lenguajes que se usan, principalmente, Solidity para Ethereum[13]; (ii) la gente normal no entiende ni conoce sobre lenguajes de programación y no puede verificar que el script efectivamente dice lo que tiene que decir; (iii) al desplegarse en una blockchain, estos programas –que no son contratos– no pueden frenarse ni revertirse, debido a la inmutabilidad de la blockchain; (iv) ningún software está libre del riesgo de errores de programación –bugs– y (v) muchos términos contractuales simplemente no pueden ser codificados en líneas de código[14].

Con una misma visión crítica, se ha sostenido que si bien es cierto que los actores con muchos recursos generalmente obtienen generalmente mejores resultados en Tribunales que los pequeños actores –generalmente más pobres[15]–, es harto discutible que los Smart Contracts per se tengan realmente tanto poder de transformación genuino, ya que los contratos inteligentes se enfocan demasiado en las medidas preventivas de seguridad, ex ante, y no tanto en las correctivas, ex post, y ello no resuelve todo el problema, del mismo modo que el cierre centralizado de puertas y las alarmas de un auto no vuelven innecesaria la necesidad de presencia y persecución policial cuando el robo del auto tiene lugar[16]. En este sentido, críticamente se ha afirmado que los Smart Contracts, por su inherente limitación de ser un programa, no pueden capturar las complejidades sociales que rodean a la costumbre de contratar, y de hecho su inflexibilidad puede ser indeseada[17].

De otro costado, es interesante el enfoque de Rohr[18], quien se refiere a los contratos inteligentes como:

“a computer protocol (code) that is stored on a blockchain (or distributed ledger) and which will be automatically executed by the nodes on the blockchain’s network upon the occurrence of specified conditions. Although they can be, Smart Contracts are not necessarily legal contracts. Because of blockchain’s immutability, Smart Contracts that have been uploaded to the blockchain take on a life of their own: they cannot be unilaterally stopped, delayed, or modified absent a fundamental change to the protocol of the blockchain on which the code resides or an “out” that was incorporated into the code from the outset ” (el resaltado es mío)

Es también interesante el enfoque de Arcari[19], quien los define como programas representados por código electrónico, instalado y que corre en una blockchain, y que permite el intercambio de dinero, propiedades, acciones, u otro tipo de contraprestaciones entre las partes. Desde el punto de vista legal, Arcari sostiene que los contratos inteligentes son acuerdos automatizados, que hacen depender el cumplimiento del contrato sobre el acaecimiento o no de ciertas condiciones objetivas, predeterminadas en el código de programación de los mismos, de acuerdo a lo pactado en un contrato.

Ahora bien, se ha afirmado que los enamorados de los Smart Contracts se confunden al no reconocer las importantes diferencias legales entre execution y enforcement, que podríamos traducir como cumplimiento voluntario y cumplimiento forzado del contrato[20]. Hoy por hoy miles de contratos se cumplen voluntariamente, de manera automatizada, especialmente en la industria financiera. Ahora bien, la novedad de los contratos inteligentes bajo estudio, es que las partes podrán “programar” el cumplimiento forzado, de modo tal que el co-contratante se desprende ex ante de su decisión de cumplir o no cumplir un contrato válidamente celebrado, y cede dicha facultad-deber-obligación a una blockchain. Y esto último, “automatizar el cumplimiento forzado”, es bastante distinto a “automatizar el cumplimiento voluntario”.

Por otro lado, con una visión menos crítica, se ha definido a los contratos inteligentes como el código de un programa de computación que automatiza la verificación, la ejecución y el cumplimiento de ciertos términos y condiciones de un contrato[21]. También se los define como software autónomo, que permite que un registro distribuido funcione como una computadora distribuida, de modo tal que el mismo algoritmo de consenso que verifica que cada nodo tenga la misma copia del registro, le permite al nodo realizar tareas idénticas computadas en un mismo orden[22].

Es también interesante la visión de Raskin[23], que por su parte los define como contratos cuya ejecución se ha automatizado mediante una o más computadoras, con la intención de asegurar su cumplimiento sin tener que recurrir a los Tribunales ante el incunmplimiento, y por ende, eliminando la discrecionalidad humana respecto a su (in)cumplimiento. Estos contratos “controlan” el activo físico o digital que constituye su objeto y sobre los cuales se predica el cumplimiento contractual. Raskin propone diferenciar entre contratos inteligentes fuertes y débiles: (i) en los fuertes, el costo de revocar o modificar el Smart Contract es prohibitivo; y (ii) en los segundos –débiles– sucede lo contrario. Ergo, si un Tribunal puede modificar un Smart Contract luego de que ha sido cumplido con facilidad, entonces es un contrato inteligente débil, y no difieren en su esencia de un contrato convencional. Ahora bien, si el costo de modificar un contrato inteligente ya cumplido es muy alto, entonces estamos frente a un contrato inteligente fuerte, y esto si es novedoso para el Derecho.

La prestigiosa American Bar Association también se ha ocupado de los contratos inteligentes en estos términos:

“Smart Contracting is a disruptive advancement that will have far-reaching impact for many industries, including financial services, government, real estate, manufacturing, and healthcare. For example, in securities trading, it currently takes several days to transfer assets, thereby increasing counterparty risk. Smart Contracts that use blockchain technology could shorten settlement times and mitigate such risk. In the insurance industry, certain policy agreements could be automated. A Smart Contract for travel insurance can be automatically triggered once a flight is cancelled. Once the cancellation is posted, the Smart Contract makes a payment directly to the policyholder, thereby bypassing the claims process. Governments may use Smart Contracts to manage title recordings, social services, and e-voting. In manufacturing, Smart Contracts may replace current supply-chain processes such as bills of lading, proof of origin, or quality control. Another interesting application is tying Smart Contracts to the Internet of Things (i.e., cars, appliances, and devices). For example, a washing machine may contain a sensor indicating when it is low on detergent and then automatically reorder it (…) as Smart Contract technology evolves, it will surely disrupt many industries (…) It is only a matter of time before the technology is fully implemented. Lawyers can play an active role by staying abreast of changes that may affect their clients. Transactional lawyers may wish to learn more about the technical aspects of their future “Smart Contract” to ensure that it aligns with their client’s wishes and goals. In the future, litigation attorneys may no longer be litigating the “four-corners” of the contract, but rather expanding into the intent of the code.”[24](el resaltado es mío)

Desde un punto de vista más tecnológico, y menos legalista, Vitalik Buterin, creador de Ethereum, los define como:

“Cryptographic "boxes" that contain value and only unlock it if certain conditions are met[25]”

Y también como:

“Ethereum is a decentralized platform that runs Smart Contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference. These apps run on a custom built blockchain, an enormously powerful shared global infrastructure that can move value around and represent the ownership of property. This enables developers to create markets, store registries of debts or promises, move funds in accordance with instructions given long in the past (like a will or a futures contract) and many other things that have not been invented yet, all without a middle man or counterparty risk.”[26] (el resaltado es mío)

Gideon Greenspan, también un referente en el ecosistema Blockchain, fundador de de MultiChain[27], define a los Smart Contracts como:

“…a piece of code that is stored on an blockchain, triggered by blockchain transactions and which reads and writes data in that blockchain’s database. That’s it. Really. A Smart Contract is just a fancy name for code that runs on a blockchain, and interacts with that blockchain’s state. And what is the code? It’s Pascal, it’s Python, it’s PHP. It’s Java, it’s Fortran, it’s C++. If we’re talking databases, it’s stored procedures written in an extension of SQL.”[28] (el resaltado es mío)

A su turno, los prestigiosos –y muy citados– Profesores Wright y De Filippi[29] los definen como:

“Digital, computable contracts where the performance and enforcement of contractual conditions occur automatically, without the need for human intervention. In some cases, Smart Contracts represent the implementation of a contractual agreement, whose legal provisions have been formalized into source code. Contracting parties can thus structure their relationships more efficiently, in a self-executing manner and without the ambiguity of words. Reliance on source code enables willing parties to model contractual performance and simulate the agreement’s performance before execution. In other cases, Smart Contracts introduce new codified relationships that are both defined and automatically enforced by code, but which are not linked to any underlying contractual rights or obligations.[30]”(el resaltado me pertenece)

Wright y De Filippi afirman también que los programadores creen que los Smart Contracts pueden facilitar la comunicación entre máquinas y la creación de organizaciones decentralizadas[31].

Por su parte, O’Shields[32] los define como:

“Smart Contracts are self-executing electronic instructions drafted in computer code. This allows a computer to “read” the contract and, in many cases, effectuate the instruction—hence the “smartness” of the contract. Smart Contracts self-execute the stipulations of an agreement when predetermined conditions are triggered. The parties “sign” the Smart Contract using cryptographic security and deploy it to a distributed ledger, or blockchain. When the conditions in the code are met, the program triggers the required action. Smart Contracts are a step beyond typical electronic contracts in that the actual agreement is embodied in computer code, rather than English or another traditional language.”

O’ Shields también aclara que variaciones de los Smart Contracts, tales como sistemas que procesan transacciones y efectúan pagos diarios computarizados entre entidades financieras, existen desde hace décadas[33].

Quizás con la máxima claridad posible, Clack, Bakshi y Braine[34] los definen como:

“A Smart Contract is an automatable and enforceable agreement. Automatable by computer, although some parts may require human input and control. Enforceable either by legal enforcement of rights and obligations or via tamper-proof execution of computer code.”

En uno de los primeros trabajos que abordó la temática de los Smart Contracts desde la óptica de los Abogados, Samuel Bourque y Sara Fung Ling Tsui los conceptualizaron del siguiente modo:

“Simply put, a Smart Contract is a self-executing contract. To wit, SCs are just like traditional paper contracts drafted in natural human language only that SCs specifically are drafted electronically in a computer interpretable language. The important effect is that the computer system that interprets the SC can execute some of the terms of the contract.”[35]

Koulu[36], por su parte, los define como:

“A Smart Contract is an automated software program built on a blockchain protocol; basically Smart Contracts are made possible by general-purpose computation that takes place “on” the blockchain. They can be used for allocating digital currency between two parties, when the requirements established in the program/contract are fulfilled. In short, Smart Contracts are programmable contractual tools, they are contracts embedded in software code. Thus, a Smart Contract can include the contractual arrangement itself, governance of the preconditions necessary for the contractual obligations to take place and the actual execution of the contract. To say that Smart Contracts are self-enforceable means that the software executes the contract, e.g. allocates digital assets autonomously and regardless of trust between the parties. Receiving a payment for sold goods is then no longer dependent on the willingness of the debtor to make the payment nor affected by bankruptcy proceedings that take place after entering the contract. The contract executes its content autonomously according to the embedded contract terms e.g. the digital assets placed within the contract are allocated by the software and no external monitoring of contractual obligations or enforcement is needed.” (El resaltado es mío)

Otra definición conceptualiza a los Smart Contracts como código de computación auto-ejecutable que procesa automáticamente sus inputs cuando son activados, cuya propuesta de valor es su cumplimiento automático[37]. Se trata de aplicaciones de segundo nivel que corren en la blockchain, y al igual que ésta, una vez desplegados no pueden ser modificados, salvo que hayan sido programados con tal característica.

Kaal y Calcaterra, a su turno, definen y ejemplifican los Smart Contracts del siguiente modo[38]:

“Smart Contracts and smart property are blockchain enabled computer protocols that verify, facilitate, monitor, and enforce the negotiation and performance of a contract. An often-cited example for Smart Contracts is the purchase of music through Apple’s iTunes platform. A computer code ensures that the “purchaser” can only listen to the music file on a limited number of Apple devices.”

A nivel institucional, hay conceptualizaciones muy pertinentes. Por caso, la prestigiosa Chamber of Digital Commerce de EE.UU[39] define a los Smart Contracts como “un código de computadora que, dado el acaecimiento de una o unas condiciones especificadas, es capaz de auto-ejecutarse automáticamente según una serie de funciones predeterminadas. El código se puede almacenar y ejecutar en un registro distribuido y puede dejar registrado en éste cualquier cambio resultante”. Se afirma también que un Smart Contract no es necesariamente un contrato en el sentido legal, sino más bien una forma avanzada de instrucciones condicionales del tipo “Si ocurre X, entonces Y” escrito en código de computadoras.

La Universidad de Yeshiva, por su parte, cuenta con un muy interesante y prestigioso proyecto dedicado al estudio de la blockchain, llamado Cardozo Blockchain Project, que también ha definido a los Smart Contracts:

“Because blockchains store tamper resilient, transparent, and non-repudiable data, the technology is being used for far more than just maintaining records of digital currency transactions. Indeed, blockchains are storing or referencing, other forms of information; blockchain-based protocols are layering additional technology to process what can essentially be thought of as small computer programs—what technologists often refer to as “Smart Contracts”(…) are being used to memorialize a portion of a parties’ agreement, with a Smart Contract assisting with one or more performance obligations and traditional legal prose memorializing other basic contractual rights, obligations, and conditions—such as representations and warranties and choice of law and dispute resolution provisions. These “hybrid” agreements blend together traditional legal prose—written in a natural language like English—with Smart Contract programs written in code. The written agreement references and incorporates a Smart Contract and contextualizes how the program fits into a larger contractual arrangement.[40]” (el resaltado es mío)

En Europa, por otra parte, el flamante Observatorio y Foro de Blockchain de la Unión Europea también se ha ocupado de los Smart Contracts, y los ha definido, en el contexto de blockchain, como código de computación que está almacenado en una cadena de bloques y que puede ser accedido por una o mas partes[41]. Se afirma que los Smart Contracts no son generalmente contratos en un sentido legal, y que pueden ser usados para cosas muy interesantes, como tokenizaciones; para codificar y automatizar procesos de negocio que puedan ser compartidos entre múltiples partes, generando reducción de costos y ganancias de eficiencias; o para codificar contratos entre partes en relación a la transferencia de valor o determinados activos –tales como escrow agreements, o contratos con cláusula de pago contra entrega–, de un modo transparente, y con ejecución automática basada en determinadas condiciones, dificultando o imposibilitando el incumplimiento de la contraparte[42].

Finalmente, en Argentina, Santiago Mora los ha definido como un contrato eletrónico con la característica distintiva de que él mismo hace cumplir sus propios términos, por lo que habitualmente estará lleno de instrucciones y condiciones propias del código informático que siguen un patrón típico de “si esto ocurre, haz esto; pero si no ocurre, haz esto otro”, y una vez iniciada la ejecución, las partes dejan de tener control sobre su cumplimiento[43]. Otra definición es la dada por Mirassou Canseco y Hadad, que los definen como como programas informáticos que facilitan, aseguran, hacen cumplir y ejecutan acuerdos registrados entre dos o más partes (personas físicas o jurídicas). Son algoritmos que operan con la característica principal de no poder ser controlados por ninguna de las partes y de ser autoejecutables, es decir, su ejecución se encuentra automatizada[44].

A continuación, una imagen de cómo “se ve” un Smart Contract:

Imagen 9: Smart Contract Town Crier

Imagen 10: Smart Contract Buterin

2.1.1 Clasificación de los contratos inteligentes

Se presentan, a los fines didácticos de este Manual, tres clasificaciones. Una es la que nos da el Observatorio y Foro de Blockchain de la Unión Europea, que propone analizar esta nueva realidad “contractual” dividiéndola en dos: (i) Smart Legal Contracts: que son contratos inteligentes en una cadena de bloques que representan o emulan un contrato en el sentido legal del término; y (ii) Smart Contracts con Implicancias Legales: construcciones o artefactos basados en nuevas tecnologías que claramente tienen implicancias legales[45].

Los Smart Legal Contracts implican que, en una legislación dada, éstos contratos son legalmente válidos por cumplir los requisitos que se exigen a cualquier contrato[46]. Puntualmente respecto a la forma escrita de los contratos, la cuestión que se presenta es si el lenguaje computable –que no es lenguaje natural– puede ser considerado un lenguaje apto para configurar la creación de derechos y obligaciones, teniendo en cuenta que los contratos formales son sólo aquéllos a los cuales la ley les impone una forma determinada[47]. Por otro lado, en caso que el contrato inteligente haya sido celebrado por adhesión, incluyendo por medios electrónicos o similares[48], la parte predisponente debe redactar el contrato de modo claro, completo y fácilmente legible[49], y se tienen por no escritas las cláusulas que por su redacción o presentación, no son razonablemente previsibles[50]. ¿El lenguaje computable –una instrucción– es fácilmente legible?¿Su forma de redacción permite razonablemente preveer el efecto que producirá?

Por otro lado, señala el Observatorio y Foro de Blockchain de la Unión Europea que los Smart Contracts con Implicancias Legales son aquellos programados para: (i) representar activos de forma digital[51]; (ii) crear DAOs[52]; y/o (iii) actuar como agentes decentralizados[53] (se volverá sobre las DAOs más abajo en § 2.6).

Otro criterio de clasifición interesante es el propuesto por Samuel Bourque y Sara Fung Ling Tsui, que los divide entre contratos inteligentes suaves o puros, dependiendo de: (i) el nivel de automatización de la ejecución contractual[54]; (ii) el grado de separación que exista entre los términos acordados en el contrato convencional subyacente y los términos codificados en algún lenguaje computable[55]; y (iii) dónde reside el código del contrato inteligente, y su grado de “discreción” para ejecutar la instrucción, sin interferencia de las partes[56].

En los Smart Contracts puros, el propio código programado es el contrato, y esto solo ha sido posible con el surgimiento de Bitcoin y la blockchain, ya que el contrato ahora efectivamente puede controlar criptomonedas. Por todo ello, sostienen los autores citados que las características esenciales de los Smart Contracts puros son: (a) mayor transparencia sobre los términos contractuales y su ejecución; (b) la separación entre la ejecución del contrato y la voluntad de las partes; y (c) la automatización de las obligaciones del contrato.
Finalmente, un tercer criterio[57] de clasificación de contratos inteligentes, los divide en:

1. Contrato inteligente en sentido operacional: se refiere a software que normalmente es utilizado en DLTs. La palabra contrato hace referencia a que este software cumple obligaciones o ejerce derechos, pudiendo para ello controlar ciertos activos dentro del DLT; y

2. Contrato inteligente en sentido legal: se refiere a cómo un contrato convencional puede ser expresado y ejecutado mediante uso de software. Aquí se vinculan aspectos operacionales, pero también aspectos vinculados a cómo se escriben los contratos convencionales, y cómo deben interpretarse. En esta clasificación se inscriben desarrollos como la integración dual[58] y los contratos Ricardianos[59], que se verán más abajo.
 
2.1.2 Naturaleza jurídica de los contratos inteligentes

Las teorías sobre la naturaleza jurídica de un contrato inteligente incluyen las siguientes posturas: (i) es un fideicomiso[60]; (ii) es un representante de las partes[61]; o (iii) es una persona jurídica –véase más abajo, en § 2.6–[62]; o (iv) es un contrato en sentido legal convencional.

Específicamente con relación a la blockchain, los Smart Contracts y los trusts del common law, se ha sostenido[63] que pueden constituirse fideicomisos on-chain que operen mediante Smart Contracts. En efecto, la American Bar Association propone:

“DL technology and Smart Contracts have the potential to be used in trust creation and estate administration. The division of assets in an estate could potentially be cryptographically and securely coded into the blockchain which, upon the passing of the testator and the registration of the death certificate, the terms of the will or trust could self-execute to disburse the assets. The piloted service Blockchain Apparatus advertises the potential to administer and execute will documents without human involvement, even allowing for revisions of the documents, which are stored in their own original state, to preserve the right to amend. Although blockchain is unable to remove all the legal disputes around the creation of a will, such as issues regarding ambiguous terms and claims that the testator was under duress, it has the potential to streamline and expedite the estate administration process and ‘make it much easier for a genuine will to be upheld, for a bogus challenge to be dismissed, and for courts to come to factual findings much more quickly’.The need for wills and estate lawyers will likely endure, as they are required to draft and encode these legal documents. However, the digitisation of the industry and the increasing use of pre-drafted will templates may put pressure on these practitioners to become technologically literate in order to remain relevant and competitive.” (el resaltado es mío)

Siguiendo el criterio del Observatorio y Foro de Blockchain de la Unión Europea antes expuesto, puede afirmarse que la naturaleza jurídica de los contratos inteligentes permite diferenciar entre los Smart Legal Contracts, que son (o pueden ser) contratos, según la definición legal de cada legislación implicada, y, pueden (o no) ser legalmente válidos como cualquier contrato si cumplen los requisitos que se les exigen a todos los contratos.

Pero, como se verá más abajo, existen otros Smart Contracts con Implicancias Legales, que son aquellos programados para representar activos de forma digital, o crear DAOs, o actuar como agentes decentralizados.

La naturaleza jurídica de estos contratos inteligentes con Implicancias Legales puede ampliamente exceder la calificación de un mero contrato, para asumir o combinarse con otras formas jurídicas mucho más complejas, como contratos multilaterales de organización que en un futuro próximo podrán (o no) ser personificados por la ley, con capacidad para, de modo autónomo o con alguna supervisión humana, ejercer derechos, contraer obligaciones y actuar en beneficio de sus representados en un entorno digital y on-chain.

2.1.3 Contratos inteligentes y el ejericio de la profesión de Abogado

¿Se requiere el asesoramiento profesional de un Abogado para negociar un contrato inteligente?¿Es conveniente?¿Es necesario?¿Es posible?

Bourque y Tsui se pronuncian, sin hesitar, por la afirmativa y sostienen que el ejercicio de la profesión de abogado debe ser ampliado para incluir, por mandato legal, el asesoramiento en la redacción de contratos inteligentes[64].

2.1.4 Smart Contracts vs. Computable Contracts

En 2012, Harry Surden, profesor de Derecho en las Universidades de Stanford y Colorado publicó un muy célebre artículo, al que tituló Computable Contracts[65], en el que analizaba cómo y para qué las empresas “codifican” ciertas obligaciones contractuales como datos computables. Describió y rotuló tal práctica como contratación orientada a datos, muy utilizada en contratos financieros –e.g. contratos de opción sobre acciones– que se representan como registros de datos con una finalidad expresa de ser luego procesados por computadoras –recordar la definición de Buterin sobre Smart Contracts.

La claridad envidiable de Surden justifica detenernos a analizar en profundidad sus ideas.

2.1.4.1  Términos contractuales computables

Las empresas saben (o debieran saber) que administrar contratos es un proceso costoso, que requiere mucho talento humano. Contratar es un proceso compuesto de varios (costosos) pasos: determinación de cuál contrato utilizar, negociarlo, firmarlo, monitorear su cumplimiento, analizar su impacto en materia de precios y suministros, e integrar toda esa información en unidades funcionales como la cadena de suministros, y convertirlo en insumo informativo para la toma de decisiones[66].

Especialmente los contrato comerciales, involucran obligaciones de acuerdo a términos y condiciones pactados, cuyo cumplimiento es (o debiera ser) supervisado de manera contínua. Supervisión ésta que cuesta dinero. Y, lógicamente, mientras más grande la red contractual de una empresa, más costoso verificar su cumplimiento, mayores costos de transacción. Para abaratar tal centro de costos, se recurre cada vez más a la tecnología.

Ahora bien, sin traer a colación los (hiper) importantes desarrollos en materia de Inteligencia Artificial aplicada al lenguaje natural y a la administración contractual que han tenido lugar entre 2012 y 2020[67], Surden señalaba en 2012 que muchos afirmaban que la tecnología no podía aún automatizar la supervisión y el compliance contractual, entendido éste proceso como un iter de dos tramos: (i) entender qué se pactó[68] y bajo qué condiciones y luego (ii) comparar lo que se pactó con lo que ocurrió (o no) finalmente[69]. Tal afirmación del año 2012 se justificaba, por un lado, en las (grandes) limitaciones para entender el lenguaje humano y natural por parte de los algoritmos (que existían en 2012)[70]. Por otro lado, para analizar el cumplimiento contractual, comparando los hechos ocurridos contra las palabras preexistentes, deben superarse otras limitaciones. En efecto, los contratos frecuentemente contienen términos de textura abierta, para tener cierta flexibilidad de cara a acontecimientos futuros e inciertos[71]. Las personas reaccionan de un modo humano ante términos adrede abiertos, que las computadoras pueden no entender, ya que son complejos procesos cognitivos y, de nuevo, humanos.

No obstante dichas dificultades, Surden afirmaba que ciertas obligaciones contractuales se pueden representar en un lenguaje que no es lenguaje natural, sino un lenguaje que las máquinas pueden procesar y entender. Machine-readable, computer data. Este enfoque de Surden propone y afirma el auge de los contracts-as-data[72], y señala que se emplean mucho en el mundo de las finanzas, e.g. contratos derivados sobre moneda extranjera, para que puedan ser procesados por sistemas electrónicos de financial trading. En estos casos, tanto las obligaciones contractuales como la información necesaria para cumplir la obligación está disponible en machine-readable format, con lo cual un software puede comparar lo prometido vs. lo ocurrido.

Así, los contratos que permiten esa puntual mejora tecnlógica, son los Computable Contracts de Surden, quien los denomina también como data-oriented contracts, aquellos en los que las partes han expresado una porción[73] de sus términos y condiciones como datos procesables por una computadora, para que ésta pueda controlar su cumplimiento posterior. Evidentemente, el concepto es muy similar al de Smart Contracts según se vio más arriba, pero no tiene en cuenta el complemento de la cadena de bloques[74].

2.1.4.2 Limitaciones de los data-oriented contracts

Poder expresar términos contractuales como datos computables abre un campo nuevo para las habilidades contractuales de los Abogados.

En efecto, los data-oriented contracts no se expresan igual que los contratos convencionales: aquéllos tienen términos y condiciones expresados como registros de datos estructurados, y éstos los expresan con lenguaje escrito y natural. Sin embargo, en los data-oriented contracts, no toda cláusula es computable, pero algunas cláusulas han sido pensadas para ser “leídas” por computadoras[75], lo que los diferencia, a su vez, de los contratos electrónicos, que no tienen éste tipo de cláusulas, y solo son un medio digital para expresar el lenguaje natural o humano[76].

Ahora bien, traducir ciertos términos legales a machine-readable format en forma de instrucciones de computación requiere estructurar los datos de un modo que, ciertamente, no admite que todo tipo de cláusulas se “traduzca” al lenguaje de la máquina, que es un lenguaje matemático[77]. Pero los contratos pueden ser diseñados ab initio con esta intención, con un enfoque orientado a datos, donde las “opciones lingüísticas” son menores que las existentes en el lenguaje natural, y están pensadas para ser entendidas por una computadora.

Pero no sólo hay que traducir cláusulas en datos legibles para el lenguaje de la máquina, sino que hay que darles un sentido a esos datos, para que la máquina entienda qué significan[78] y ejecute la instrucción que corresponda. Las partes contratantes recurren para ello a (i) data-meaning agreements[79], a (ii) estándares generalmente aceptados sobre el significado de ciertos datos, muy frecuentes y comunes en el ámbito de las finanzas[80] y (iii) a procedural agreements que disponen cómo convertir expresiones contractuales en data-oriented expressions[81].

2.1.4.3 Otras limitaciones y beneficios

Los contratos que requieran un cierto grado de abstracción conceptual, o grados amplios de flexibilidad ex post facto para analizar hechos –o sus impactos–, o estén sujetos a determinaciones de profesionales expertos, o tengan intrínsecamente un alto grado de incertidumbre, no serán fácilmente computables[82]. Sin embargo, en los casos en que sí sea posible computar contratos, los beneficios serán una reducción de los costos de transacción[83] y, en mayor medida, la contratación machine-to-machine[84].

2.1.5 La visión de Samuel Bourque

Así como el trabajo de Surden en 2012 ha sido sin dudas pionero, lo mismo puede decirse sobre Samuel Bourque, que comenzó a analizar los contratos inteligentes en 2014. Bourque se preguntaba en aquél momento si era necesario ser Abogado para asesorar en materia de contratos inteligentes, o si un contrato inteligente puede ser considerado una persona en sentido legal, o si es necesario regularlos. Interesantes preguntas que comienzan a tener respuesta (parcial) recién en 2020. Por ello, nos detendremos en analizar la visión de este programador y abogado que vive en Hong Kong.

Bourque ha afirmado que el Derecho no ha visto muchos cambios tecnológicos, y que en general, los sistemas legales no compiten entre sí, salvo en materia de arbitraje institucional y de forum shopping. Por otro lado, ha señalado acertadamente que desde y gracias al surgimiento de Internet, la tecnología ha evolucionado encapsulada, un poco al margen del Derecho, porque los programadores normalmente ignoran el Derecho.
Con relación a los Smart Contracts, Bourque señala que no son un concepto nuevo, pero al asociarse y vincularse con criptomonedas, comienzan a desarrollarse sin tener que recurrir a los bancos, que nunca serían partes de Smart Contracts programados por particulares.

Según Bourque, los Smart Contracts son una nueva plataforma para el desarrollo de aplicaciones para transacciones complejas[85]. Los clasifica en (i) suaves (Amazon, Apple, mercados de futuros): son contratos tipo take it or leave it, donde una parte –e.g. Amazon– ejecuta todas las obligaciones e incluye referencias a T&Cs contenidos en otros lugares, que pueden modificarse sin que se modifique el contrato inteligente suave, que sólo ejecuta una parte de las obligaciones que está programada para ser automatizada; o (ii) puros: que son la segunda generación de contratos inteligentes que la blockchain 2.0 permite.

Bourque aclara, con razón, que un Smart Contract no es necesariamente un contrato en sentido legal. Un Smart Contract es una plataforma de desarrollo, y lo desarrollado en ella puede no cumplir con los requisitos de un contrato. Un Smart Contract es más bien una instrucción, o una serie de instrucciones condicionales, escritas en el lenguaje de programación en una plataforma que permite ejecutar las instrucciones. Precisa, además, que con relación al cumplimiento contractual, todo lo que puede ser hecho on line, puede ser “tercerizado” a un Smart Contract. Y con el desarrollo de la IoT y la Smart Property, se pueden vincular con el mundo off-line.

Sostiene Bourque que hay muchos beneficios por desarrollar Smart Contracts puros:

i. menos ambigüedad, por la necesidad del lenguaje de programación;

ii. más claridad en sus términos, ya que el contrato es el código y el código es el contrato;

iii. pre-verificable: el compilador detecta si hay un error de sintaxis, con lo cual se puede chequear el contrato antes de iniciarlo;

iv. predecible: se puede simular y se puede testear fuera del mundo real;

v. eficiencia: permite automatizar procesos;

vi. privacidad: se puede encriptar;

vii. más barato: usar el sistema de justicia convencional para reclamar incumplimientos contractuales es caro, pero desarrollar un Smart Contract tampoco es gratis; y

viii. independencia: Amazon puede tener un conflicto de interés en inclinar los T&Cs a su favor; en cambio en los Smart Contracts, hay una plataforma, quizás Ethereum, que cumple los términos del contrato, así como su ejecución, de manera imparcial y agnóstica.

Señala que también hay importantes problemas vinculados a los Smart Contracts:

i. cuestiones de lenguaje: poca gente puede leer el lenguaje de programación;

ii. sofisticado: no es sólo el lenguaje, sino también la forma de pensar, orientada a los detalles; programar requiere mucho detalle y entendimiento;

iii. tedioso;

iv. la infraestructura tecnológica: no todo está digitalizado y eso puede frenar el desarrollo de los contratos inteligentes;

v. resistencia de sistemas precedentes –legacy systems–: habrá que modificar leyes para que algunas transacciones sean 100% digitalizadas;

vi. vinculación tecnológica: ejemplifica el autor citado que si quieres escribir un Smart Contract sobre una stock option, tenés que recurrir a información de terceros, y si esta información es incorrecta, el contrato no funcionará bien.

Señala Bourque los siguientes atributos de los contratos inteligentes:

Privacidad: esta es una característica esencial. Se pueden encriptar, hashear, y es fácil darles privacidad. Además, hay una sola versión del contrato, alojada en la plataforma de que se trate.

Firmas: con la tecnología de Public Key Infraestructure (PKI), hay una llave pública y una privada, y si las juntas podés identificar a la persona. La identidad PKI puede ser uni-direccional o bi-direccional. Uni-direccional: desde el contrato per se, no se puede saber quién es la parte contratante, salvo que se dé a conocer, aparezca y utilice la llave privada correspondiente. Bi-direccional: la parte es identificable y verificable. Cada contrato puede ser programado uni o bi-direccional.

Custodia: un Smart Contract tiene su propia identidad, su propia billetera (llave pública), su propia firma, o puede estar sujeto a múltiples firmas de terceros –es lo más parecido a una cuenta corriente que gira a la orden conjunta de dos o más partes– para operar o ejecutar acciones o disponer de activos digitales, y puede tener acceso a determinados derechos o a activos digitales. Quien ejecuta el contrato es la plataforma donde está programado, i.e. Ethereum, que es como si fuera un tercero invisible que es parte del contrato.

Cláusulas off-line: hay cláusulas de un contrato convencional que no son derechos ni obligaciones, por ejemplo: preámbulo, antecedentes, ley aplicable, forma de resolución de conflictos, cláusulas de non-disclosure o non-competition. Pero la resolución de conflictos se puede programar dentro del contrato, para que, por ejemplo, congele los fondos hasta tanto la disputa sea resuelta, o un árbitro decida quién tiene razón.

Pseudo-anonimidad: la identidad en blockchain es la llave pública, pero nadie sabe a quién corresponde. Sin embargo, el caso Silk Road ejemplifica que es posible vincular la llave pública con una persona concreta si se quiere hacerlo.

En cuanto al funcionamiento de un contrato inteligente per se, Bourque lo asimilaba al de un web service: permite escuchar eventos (vía Oráculos), verificar si una parte tiene derecho a disponer determinados activos (on-chain y off-chain), ejecutar acciones según se requiera, automatizarlas, responder a preguntas de las partes, ser revisado, modificado, terminado, o borrado, si las partes acuerdan tal flexibilidad futura al momento de programarlo.

Señala Bourque que lo nuevo y disruptivo es que se combinan, por un lado, el contrato, sus términos y, por otro, la ejecución del contrato, en un único lenguaje, y la ejecución, a su vez, depende o se confía a una tercera parte: la blockchain donde corre. Además, los términos del código, o del contrato, son transparentes, están a la vista de todos.

Ya en 2014 Bourque también adelantaba conceptos sobre DAOs y DACs, que se analizan más abajo. Las definía como organizaciones donde el gobierno interno está automatizado por muchos contratos inteligentes. Es el Corporate Governance 2.0. Es una red de contratos, que puede ser programada para que sea autónoma. Pueden ser o no registradas en una jurisdicción determinada, o en una jurisdicción amigable. Pero no está implícito que deban estar registradas. Pueden emular el funcionamiento societario, o no[86].

2.2. Cuatro pilares fundamentales de los Smart Contracts [arriba] 

Siguiendo a Szabo, y dejando atrás la (fundada) polémica existente en punto a la naturaleza y utilidad actual o futura de los contratos inteligentes, se pueden apreciar y analíticamente separar cuatro pilares fundamentales que rodean o enmarcan la realidad de los contratos inteligentes.

2.2.1. Observabilidad: el regreso de la Pitonisa (reloaded) y los Oráculos

El término observabilidad hace referencia a la aptitud de las partes de un contrato inteligente –o de un tercero por ellas designado– de poder observar recíprocamente el cumplimiento de la prestación a su cargo, i.e. de poder verificar que el cumplimiento de la prestación se ajusta a los términos pactados[87]. Para facilitar este proceso de observación, es que aparece entonces el concepto de los Oráculos.

Los Oráculos pueden definirse como un programa de computación que opera de manera separada al código de un Smart Contract, y que recopila o tiene acceso a información off-chain, es decir, que no se encuentra en la blockchain, y la ponen a disposición del Smart Contract, para confirmar si las partes han cumplido lo pactado, o no[88]. Evidentemente, el rol de los Oráculos es clave, puesto que si la información que entregan no es correcta o fidedigna, el Smart Contract no funcionará del modo que la intención común de las partes lo quiso.

Los Oráculos deben ser per se confiables. Así, existen data feeds que son, en sí mismos, Smart Contracts que interactúan con otros Smart Contracts, proveyendo simplemente información determinada[89]. En este sentido, se ha sostenido que el Oráculo en alguna medida empuja la información externa hacia dentro de la blockchain –en lugar de un Smart Contract tirando la información hacia adentro de la blockchain[90]– y, obviamente, se asume que serán muy confiables, pero al ser un recurso que está captando datos de afuera de la blockchain, se afecta el carácter decentralizado de la cadena.

Mik define a los Oráculos como entidades que cuentan con la infraestructura técnica necesaria para comunicar a los Smart Contracts cierta información que refiere a hechos ocurridos afuera de la blockchain[91]. Enseña Mik que los Oráculos no “insertan” la información de manera directa en la blockchain, sino que “firman”, con su llave privada, un Smart Contract que produce que un token –objeto del Smart Contract– se transfiera con algún destino preestablecido, si un hecho externo off-chain X efectivamente ocurrió. Subraya también las grandes dificultades que existen en la materia: (i) es difícil conseguir Oráculos confiables[92], (ii) es difícil conseguir fuentes externas fiables de datos, (iii) los dos aspectos anteriores ponen en duda la propia seguridad ofrecida por una blockchain, al recurrir a elementos off-chain que no gozan de los atributos de seguridad de una blockchain, y (iv) muchos hechos externos a la cadena de bloques no pueden representarse en machine-readable format[93].

Buterin[94], por su parte, describe el funcionamiento de los Oráculos del siguiente modo:

“Essentially, instead of a long-running contract being run directly on the blockchain, all funds that are intended to go into the contract would instead go into an M-of-N multisig address controlled by a set of specialized entities called “oracles”, and the contract code would be simultaneously sent to all of these entities. Every time someone wants to send a message to the contract, they would send the message to the oracles. The oracles would run the code, and if the code execution leads to a withdrawal from the contract to some particular address then the oracles circulate a transaction sending the funds and sign it.” (el resaltado es mío)

Werbach, finalmente, afirma:

“Oracles can also be humans. Consider a simple Smart Contract in which each of the parties has a private key and a third key is given to an expert arbitrator. The Smart Contract requires two of three keys in order to execute. If the parties agree the contract has been fully performed, they each provide their key and the Smart Contract executes. If there is a dispute, they turn to the arbitrator. She either provides her key along with that of the party seeking to enforce the contract or refuses it and therefore prevents completion of the transaction. This system mimics a legal arbitration process.” (el resaltado me pertenece)

Para finalizar, se trae a colación un caso muy interesante de diseño de un Oráculo implementado por SWIFT[95] recientemente[96], con el objetivo de proveer de información off-chain a los Smart Contracts de varias redes, que permitirán hacer pagos y liberar garantías en más de 11.000 bancos que forman parte de SWIFT[97].

2.2.2 Verificabilidad

La verificabilidad implica la posibilidad real de cualquiera de las partes involucradas en un Smart Contract –o de un tercero árbitro, en su caso– de poder demostrar ante un tercero (o que éste pueda corroborar) que el contrato se cumplió, o que no se cumplió[98].

Este atributo, según Szabo, es muy propio de los contratos inteligentes ya que es necesario que un tercero verifique el cumplimiento (o su falta); algo que en los contratos convencionales es determinado sólo por las partes. Igualmente, es quizás el elemento más complejo de los contratos inteligentes, ya que también se vincula con la prueba de identidad de las partes on-chain, ya que el árbitro debe conocer la identidad de las partes para poder resolver conflictos eventuales.

Siguiendo a Arcari en este punto[99], la verificabilidad tiene dos aspectos: (i) acceso abierto a la información para el árbitro; y (ii) que las partes cumplan con la obligación de proveer esa información al árbitro –o que acuerden qué Oráculo será utilizado, si es que existe uno que sea adecuado según la naturaleza del Smart Contract. La presencia de este árbitro implica el nacimiento de una nueva e interesante rama del Derecho, y ya comienzan a ofrecerse estos servicios por parte de estudios jurídicos en todo el mundo[100], recomendándose la utilidad de diseñar en cada contrato inteligente una cláusula de verificabilidad, similar a una cláusula de resolución de controversias en un contrato convencional. El arbitrador suele ser un abogado, y se afirma que:

“Smart Contract arbitration still offers efficiency for Smart Contract parties despite the human influence, particularly its speed and flexibility. Arbitration often takes a fraction of the time a court case and additionally arbitration’s flexibility provides a neutral venue to enable parties to efficiently resolve disputes, wherever they are located.”[101]

Finalmente, Arcari afirma que un árbitro necesita dos tipos de información para resolver: (i) información referida a datos que están fuera de la blockchain –quizás mediante Oráculos– y (ii) una versión del contrato inteligente en lenguaje natural, de modo tal que pueda entender cuál fue la intención de las partes al codificarlo[102]. Según la materia sobre la cual verse el código del Smart Contract, puede que no existan Oráculos disponibles, y que la información pertinente deba entonces ser provista por las partes del contrato al árbitro, lo que debe estar previsto en el contrato por el cual se acordó automatizar ciertas partes de la relación contractual mediante su codificación.

2.2.3 Privacidad (efecto relativo 2.0 +/- identidad +/- confidencialidad +/- anonimidad)

En el ámbito de los contratos inteligentes, la privacidad implica que sólo las partes contratantes (i) controlan, (ii) conocen y (iii) se benefician por la ejecución del contrato en una blockchain. La tercer característica antes mencionada, es una característica que comparten los contratos inteligentes con todos los contratos convencionales, y que se sintetiza en el conocido adagio latino, norma general del derecho de los contratos: res inter alios acta, aliis nec prodesse, nec nocere potest, también conocido como el principio del efecto relativo de los contratos[103].

Ahora bien, evidentemente, las otras dos notas características de privacidad en los Smart Contracts tienen que ser precisadas, ya que se vinculan intrínsecamente con el control y con la confidencialidad, y también con las particulares formas de identidad –anonimidad y pseudonimidad– que la blockchain permite.

En blockchain, la privacidad se consigue de tres modos[104]: (i) operando anónimamente, utilizando por ejemplo tecnologías de Zero Knowledge Proof (ZKPs[105]); (ii) encriptando la información; y (iii) no alojando información sensible en una blockchain, sino en canales paralelos off-chain[106].

Seguidamente se presentarán los aspectos vinculados al control de privacidad del contrato y la confidencialidad. En § 2.2.3.1 siguiente se analizará la problemática de la anonimidad y la pseudonimia en blockchain.

Con relación al control de privacidad del contrato, Arcari propone entender gráficamente la privacidad en Smart Contracts como si fuera una muralla alrededor del contrato, con un único acceso, y donde las partes tienen la posibilidad de abrir la reja y permitir que terceros, en ciertas condiciones, ingresen al contrato –i.e., Oráculos, árbitros[107] al otorgárseles una llave privada. En este sentido, en materia de contratación inteligente efectivamente las partes controlan el contrato, y pueden decidir dar o permitir acceso al mismo a terceros, y de hecho en la mayoría de los Smart Contracts, han sido programados de modo tal de permitir dicho acceso a una serie de partes autorizadas. Imagine, lector, que el Smart Contract es un Google Docs: se pueden otorgar distintos permisos a otros usuarios.

Ahora bien, hay otra particularidad: el código del contrato es públicamente visible por todos –si corre en una blokchain pública como Ethereum, por supuesto– y, por ende, el contrato per se no es ni será nunca confidencial[108]; las partes no son las únicas que lo conocen toda vez que una blockchain pública es, justamente, pública, y todos pueden ver a las partes involucradas (i.e., sus llaves públicas) y las cantidades de tokens, altcoins[109], bitcons o Ethers transferidas entre ellas desde que el contrato se inició. Lo anterior no impide que los Smart Contracts pueden ser ab initio programados de modo tal de requerir autorización para que terceros extraños no puedan acceder a ninguna otra información que contengan[110].

2.2.3.1 Anonimidad y pseudonimidad en la blockchain: encriptado asimétrico y On-Chain Analytics

Existe una creencia general equivocada, que sostiene que Bitcoin, Ethereum, NEM y tantas otras blockchains son anónimas e intraceables. Nada más alejado de la realidad. Todas las blockchains permiten justamente dejar un registro –ver una trazabilidad total de las transacciones, con sus fechas y montos–, y asociar tales transacciones a las llaves públicas entre las cuales tuvieron lugar –éstas no son necesariamente conocidas por todo el mundo[111]. Por tanto, es técnicamente más correcto hablar de pseudonimidad[112].

Los desarrollos de encriptado asimétrico no son nuevos, y son una característica esencial de todas las blockchains públicas. Es la tecnología que permite que la identidad real de un usuario de blockchain sea protegida, del mismo modo que se protegen los números de una tarjeta de crédito cuando se hace una compra online a través de una línea no segura[113]. En la criptografía de llave pública, un vendedor on line tiene dos números, muy largos, uno es una llave pública –todo el mundo puede verla–, y el otro es una llave privada –secreta–; parecen ser números aleatorios, pero no lo son: son elegidos cuidadosamente de modo tal que cualquier mensaje pueda ser encriptado y desencriptado con dos operaciones muy simples[114].

En el caso de Bitcoin, por ejemplo, se dice que las identidades de sus dueños están protegidas[115], porque las direcciones que registran la tenencia de los bitcoins están criptográficamente protegidas –mediante un algoritmo llamado ECDSA[116]– con una llave pública, y sin su correspondiente y única llave privada[117], es absolutamente imposible mover, transferir o disponer de los bitcoins “aparcados” en la llave pública del usuario. Así, el tenedor de una llave privada no necesita entregar información personal –i.e. su identidad– para demostrar que realmente posee las bitcoins “registradas” o “asociadas” a una determinada llave pública[118].

Ahora bien, existen múltiples formas de asociar una llave pública a una identidad real, de hecho hay empresas que ofrecen estos servicios[119]. Y también se ofrecen servicios en la dirección contraria, buscando dificultar que se asocien identidades a llaves públicas[120]. También es posible crear una llave pública para cada transacción, de modo tal de dificultar que se extraigan patrones entre llaves públicas que puedan permitir conocer la identidad real del usuario[121].

En efecto, existe ya un nuevo sector de negocios, que puede denominarse On-Chain Analytics, que extrae conocimiento de los distintos datos públicos registrados en una blockchain, previo procesamiento[122]. Las empresas que operan en este nuevo sector, toman información vinculada a los detalles de cada bloque (sello de tiempo, pago de comisiones y black rewards a mineros, direcciones, usuarios), de cada transacción (direcciones entre las que se hicieron, cantidades, cuánto tiempo retuvieron las criptomonedas –UTXO data[123]–, etc.), y los Smart Contracts utilizados, y de allí extraen patrones de quién, cómo y cuándo utiliza criptomonedas.

Cada día, distintas propuestas de soluciones tecnológicas se van desarrollando –siempre siguiendo a Arcari– que permiten seguir avanzando en la disciplina y en las novedosas cuestiones vinculadas a la privacidad en blockchain, tecnología ésta que recién transita por su infancia.

En efecto, por un lado, la confidencialidad puede “fortalecerse” con técnicas de encriptación on-chain, tales como Key Definition Functions (KDF) o protocolos de Confidential Transaction (CT)[124]. También se han propuesto nuevas formas de “camuflar” a los Smart Contracts y de ofrecer transactional privacy [125].

2.2.3.1.1 Llave pública y billeteras digitales – Wallets

Útil es recordar cómo se ve una llave pública o dirección en una blockchain:

Imagen 1: llave pública

Muy vinculado a las llaves públicas (y privadas), está el concepto de las billeteras digitales o wallets[126].

Las wallets son un programa de software que almacena llaves públicas y llaves privadas, y que interactúan con varias blockchains –Bitcoin, Ethereum, NEM, etc.–, permitiendo a los dueños de las wallets enviar y recibir criptomonedas y ver el balance diario de criptomonedas en su/s llave/s pública/s –i.e. en sus direcciones, si se prefiere

Es importante entender que una e-wallet no funciona como una billetera en el sentido tradicional y off-chain. En efecto, la wallet per se no contiene criptomonedas; sólo contiene la/s llave/s pública/s y privada/s de una persona. Cuando una persona envía a otra bitcoins o cualquier otra criptomoneda, lo que en realidad hace es (i) firmar una transferencia “dominial” de dichas monedas a favor de la dirección –llave pública– de una wallet de otra persona, y (ii) quien las recibe, para poder gastarlas –i.e., transferirlas nuevamente– debe a su turno ingresar –i.e. firmar– con su llave privada, que está criptográficamente asociada a su llave pública contenida en la wallet, la que también le permite ver el saldo de todas sus tenencias.

Generalmente las billeteras pueden ser un software, un hardware, o simplemente un papel a donde están anotadas la llave pública y privada de una persona.

Cuando la billetera es un software, pueden funcionar como un software para computadoras de escritorio, y sólo pueden accederse desde la computadora en la cual se descargaron. También pueden funcionar como una aplicación móvil, que se descarga y se utiliza desde el teléfono. O pueden ser wallets online, alojadas en la nube, y accesibles desde cualquier dispositivo[127].

Cuando la billetera es un hardware, la llave privada es almacenada normalmente en un pen drive, con lo cual la llave privada está en un “depósito off line”.

Cualquiera sea el tipo de wallet empleado, si uno pierde la llave privada[128] –o se hace pública–, no hay forma de recuperar las criptomonedas[129] o de frenar su uso indebido. Recordar que el dominio de un criptoactivo se acredita y se ejercita sólo con la llave privada criptográficamente asociada a una llave pública que, según la blockchain de que se trate, tiene asociado el criptoactivo, por tanto, la llave privada no es una contraseña común y cualquiera y su pérdida (o robo) puede causar un daño irreparable[130].

Ahora bien, una persona humana (o jurídica) puede tener cuantas direcciones –i.e., llaves privadas– quiera, y en esas direcciones tener criptomonedas que son en sí totalmente trazables[131], pero como se adelantó, no es fácil asociar la llave pública a una identidad real[132]. Ahora bien, una vez que se asocia una llave pública a una identidad real, tampoco hay forma alguna de borrar el historial de transacciones, con lo cual se puede saber el origen (lícito o ilícito) de esas transferencias[133]. Y esto es, también, revolucionario. Por tomar Bitcoin, permite auditar el camino inverso de transacciones de un modo que es, precisamente, inmutable, aunque no necesariamente implica llegar, en todos los casos, al destinatario final[134].

Una de las formas de trackear la actividad en Bitcoin es mediante el clustering, que consiste en mirar de cerca la actividad en una blockchain aplicando Machine Learning, y de tal modo intentar detectar cuentas que parecen ser de una misma wallet, por ende, controladas por una sola persona o entidad[135]. La prestigiosa MIT Technology Review lo pone en estos términos:

“Multiple addresses initiating the same transaction might begin to look like one person or organization consolidating smaller funds into one bigger pot, for example. Another telltale sign is when change from a Bitcoin transaction is routed back into an account different from the one where the funds started off. In time, the chaos resolves itself into regular patterns. Once multiple accounts have been linked to the same owner, you can try to figure out who that owner is. Linking Bitcoin accounts to real-world identities is possible because information tends to leak out. Regulated cryptocurrency exchanges—generally those in the US or Europe—must follow know-your-customer and anti-money-laundering rules, which require people to hand over identification before using their services.”[136] (el resaltado me pertenece) 

Como síntesis de los varios asuntos vinculados a la privacidad en los Smart Contracts, a medida que nuevas tecnologías –tales como las ya analizadas ZKPs– y nuevos servicios –como Zcash[137] o Monero[138]– se empleen para potenciar o proteger la privacidad, el clustering será menos eficiente. Pero también serán cada vez más supervisados –y eventualmente sancionados– los actores vinculados al ecosistema blockchain que no cumplan con las normas de KYC y AML, como ilustra el caso del Exchange ruso BTC-e[139].

2.2.4 Ejecutabilidad (o cumplimiento forzoso o automatizado).

La última característica que Szabo señalaba como propia y fundacional de los Smart Contracts es su enforceability, que podría traducirse como su cumplimiento forzoso[140], o automático, o mejor dicho, automatizable[141], como la lógica consecuencia que deriva de iniciar un contrato inteligente en una blockchain: lo programado –sea lo que sea– se auto-ejecutará, sin ninguna intervención de la contraparte, y sin poder revertirse la operación debido a la inmutabilidad de la blockchain, salvo que el programa haya sido escrito previendo formas de reversión.

Lo expuesto, a su turno, se vincula con un problema también propio, pero más amplio, vinculado a los contratos inteligentes: la consecuente posibilidad (real o no) de demandar jurisdiccionalmente la nulidad[142] de una obligación codificada en una cadena de bloques, ejecutada mediante un contrato inteligente que no es reversible.

En un sentido más amplio, se ha sostenido que un contrato inteligente puede funcionar mal por razones inherentes al código del contrato o a la plataforma en la que está siendo ejecutado, o, inversamente, puede haber funcionado adecuadamente bien, pero ciertas razones o causas extrañas al contrato y a la plataforma hacen que exista un incumplimiento contractual[143]. En este sentido, el incumplimiento o el cumplimiento defectuoso de una obligación contractual automatizada puede habilitar para la parte perjudicada medios tradicionales –i.e. jurisdicción común, o de excepción, arbitraje– o medios no tradicionales, que pueden ser incluso nativos en una plataforma dada[144], como son los casos de Aragon y OpenBazaar que más abajo se analizan[145].

Ahora bien, en términos más analíticos y también más polémicos, la ejecutabilidad de un contrato inteligente dispara otros muchos interrogantes jurídicos: ¿los Smart Contracts son contratos para la Ley?¿Se necesita el dictado específico de una ley que los califique legalmente como un contrato[146]?¿Es (o será) posible demandar judicialmente su nulidad, o su incumplimiento esencial[147], o daños y perjuicios con título, causa u origen en un cumplimiento que se aparta de lo pactado?

A su vez, cuando haya consumidores involucrados, ¿un Smart Contract puede ser considerado un contrato celebrado fuera del establecimiento comercial[148], o celebrado a distancia y sujeto a la facultad de revocación del consumidor[149]? ¿Iniciar un contrato inteligente en una blockchain equivaldrá a una celebración por escrito de un contrato[150]? En tal caso, ¿deberían los proveedores de servicios digitales informar a los consumidores que los Smart Contracts son –generalmente– irreversibles[151]?¿Quién asume el riesgo de un error en la codificación, como ocurrió con TheDAO?

Todos estos interrogantes serán respondidos más adelante en el Capítulo siguiente, pero reténgase aquí que el rasgo esencial de los Smart Contracts –quizas su mayor atractivo– es la imposibilidad técnica de incumplirlos, toda vez que el código de un Smart Contract se ejecuta de manera autónoma una vez iniciado, y salvo que se haya previsto desde su diseño la posibilidad de detenerlo, se auto-ejecutará por si mismo en la blockchain[152].
 
2.3. Usos actuales de Smart Contracts. Smart Contracts híbridos [arriba] 

El Cardozo Blockchain Project señala[153] que existen dos grandes campos de uso de los contratos inteligentes.

Por una lado, se los utiliza para transacciones simples, donde las partes confían y delegan enteramente el cumplimiento en Smart Contracts, sin ni siquiera celebrar un contrato convencional. Así, el código del programa regula la relación comercial en todas sus partes, incluyendo pagos, transferencia de activos, y términos y condiciones asociados. Ejemplos actuales de este uso novedoso de los de Smart Contracts son Ujo Music[154], OpenBazaar[155] y SafeMarket[156].

Por otro lado, los Smart Contracts también se pueden utilizar para codificar una parte de las obligaciones contractuales de una parte –las que se puedan automatizar[157]–, mientras que otras obligaciones se mantienen en la esfera convencional tradicional[158] –i.e., declaraciones y garantías, ley aplicable, y procedimientos para resolver controversias–[159]. Se trata de Smart Contracts híbridos, en los que el contrato convencional expresamente hace referencia al Smart Contract y contextualiza cómo esa porción de obligaciones se incrusta dentro de un acuerdo comercial más amplio[160].

En estos Smart Contracts híbridos, las partes voluntariamente elijen delegar el cumplimiento de una parte de sus obligaciones en un programa de computación que se auto-ejecuta de manera decentralizada en una blockchain.

Si hubiera un conflicto, las partes podrán siempre renegociar/ajustar el contrato convencional subyacente, o, si es posible, buscar la forma tecnológica de revertir los efectos del Smart Contract autónomo. Sin embargo, la dificultad asociada a ésta última situación puede ser justamente lo que las inclinó ab initio a utilizar un contrato inteligente e irreversible, que (i) libera a las partes de la carga de supervisar el cumplimiento de la contraprestación; y (ii) se ejecutará siempre, si se cumplen las condiciones programadas. Incluso, las partes pueden haber programado al contrato inteligente de modo tal que, recurriendo a Oráculos, modifique o se adapte[161] a una serie de opciones de cumplimiento programado, de acuerdo a la variación de condiciones exógenas al contrato inteligente, pudiéndose incluso recurrir a datos tomados o informados por sensores con IoT, o IIoT, etc[162].

Naturalmente, la tecnología permite testear el código de un Smart Contract –así como cualquier tipo de software puede ser testeado[163]– antes de ejecutarlo en una blockchain, de modo de verificar que se ejecuta tal como fue acordado por las partes.
Evidentemente, cada vez que una empresa explore la posibilidad de celebrar Smart Contracts híbridos, sus abogados deberán necesariamente involucrarse en el asunto, y trabajar cabeza a cabeza con el equipo de programación, para asegurar que el código refleje lo pactado en el contrato convencional subyacente[164].

2.4. Desmitificando a los Smart Contracts [arriba] 

Ahora bien, analizadas las definiciones de los Smart Contracts, y planteadas sus principales características y vistos algunos usos actuales, luce conveniente ahora situarlos en la complejidad del mundo real, y desmitificarlos[165].

2.4.1 Creación de tokens vs. transferencia de tokens vía Smart Contracts

Como regla general, los Smart Contracts sirven sólo para transferir tokens, o criptomonedas. Los Smart Contracts no crean nuevos tokens[166]. Cuando se dice que un Smart Contract se auto-ejecutará, lo que se quiere decir en realidad es que transferirá los tokens que controle, si ocurren determinadas condiciones pre-establecidas, y a favor de determinada llave pública pre-establecida[167].

2.4.2 Codificación deficiente o inexacta de un Smart Contract

Como todo software, un Smart Contract está sujeto al riesgo de codificación deficiente o inexacta. Codificación deficiente hace referencia a la existencia de errores de programación en el código de un Smart Contract, llamados informalmente bugs.

Si un contrato inteligente tiene un error de codificación, se ejecutará mal, de modo tal que la auto-ejecución no garantiza el cumplimiento perfecto de la prestación codificada[168]. Es prácticamente imposible garantizar que un código de programación no tendrá bugs, con lo cual es importante auditar el código y probar su funcionamiento antes de desplegarlo en la vida real. Las partes contratantes debieran dejar previsto “cláusulas de escape” para corregir los eventuales bugs que aparezcan, de lo contrario, la parte perjudicada debiera acudir a la Justicia para solicitar la reparación de los perjuicios causados[169]. Se volverá sobre esto en el Capítulo siguiente.

Por otro lado, la codificación puede no contener errores, sino ser inexacta, en el sentido de no reflejar adecuadamente la intención de las partes que lo utilizan.

El programador –o la empresa de programación– contratado para escribir el código de un Smart Contract puede no entender cabalmente la intención de las partes, actuando con negligencia o quizás dolosamente. A menos que las partes sean programadores y puedan ellos mismos verificar qué dice el código, deberán recurrir al servicio de terceros para corroborar que el código refleja lo que las partes quisieron que reflejara[170]. Además, es prácticamente imposible codificar de manera anticipada todos los futuros escenarios posibles, lo que impone aceptar que un contrato inteligente pensado adrede para durar en el tiempo no podrá probablemente adaptarse a (todas) las nuevas circunstancias imprevistas.

Pues bien, debe aceptarse entonces que los errores de codificación son harto frecuentes y prácticamente inevitables[171]. Sin embargo, existen mecanismos para detectarlos: herramientas de análisis estático que pueden detectar patrones conocidos de errores, y herramientas de verificación formal, que permiten garantizar que un contrato inteligente se comportará de modo correcto[172]. Por otro lado, existen herramientas para realizar ingeniería inversa en los Smart Contracts, que permiten auditar el código fuente de un contrato inteligente[173].

2.4.3 Traducción del lenguaje natural: sus limitaciones

Normalmente, las partes que decidan implementar un contrato inteligente para automatizar determinados aspectos de su relación, delinearán el alcance y características que el contrato inteligente deberá tener y cumplir en un documento escrito precedente, en lenguaje natural, que luego debe ser “traducido” al lenguaje que procesan las computadoras[174].

Eliza Mik señala, con razón, que este proceso de “traducción” desde el lenguaje natural al lenguaje de programación –source code– que utilice el contrato inteligente es harto complejo y suele ser subestimado. Es un proceso manual, donde la supervisión del empleo y el significado de los términos legales por parte de abogados es absolutamente crucial.

Por otro lado, la terminología legal sigue siendo un tipo de lenguaje natural calificado, que no es tan fácilmente codificable, y que requiere de una interpretación previo a su codificación[175]. Normalmente, lo que ocurre es que los Tribunales interpretan[176] los contratos ex post, cuando surge el conflicto y se judicializa. Por tanto, los programadores que codifican Smart Contracts requieren el acompañamiento de Abogados, quienes deben ex ante explicar los efectos de los conceptos jurídicos involucrados, prestando atención al contexto en el cual los conceptos jurídicos se utilizan[177] y teniendo en cuenta la ambigüedad de las palabras.

No obstante lo anterior, Koulu[178] sostiene que los contratos inteligentes operan con una lógica similar a la de los contratos convencionales, en el sentido que es siempre necesaria la intención común de las partes para vincularse, y en los Smart Contracts esto suele ocurrir cuando las partes “transfieren” tokens o criptomonedas al Smart Contract. Incluso acuña un término que puede ser interesante explorar: Legal Programming.

2.4.4 Codificación directa de obligaciones contractuales

Es posible también que las partes no celebren un documento precedente delineando el alcance del futuro contrato inteligente, sino que elijan directamente codificar sus obligaciones[179], para eliminar los riesgos asociados a la codificación del lenguaje natural y/o la ambigüedad de las palabras.

Esto implica asumir que los Abogados aprendan a programar, o que los programadores aprendan Derecho, lo que seguramente ocurrirá en el futuro, pero no es una realidad cotidiana en el presente. Lo que sí puede hacerse en el momento presente es redactar contratos teniendo en cuenta que serán (o que podrían ser), en alguna de sus partes, susceptibles de codificarse con Smart Contracts[180]. Surden, según se analizó más arriba, denominaba esta práctica data-oriented contracts.

Mik afirma, con razón, que la ambigüedad de las palabras en sentido legal no es necesariamente un defecto inadmisible, tal como los programadores lo consideran[181]. En efecto, si bien la ambigüedad puede generar conflictos eventuales respecto al alcance de las obligaciones de las partes, también permite cierto grado de flexibilidad, y adaptarse a nuevas circunstancias imprevistas, y de hecho, muchas cláusulas contractuales son redactadas con términos amplios, a propósito. En la terminología contractual muchas veces se debe balancear la certeza de las palabras contra la adaptabilidad del contrato, especialmente cuando los contratos son de largo plazo, y con mucha razón protesta Mik cuando afirma que los contratos inteligentes pueden requerir formalizar lo informal, o cuantificar lo cualitativo[182]. Menuda tarea.

Por otro lado, es prácticamente imposible prever en un contrato convencional absolutamente todos los escenarios futuros posibles, y lo mismo se predica de un contrato inteligente. Para prever todas las opciones posibles, éstas deben codificarse, lo que implica largas líneas de código y la creciente posibilidad de cometer un error en la codificación.

Para finalizar, Mik también señala que no toda obligación es codificable. Cierto tipo de obligaciones, en su esencia, no son susceptibles de codificarse ni de automatizarse ya que requieren el ejercicio del juicio humano[183], mientras que otras, más manuales, sí lo serán.

2.4.5 Criminal Smart Contracts

Desmitificar a los contratos inteligentes implica también señalar que existen quienes creen que los Smart Contracts pueden ser o serán utilizados para el mal, configurando verdaderos Criminal Smart Contracts[184].

Blockchain en sí, especialmente Bitcoin, también ha sido utilizada para monetizar actividad legal, a través de ransomware[185], o para pagar la adquisición de bienes ilegales[186], y para el lavado de dinero[187]. Ahora bien, a medida que la utilización de Smart Contracts se masifique, se ha señalado que también podrían ser técnicamente programados para cometer actos ilícitos, como por ejemplo, robar llaves privadas, filtrar documentos confidenciales, y retribuir delitos por encargo[188].

En este sentido, puede tomarse el caso de Darkleaks[189] que sirve como un mercado descentralizado para la filtración pública y anónima de secretos que van desde películas, secretos comerciales, código fuente de software, diseños industriales, etc.[190].

Siguiendo a Juels, es posible hoy programar contratos inteligentes malos para solicitar el robo de una llave privada que corresponde a una llave pública, o lo que es lo mismo, la llave de la bóveda que aloja criptoactivos, utilizando técnicas como el zk-SNARKs[191]. Esto implica, lógicamente, que los contratos inteligentes buenos hoy ya deben ser programados previendo esta posibilidad cierta de ataque.

Como primera medida de seguridad, se ha intentando recurrir a “listas negras”[192] de monedas –que se sabe que fueron robadas–. En esta misma línea, en Agosto de 2019 el Departamento del Tesoro de EE. UU ha publicado llaves públicas de Bitcoin que pertenecían a presuntos narcotraficantes[193]. Como segunda medida, Juels propone crear un sistema en el cual un conjunto de entidades a ser designadas sean facultadas para remover criminal Smart Contracts de la blockchain, sin requerir que sus usuarios se identifiquen, aunque también reconoce que la posibilidad técnica de poder implementar un sistema así es una cuestión aún abierta[194].

2.4.6 Problemas para la ejecución judicial de Smart Contracts

Finalmente, para el caso que el Smart Contract no funcione, no opere, o no se ejecute totalmente[195] tal y como se pensó que lo haría, las partes “programantes” quizás deban recurrir al servicio de administración de justicia convencional, asumiendo que conocen las identidades de (todas) las partes contratantes. Se ha sostenido que una forma de darle “ejecutoriedad legal” a un Smart Contract es incluir en él una referencia al contrato off-chain, y viceversa, práctica denominada integración dual[196]. En éste sentido, véanse las propuestas de valor de CommonAccord[197] y Legal Markdown[198].

Sin embargo, es evidente que la tutela jurisdiccional tendrá un limitado alcance en la materia[199]. Alguna doctrina sostiene que deberán aplicarse a los incumplimientos de Smart Contracts (sic) –asumiendo que ello sea posible dada su ejecución automática[200]– los mismos principios y reglas que se aplican a los incumplimientos contractuales convencionales[201]. En este particular, sería computacionalmente imposible afectar o modificar retroactivamente una transacción ya ejecutada vía Smart Contract, ya que el programa está desplegado en una blockchain, con lo cual el único remedio posible –si se conoce la identidad de las partes– sería ordenar judicialmente la programación de un nuevo contrato inteligente reverso[202].

Otros sostienen que dado el carácter territorial de la jurisdicción, sería imposible poder demandar a la contraparte en un Smart Contract decentralizado, salvo que algún “operador”[203] de la red permita identificarlo[204], o que se pueda identificar al “creador” de una blockchain[205].

Además, no serían menores las dificultades de un Tribunal a la hora de interpretar un contrato inteligente, escrito en un lenguaje de programación normalmente desconocido para un Juez, y más allá de las pericias técnicas que se puedan disponer a pedido de parte o como medidas para mejor proveer para intentar descifrar qué dice el código de un contrato inteligente[206]. Innegablemente, el código de programación del Smart Contract, cualquiera sea el lenguaje utilizado, deberá ser traducido a lenguaje natural para que los Jueces puedan entenderlos[207].

2.5 Juez competente, ley aplicable y resolución de controversias en un entorno de blockchain-based Smart Contracting [arriba] 

Además de las (grandes) limitaciones técnicas para codificar obligaciones, de los casi inevitables errores de codificación asociados al arte de programar, de la necesidad de tener que recurrir a los Oráculos para obtener información off-chain, y de, incluso, la posibilidad de programar los llamados Criminal Smart Contracts, los Smart Contracts plantean otros interesantes problemas (y también novedosas soluciones), vinculados a la gestión y resolución de conflictos en entornos blockchain, que se inscriben en una categoría analítica más amplia, la de gestión de conflictos online, comúnmenente denominada Online Dispute Resolution[208].

Se ha afirmado que la infraestructura legal actual no podrá, eficientemente, resolver dichos conflictos (i) al no poder identificar a las partes que celebran transacciones sobre criptoactivos[209] y, además, por (ii) el posible carácter transnacional de la disputa agravado por el hecho de que muchas veces el monto del conflicto no justificaría el acceso a la justicia.

En este sentido, se ha puntualizado que las cláusulas de resolución de conflictos en contratos on line deben ser repensadas si el contrato puede auto-ejecutarse sólo si se dan ciertas condiciones, e incluso, tales cláusulas pueden perder utilidad en contratos comerciales multi-jurisdiccionales, en la medida que la resolución del eventual conflicto pueda ser automatizada[210]. Como solución, se ha propuesto un enfoque de Justicia Distribuida que seguidamente se analizará en profundidad.

2.5.1. Justificantes de una Jurisdicción Distribuida

En la visión de Kaal y Calcaterra[211], la lógica subyacente a la necesidad de una Jurisdicción Distribuida es la siguiente: (i) la ausencia de un mecanismo de resolución de controversias eficiente en blockchains –públicas–, a largo plazo terminará afectando la confianza decentralizada que la blockchain permite; y (ii) la ausencia de medios jurisdiccionales para resolver conflictos generados por Smart Contracts, puede también provocar la pérdida de confianza de los consumidores y la consecuente no utilización de los contratos inteligentes. Ambos déficits, a su turno, pueden afectar el desarrollo de la criptoeconomía.

A la lógica antes expuesta, se deben sumar dos factores muy importantes. En primer término, la separación entre identidades físicas y digitales producto de la anonimidad relativa en la criptoeconomía afectará también a los mecanismos tradicionales y jurisdiccionales de resolución de conflictos, que han sido pensados: (i) con lógicas de competencia territorial[212] –que no tienen un correlato en la economía digital[213] donde surgirán contratos inteligentes con marcado carácter supra-nacional[214]–, (ii) para identidades off-chain, que tampoco están presentes en la criptoeconomía debido a la pseudonimia[215], y (iii) para contratos convencionales, que son muy diferentes a los contratos inteligentes encriptados y decentralizados.

En segundo término, existe muy poca jurisprudencia que aborde específicamente la blockchain y los Smart Contracts, lo que genera incertidumbre –i.e., inseguridad jurídica–, aun cuando esta tecnología no es muy distinta de cualquier otro software virtual. Por otro lado, los registros distribuidos no existen en el mundo físico, y por ende no tienen una ubicación determinada, a lo que se suma que los nodos de una blockchain pueden estar localizados en cualquier parte del mundo, con lo cual las transacciones estarían sujetas a la ley aplicable a cualquier nodo de la red[216].

Por tales motivos, es que los autores citados proponen un interesante enfoque de gobernanza intra-blockchain, capaz de brindar soluciones especiales para un nuevo entorno transaccional de blockchain-based Smart Contracting que, sin dudas, es muy especial[217]. Ponen Kaal y Calcaterra el énfasis en que casos como el TheDAO serán cada vez más usuales, y en que los Smart Contracts traerán inevitablemente nuevos tipos de conflictos, potenciados por el encriptado asimétrico, el hashing y la anonimidad relativa.

2.5.2 Características de una Jurisdicción Distribuida

Una Jurisdicción Distribuida como proponen Kaal y Calcaterra asume dos realidades: (i) que la existencia de errores en la codificación de Smart Contracts es innegable, como así también es innegable que es imposible que todas las posibles formas de incumplir un contrato inteligente puedan ser codificadas ex ante facto, debido a la propia limitación humana, y (ii) el caso TheDAO sobra como muestra de que lo anterior es, efectivamente, innegable.

Desde ese punto de partida sociológico, se afirma que la forma de resolver las eventuales disputas generadas por Smart Contracts debe, necesariamente, ser intra-blockchain, es decir, la forma de resolver los conflictos (i) no puede ser exógena, sino que debe ser endógena y dentro del mismo entorno blockchain, para poder mantener la anonimidad propia del entorno, y (ii) requiere un sistema de administración –o de gobierno, si se quiere– programado dentro de la o las blockchains de que se trate, como por ejemplo ofrece la red Aragon que se verá más abajo[218].

En la visión de Kaal y Calcaterra, una Jurisdicción Distribuida debiera ser: (i) una plataforma open source que garantice la anonimidad; (ii) a la que las partes de un Smart Contract que tengan un conflicto real puedan voluntariametne someterse; (iii) exista una reputación de cada árbitro –cuya identidad es desconocida– de modo que las partes puedan elegir al que consideran más adecuado; (iv) los árbitros presentarían sus laudos a la comunidad de árbitros, la que podría confirmarlos o rechazarlos, afectándose lógicamente la reputación del árbitro en función del dictamen final de la comunidad sobre cada laudo; y (v) los laudos no serían nunca finales y definitivos, pudiéndose reabrir el caso[219].

2.5.3 Casos de uso. Say (again) hello to Ricardian contracts!

Señalan Kaal y Calcaterra los ejemplos de Aragon y de OpenBazaar.

El primero utiliza una forma de jurisdicción digital distribuida, administrada por una sistema de jueces y reguladores anónimos, cuyo poder depende de su tenencia de tokens de la red, y de la reputación que construyan resolviendo conflictos. Aragon sacó a la venta su token, ANT en Mayo de 2017, y levantó 25 millones de Dólares en 15 minutos[220], el cuarto evento de crowdfunding más importante de la historia, y el segundo mayor sino se tiene en cuenta TheDAO.

OpenBazaar, por su lado, si bien no utiliza blockchain y Smart Contracts técnicamente hablando[221], sí utiliza una red distribuida y todas las partes y transacciones son anónimas y propone un modelo de contratos Ricardianos para resolver disputas, modelo que, para algunos, es la segunda generación de contratos inteligentes[222], y que tampoco son tan nuevos.

En efecto, los contratos ricardianos fueron propuestos en 1996 por dos programadores, Ian Grigg y Gary Howland, como parte de un sistema de pagos más amplio llamado Ricardo[223] y cuyas características esenciales son:

i. ser un contrato ofrecido por un emisor a un tenedor;

ii. por algún derecho de valor tenido por los tenedores, y administrado por el emisor;

iii. fácilmente legible por humanos como un contrato firmado en papel;

iv. también legible por programas de computación;

v. firmado digitalmente;

vi. que lleva consigo las llaves y la información del servidor; y

vii. con un identificador seguro y único.

En OpenBazaar, se puede recurrir a un tercero, llamado coloquialmente notario. Las partes del contrato no están obligadas a involucrar a un notario –se ahorran ciertas comisiones–, pero si eligen esta opción, entonces un notario verifica que el contrato se firmó y que el vendedor depositó bitcoins como depósito en garantía –escrow account–. Si el comprador está satisfecho, entonces se libera la garantía del vendedor; si hay conflicto, el notario actúa como árbitro. Durante todo el proceso, se mantiene la anonimidad de las partes –más técnicamente, la pseudonimidad mediante la utilización de llaves públicas–, y los notarios son aleatoriamente designados, aunque existen pools de notarios con expertise particular a disposición de las partes contratantes[224].

OpenLaw[225] es otra plataforma de Smart Contracts que desarrolla el concepto de Contratos Ricardianos, en la que participa como co-founder el prestigioso abogado especialista en Blockchain, Aaron Wright, del Cardozo Blockchain Project. La (ambiciosa y muy prometedora) propuesta de valor de OpenLaw es la siguiente:

“OpenLaw is the first fully expressive Ricardian contracting system — the bridge between traditional legal regimes and the Ethereum world. OpenLaw can be used to create binding legal agreements and tie them to the execution of one or more Smart Contracts, including Smart Contracts that create and manage tokens. Through this approach, any token operating on Ethereum and any Smart Contract can be imbued with legal effect.”

2.6 Dapps, DOs, DAOs y DACs [arriba] 

Sin dudas, si la nueva disciplina del Smart Contracting es de por sí interesante para el Abogado, las (inmensas) posibilidades que se abren cuando los Smart Contracts comienzan a intereactuar autónomamente entre ellos, formando DAOs y DACs[226], son simplemente alucinantes, bordeando la ficción, especialmente para el autor, que hace 10 años da clases de Sociedades. Pero el futuro llegó hace rato, y las Dapps, DOs, DAOs y DACs ya están aquí.

Hace 6 años, en 2014, Vitalik Buterin daba las primeras definiciones de las Dapps en un controvertido artículo, titulado DAOs, DACs, DAS and more: an incomplete terminology guide[227].

Allí se precisaba que una Dapp –Decentralized Application– es una variación de un Smart Contract, es decir un mecanismo que involucra activos digitales y dos o más partes, donde alguna o todas las partes afectan activos digitales, los que son automáticamente distribuidos entre las partes de acuerdo a una fórmula basada en ciertos datos que, al momento de iniciar el contrato, no son conocidos.

La Dapp es similar a un Smart Contract, pero con dos diferencias: (i) puede haber un número ilimitado de participantes de cada lado del contrato y (ii) no tiene necesariamente que estar vinculada a transacciones financieras.

Las Dapps son a su vez clasificables en dos tipos de clases: (a) totalmente anónimas, o (b) basadas en reputación, a donde algunos nodos siguen la performance de otros, con el fin de mantener la confianza en ellos.

Luego, Buterin también definía a las DOs –Decentralized Organizations– como una organización en la que los humanos participan de acuerdo a las reglas fijadas en el protocolo programado –como si fuera el Estatuto Social de una sociedad anónima, o el Estatuto Social de una asociación civil–, pero con la particularidad que dicho protocolo será aplicado a raja tabla por la blockchain. Toda la estructura convencional de las sociedades y su tipología legal y distintos tipos de organicismos, puede ser migrada a una blockchain, para que registre las tenencias de los accionistas/asociados, quienes expresan su voluntad –votan– también vía blockchain. Lo mismo es predicable respecto de personas jurídicas sin fines de lucro. La DO puede controlar activos digitales, o físicos, en la medida que su código interactúe con tales activos.

Avanzando un poco más, Buterin definió también a las DAOs –Decentralized Autonomous Organizations– como el Santo Grial de los Smart Contracts. Una DAO es un término genérico, que incluye también las DACs –Decentralized Autonomous Corporations–, una especie de DAO.

A diferencia de la DOs, las DAOs y DACs son entidades que viven en Internet, son autónomas, y pueden incluso contratar a personas para que realicen las tareas que ellas no pueden. Las DAOs vendrían a ser los espejos en blockchain de una fundación o una asociación civil, i.e. entidades sin fines de lucro, aunque tienen un “capital digital”, y están facultadas por su código de programación para disponer de dicho capital en ciertas circunstancias, generalmente para retribuir o premiar conductas. En el caso de las DOs, éstas también tienen un capital, pero éste está gestado por humanos que son quienes toman las decisiones al final del día; mientras que el capital “digital” de las DAOs está gestado por el código de la DAOs, de manera autónoma. Ejemplos actuales de DAOs son SolarDAO[228], DAOStacks[229], Wings[230], XWIN[231], y PieDAO[232].

El tema comienza a llamar la atención de muchos. Se ha sostenido que 2020 será “El Año de las DAOs”[233]. En opinión personal del autor, la década del 2020-2030 será la Década de las DAOs, y recordando el informe de Gartner antes citado, el mercado de servicios en blockchain tendrá un tamaño equivalente a 6 PBIs de Argentina al final de la década. Pero en el corto plazo, i.e., 2020-2023, se comenzará a ver muchísima actividad –i.e., innovaciones incrementales encadenadas, o incremental on-chain innovations, Io-cI, como yo las llamo– en materia financiera, en una tendencia que se denomina Decentralized Finance (“DeFi”), que combinará Smart Contracts, DAOs y, especialmente, una fuerte creencia de underperformance por parte de la banca tradicional[234]. MakerDAO[235] es un ejemplo exitoso de esta nueva tendencia DeFi.

Finalmente, Buterin definió a las DACs como una especie del género de las DAOs, con la diferencia que la DAC paga dividendos, es decir, es (o sería) una persona jurídica digital con fines de lucro, a diferencia de las DAOs que son sin fines de lucro. Buterin señala que el énfasis en los dividendos puede complicar definir situaciones en la que los partícipes reciben tokens como dividendo, y estos tokens, a su vez, pueden ser:

i. meros “permisos de uso” de ciertos activos digitales que integran “el activo digital” de la DAO o de la DAC; o pueden ser

ii. monedas propias emitidas por la DAO/DAC, o pueden

iii. ser otras criptomonedas adquiridas, en contraprestación por los bienes y servicios producidos por la DAO/DAC y comercializados a terceros, o

iv. moneda fiat, de curso legal, convencional, emitida por un Estado.

Es útil a los fines pedagógicos traer ahora a colación una segunda definición de una DA y DAOs, y entender el concepto comparándolo con el de sociedad anónima convencional:

“A decentralized organization is a computer program with no single leader, running on a peer-to-peer network that involves a set of users interacting with each other according to protocol programmed through code and enforced on a blockchain.[236]”

“A decentralized organization operates under the same basic concepts of a corporation but has a decentralized management structure—eliminating the board of directors, for example. The structure of a simple corporation has three classes of members: shareholders, a board of directors, and other members involved in the corporate hierarchy. To become a member in the corporation, shareholders purchase a slice of the company. Investors follow a set of bylaws determining how votes are cast, how they can select the board of directors, and so on. Other members in the corporation, such as employees, are hired by either directors in the corporation or other employees in the hierarchy. A decentralized organization involves a set of users interacting with each other and making decisions according to protocol specified in code and enforced on the blockchain. In a decentralized organization, the contract is coded in the blockchain and maintains a record of each shareholder’s holdings and allows for shareholders to vote on various items through the blockchain. What distinguishes a decentralized autonomous organization from a decentralized organization is its autonomous capability. Decentralized autonomous organizations are essentially a set of Smart Contracts that encode the bylaws of the entire organization. This means that the traditional terms that make up a contract are coded and uploaded to the blockchain, creating a decentralized Smart Contract. Unlike the traditional organization, the decentralized autonomous organization does not need to rely on a third party for recordkeeping or enforcement. The blockchain stores information including how many tokens each participant owns in the company or its bylaws. When certain pre-programmed conditions are satisfied, the decentralized autonomous organization automatically executes contractual clauses in the blockchain. In this way, decentralized organizations and decentralized autonomous organizations are similar. However, although decentralized organizations are also made up of Smart Contracts, human intervention in some way is still required. Decentralized organizations like the DAO depend on human involvement on each end of various transactions. In contrast, a decentralized autonomous organization is designed to run autonomously on a blockchain and is solely controlled by code, without any need for human involvement. [237]” (el resaltado es mio).

2.6.1 Round 1: Enter The DAO

Se ha señalado con gran razón que el Derecho tiene amplia tradición en reconocer que ciertas ficciones jurídicas pueden tener la misma capacidad legal que los seres humanos[238]. En efecto, esa es precisamente la lógica que subyace en todo el Derecho Societario, desde el Derecho Romano en adelante, con la particularidad de que en las personas jurídicas que nuestra legislación reconoce, siempre hay en el back-office personas humanas[239].

En efecto, se ha señalado que desde antaño, diversas agrupaciones combinan la posibilidad de aglutinar capital y habilidades humanas, las que con ayuda de técnicas asociadas han evolucionado hasta conformar patrimonios auto-gestantes, escindidos de los sujetos que originalmente acuden a su formación[240]. Los antecedentes más antiguos tienen origen babilónico –1.900 AC–, pero también los griegos recurrieron a esta técnica; los romanos la perfeccionaron y modelaron en un modo que ha llegado, con pequeños ajustes bárbaros, hasta el Siglo XIII[241]. Ya en el Siglo XV se gestaron las primeras Compañías que sí son antecedente directo de nuestras sociedades comerciales[242].

¿Acaso en el Siglo XXI habrá llegado el momento de ampliar la ficción de la personalidad jurídica para incluir a las DAOs y DACs, entidades desprovistas de personas humanas? Bayern no duda en contestar afirmativamente a la cuestión planteada, y de hecho afirma que ello ya ha ocurrido[243], pero también plantea interesantes preguntas que nos llevan a un plano más Iusfilosófico: ¿es conveniente o necesario aplicar el sistema legal convencional a estas nuevas entidades? ¿Qué tiene de malo que exista una entidad autónoma que persiga su propio fin sin rendir cuentas a nadie? ¿Será un problema que tal entidad tenga empleados humanos? Si fueran configuradas como entidades sin fines de lucro, ¿no podrán ofrecer bienes y servicios más competitivos? ¿No serán mejor gestionadas por algoritmos que por humanos formados en Administración de Negocios?[244]

2.6.1.1 El Caso TheDAO 

Pero no todo lo que brilla es Oro. Es necesario en esta instancia volver a la realidad del mundo no digital, formado por seres humanos, muchos de los cuales se relacionan de un modo ético, y otros tantos, no.

TheDAO fue la primera DAO en ser testeada en el mundo digital. La historia no tiene un final feliz, pero al menos nos demuestra que es posible dar vida a una DAO. Los hechos del caso fueron los siguientes:

1. TheDAO fue una DAO, es decir, una organización virtual[245], creada por una empresa alemana, Slock.it[246] en la blockchain de Ethereum. La Securities and Exchage Commission de EE.UU (SEC) definió los siguientes aspectos sobresalientes:

“The DAO was created by Slock.it and Slock.it’s co-founders, with the objective of operating as a for-profit entity that would create and hold a corpus of assets through the sale of DAO Tokens to investors, which assets would then be used to fund “projects.” The holders of DAO Tokens stood to share in the anticipated earnings from these projects as a return on their investment in DAO Tokens. A DAO Token granted the DAO Token holder certain voting and ownership rights. According to promotional materials, The DAO would earn profits by funding projects that would provide DAO Token holders a return on investment. DAO Token holders would then vote to either use the rewards to fund new projects or to distribute the ETH to DAO Token holders. In addition, DAO Token holders could monetize their investments in DAO Tokens by re-selling DAO Tokens on a number of web-based platforms that supported secondary trading in the DAO Tokens. In addition to secondary market trading on the Platforms, after the Offering Period, DAO Tokens were to be freely transferable on the Ethereum Blockchain. DAO Token holders would also be permitted to redeem their DAO Tokens for ETH through a complicated, multi-week (approximately 46-day) process referred to as a DAO Entity “split.

The DAO was to be “decentralized” in that it would allow for voting by investors holding DAO Tokens. All funds raised were to be held at an Ethereum Blockchain “address” associated with The DAO and DAO Token holders were to vote on contract proposals, including proposals to The DAO to fund projects and distribute The DAO’s anticipated earnings from the projects it funded.

The DAO was intended to be “autonomous” in that project proposals were in the form of Smart Contracts that exist on the Ethereum Blockchain and the votes were administered by the code of The DAO. Submitting a proposal to The DAO involved: (1) writing a Smart Contract, and then deploying and publishing it on the Ethereum Blockchain; and (2) posting details about the proposal on The DAO Website, including the Ethereum Blockchain address of the deployed contract and a link to its source code. Proposals could be viewed on The DAO Website as well as other publicly-accessible websites (…) there were two prerequisites for submitting a proposal. An individual or entity must: (1) own at least one DAO Token; and (2) pay a deposit in the form of ETH that would be forfeited to the DAO Entity if the proposal was put up for a vote and failed to achieve a quorum of DAO Token holders.

ETH raised by The DAO was to be distributed to a Contractor to fund a proposal only on a majority vote of DAO Token holders. DAO Token holders were to cast votes, which would be weighted by the number of tokens they controlled, for or against the funding of a specific proposal. Before any proposal was put to a vote by DAO Token holders, it was required to be reviewed by one or more of The DAO’s “Curators.” At the time of the formation of The DAO, the Curators were a group of individuals chosen by Slock.it (…) Curator was responsible for: (1) confirming that any proposal for funding originated from an identifiable person or organization; and (2) confirming that Smart Contracts associated with any such proposal properly reflected the code the Contractor claims to have deployed on the Ethereum Blockchain. If a Curator determined that the proposal met these criteria, the Curator could add the proposal to the “whitelist,” which was a list of Ethereum Blockchain addresses that could receive ETH from The DAO if the majority of DAO Token holders voted for the proposal.

The DAO Website (…) described how The DAO operated, and included a link through which DAO Tokens could be purchased. The DAO Website also included a link to the White Paper, which provided detailed information about a DAO Entity’s structure and its source code and, together with The DAO Website, served as the primary source of promotional materials for The DAO. On The DAO Website and elsewhere, Slock.it represented that The DAO’s source code had been reviewed by “one of the world’s leading security audit companies.” [247] (los resaltados son míos).

2. Los DAO Tokens fueron ofrecidos al público entre el 30/04/16 y el 28/05/16. Fue un éxito histórico de ventas: se vendieron 1.150 millones de DAO Tokens a unos 11.000 inversores, levantándose 12 millones de Ethers –equivalentes, a tal momento, a unos 150 millones de U$D– en la campaña más grande y exitosa de crowdfunding de la historia[248].

3. Días antes de finalizar el road show de los DAO Tokens (i.e., 28/05/16) comenzaron a circular rumores de posibles errores de programación en el código de la DAO. El 25/05/16 los organizadores (i.e. Slock.it) propusieron establecer un mecanismo de recompensas para quien descubriera y denunciara fallas de seguridad en el código, pero la propuesta no fue aceptada por los inversores por considerarla muy cara (su costo era de 125.000 ETH, aproximadamente el 1% del total del patrimonio de TheDAO). El 26/05/16, los organizadores propusieron designar a un experto en seguridad para que auditara el código de TheDAO[249].

4. El 17 de Junio de 2016, una persona o grupo de personas no identificadas detectaron un bug[250] en el código de TheDAO, y lograron que 1/3 del total del patrimonio de TheDAO fuera transferido a otra cuenta en Ethereum, a donde quedó inmovilizado por 27 días[251]. El 20 de Julio de 2016, por mayoría de nodos, se decidió implementar un muy debatido hard fork en la blockchain de Ethereum, que permitió que los fondos fueran enviados a una nueva cuenta, en la cual los inversores perjudicados podían cambiar sus DAO Tokens por Ether, y salir de TheDAO como si no hubieran sufrido ninguna pérdida. Una minoría que votó en contra del hard fork no actualizó el software a la nueva versión de Ethereum, por lo que al día de hoy existe una blockchain llamada Ethereum Classic (ETC), y una Ethereum post-TheDAO (ETH)[252].

Los términos y condiciones publicitados por TheDAO expresamente negaban que los DAO Tokens fueran participaciones sociales, acciones o títulos valores similares en ninguna persona jurídica en ninguna jurisdicción del mundo, por lo cual los inversores que los adquiriesen no eran socios[253]. Sin embargo, la SEC afirmó que los DAO Tokens eran títulos valores sometidos a su competencia y jurisdicción[254], ya que había una promesa de ganancia derivada o producto de la gestión empresarial de otras personas. En contra de esta opinión de la SEC, se ha sostenido que en TheDAO eran los propios invesores los que decidían a dónde invertir; y no un equipo de gestión. No existían, de hecho, autoridades formales en TheDAO[255].

Recientemente, Laila Metjahic ha analizado el caso en profundidad en un muy interesante y jugoso artículo publicado en la prestigiosa Cardozo Law Review[256] y “curado” por Aaron Wright. En los apartados siguientes se seguirá la exposición de Metjahic, quien identificó las siguientes cuestiones legales:

2.6.1.1.1 Responsabilidad de los inversores y desarrolladores

Afirma Metjahic que bajo la legislación societaria norteamericana, los inversores y desarrolladores de TheDAO podrían ser considerados socios de una general partnership, en la cual asumen responsabilidad directa, ilimitada y solidaria ante terceros, y ciertos deberes fiduciarios entre ellos[257].

En nuestro derecho, sería equiparable a la responsabilidad del socio colectivo, con la importante diferencia de que éste asume una responsabilidad subsidiaria y puede invocar el beneficio de excusión[258]. También podría ser asimilada a la calidad de socio de una sociedad simple, regulada en la Sección IV de la Ley General de Sociedades, en la cual el socio asume frente a terceros una responsabilidad mancomunada y subsidiaria, en principio[259].

Metjahic también se pregunta si TheDAO podría ser considerada una sociedad anónima[260], y responde negativamente, ya que no delegaron el poder de decisión en un órgano de administración, sino que gracias a la decentralización de la blockchain, retuvieron para sí el poder de decidir en qué negocios se invertiría el capital digital.

En nuestro derecho, en las sociedades por partes de interés –entre las que se incluye la sociedad colectiva, y a donde no hay limitación de la responsabilidad del socio– la sencilla estructura de las mismas no requiere la existencia de órganos diferenciados –como en el caso de las sociedades de capital, donde sí se limita la responsabilidad del socio–, adoptando un auto-organicismo de estructura simple, por cuanto el carácter de órgano corresponde a cualquier socio, que actúa de manera directa como si fuera la sociedad[261].

2.6.1.1.2 Naturaleza jurídica de la participación societaria

Como consecuencia del encuadre de TheDAO como general partnership bajo el derecho anglosajón, en opinión de Metjahic la participación de sus socios –llamada partnership interests en EE.UU; partes de interés en nuestro derecho[262]– encuadra dentro de la definición federal de security –título valor–. A la misma conclusión llegó la SEC al analizar la plataforma fáctica del caso TheDAO, citando el holding del año 1946 in re SEC v. W.J. Howey, Co.[263].

Como consecuencia de lo anterior, el ofrecimiento público de un security debe (i.e. debió) cumplir ciertas normas registrales previo a su ofrecimiento, bajo apercibimiento de acciones civiles y penales a ser iniciadas por la SEC[264] –que finalmente no se iniciaron ya que el hard fork de Ethereum volvió las cosas a su estado anterior, y no hubo perjuicios causados más allá de la desilusión general–.

2.6.1.1.3 Status legal de una DAO: una propuesta de lege ferenda

Afirma Metjahic que el diseño de TheDAO encuadraba (y en el futuro, encuadraría) en la definición de general partnerships[265], o, en su defecto, en la definición de joint venture, que para el derecho norteamericano es tratado en muchos casos como una general partnership con objeto específico[266].

En el Estado de Delaware, por ejemplo, la definición de Joint Venture pivotea sobre cinco elementos:

i. debe existir una comunidad de intereses en el resultado de un negocio común;

ii. debe haber control común de la empresa;

iii. debe existir un derecho de propiedad compartido en relación al objeto o resultado de la empresa común; y

iv. un interés compartido en repartir las ganancias y soportar las pérdidas[267]. Afirma Metjahic que TheDAO cumplía, con certeza, estos cinco requisitos.

Por otro lado, los tokens emitidos por TheDAO, en opinión de Metjahic eran (y, en el futuro, serían) securities según la legislación federal de títulos valores que la SEC debe hacer cumplir. Es más, afirma Metjahic que la SEC ya ha considerado en 2014 que bitcoin es un security, igual que Ether[268]; y que los tokens emitidos por TheDAO, pagados con Ether, eran un contrato de inversión ya que:

“..the DAO is a scheme whereby a person invests his money in a common enterprise and is led to expect profits solely from the efforts of a third party. As such, the DAO is an investment contract, with Ether as the security interest. Together, the DAO and its sale of Ether should be considered security interests subject to SEC regulation.[269]” (el resaltado es mío).

La opinión de Metjahic no se comparte, ya que en el esquema de TheDAO no existía la figura del promotor de Howey; no existió un tercero[270] que realice o brinde esfuerzos manageriales para extraer una rentabilidad repartible; y de hecho, los propios tenedores de tokens eran quienes votaban dónde invertir el activo digital de TheDAO.

2.6.2 DAOs, DACs e Internet of Things

El potencial de las DAOs y DACs va de la mano del crecimiento de la IoT a nivel doméstico, e industrial –Industrial Internet of Things: IIoT–. En efecto, Christidis y Devetsikiotis[271] afirman que la tecnología decentralizada y peer-to-peer de la blockchain es ideal para el desarrollo y expansión del ecosistema de IoT, con grandes beneficios tanto para los productores de dispositivos, como para sus usuarios[272].

La combinación de blockchain, Smart Contracts, DAOs y IoT puede permitir diseñar e implementar ejemplos como el que sigue, que probablemente en poco tiempo será seguramente un caso real de uso: un Municipio X que decide adquirir 2.000 bicicletas para uso social y comunitario, repartidas en 100 estaciones barriales con 20 bicicletas cada una, con su respectivo chip RFID que le da conectividad permanente: IoT. Cada usuario que desee usar una bicicleta, debe descargar una app, acreditar su identidad con lectura del código de barra en su DNI, y cargar crédito, comprando BiciTokens, cuyo valor es fijado por el Municipio. Cada BiciToken permite circular 100 horas, en tramos de 1 hora cada uno. Los BiciTokens son para uso personal, pero pueden ser cedidos gratuitamente a otros usuarios de la red. Cada 100 horas de circulación en bicicleta, el sistema acredita 0.5 BiciTokens en la cuenta del usuario, como premio por ejercitarse y utilizar un medio de movilidad sustentable. Todo el sistema corre en una blockchain privada, permisionada, donde existen tres nodos:

i. el Municipio: que vende o acredita los BiciTokens a los ciudadanos dados de alta;

ii. un servicio de mantenimiento de las bicicletas, que pueden ser organizaciones sociales o centros vecinales, ya que se sabe que el 2% de ellas debe ser reparado mensualmente; y
iii. sponsors privados, que aportan fondos para adquirir las bicicletas y para mantener el sistema, y que pueden disparar campañas de marketing segmentadas para los usuarios.

Todo el sistema se programa para operar como una Organización Autónoma Decentralizada (DAO), es decir, un conjunto de contratos inteligentes que interactúan entre sí, y donde se configuran las siguientes funcionalidades:

(1) si un usuario acredita 1000 horas de movilidad sustentable –el sistema vía RFID lo puede confirmar–, el Municipio puede premiar tal conducta con beneficios fiscales –reducción del 1% en cualquier tasa municipal que el usuario deba pagar;

(2) si un usuario acredita la reparación de 10 bicicletas en un mes, certificadas por el servicio de mantenimiento, puede acceder a los mismos beneficios que en el caso anterior;

(3) los sponsor privados pueden comprar publicidad estática en las 100 estaciones y en las 2000 bicicletas móviles así como banners en la app, sea entregando nuevas bicicletas al sistema, reparando las afectadas, o acreditando beneficios –vouchers, descuentos, canjes– para los usuarios del sistema, bajo forma de BiciTokens con afectación específica –por ejemplo, el pago de restaurants, vestimenta, etc. –, permitiendo el sistema segmentar y premiar a los más comprometidos (e.g., los que pedalean más de 500/1000/2000 horas mensuales);

(4) las compras de publicidad estática o móvil por parte de privados puede, a nivel del usuario, ser reflejada en contratos inteligentes que le permiten acceder automáticamente a los beneficios sólo si se cumplen determinadas condiciones –e.g., pedalear 3000 horas–, y estos beneficios pueden ser cesibles, o de uso personal, según cómo se configure el contrato inteligente que los aloja; y

(5) al estar registrado en una blockchain, el funcionamiento del sistema es transparente, auditable, y medible desde el punto de vista de mitigación del Cambio Climático.

Una DAO como la expuesta, no tiene fines de lucro, sino un fin muy distinto: promover la movilidad sustentable y crear un circuito cerrado –pero auditable y transparente– de premios e incentivos públicos y privados para una Ciudad Sostenible. Una DAO como la expuesta es una entidad digital que funcionará del modo que se la programe, sin necesidad de intervención humana, pudiendo incluso pagar los servicios off-chain de mantenimiento brindados por el nodo de mantenimiento mediante una moneda nativa, BiciRepairToken, que sea canjeable por moneda de curso legal, a donde los privados pueden comprar BiciRepairTokens de modo tal que los reparadores cobran por su trabajo, también mediante contratos inteligentes. Todos los tokens del sistema se representan en códigos QR, que son escaneados desde aplicaciones móviles, con lo cual sólo se requieren Smart Phones, cada vez más frecuentes.

Ahora bien, para finalizar, se ha sostenido que la autonomía completa de un Smart Contract puede ser una espada de doble filo[273], y deben tomarse recaudos a nivel de arquitectura de software que permitan modificar los outputs de un contrato inteligente en función de distintos inputs variables, o que permitan directamente eliminar el contrato de la blockchain mediante una función de “auto-destrucción”[274]. De lo contrario, el sistema –i.e. la DAO– no podría ser modificado y es posible imaginar casos donde tokens o monedas sean retenidas ad infinitum por un error de programación. Un contrato inteligente que retenga lo que, por alguna razón, debe ser liberado, debe poder ser eliminado.

2.6.3 Round 2: Enter The LAO (DAOs 2.0!)

Como se dijo más arriba, la década de 2020-2030 será la Década de las DAOs, y el debut accidentado del TheDAO no podrá detenerlo. Así, a fines de 2019 ya se ha propuesto una nueva estructura, bajo la creencia firme de que las DAOs tienen el (enorme, por cierto) potencial de reducir costos de transacción al confiar y delegar en contratos inteligentes el gobierno y la coordinación de acciones y comportamientos on line[275]. La tesis subyacente es simple, y puede dar nacimiento al Gobierno Corporativo 2.0:

“Through the use of Smart Contracts, parties can automate certain aspects related to the way organizations and groups operate, reducing operational costs and improving internal controls while simultaneously increasing the overall transparency of an organization.[276]”

A continuación se resaltan los caracteres más sobresalientes de esta nueva e interesante figura legal digital que se propone:

“The LAO will provide a legal structure to enable members to not just give grants, but to invest in blockchain-based projects in exchange for tokenized stock or utility tokens. Projects or Ethereum-based projects will be able to receive funding for their projects in days once submitted to the LAO.

Using the tooling provided by OpenLaw, the LAO will be set up as a limited liability entity, organized in Delaware, using curated Smart Contracts to handle mechanics related to voting, funding, and allocation of collected funds. This entity will presumably limit the liability of LAO members and help clarify their relationship to avoid knotty questions related as to whether partnership law applies.

This structure will also provide members of the LAO with tax flow — through treatment by the Internal Revenue Service, such that tax is not paid by both the entity and a person holding a beneficial interest in the LAO.

Members will be able to purchase interests in the LAO and the proceeds from the purchase will be pooled and allocated by members to startups and other projects in need of financing, using a voting mechanism and tools similar to Moloch DAO.

In order to comply with United States law, membership interests of the LAO will be limited and only available to parties that meet the definition of an accredited investor — although there are arguments that LAO membership interests may not be securities. And, the LAO will be anchored by 10 founding members (which will be announced shortly). Other interested parties will be able to purchase interests in the LAO (potentially through a public sale).

Through OpenLaw’s tools, the creation and set up of The LAO will be streamlined. All of the relevant legal documents from the entity formation documents to member subscription agreements will be generated via the OpenLaw protocol — taking complex corporate financial processes and streamlining their operation — while also providing members with the backing of the U.S. legal system. We also will be exploring on-chain verification of accredited status for the LAO using third-party oracle services (such as ChainLink) to streamline the onboarding process.

Much like the original Moloch design, members of the LAO will be able to ragequit and immediately retrieve back their fair share of unallocated funds based on their economic contribution (regardless of voting weight). With this safety mechanism in place, LAO members will always have the option to opt-out of the LAO should they disagree with aspects of the LAO membership, investment portfolio or need to rapidly receive back their assets. Extending emerging Moloch designs further, LAO members can also continuously claim their fair share of profits provided by tokens received from projects that receive investment from the LAO, further incentivizing collective LAO diligence, voting participation, and membership stability.

The LAO will allocate to potential projects funding in Ether (or potentially DAI). Funding will be provided once a member nominates a project for funding and a majority of the members (based on their voting weight) approve the allocation of funds.

The funding will be provided on a take it or leave it basis. The LAO will receive a certain portion of the projects tokenized stock or other ERC-20 token in exchange for a fixed amount of funding from the LAO.

To accept funding, projects will submit an application and be required to create a Delaware legal entity and OpenLaw will provide a set of standardized documents to streamline the process. If the project is later stage, OpenLaw will work with the project to ensure that the LAO can provide funding, given the project or entity’s then-current legal structure.” [277] (los resaltados son mios)

Sin dudas, con la muy reciente irrupción del LAO estamos frente a un concepto que al final de la década habrá disruptado al derecho societario, al menos en lo que a negocios digitales se refiere. La ola de las DAOs 2.0 ya inició, y mientras estas líneas se escriben, se escriben también las líneas de programación del TheDAO reloaded[278]. Como se dijo antes, durante esta década se verán nuevos desarrollos a medida que madure la Blockchain 2.0 hacia una Blockchain 3.0.

2.6.3.1 Ragequit, o el derecho de receso digital en el Siglo XXI

Antes de finalizar este tratamiento superficial de las DAOs y las LAOs, quiero volver a llamar la atención sobre un concepto que, como profesor de Sociedades, luce muy interesante, y hasta familiar: Ragequit, una función desarrollada en los contratos inteligentes que ofrece una DAO llamada MolochDAO[279], descripta en su White Paper en los siguientes términos:

“We recognize that in any voting-based system, there are a large number of edge cases created by possible collusion or unavailability of stakeholders. To handle these, we built a catch-all mechanism that allows participants to exit with their funds if they did not agree with the result of a vote. This is done by allowing members to “Ragequit” the guild within a “grace period” after voting on a proposal completes but before those members’ ownership is affected by that proposal.

Let’s say for instance that 99% of the guild colludes and submits a proposal to issue 99% more Shares to themselves and dilute the remaining 1% down to effectively zero. In this case, the 1% would Ragequit the guild during the grace period, negating the majority voting bloc’s attack.

Note that the remaining members after the grace period ends bear the cost of the proposal. In the case of a contentious vote where a large minority exits (e.g. a 51% attack), this means that cost is greatly increased for those who stay. To enforce this, we restrict Ragequitting to only members who voted “No” in a given proposal if the proposal passes. This forces “Yes” voters to bear the cost of a malicious proposal.

We expect this to create an interesting additional meta-incentive for mutual cooperation, since guild members would be strongly disincentivized to submit proposals that might cause a large proportion of other members to ragequit.

Readers may note that an attack vector exists where participants can repeatedly Ragequit to either avoid dilution or grief the guild. This would be an effective method to avoid paying the cost of a single proposal. However, if the member wanted to avoid paying they would have to Ragequit the entirety of their shares, completely removing them from the guild. They would then have to reapply as a member, and we expect that existing members would be hesitant to readmit the defecting applicant. From existing game theoretic research, we are confident that this will be a strong incentive for members to not abuse the ragequit mechanism.[280]” (los resaltados son mios)

Si uno entiende el funcionamiento de la función ragequit, y conoce el funcionamiento del derecho de receso en materia societaria[281], encontrará llamativas similitudes y muchos puntos de contacto.

2.7 Haciendo marcha atrás con un Smart Contract: ¿Se puede? [arriba] 

Habiendo visto hasta ahora las muchas definiciones de un contrato inteligente, sus distintas clasificaciones posibles, sus cuatro pilares fundamentales, algunos casos de usos y muchos de los problemas asociados a ellos, la pregunta que ahora debe estar en el aire es: si un contrato inteligente funciona mal, por acción u omisión de su programador ¿es posible volver hacia atrás, sin tener que impulsar un hard fork y romper la inmutabilidad de la blockchain, tal como ocurrió en el caso TheDAO?

Evidentemente, la cuestión tiene distinta naturaleza (y posibilidad de respuesta) en blockchains públicas que en blockchains privadas o consorciadas. En éstas, la arquitectura puede prever formas de retrotraer los efectos de un contrato inteligente, ya que en alguna medida, hay un control central.

Por el contrario, en blockchains públicas, especialmente en Ethereum, la cuestión aún no tiene una respuesta clara, y quizás haya que esperar hasta tener una respuesta o técnica sólida. De allí la imperiosa necesidad de auditar el código del contrato inteligente antes de que sea puesto en acción, necesidad que tiene una cada vez mayor oferta de servicios[282], y que será analizado en profundidad en el Capítulo IV.

2.7.1 Token propio

Se ha sostenido que una posibilidad de “dar marcha atrás” depende de que el token en cuestión sea un token propio del proyecto o de la empresa fondeada. En éstos casos, es posible retrotraer operaciones; o bien congelar los tokens afectados y emitir nuevos en su reemplazo[283], pero evidentemente requieren un “control central” que está en las antípodas de la decentralización que plantea la blockchain.

2.7.2 ¿Contrato reversible?

Se ha señalado que existen formas de “actualizar” un Smart Contract que no está funcionando correctamente o tiene alguna vulnerabilidad detectada, sin que ello implique ipso facto poder revertir las operaciones defectuosas[284]. Así, una forma es crear un contrato intermedio –i.e. caller contract–, que aloja la dirección del contrato activo o principal –i.e., target contract–[285].

2.8 Hacia la estandarización de Smart Contracts [arriba] 

Como se verá más abajo en § 3.4.1.3, el Reino Unido recientemente ha considerado que los criptoactivos son una propiedad tranzable y que los Smart Contracts son contratos válidamente celebrados bajo la legislación inglesa[286].

En la misma línea, recientemente, el British Standards Institute ha iniciado un proceso de elaboración participativa de estándares para Smart Contracts[287], enfoncándose en las especificaciones técnicas que debieran cumplir los contratos que sean legibles tanto por humanos como por máquinas, con el fin de fijar un estándar para toda la industria que se dedica al desarrollo de software que utiliza, ofrece o codifica Smart Contracts, tanto actuales como futuros[288].

Vinculado a la estandarización[289], en un muy interesante trabajo del año 2016, Clack, Bakshi y Braine[290] indagan en la conveniencia de generar modelos de Smart Contracts para redes decentralizadas, con la mira puesta en la industria de las finanzas, y con el objetivo de facilitar el cumplimiento automático y que, en caso de conflicto, tengan una referencia a la documentación legal subyacente[291].

Estos modelos estandarizados de Smart Contracts utilizan parámetros que conectan el lenguaje natural legal –la prosa legal[292]– con su correspondiente lenguaje de programación machine-readable. Dichos parámetros operacionales permiten direccionar el comportamiento del Smart Contract[293], pero determinarlos puede no ser tan sencillo[294]. Concluyen los autores afirmando que el uso de parámetros no solo agilizaría la estandarización del lenguaje de programación para Smart Contracts, sino que también produciría que en el futuro, la prosa legal se exprese de forma más estructurada y formal, e incluso, hasta permita reemplazar la lógica a veces ambigua de la prosa legal por expresiones aritméticas y lógicas, lo que a su turno reduciría la ambigüedad y los errores en el lenguaje natural legal[295].

A su vez, mientras más estandarizado sea el código de los Smart Contracts, lo vuelve más genérico, y en algún punto se llegaría a un código de programación compartido, común, y de uso masivo[296].

Notas [arriba] 

[1] Confr. término empleado –con precisión– por Kevin Werbach, en Trust, but verify… o.c. p. 526.
[2] Confr. Nick Szabo, The idea of Smart Contracts, disponible en https://perma.cc/YED2-ACVP, conceptos que luego fueron ampliados en una publicación titulada Formalizing and securing relationships on public networks, disponible en: https://perma.cc/U2L2-B34P.
[3] Confr. Kevin Werbach, en Trust, but verify… o.c. p. 505.
[4] Confr, Nick Szabo, https://en.wikipedia.org/wiki/Nick_Szabo.
[5] Confr. Nick Szabo, The idea of Smart Contracts, disponible en https://perma.cc/YED2-ACVP.
[6] Confr. Nick Szabo, Formalizing and securing relationships on public networks, disponible en: https://perma.cc/U2L2-B34P.
[7] Confr. Karen Yeung, en Regulation by blockchain.. p. 223, nota 65.
[8] Confr. Nick Szabo, Smart Contracts: building blocks for digital markets, recuperado el 16/04/2020 en http://www.fon.hum.uva.nl/rob/Courses/ InformationInSpeech/CDROM/Literature/ LOTwinterschool2006/szabo.best. vwh.net/smart_contracts_2.html.
[9] El Código Civil y Comercial de la Nación en su Art. 957 define al contrato como “acto jurídico mediante el cual dos o más personas manifiestan su consentimiento para crear, regular, modificar, transferir o extinguir relaciones jurídicas patrimoniales.” El Art. 958, por su parte, consagra la libertad de contratar dentro de los límites legales; el Art. 959 declara su efecto vinculante; el Art. 960 dispone que los jueces no pueden modificarlos salvo si hay afectación del orden público; el Art. 961 consagra la buena fe en materia contractual y el Art. 962 dispone que en la materia contractual las normas son, por regla, supletorias de la voluntad de la partes. El Art. 965 por su parte declara que los derechos resultantes de los contratos intengran el derecho de propiedad del contratante. El Art. 969 se refiere a las formas contractuales, y el Art. 970 recepta los contratos innominados.
[10] Eliza Mik, Smart Contracts: terminology, technical limitations…o.c., p. 272.
[11] Eliza Mik, Smart Contracts: terminology, technical limitations…o.c., p. 273.
[12] Eliza Mik, Smart Contracts: terminology, technical limitations…o.c., p. 274.
[13] Confr. Riikka Koulu, en Blockchains and Online Dispute Resolution: Smart Contracts as an alternative to enforcement, publicado en ScriptEd, Vol. 13, Número 1, Mayo 2016, p. 57, sobre Solidity, aclara: “Solidity, the object-oriented programming language used within the Ethereum platform to draft smart contracts. Object-oriented programming is based on “objects”, that are data structures containing both data fields (attributes) and procedures (methods). The procedures of a software program can access and modify the data fields of other programs that they interact with. Objects are created based on templates called classes that define the initial values and methods or functions for the program. Fields are data organised within the classes or objects. Regular fields are also called instance variables, where there is a different variable for different instances (e.g. a class called “student” includes a field called “name” and each student has a distinct name). There are also static fields, where the field only has one variable that stays the same in all instances of the object (e.g. all students have the right to study). Smart contracts written with Solidity govern the behaviour of different accounts within Ethereum and the language is designed to correspond with such external concepts as ownership and identity. The basic structure of Solidity is the contract, which also forms a separate object on the blockchain. A contract deployed on the blockchain can be seen as an instance of a class.”El resaltado es mío.
[14] Confr. David Black, Blockchain smart contracts aren’t Smart and aren’t Contracts, recuperado el 16/04/2020 en https://www.forbes.com/sites/davidblack /2019/02/04/blockchain- smart-contracts-arent-smart-and- arent-contracts/#1e224ffb1e6a.
[15] Karen Levy, Book-smart, Not street-smart: blockchain-based smart contracts and the social workings of law, disponible al 16/04/2020 en https://estsjournal.org/ article/view/107, p. 3.
[16] Idem, p. 4.
[17] Idem, p. 10.
[18] Confr. Jonathan G. Rohr, Smart contracts and traditional contract law, or: the law of the vending machine, publicado en Cleveland State Law Review, Enero de 2019, Vol. 67, número 1, p. 68. 
[19] Confr. Jared Arcari, en Decoding Smart Contracts…o.c., p. 370.
[20] Confr. Kevin Werbach, en Trust, but verify… o.c. p. 527.
[21] Confr. Karen Yeung, en Regulation by blockchain.. p. 223.
[22] Confr. Kevin Werbach, en Trust, but verify… o.c. p. 505.
[23] Confr. Max Raskin, en The law and legality of smart contracts…o.c. p. 3.
[24] Confr. Tsui S. Ng, Blockchain and beyond: Smart Contracts, recuperado el 16/04/2020 en https://www.americanbar.org/groups/ business_law/publications/ blt/2017/09/09_ng/.
[25] Vitalik Buterin, A next-generation smart contract and decentralized application platform, el White Paper de Ethereum, disponible en https://github.com/ethereum/wiki/wiki/White-Paper al 17/04/2020. En algún momento, Vitalik utilizó la expresión Smart Contracts con demasiado desapego a sus contornos legales, y reconoció luego públicamente que el término era erróneo y equívoco, por lo que generalmente estaba mal empleado, ya que no había un contrato legal subyacente en muchas ocasiones. Esto es cierto, y también lo inverso. Casos hubo –véase los T&Cs del TheDAO– en los que en la realidad on-chain existía un contrato legal subyacente, pero se intentó evitar las consecuencias de tal realidad, afirmando que la codificación en machine-readable format no generaría obligaciones en formato judicialmente ejecutable.
[26] Confr. ETHEREUM, https://www.ethereum.org; Gavin Wood, Ethereum: A Secure Decentralised Generalised Transaction Ledger, http://gavwood.com/paper.pdf, recuperado el 18/04/2020.
[27] Confr. MultiChain: https://www.multichain.com.
[28] Confr. Gideon Greenspan, Why many smart contract use cases are simply impossible, recuperado el 15/04/2020 en https://www.coindesk.com/three-smart- contract-misconceptions.
[29] Confr. Aaron Wright y Primavera De Filippi, Decentralized…p. 10.
[30] Idem, p. 11.
[31] Confr. Aaron Wright y Primavera De Filippi, Decentralized.. p. 10, nota 46.
[32] Confr. Reggie O’Shields, Smart Contracts: legal agreements for the blockchain, publicado en 21 N.C. Banking Inst. 177 (2017), disponible al 18/04/2020 en: http://scholarship.law.unc.edu /ncbi/vol21/iss1/11, p. 179.
[33] Ibid.
[34] Confr. Christopher Clack, Vikram Bakshi y Lee Braine, Smart contracts templates: foundations, design landscape and research directions, recuperado el 23/04/2020 en https://arxiv.org/abs/ 1608.00771, p. 2.
[35] Confr. Samuel Bourque y Sara Fung Ling Tsui, A lawyer’s introduction to smart contracts, publicado en la revista polaca Scientia Nobilitat, en 2014, p. 4. Ejemplifican el funcionamiento de un contrato inteligente del siguiente modo: “An appropriate analogy for the reader to envision would be that of two masters that share a servant; the latter has the ability to read and is bound to obey both his masters’ signed instructions. When the two masters draft and sign an agreement; the servant, upon receipt of the written contract, would oversee and perform the contractual obligations through to the contract’s termination. To draw the parallel back to SCs, the masters are the parties to the contract and the SC is the servant that executes the contract obligations.”
[36] Confr. Riikka Koulu, en Blockchains and Online Dispute Resolution: Smart Contracts as an alternative to enforcement, publicado en ScriptEd, Vol. 13, Número 1, Mayo 2016, 53.
[37] Confr. Michèle Fink y Valentina Moscon, Copyright law on blockchain: between new forms of rights administration and digital rights management 2.0, publicado en la International Review of Intellectual Property and Competition Law, vol. 50, pag. 77–108, 2019, disponible al 15/04/2020 en https://link.springer.com/article/10.1007% 2Fs40319-018-00776-8, p. 92.
[38] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute resolution, publicado en The Business Lawyer, Primavera 2019, p. 12.
[39] Confr. Chamber of Digital Commerce, White Paper: Smart Contracts: is the Law ready?, disponible al 16/04/2020 en https://digitalchamber.org /smart-contracts-whitepaper/, p. 10.
[40] The Cardozo Blockchain Project, “Smart Contracts” & Legal Enforceability, 2018, reporte n º 2, recuperado el 16/04/2020 en https://larc.cardozo.yu.edu/blockchain-project-reports/2, p. 3.
[41] Confr. European Union Blockchain Observatory and Forum, Legal and regulatory framework of blockchains and smart contracts, disponible al 16/04/2020 en https://www.eublockchainforum.eu/reports, p. 22.
[42] Ibid.
[43] Confr. Santiago Mora, La tecnología blockchain. Contratos inteligentes, ofertas iniciales de monedas y demás casos de uso, publicado en La Ley 01/04/2019, cita online: AR/DOC/537/2019.
[44] Confr. Carlos Mirassou Canseco y Andrés Hadad, Nuevo paradigma contractual: los smart contracts,
publicado en Sup. Esp. LegalTechII 2019 (noviembre), 11/01/2019, 49, cita online: AR/DOC/3578/2019.
[45] Confr. European Union Blockchain Observatory and Forum, Legal and regulatory framework of blockchains and smart contracts, disponible al 16/04/2020 en https://www.eublockchainforum.eu/reports, p. 23.
[46] En la República Argentina, la regulación general de los contratos está contenida en el Código Civil y Comercial de la Nación, Libro III, Derechos Personales, Título II, Contratos en general, Capítulos I (Disposiciones generales), II (Clasificación de los contartos), III (Formación del Consentimiento), IV (Incapacidad e Inhabilidad para Contratar), V (Objeto), VI (Causa), y VII (Forma). Los Capítulos VIII, IX y X regulan la prueba, los efectos y la interpretación de los contratos, respectivamente.
Si un contrato inteligente cumple los requisitos prescriptos en los Capítulos I-VII, entonces puede ser considerado un contrato para la legislación argentina.
[47] C.C.C.N., Art. 1015.
[48] C.C.C.N., Art. 984.
[49] C.C.C.N., Art. 985.
[50] C.C.C.N., Art. 988, inc. c.
[51] Confr. European Union Blockchain Observatory and Forum, Legal and regulatory…o.c., p. 25, se señala que se puede tratar de la representación on-chain –i.e, en blockchain– de bienes off-chain (inmuebles, etc.), o directamente de la representación digital de activos nativos on-chain (criptomonedas, o derechos de acceso, propiedad intelectual). La tokenización de activos off-chain se potencia sobremanera cuando se complementa con smart contracts. Ahora bien, cuando el activo es per se nativo digital, como una criptomoneda u otros tipos de tokens, sin ningún correlato subyacente y físico, aparecen allí los problemas de la naturaleza jurídica del token, situación que es aún más compleja cuando se crean tokens híbridos, sumado a todo ello la pseudonimia propia de los entornos blockchain.
[52] Confr. European Union Blockchain Observatory and Forum, Legal and regulatory…o.c., p. 27. Véase supra lo expuesto sobre DAOs y DACs en las notas 219 a 223. La naturaleza jurídica de una DAO y de sus miembros, es un punto en arduo debate en todo el mundo. Distintas legislaciones le asignan distinta naturaleza jurídica, incluyendo ser un contrato multilateral de organización no personificado, una sociedad simple, un contrato de colaboración, una sociedad con responsabilidad ilimitada, o una sociedad con responsabilidad limitada. La discusión abierta en este momento en todo el mundo, es si debiera reconocérseles a las DAOs personalidad jurídica diferenciada, o no, más allá de la dificultad práctica de determinar qué jurisdicción territorial es competente para asignarle un determinado status legal.
[53] Confr. European Union Blockchain Observatory and Forum, Legal and regulatory…o.c., p. 31. Ciertos contratos inteligentes pueden programarse para tomar decisiones “por su cuenta”.¿Puede un software ser considerado un representante de una parte? ¿Debiera desarrollarse una nueva categoría de persona, que no es humana ni jurídica, sino electrónica? Recordar siempre que el software, como cualquier creación humana, es falible y puede contener bugs. ¿Quién responde por los daños y perjuicios causados por un smart contract mal programado?¿Hay un representado a quién demandar?¿Debiera el representante contratar un seguro de responsabilidad civil por actuación digital perjudicial a terceros? Como señala el informe del Observatorio Europeo: “The answers to such questions are important. There is always a possibility that a smart contract has a flaw, that the integrity of the blockchain is corrupted. In these situations questions of liability immediately arise, as has been set out above, putting coders, miners and other stakeholders at risk. To promote decentralised forms of cooperation on a DLT
as means to develop commercial ventures, the cooperating entities - be they private or public
- may wish to run the blockchain/DLT and use applications on top through a legal vehicle. This can be a for-profit company (e.g.: LLP, GmBH, Société Anonyme) or a not-for-profit legal vehicle (e.g. foundation). Whatever the choice, implications for liability emerge. The choice of the legal vehicle and its registration also have immediate fiscal repercussions. It has so far not been explored whether legal vehicles available under national regimes suffice to serve as underpinning autonomous smart contracts and other forms of decentralised DLT co-operation that operate cross-border across regions and continents, or whether a specific new legal vehicle of a transnational nature would be required.” El resaltado es mío.
[54] Confr. Samuel Bourque y Sara Fung Ling Tsui, A lawyer’s introduction to smart contracts…o.c., p. 5, señalan que no es una novedad que ciertos términos contractuales sean parcialmente codificados para automatizar su ejecución, sin requerir actividades manuales. Por ejemplo, comprar una canción por iTunes: una vez confirmado el pago, el cumplimiento de la contraprestación se encuentra totalmente automatizado.
[55] Ibid. Señalan Bourque y Tsui que en muchos casos el contrato convencional subyacente es un contrato por adhesión, redactado por el vendedor, mientras que el código que ejecuta éstos términos no está incluido ni expuesto en ellos, está físicamente separado, en muchos casos siendo una práctica comercial poco transparente.
[56] Ibid. Es posible que el código esté bajo custodia del vendedor/proveedor, y que el comprador no tenga derecho a auditarlo, por razones de seguridad de los sistemas informáticos del vendedor. También es posible que el código del contrato esté bajo custodia y control de una tercera parte, con lo que ni el vendedor ni el comprador tienen control sobre el mismo, y en principio habría allí más transparencia sobre los términos codificados.
[57] Confr. Christopher Clack, Vikram Bakshi y Lee Braine, Smart contracts templates: foundations, design landscape and research directions, recuperado el 23/04/2020 en https://arxiv.org/abs/1608.00771, p. 2, siguiendo a Josh Stark, Making sense of blockchain smart contracts, recuperado el 25/04/2020 en https://www.coindesk.com/ making-sense-smart-contracts.
[58] Véase infra § 2.4.6.
[59] Véase infra § 2.5.3.
[60] Confr. Samuel Bourque y Sara Fung Ling Tsui, A lawyer’s introduction...o.c. p. 17. Sostienen los autores que el smart contract sería el fiduciario, y las partes que lo programan serían fiduciantes y beneficiarios o fideicomisarios. El código programado es la manda fiduciaria, y el activo fiduciario serían los bienes que el smart contract controle. En nuestro derecho, el fiduciario debe ser una persona humana o jurídica.
[61] Ibid. Dado que un contrato inteligente puede ser programado para celebrar otros contratos, se ha considerado la posibilidad de considerarlo un representante convencional de la o las partes. Al igual que respecto del fiduciario, en nuestro derecho el representante debe ser una persona humana o jurídica.
Sin perjuicio de lo anterior, Riikka Koulu, o.c., p. 55, nota 50, señala que los consumidores –y los prosumidores, con más razón– podrían beneficiarse de smart contracts que los representen, existiendo un gran “potential from the perspective of consumer protection in online transactions, where consumers' possibilities of negotiating their own contract terms has otherwise become compromised. He suggests that automated agents could help in restoring consumers' bargaining power by searching and concluding an online contract on their behalf without relying on e-commerce intermediaries' standard terms or revealing the consumers' identity beyond their capability to pay for the transaction. However, Fairfield identifies several challenges for actualising the potential of smart contracts: the technology is not yet commoditised, it is unclear, how companies will react to consumer- oriented contract terms and how individualised contract negotiations will affect overall transaction costs.” El resaltado es mío.
[62] Ibid. ¿Podría un contrato inteligente ser considerado una persona jurídica? La discusión también se predica respecto de las DAOs y DACs, véase supra notas 219 a 223. El Art. 141 del CCCN reza: “Son personas jurídicas todos los entes a los cuales el ordenamiento jurídico les confiere aptitud para adquirir derechos y contraer obligaciones para el cumplimiento de su objeto y los fines de su creación.” El resaltado es mío.
[63] Confr. Gabrielle Patrick y Anurag Bana, miembros del IBA Legal Policy & Research Unit Legal Paper, en Rule of Law Versus Rule of Code: A Blockchain-Driven Legal World, recuperado el 10/05/2020 en https://www.google.com/url? sa=t&rct=j&q=&esrc=s&s ource=web&cd=6&ved=2ahUKE wi5zPvGwqnpAhUDHrkGHX ccCTwQFjAFegQIBhAB&url= https%3A%2F%2Fwww.ibanet.org%2FDocument%2F Default.aspx%3FDocumentUid% 3D73B6073F-520D-45FA-A29B -EF019A7D7FC9&usg=AOvVa w1Wtx9ZZkf0ltdfa1eqvS_f, p. 39.
[64] Confr. Samuel Bourque y Sara Fung Ling Tsui, A lawyer’s introduction to smart contracts…o.c., p. 23.
[65] Confr. Harry Surden, Computable Contracts, publicado por la Universidad de California en Davis, en su Revista de Derecho, vol. 46, nº 629, disponible al 17/04/2020 en https://papers.ssrn.com/sol3 /papers.cfm?abstract_id=2216866.
[66] Harry Surden, Computable Contracts…o.c., p. 631, nota 1.
[67] Puede ampliarse –en general– en la página de la International Legal Technology Association, https://www.iltanet.org/about, y en particular, sobre Legal-AI en: Joe Dysart, AI removes the drudgery from legal due diligence, recuperado el 14/04/2020 en https://cacm.acm.org/news/233886-ai -removes-the-drudgery-from-legal- due-diligence/fulltext, sosteniendo que “AI due diligence software, found that AI was better at finding loopholes and other risks in proposed non-disclosure agreements than professional veterans”; Ben Klaber, en Artificial Intelligence and Transactional Law: Automated M&A Due Diligence, recuperado el 14/04/2020 en http://users.umiacs.umd.edu/~oard/ desi5/additional/Klaber.pdf, sosteniendo que los “intelligent electronically stored information (ESI) management systems are now commonly used” y afirmando que “an integrated human and machine-learning process can identify, classify, organize, prioritize and highlight documents, which must be disclosed pursuant to some type of business combination agreement (e.g., stock purchase agreement), with higher efficacy and speed and lower cost than humans can alone”. Para un mapeo de la variedad de servicios legales potenciados por la Inteligencia Artificial, véase, en general: Alex Crowley, AI and legal services in 2020, recuperado el 15/04/2020 en https://www.iltanet.org/blogs/alex-crowley 1/2020/02/04/ai-and-legal -services-in-2020?ssopc=1.
[68] Harry Surden, Computable Contracts…o.c., p. 660, nota 120 y ss., trae como ejemplos “actuales” (en 2012) los contratos financieros de swap de tipos de cambio, y los contrato de opción sobre acciones, y contratos de distribución on line de contenidos digitales vía streaming que especifican jurisdicciones admitidas y no admitidas a través de datos vinculados al IP de una computadora.
[69] Harry Surden, Computable Contracts…o.c., p. 632.
[70] El proceso por el cual los algoritmos permiten o facilitan que las computadoras entiendan el lenguaje natural (humano) se conoce como Natural Language Processing (NLP). Para una revisión del estado del arte a 2019 sobre el NLP aplicado al lenguaje contractual, véase Mark Sears, AI challenges and why legal is a great place to kick-start great NLP, recuperado al 16/04/2020 en https://www.forbes.com/ sites/marksears1/2019/05/14/ai- challenges-and-why-legal-is-a-great -place-to-kick-start-great-nlp/#56e5c87c4408, quien sostiene que “a machine can review in seconds what would take an expensive attorney hours to review. Heretik, a company based in Chicago, Ill., uses machine learning (ML), specifically NLP, to automate tasks related to the legal domain, such as contract review and project forecasting.” El futuro llegó, hace rato.
[71] Harry Surden, Computable Contracts…o.c., p. 633.
[72] Idem, p. 658. Se afirma allí que se pueden crear instrucciones computarizadas que reflejan la intención de las partes contratantes en ciertas clásuales específicas, a través de datos que tienen un sentido específicamente asignado, y que permiten determinar si ciertos hechos transformados en datos son contestes con términos contractuales especificados ex ante. Y el resultado de tales instrucciones computables, servirá como un primer “chequeo” del cumplimiento del contrato, pudiendo o no convertirse en una consecuencia legal conclusiva.
[73] Idem, p. 664. No todo término o condición contractual es computable. La semántica es la disciplina de las Ciencias de la Computación que estudia cómo traducir a lenguaje no humano las palabras o conceptos que tienen un sentido determinado en el lenguaje humano. Así, la claridad de Surden se trae, nuevamente, a colación: “To tell a computer what a word means, in many cases, is to provide a translation between a given word and a set of computer instructions producing outputs that are consistent with what a person would understand the word to mean” y “it is sometimes possible to functionally convey meaning to computers, and that functional translation may be sufficient for particular computing purposes — including creating computable contract terms. In other words, given a particular concept, there may be a functional, computer-processable “translation” of the meaning of that word, if one can find a set of computer instructions, or data-relationships, that produce output that is consistent with what a person with a deep conceptual understanding would expect”. “The computer has been provided with a set of automatable computer instructions resulting in outputs that are consistent with what a person, with a conceptual understanding of the term, would have intended — an approximation of meaning based upon functional output.” Los resaltados son míos.
[74] Idem, p. 636.
[75] Idem, p. 667. La expresión cláusulas legibles por una computadora, en realidad significa que “parties wishing to create computable contract terms can sometimes (but not always) devise a set of computer instructions that act as functional translations of contract terms. This permits automated comparisons, which can be consistent with the limitations that the parties intended to convey, but which employ computer processes to lower certain transaction costs. Computers can be told the meaning of the words directly, or they can be told how to find information necessary to determine what a word means”. El resaltado es mío.
[76] Idem, p. 642. Son ejemplo de un contrato electrónico los términos y condiciones de un WebSite, y la contratación vía e-mail, entre otros.
[77] Idem, p. 650, sostiene que no todas las cláusulas deben ser “traducidas” a machine-readable format en un data-oriented contract, sino sólo aquéllas que (i) puedan ser convertidas a un lenguaje no humano, e.g., precios, fechas, cantidades, y (ii) tenga algún sentido de negocio (o económico) hacerlo.
[78] Idem, p. 669. Surden introduce el concepto de captured legal assertions. “The general idea behind a “captured legal assertion” is to have a qualified person — someone who has the ability to employ professional or subject matter judgment — and have that person apply that judgment to a set of facts. We might sometimes “capture” the results of that judgment as computer- processable data … parties can sometimes effectively give the computer access to the results of an earlier judgment made by a person who does have the capacity to make such an assessment, by expressing those results as data.”El resaltado es mío.
[79] Confr. Harry Surden, Computable Contracts…o.c., p. 651, los define como contratos convencionales, redactados en lenguaje humano, que se negocian y firman antes de comenzar a desarrollar los data-oriented agreements, y que establecen las condiciones de éstos últimos, cómo deben interpretarse específicamente los datos colectados, y cuáles serán las reglas para gestionar excepciones no anticipadas. Estos contratos, según Surden y en opinión que se comparte, son de gran importancia ya que vinculan (i) lo que las partes entendieron al momento de contratar –su intención expresada– y (ii) la representación computacional de sus obligaciones.
El Art. 1063 del CCCN, titulado Significado de las palabras, sostiene que “Las palabras empleadas en el contrato deben entenderse en el sentido que les da el uso general, excepto que tengan un significado específico que surja de la ley, del acuerdo de las partes o de los usos y prácticas del lugar de celebración conforme con los criterios dispuestos para la integración del contrato. Se aplican iguales reglas a las conductas, signos y expresiones no verbales con los que el consentimiento se manifiesta”. El Art. 1065, titulado Fuentes de interpretación, sostiene que “Cuando el significado de las palabras interpretado contextualmente no es suficiente, se deben tomar en consideración: (a) las circunstancias en que se celebró, incluyendo las negociaciones preliminares; (b) la conducta de las partes, incluso la posterior a su celebración; y (c) la naturaleza y finalidad del contrato.”
Si la finalidad de las partes fuera la de celebrar un contrato computable, o un Smart Contract, sin dudas deberán celebrar un contrato convencional donde precisen el significado de las palabras y cómo éstas se reflejarán en el lenguaje de la máquina –que puede ser considerado un conjunto de signos–, precisando las circunstancias específicas que hacen conveniente y justifican que ciertas obligaciones se automaticen mediante un código de programación, cualquiera sea el lenguaje –signos– de programación empleado(s), e independientemente de su ejecución –i.e., transcripción en signos que la máquina entiende– en una cadena de bloques, o en servidores centrales controlados por cada parte contratante.
[80] Harry Surden, Computable Contracts…o.c., p. 653, nota 93.
[81] Surden, o.c. p. 655 los define como contratos que fijan reglas de procedimiento sobre cómo incluir futuras cláusulas data-oriented, sin detenerse en el significado de éstas, sino enfocándose en la necesidad de dotar de carácter contractual a los datos que se ingresen, incluyendo reglas sobre cómo proceder si aparecen errores en los datos. En el caso de los contratos derivados, este procedural agreement es un “estándar” al que directamente las partes se remiten, como si fueran, mutatis mutandis, un INCOTERM. Confr. ISDA, Legal guidelines for smart derivatives contracts: the ISDA Master Agreement, Febrero de 2019, disponible el 16/04/2020 en https://www.isda.org/ a/23iME/Legal-Guidelines- for-Smart-Derivatives-Contracts -ISDA-Master-Agreement.pdf.
[82] Harry Surden, Computable Contracts…o.c., p. 683.
[83] Idem, p. 689.
[84] Idem, p. 694. Surden se refiere a esta posibilidad como autonomous computable contracting, o bien podríamos decir Smart Contracting en terminología del año 2020. Constituye una práctica ya muy conocida en los mercados financieros, que entrenan y recurren a trading algorithms. Con razón indica Surden que para poder llegar al estadío de autonomous computable contracting, antes debe necesariamente transitarse el camino de los computable contracts.
[85] Confr. Samuel Bourque, Ethereum HK: Samuel Bourque on Smart Contracts and DAOs, video de YouTube disponible el 24/04/2020 en https://www.youtube.com/ watch?v=cTYqRClh3Mo.
[86] Confr. Samuel Bourque, Ethereum HK: Samuel Bourque on Smart Contracts and DAOs, video de YouTube disponible el 24/04/2020 en https://www.youtube.com /watch?v=cTYqRClh3Mo.
[87] Confr. Jared Arcari, en Decoding Smart Contracts…o.c., p. 373. Véase también, del mismo autor, Smart Contract Basics – A legal contract perspective, recuperado el 16/04/2020 de https://medium.com/ fordham-business -law-association/smart-contract -basics-a-legal-contract -perspective-8da04b022973.
[88] Ibid.
[89] Confr. Fan Zhang, Ethan Cecchetti, Kyle Croman, Ari Juels y Elaine Shi, Town crier: an authenticated data feed for smart contracts, disponible el 16/04/2020 en https://www.researchgate.ne t/publication/308691770_ Town_Crier_An_Authenticated_ Data_Feed_for_Smart_Contracts.
[90] Confr. Gideon Greenspan, Why many smart contract use cases are simply impossible.. o.c.
[91] Confr. Eliza Mik, Smart Contracts: terminology, technical limitations…o.c., p. 296.
[92] Las siguientes empresas ofrecen estos servicios: www.realitykeys.com y www.oraclize.it. Es también interesante el Oráculo de Thompson Reuters, BlockOne IQ. Véase https://blockoneiq.thomsonreuters.com
[93] Confr. Eliza Mik, Smart Contracts: terminology, technical limitations…o.c., p. 298.
[94] Confr. Vitalik Buterin, Ethereum and Oracles, 22/07/2014, recuperado el 16/04/2020 en https://blog.ethereum.org/ 2014/07/22/ethereum-and-oracles/.
[95] Confr. https://www.swift.com/about-us.
[96] Confr. https://create.smartcontract.com/sibos17, disponible al 15/04/2020.
[97] Confr. https://www.financedigest.com/ smartcontract-com-used-by-swift- announces-technical-leaders-as-advisors- launches-chainlink-to-connect-smart- contracts-to-off-chain-data-payments.html, recuperado el 17/04/2020.
[98] Confr. Jared Arcari, en Decoding Smart Contracts…o.c., p. 373.
[99] Confr. Jared Arcari, Smart Contract Basics – A legal contract perspective Part II: Verifiability, recuperado al 17/04/2020 en https://medium.com/ fordham-business-law-association/ smart-contract-basics-a-legal-contract -perspective-part-ii-verifiability-4bc5c4ca8b88.
[100] Ibid. Véase el caso de la empresa CodeLegit, confr. https://datarella.com/codelegit- conducts-first-blockchain-based- smart-contract-arbitration-proceeding/, recuperado el 18/04/2020.
[101] Ibid.
[102] Ibid.
[103] El CCCN consagra este principio en los Art. 1021 y 1022: “Regla general. El contrato sólo tiene efecto entre las partes contratantes; no lo tiene con respecto a terceros, excepto en los casos previstos por la ley.”
Art. 1022.- Situación de los terceros. El contrato no hace surgir obligaciones a cargo de terceros, ni los terceros tienen derecho a invocarlo para hacer recaer sobre las partes obligaciones que éstas no han convenido, excepto disposición legal.”
[104] Confr. Michael Smolenski, Smart contracts: privacy vs. confidentiality, recuperado el 16/04/2020 en https://hackernoon.com/ smart-contracts-privacy- vs-confidentiality-645b6e9c6e5a.
[105] ZKP es un método de encriptación, un nuevo protocolo que permite agregar una nueva capa de seguridad para operar en blockchain. Permite que un usuario demuestre a otro que sabe o conoce un valor absoluto X, sin dar ninguna otra información sobre qué es o para que sirve X. Ampliar en Hasib Anwar, What is ZKP? A complete guide to Zero Knowledge Proof, recuperado el 16/04/2020 en https://101blockchains.com/zero-knowledge-proof/#2. Véase también el protocolo zk-SNARKs, acrónimo de Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, que refiere a una construcción de prueba en la que se puede demostrar la posesión de cierta información, por ejemplo, una clave secreta, sin revelar esa información, y sin ninguna interacción entre el proveedor y el verificador, disponible al 15/04/2020 en https://z.cash/es/ technology/zksnarks/.
[106] Confr. Michael Smolenski, Smart contracts…o.c. afirma que los llamados State Channels permiten que en la blockchain solo se registre una referencia a una transacción exitosa, pero la transacción en sí no se realiza en la blockchain. Son muy útiles cuando hay micropagos entre dos partes, pero en alguna medida eliminan los atributos más sobresalientes de la blockchain: dejar un registro abierto, transparente e inmutable.
[107] Confr. Jared Arcari, en Decoding Smart Contracts…o.c., p. 375.
[108] La confidencialidad en materia contractual convencional está regulada en el Art. 992 del CCCN y en la Ley Nº 24.766 (B.O. 30/12/1996). El primero dispone: “Deber de confidencialidad. Si durante las negociaciones, una de las partes facilita a la otra una información con carácter confidencial, el que la recibió tiene el deber de no revelarla y de no usarla inapropiadamente en su propio interés. La parte que incumple este deber queda obligada a reparar el daño sufrido por la otra y, si ha obtenido una ventaja indebida de la información confidencial, queda obligada a indemnizar a la otra parte en la medida de su propio enriquecimiento.”
La Ley 24.766, a su turno, dispone:
“Art.1°- Las personas físicas o jurídicas podrán impedir que la información que esté legítimamente bajo su control se divulgue a terceros o sea adquirida o utilizada por terceros sin su consentimiento de manera contraria a los usos comerciales honesto, mientras dicha información reúna las siguientes condiciones:(a) sea secreta en el sentido de que no sea, como cuerpo o en la configuración, reunión precisa de sus componentes, generalmente conocida ni fácilmente accesible para personas introducidas en los círculos en que normalmente se utiliza el tipo de información en cuestión; y (b) tenga un valor comercial por ser secreta; y (c) haya sido objeto de medidas razonables, en las circunstancias, para mantenerla, secreta, tomadas por la persona que legítimamente la controla.
Se considerará que es contrario a los usos comerciales honestos el incumplimiento de contratos, el abuso de confianza, la instigación a la infracción y adquisición de información no divulgada por terceros que supieran o no, por negligencia grave, que la adquisición implicaba tales practicas.
Art. 2°- La presente ley se aplicará a la información que conste en documentos, medios electrónicos o magnéticos, discos ópticos, microfilmes, películas u otros elementos similares.”(el resaltado es mío).
[109] La expresión Altcoin hace referencia a toda criptomoneda similar a bitcoin. A principios del año 2020, existen ya más de 5.000 altcoins, y representan el 34% de todo el cryptomarket. Confr. https://www.investopedia.com/terms/a/altcoin.asp, recuperado el 16/04/2020.
[110] Confr. Michael Smolenski, Smart contracts…o.c. proponiendo un enfoque en este sentido a través de LightStreams, confr. https://lightstreams.network.
[111] Confr. Jordan Clifford, Privacy on the blockchain, disponible al 18/04/2020 en https://medium.com/hackernoon/privacy-on-the-blockchain-7549b50160ec.
[112] Confr. Samuel Bourque y Sara Fung Ling Tsui, A lawyer’s introduction to… p. 13, indican que “Pseudo-anonymity is an interesting concept; it ought not to be as intimidating a term as it sounds. A simple way to look at it, is to examine how email addresses do not in-and-of themselves reveal the identity of the person; only if one has the email registered in his own address book would he know who the person is. There is no centralized registration of databases and new, free emails can be created on a whim. The same is true of cryptocurrency wallets. The major difference is that wallets are not human-readable, to the point where one could perhaps not recognize his own wallet address. Otherwise, all is unchanged, the cryptocurrency wallet address is a one-way unique identifier that guarantees reaching a person’s pocketbook, or inbox, but does not reveal the person’s identity (…) as wallet addresses will not inherently provide any clues to the party’s identities. An additional consideration is the encryption of the body of the SC. The authorities may attach the SC via injunction, but neither its content, nor the parties’ may be interpretable or identifiable without the parties’ encryption keys.” El resaltado es mío.
[113] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute resolution, publicado en The Business Lawyer, Primavera 2019, p. 16.
[114] Ibid.
[115] Idem, p. 37, nota 82, se señala allí que “Like the government or any other authority, hackers are unable to interfere in blockchain because of public-key encryption”.. y que “When consumers send information over the internet, nearly anyone can get that information because it travels through many uncontrolled nodes. But, public-key encryption guarantees that anyone reading the information cannot understand it unless they were accepted by the respective consumer to have the key. If hackers could break public-key encryption they would instantaneously be able to influence and control a significant proportion of the existing wealth of nations.” El resaltado es mío.
[116] Idem, p. 18. ECDSA significa Elliptic Curve Digital Signature Algorithm. Señalan Kaal y Calcaterra que: “This scheme uses elliptic curve algebra in order to garble the message, but otherwise it is very similar to the RSA method of taking powers of large numbers with modular arithmetic. ECDSA also naturally incorporates a changing scale of encryption strength, which is one minor way bitcoin security responds automatically to improvements in computing power through the years, giving users long term confidence in the system. The public-key algorithm makes the location and ownership of bitcoins as perfectly anonymous within the system as is practically possible. Experts are confident this protocol will resist any foreseeable development in computing, such as changes in hardware like the imaginable switch from electronic to quantum computing.”El resaltado es mío.
[117] Confr. Wulf A. Kaal y Craig Calcaterra..o.c., p. 23 sostienen: “With the use of public-key cryptography and cryptographic hash functions, blockchain architecture gives its users long term confidence in anonymity, security, and decentralized autonomy. Users’ accounts are encoded by private keys, so their information is securely encrypted. They have complete power over whether they share information and with whom. When sharing generic information, such as the fact that they own more than 10 bitcoins, they reveal no private information. Further, each time a transaction is made, a new private key can be made. So, while we can track the public key of the addresses of each transaction, and that information is stored eternally in the blockchain, each transaction allows for an entirely new private identity which is cryptographically secured. This gives more anonymity in business transactions than ever before imagined.” (el resaltado es mío).
[118] Idem, p. 48, nota 97, levantan el punto de la anonimidad versus la capacidad de almacenamiento de datos, en estos términos: “The blockchain is immutable. All that is stored in blockchain remains there forever and cannot be deleted. This is a serious drawback, given that most of the information in the interaction of users can be temporary and it could be deleted when the need for its storage disappears. Eternal storage of information also works against anonymity. Each node is a complete replica of other nodes. As a result, with the explosive growth of the application's popularity on the blockchain, the size of the blockchain grows rapidly at all nodes simultaneously. At some point, the size of blockchain can exceed the capacity of mass-produced hard disks and for the operation of the nodes, special equipment will be required, which only large companies can afford, which leads to dangerous centralization.” El resaltado es mío.
[119] Confr. https://www.elliptic.co y https://www.chainalysis.com, citados por Jordan Clifford, Privacy on the blockchain…o.c.
[120] Confr. https://bitcointalk.org/index.php?topic=279249.0 y https://themerkle.com/ top-4-reliable-bitcoin-mixers/, citados por Jordan Clifford, Privacy on the blockchain…o.c.
[121] Confr. Konstantinos Christidis y Michael Devetsikiotis, en Blockchains and Smart Contracts for the Internet of Things….o.c., p. 2300.
[122] Confr. Pedro Febrero, What on-chain analytics tell us about bitcoin transactions in 2020? Recuperado el 16/04/2020 en https://cointelegraph.com /news/what-on-chain-analytics-tell-u s-about-bitcoin-transactions-in-2020.
[123] UTXO significa Unspent Transaction Output. Ampliar en Steven Buchko, What is a UTXO? A beginner’s explainer on transactions outputs, disponible al 16/04/2020 en https://coincentral.com/utxo-beginners-explainer/.
[124] Confr. Jordan Clifford, Privacy on the …o.c.
[125] Confr. Ahmed Kosba, Andrew Miller, Elaine Shi, Zikai Wen y Charalampos Papamanthou, Hawk: The blockchain model of cryptography and privacy-preserving smart contracts, recuperado el 16/04/2020 en https://ieeexplore.ieee.org/ stamp/stamp.jsp?tp=& arnumber=7546538.
[126] Ampliar en Ameer Rosic, Cryptocurrency Wallet Guide: a step-by-step tutorial, disponible al 16/04/2020 en https://blockgeeks.com/guides /cryptocurrency-wallet-guide/.
[127] Ibid.
[128] La tragicomedia ocurrió en 2013, cuando sin querer una persona tiró un pen drive, que contenía la llave privada asociada a una llave pública que tenía 7.500 bitcoins. Ampliar en https://cointelegraph.com/news/infamous-discarded-hard- drive-holding-7500-bitcoins-would -be-worth-80-million-today, recuperado al 16/04/2020.
[129] Aunque se está avanzando en técnicas de recuperación de llaves privadas. Ampliar en Antoine Herzog, Private key recovery – decentralize user’s responsability, disponible al 15/04/2020 en https://medium.com /iov-internet-of-values/private- key-recovery-decentralize-users- responsibility-88fa60ee905.
[130] Confr. Connor Blenkinsop, How to recover your wallet if your private keys are lost, recuperado el 16/04/2020 en https://cointelegraph.com/ news/how-to-recover- your-wallet-if-your-private-keys-are-lost.
[131] Sirve de muestra el ejemplo del robo ocurrido en Enero de 2018 en Japón por un monto cercano a los 500 millones de Dólares en una criptomoneda llamada NEM. La víctima fue un Exchange japonés llamado CoinCheck, que alojaba todas las llaves privadas de las cuentas de sus clientes en una hot wallet. Es el segundo robo más grande en la historia de las criptomonedas, luego del caso Mt Gox en 2014, de donde se robaron una cantidad de bitcoins que en aquel momento equivalía al 6% de todo el circulante, llevando a la quiebra a Mt Gox.
En el caso CoinCheck traído a colación, se robaron 500 millones de tokens de la criptomoneda NEM, que se distribuyeron luego en 19 direcciones de la blockchain. CoinCheck indemnizó a los 260.000 usuarios perjudicados y desde la Foundación NEM se identificó los 500 millones de tokens robados, colocando un aviso para que todo el mundo supiera que eran robados y se identificó e hizo públicas once direcciones que alojaban parte de los tokens robados, pero sin saberse quiénes eran los dueños de las cuentas. Los ladrones finalmente pudieron cambiar los tokens en exchanges no regulados, que no tienen procedimientos de KYC y AML. Ampliar en Brian Curran, The history of the CoinCheck Hack: one of the largest Heists ever, disponible al 16/04/2020 en https://blockonomi.com/ coincheck-hack/.
[132] Confr. Will Douglas Heaven, Sitting with the cyber-sleuths who track cryptocurrency criminals, MIT Technology Review, 19 de Abril de 2018, recuperado el 16/04/2020 en https://www.technologyreview.com/ 2018/04/19/3011/sitting-with-the-cyber -sleuths-who-track-cryptocurrency-criminals/.
[133] Ibid.
[134] Ibid.
[135] Para ampliar sobre desarrollos actuales del clustering, véase la obra de Sudarshan S. Chawathe, Clustering blockchain data: techniques, toolboxes and applications, publicado en el libro Clustering Methods for Big Data Analytics, y disponbile al 15/04/2020 en https://www.researchgate.net/ publication/328570658_Clustering_ Blockchain_Data_Techniques_ Toolboxes_and_Applications.
[136] Confr. Will Douglas Heaven, Sitting with the cyber-sleuths…o.c.
[137] Véase https://z.cash/es/.
[138] Véase https://www.getmonero.org.
[139] Ampliar en https://cointelegraph.com/ news/us-prosecutors-indict-btc-e -crypto-exchange-seek-millions- in-penalties, recuperado el 16/04/2020.
[140] Confr. Jared Arcari, en Decoding Smart Contracts…o.c., p. 375.
[141] Confr. Christopher Clack, Vikram Bakshi y Lee Braine, Smart contracts templates…o.c. precisan que “We say that a smart contract is “automatable” rather than that it is “automated” because in practice there may be parts of a legal agreement whose performance requires human input and control. However, to be a “smart contract” we require that some part of the agreement is capable of being automated (otherwise it is not “smart”). Automation is generally accomplished by the use of one or more computers. The phrase “by electronic means” is a synonym. Our definition of smart contract does not require that this automation occurs on a shared ledger, though that is certainly a possible and even probable method.” El resaltado es mío.
[142] El CCCN dispone en su Art. 390: “Restitución. La nulidad pronunciada por los jueces vuelve las cosas al mismo estado en que se hallaban antes del acto declarado nulo y obliga a las partes a restituirse mutuamente lo que han recibido. Estas restituciones se rigen por las disposiciones relativas a la buena o mala fe según sea el caso, de acuerdo a lo dispuesto en las normas del Capítulo 3 del Título II del Libro Cuarto.”
[143] Confr. Christopher Clack, Vikram Bakshi y Lee Braine, Smart contracts templates…o.c. p. 3 ejemplifican tales causas extrañas al contrato inteligente con deficiencias en la entrega física de bienes.
[144] Idem, p. 4, ven con cierto temor la posibilidad real de implementar medios no tradicionales de resolución de conflictos para contratos inteligentes, ya que: (i) los sistemas distribuidos como la blockchain, no permiten modificar el código de un smart contract una vez iniciado; (ii) los contratos de la vida real normalmente necesitan un “ajuste dinámico”, y todos estos ajustes debieran forzosamente ser codificados ex ante si el contrato corre en una blockchain; (iii) el cumplimiento forzoso dentro de la red sólo puede referirse a derechos y obligaciones que están “dentro de la red”, quedando afuera objetos y derechos off-chain; y (iv) para el caso de smart contracts que permiten automatizar pagos, para prevenir posibles perjuicios por ejecución deficiente, debieran constituirse garantías que también operarían de modo automático, quedando afectadas siempre al contrato que “afianzan”. Estas garantías pueden afectar la liquidez del mercado, y su capacidad de apalancamiento financiero.
[145] Ibid.
[146] En el caso de EE.UU, legislación a nivel federal (Uniform Commercial Code y la Electronic Signatures in Global and National Commerce Act, conocida como la E-Sign Act) así como legislación estadual que sigue el modelo de la Uniform Electronic Transactions Act los ha reconocido como contratos sin mayores reparos.
[147] El CCCN dispone en su Art. 1084: “Configuración del incumplimiento. A los fines de la resolución, el incumplimiento debe ser esencial en atención a la finalidad del contrato. Se considera que es esencial cuando: (a) el cumplimiento estricto de la prestación es fundamental dentro del contexto del contrato; (b) el cumplimiento tempestivo de la prestación es condición del mantenimiento del interés del acreedor; (c) el incumplimiento priva a la parte perjudicada de lo que sustancialmente tiene derecho a esperar; (d) el incumplimiento es intencional; (f)el incumplimiento ha sido anunciado por una manifestación seria y definitiva del deudor al acreedor.”
[148] El CCCN dispone en su Art. 1104: “Contratos celebrados fuera de los establecimientos comerciales. Está comprendido en la categoría de contrato celebrado fuera de los establecimientos comerciales del proveedor el que resulta de una oferta o propuesta sobre un bien o servicio concluido en el domicilio o lugar de trabajo del consumidor, en la vía pública, o por medio de correspondencia, los que resultan de una convocatoria al consumidor o usuario al establecimiento del proveedor o a otro sitio, cuando el objetivo de dicha convocatoria sea total o parcialmente distinto al de la contratación, o se trate de un premio u obsequio.” El resaltado es mío.
[149] El CCCN dispone en su Art. 1105: “Contratos celebrados a distancia. Contratos celebrados a distan- cia son aquellos concluidos entre un proveedor y un consumidor con el uso exclusivo de medios de comunicación a distancia, entendiéndose por tales los que pueden ser utilizados sin la presencia física simultánea de las partes contratantes. En especial, se consideran los medios postales, electrónicos, telecomunicaciones, así como servicios de radio, televisión o prensa.” El resaltado es mío.
El Art. 1110, por su parte, dispone: “Revocación. En los contratos celebrados fuera de los establecimientos comerciales y a distancia, el consumidor tiene el derecho irrenunciable de revocar la aceptación dentro de los diez días computados a partir de la celebración del contrato.
Si la aceptación es posterior a la entrega del bien, el plazo debe comenzar a correr desde que esta última se produce. Si el plazo vence en día inhábil, se prorroga hasta el primer día hábil siguiente.
Las cláusulas, pactos o cualquier modalidad aceptada por el consumidor durante este período que tengan por resultado la imposibilidad de ejercer el derecho de revocación se tienen por no escritos.”
Por su parte, se consagran algunas excepciones a la facultad de revocación en el Art. 1116: “Excepciones al derecho de revocar. Excepto pacto en contrario, el derecho de revocar no es aplicable a los siguientes contratos: (a) los referidos a productos confeccionados conforme a las especificaciones suministradas por el consumidor o claramente personalizados o que, por su naturaleza, no pueden ser devueltos o puedan deteriorarse con rapidez; (b) los de suministro de grabaciones sonoras o de video, de discos y de programas informáticos que han sido decodificados por el consumidor, así como de ficheros informáticos, suministrados por vía electrónica, susceptibles de ser descargados o reproducidos con carácter inmediato para su uso permanente; y (c) los de suministro de prensa diaria, publicaciones periódicas y revistas.” Los resaltados son míos.
[150] El CCCN dispone en su Art. 1106: “Utilización de medios electrónicos. Siempre que en este Código o en leyes especiales se exija que el contrato conste por escrito, este requisito se debe entender satisfecho si el contrato con el consumidor o usuario contiene un soporte electrónico u otra tecnología similar.” El resaltado es mío.
[151] El CCCN dispone en su Art. 1107: “Información sobre los medios electrónicos. Si las partes se valen de técnicas de comunicación electrónica o similares para la celebración de un contrato de consumo a distancia, el proveedor debe informar al consumidor, además del contenido mínimo del contrato y la facultad de revocar, todos los datos necesarios para utilizar correctamente el medio elegido, para comprender los riesgos derivados de su empleo, y para tener absolutamente claro quién asume esos riesgos” El resaltado es mío.
[152] Confr. The Cardozo Blockchain Project, “Smart Contracts” & Legal Enforceability,…o.c., p. 5.
[153] Confr. The Cardozo Blockchain Project, “Smart Contracts”..o.c., p. 6.
[154] Confr. UJO Music, https://ujomusic.com. Ampliar en https://www.forbes.com/ sites/jonathanchester/2016/09/16/ how-blockchain-startups-are-disrupting- the-15-billion-music-industry/# 2b947e6a407c, recuperado el 16/04/2020 y en https://medium.com/ humanizing-the-singularity/smart-contracts -for-the-music-industry-3e641f87cc7, recuperado el 16/04/2020.
El smart contract de UJO Music permite que cuando alguien escucha una canción bajada desde UJO Music, la plataforma “…automatically triggers an agreement for everyone involved in the creative process of a song with those who choose to interact with it — fans, streaming services, or film crews (…) It was the first song to automatically distribute payments via a smart contract to all creatives involved in the making and recording of the song.”
[155] Confr. OpenBazaar, https://openbazaar.org. Ampliar en https://openbazaar.org/blog/ Escrow-Smart-Contract-Specification-in-OpenBazaar/, recuperado el 17/04/2020.
El smart contract de OpenBazaar es un escrow agreement, un depósito en garantía. Aquí se describe su funcionamiento: “When a buyer and seller have agreed on a product and a price, the buyer sends their funds to an escrow address, which is a 2-of-3 multisig address with one key controlled by the buyer, one key controlled by the seller, and one key controlled by a moderator that has been agreed upon by both the buyer and the seller. On the “happy path”, the seller delivers the goods, then the buyer releases the funds to the seller (with the buyer and seller signing the payout transaction from the escrow address).
In the event that the seller does not deliver the goods as promised, the buyer pleads their case to the moderator, and the buyer & moderator can send the funds from escrow back to the buyer.
In the (very common) case where the buyer receives their goods but doesn’t release the funds to the seller, the seller presents their case to the moderator, and the seller & moderator sign the funds from escrow to the seller. The seller can also unilaterally release funds from escrow after a previously agreed upon amount of time has passed. This allows the seller to release the funds from escrow without the moderator in the event that the buyer disappears. With UTXO-based coins, this is achieved by requiring that the buyer sign an nLockTime transaction releasing funds to the seller, and then passing that transaction to the seller (off-chain) before the seller delivers the product or service.”
[156] Visitar https://safemarket.github.io, con una propuesta de valor similar a OpenBazaar.
[157] Confr. Christopher Clack, Vikram Bakshi y Lee Braine, Smart contracts templates..o.c., p. 5 denominan “aspectos operacionales” a aquéllas cláusulas de un contrato convencional que serían automatizadas. Respecto de tales aspectos y cláusulas, señalan los autores que es posible y conveniente estudiar las “equivalencias semánticas” entre el lenguaje natural legal, y el lenguaje de programación que codifica una cláusula.
[158] Ibid. A estas cláusulas las denominan “aspectos no operacionales”: son los que no se pueden o no conviene que se automaticen.
Con muchísima claridad, Clack, Bakshi y Braine señalan que “The operational aspects of a contract would typically dictate the successful performance of the contract to completion. If a dispute arises, then the non-operational aspects of the contract would typically dictate what happens next — i.e. in the context of the rights and obligations of the parties, the specification of what remedies shall be applied in the case of contract partial-performance or non-performance by one party. The greater part of a legal contract may often be devoted to defining the rights and obligations of the parties in the event of a problem. Sometimes, the actions to be taken in case of material breach of contract are expressed precisely; however, this is not always the case and dispute resolution may require a protracted process of negotiated settlement, arbitration, or court proceedings. Furthermore, it is important to understand the role of law. A lawyer would read and understand the contract in the context of the governing law — i.e. each legal document must be interpreted according to the relevant law (corporate law, consumer law, etc.) of its stated or inferred jurisdiction, and therefore the semantics of that law must also be understood. It should be noted that the issue of law relates not only to the non-operational aspects but also to the operational aspects —for example, trading with certain countries may be illegal due to government-imposed sanctions.”
[159] Confr. The Cardozo Blockchain Project, “Smart Contracts”..o.c., p. 6.
[160] Ibid.
[161] Id., p. 7. Se afirma que gracias a los Oráculos, los smart contracts se pueden adaptar a nuevas condiciones prácticamente en tiempo real. Incluso, se pueden delegar en Oráculos humanos i.e., abogados, la constatación del cumplimiento de ciertas obligaciones que no pueden ser fácilmente codificadas.
[162] Ibid.
[163] Para ampliarse sobre el software testing, véase: https://www.guru99.com/ software-testing-introduction-importance.html, recuperado el 16/04/2020; en https://medium.com/better -programming/how-to-test-ethereum- smart-contracts-35abc8fa199d, recuperado el 18/04/2020; y en https://dev.to/smartym/how-to-test- ethereum-smart-contracts-audi t-best-practices-53kg, recuperado el 17/04/2020.
[164] Confr. Reggie O’Shields, Smart Contracts: legal agreements…o.c. p. 193.
[165] Se sigue, en general, la exposición de Eliza Mik, Smart Contracts: terminology, technical limitations…o.c., p. 298.
[166] Confr. Eliza Mik, Smart Contracts: terminology, technical limitations…o.c., p. 277.
[167] Idem, p. 280.
[168] Idem, p. 281.
[169] Confr. Samuel Bourque y Sara Fung Ling Tsui, A lawyer’s introduction…o.c. p. 17.
[170] Ibid.
[171] Pueden consultarse los siguientes casos ya detectados: eventos vinculados al software Parity: https://www.coindesk.com/ ethereum-client-bug-freezes-user- funds-fallout-remains-uncertain, recuperado el 20/04/2020; en relación a un ataque reciente realizado el 31/12/2019, véase: https://www.crowdfundinsider.com/ 2020/01/155850-hackers-exploited -parity-node-bug-to-attack-ethereum -network-december-30th/, recuperado el 20/04/2020.
Sobre errores de codificación en el HKG token, véase: https://bitcointalk.org/index.php?t opic=1744115.0, recuperado el 20/04/2020.
Sobre errores de codificación en el compilador de Ethereum, Viper, que es el encargado de traducir de lenguaje de programación al lenguaje que puede ser procesado por la EVM, véase: https://es.cointelegraph.com/ news/bugs-found-in-compiler-for- readable-ethereum-smart-contracts -team-downplays-concerns, recuperado el 20/04/2020. Otros bugs en Ethereum son señalados por Stegeman, o.c. en nota siguiente.
Sobre posibles soluciones a las vulnerabilidades de programación de smart contracts, se recomienda la lectura del interesantísimo artículo de Shuai Wang, Chengyu Zhang y Zendong Su, Detecting nondeterministic payment bugs in Ethereum smart contracts, disponible al 20/04/2020 en http://chengyuzhang.com/paper/oopsla19.pdf.
[172] Confr. Lars Stegeman, Solitor: runtime verification of Smart Contracts, recuperada al 21/04/2020 en https://fmt.ewi.utwente.nl /media/LarsStegeman_SmartContract RuntimeVerification.pdf, p.4. La tesis de maestría de Stegeman propone una herramienta para Solidity que permite detectar bugs, a la que nomina Solitor. Excede ampliamente el objeto de este Manual, y principalmente la capacidad de su autor, emitir un juicio sobre la utilidad, conveniencia o aplicabilidad real de Solitor.
[173] Véase la interesante herramienta propuesta por Yi Zhou, Deepak Kumar, Surya Bakshi, Joshua Mason, Andrew Miller y Michael Bailey, Erays: reverse engineering Ethereum’s opaque smart contracts, recuperado el 21/04/2020 en https://www.usenix.org/ system/files/conference/usenixsecurity 18/sec18-zhou.pdf.
[174] Idem, p. 288.
[175] Idem, p. 289.
[176] Confr., CCCN Art. 1061 y siguientes.
[177] El CCCN, en su Art. 1065 dispone: “Fuentes de interpretación. Cuando el significado de las palabras interpretado contextualmente no es suficiente, se deben tomar en consideración: (a) las circunstancias en que se celebró, incluyendo las negociaciones preliminares; (b) la conducta de las partes, incluso la posterior a su celebración; y (c) la naturaleza y finalidad del contrato.”El resaltado es mío.
[178] Confr. Riikka Koulu, Blockchains and Online Dispute Resolution…o.c. p. 65.
[179] Confr. Eliza Mik, Smart Contracts: terminology, technical….o.c., p. 291.
[180] Ibid.
[181] Idem, p. 293.
[182] Ibid.
[183] Idem, p. 294.
[184] Confr. Ari Juels, Ahmed Kosba y Elaine Shi, The ring of Gyges: investigating the future of Criminal Smart Contracts, recuperado el 17/04/2020 en https://www.researchgate.net/ publication/310821111_The_Ring_of_Gyges _Investigating_the_Future_of_ Criminal_Smart_Contracts.
[185] El ransomware es un tipo de delito cibernético que consiste en encriptar la información dentro de una computadora, y exigir el pago de un “rescate” para desencriptarla. Ampliar en https://us.norton.com/internetsecurity -malware-ransomware-5-dos-and-donts.html disponible al 15/04/2020.
[186] El célebre caso Silkroad sustenta muy bien el punto. Ampliar en https://medium.com/@gritarespoco/silk-road- y-el-cibermercado-ilegal- c45967853f46, recuperado el 18/04/2020. Véase también infra en 3.2.1.1.
[187] Ampliar en https://www.wired.com/2014/04 /dark-wallet/, recuperado el 18/04/2020. Durante el año 2019, aproximadamente 4.500 millones de Dólares se perdieron por esquemas fraudulentos en Bitcoin, robos de criptomonedas, y ciberataques a Exchanges, confr. CipherTrace, Q4 2019 cryptocurrency anti-money laundering report, disponible al 19/04/2020 en https://ciphertrace.com/q4-2019-cryptocurrency-anti-money-laundering-report/. En 2018, este tipo de actividad ilegal representó pérdidas por 1.360 millones de Dólares, confr. Vandana Beessoo, Money laundering through Bitcoin: the emerging implications of technological advancement, disponible el 19/04/2020 en https://papers.ssrn.com/ sol3/papers.cfm?abstract_id= 3468300&download=yes.
[188] Confr. Ari Juels, Ahmed Kosba y Elaine Shi, The ring of Gyges…o.c. p. 2.
[189] Ampliar en https://github.com/darkwallet/ darkleaks, recuperado el 18/04/2020.
[190] Confr. Ari Juels, Ahmed Kosba y Elaine Shi, The ring of Gyges…o.c. p. 6.
[191] Idem, p. 10.
[192] Confr. Hisashi Oki, Blacklists aren´t enough to stop crypto fraud, recuperado el 18/04/2020 en https://cointelegraph.com /news/blacklists-arent-enough -to-stop-crypto-fraud.
[193] Confr. Max Boddy, US Treasury targets crypto addresses of alleged narcotics trafickers, recuperado el 18/04/2020 en https://cointelegraph.com /news/us-treasury-sanctions-bitcoin- litecoin-addresses-under-kingpin-act.
[194] Confr. Ari Juels, Ahmed Kosba y Elaine Shi, The ring of Gyges…o.c. p. 13.
[195] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction …o.c. p. 40 aclaran el punto en estos términos: “an Ethereum transaction is a complete smart contract. Therefore, the whole contract is either added to the blockchain or not. An Ethereum transaction can’t be partially added to the blockchain. The second interpretation is the contract transactions between the parties. It is possible that parties can partially fulfil a smartcontract. But in that case the smart contract already has all eventualities accounted for—it is completely self-executing and self-regulating. Therefore, if one provision of the contract is fulfilled and another is not, the consequences of that situation is already stipulated in the code with mathematical inevitability. Whatever the program stipulates will happen, happens; including if nothing happens.” El resaltado es mío.
[196] Confr. Konstantinos Christidis y Michael Devetsikiotis, en Blockchains and Smart Contracts for the Internet of Things….o.c., p. 2300, quienes ejemplifican la integración dual del siguiente modo: “(a) deploy the smart contract in question, record its address on the blockchain, and include that address in the real contract (b) hash the corresponding real-world contract, record its hash digest, store the real contract in a safe space (can be centralized, or decentralized), (c) send a transaction to the smart contract that includes the real contract’s hash in its metadata; the contract then stores that piece of information in its own, internal database. In case of a legal dispute, you can point to the hash stored in the smart contract, then present the real-world contract (that is uniquely identified by that hash) and prove the link between the actions on the blockchain and the expected outcome in the physical world.” El resaltado es mío.
[197] Ampliar en https://www.w3.org/2016/04/blockchain-workshop/interest/hazard-hardjono.html, recuperado el 22/04/2020.
[198] Confr. https://medium.com/ @OpenLawOfficial/accelerating-the- transformation-of-the-legal-industry -9d349535190f recuperado el 22/04/2020.
[199] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction …o.c. p. 38.
[200] Ibid.
[201] Ibid, véase también nota 83 y doctrina allí citada.
[202] Idem, p. 41. Ampliar sobre contratos inteligentes reversos infra en § 2.6.
[203] Confr. Reggie O’Shields, Smart Contracts: legal agreements for …o.c. p. 191 indica que el operador de una blockchain puede estipular qué ley será aplicable y quién será el juez competente para los contratos que en ella se ejecuten.
[204] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction …o.c. véase en particular notas 84 y 85 y doctrina allí citada.
[205] Idem, p. 43. Sostienen los autores citados que: “The exercise of traditional jurisdictional means over the creator of blockchains may encounter problems over time. First, it is only a matter of time until blockchains are created by other blockchains. Moreover, governing the creation of blockchains may encounter practical problems associated with anonymity. For instance, Satochi, the billionaire founder of bitcoin is unknown and most hackers make it their personal hobby to ascertain his/her identity.” 
[206] Idem, p. 39 y nota al pie 88.
[207] Confr. Reggie O’Shields, Smart Contracts: legal agreements…o.c. p. 190.
[208] Confr. Riikka Koulu, en Blockchains and Online Dispute Resolution: Smart Contracts as an alternative to enforcement, publicado en ScriptEd, Vol. 13, Número 1, Mayo 2016, 42.
Señala Koulu “Despite, or more likely due to its origins in the 1990s, ODR still lacks a uniform definition. Some use the term to refer only to privately organised models of technology- augmented dispute resolution, while others include courtroom technology, e.g. e-filing and case management systems, videoconferencing and automated document generation. In short, ODR tools, models and applications vary significantly, but they all have in common the implementation of technology to dispute resolution in order to provide more efficient conflict management. ODR applications may exist separately, linked with public courts or as an integral part of e-commerce sites, as is the case with eBay’s Resolution Center. Due to the constraints of territorial jurisdiction, state sovereignty and the newness of ODR, there are no global legal instruments for regulating legal issues related to cross- border ODR. This means that the choice of law or jurisdiction, or the recognition and enforcement of ODR decisions, are all determined based on national law, which may often lead to complications in cross-border situations. In response to these challenges, the EU has created a union-wide ODR platform with translation services through the ODR Regulation (524/2013) and ADR Directive (2013/11/EU). Also, the United Nations Commission on International Trade Law (UNCITRAL) has attempted to draft uniform procedural rules for ODR but the work has come to a relative standstill.” El resaltado es mío. Para un análisis del estado actual de la cuestión de los ODRs y cloud computing contracts, véase UNCITRAL, Draft notes on the main issues of Cloud Computing Contracts, en https://uncitral.un.org/en/cloud/dispute%20resolution, disponible al 20/04/2020. Para una revisión de los ODRs y derecho del consumidor, véase Mirèze Philippe, ODR redress system for consumer disputes, recuperado el 20/04/2020 en https://www.elevenjournals.com/ tijdschrift/ijodr/2014/1/IJODR_ 2014_001_001_004.pdf. Para un análisis del funcionamiento de la ADR Directive, véase: https://ec.europa.eu/info/ alternative-dispute-resolution-reports_en, recuperado el 20/04/2020.
[209] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute resolution, publicado en The Business Lawyer, Primavera 2019, p. 4. En efecto, en la página 46 afirman los citados autores que “as Ethereum and other blockchain-based smart contracting networks become increasingly autonomous, legislators simply will not have the ability and authority to dictate to contracting parties and Ethereum itself whether or not to code existing legal rules into a given smart contract. Anonymity means the government cannot identify citizens with access to a free internet who use the blockchain. Nor can the government prevent citizens from adding contracts anonymously to the blockchain. Autonomy means the government cannot stop the blockchain miners from automatically adding contracts because the protocols do not recognize distinctions between good and bad contracts that any outside body dictates (as miners are also anonymous.) Also, the distributed nature of the blockchain means the government cannot control the nodes which maintain the blockchain without an effective world-wide governing body—which is obviously nowhere near feasible at this point in history—not even if the nodes were known to the government, which they are not.” Los resaltados son míos.
[210] Confr. Riikka Koulu, en Blockchains and Online..o.c., p. 55, quien también afirma, en opinión que se comparte, que “Self-executing contracts might significantly alter dispute resolution, although it is unlikely that disputes will disappear completely. It is more likely that disputes themselves will change in step with the change of the methods for resolving them. Therefore, the challenge created by smart contracts is not directed simply to contractual law but is also relevant to dispute resolution and due process.”El resaltado es mío.
[211] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute ..o.c. p. 7.
[212] Confr. Samuel Bourque y Sara Fung Ling Tsui, A lawyer’s introduction… p. 13, indican que “the Smart Contract is not physically located, nor administered in any one specific physical location. In actuality, it is copied worldwide in a consensus network that guarantees its integrity. In a sense, it is both everywhere and nowhere. Such Smart Contracts without seat are technically possible with current technology on Ethereum.”
[213] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute ..o.c. p. 36. Señalan, con relación a la competencia territorial de los Tribunales, que “..the concept of location or presence in jurisdictional means does not apply to the blockchain. A location for the blockchain does not exist - not physically or even electronically. Nodes that contain the blockchain and all of its information are located all over the world. Transactions in the blockchain are fully networked and “present” only in cyberspace. The nodes hold imperfect partial copies of the blockchain; no particular node holds the entire blockchain.” El resaltado es mío.
[214] Idem, p. 45, indicando que la “supra-nacionalidad” en este contexto se vincula, como contracara, con la (deseada) extraterritorialidad de ciertas leyes y regulaciones nacionales, y, a su turno, con la dificultad real de poder hacer cumplir tales efectos “extra-nacionales” fuera de las fronteras de un país, y especialmente dentro del entorno blockchain.
[215] Idem, p. 7. Sostienen allí que la “anonymity gained by the use of public-key encrypted identities and VPNs prevents the identification of the parties to a smart contract. Without identifiable parties, jurisdictional principles such as subject matter jurisdiction, personal jurisdiction, diversity jurisdiction, and federal question jurisdiction become irrelevant.” El resaltado es mío.
[216] Idem, p. 28.
[217] Idem, p. 35. Sostienen los autores citados, en opinión que se comparte, que los blockchain-based smart contracts crearán un nuevo y especial entorno contractual digital, hasta ahora desconocido, y muy distinto a la contratación vía Internet que se ha desarrollado desde 1995 a 2020.
Así, en una transacción usual de Internet: (i) las partes que contratan son conocidas, sea de modo directo o de modo indirecto a través de los Internet Service Providers, (ii) si las partes no son conocidas, la dirección de IP de una persona sí es conocida, (iii) se pueden conocer los detalles de la propiedad objeto de la transacción, y también la mecánica de pagos empleada, (iv) los pagos se hacen en moneda convencional, no en criptomonedas, (v) y todo lo anterior ocurre en el marco de servidores centrales, no distribuidos, y precisamente por eso, la Justicia puede resolver conflictos con relativa facilidad.
En cambio, en un entorno de smart contracts, ocurre lo siguiente: (i) las partes no se conocen y los IPs de una computadora tampoco permiten conocer la identidad real, (ii) no habrá detalles sobre el objeto vendido, ni la forma de pago empleada si las partes pagan con criptomonedas, sólo se pueden ver transferencias entre llaves públicas, (iii) los contratos se auto-ejecutan de acuerdo a su programación específica, en una red decentralizada y autónoma que no está sujeta a ningún control estatal o jurisdiccional, y por todo ello (iv) no es técnicamente posible la intermediación tradicional de los sistemas jurisdiccionales.
[218] Idem, p. 47. Ampliar en https://www.blockchainaragon.com. Anotando el caso Aragon, Kaal y Calcaterra apuntan que: “The jurisdiction of the Aragon Network is distributed. Specifically, this means the network does not have a localized geographical existence; it is supranational. Therefore, no existing governmental entity has current legal jurisdiction over the regulation of general smart contracts. The Aragon Network’s particular jurisdiction cannot be controlled by any nation-based court for the practical reason that all litigants and judges are anonymous, and so have no determinable national location. Consequently, no political entity will have any practical effect in the governance of general DAOs. The Aragon Network has three primary goals: 1. Provide models for starting well-designed DAOs. 2. Regulate the behavior of these DAOs according to rules decided upon by a dynamically evolving Aragon constitution, which rewards the discovery of potential hacks. 3. Provide a digital jurisdiction for settling contractual disputes in an anonymous and democratic manner.” Los resaltados son míos.
[219] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute resolution, publicado en The Business Lawyer, Primavera 2019, p. 55.
[220] Ampliar en https://blog.aragon.org/ the-aragon-token-sale-the-numbers-1 2d03c8b97d3/, disponible al 18/04/2020. Funciona del siguiente modo: “Whenever a user wishes to dispute the execution of a contract in the Aragon Network, they post a bond (which will be returned if the dispute is decided in their favor) and a brief of their argument. 5 judges who have posted bonds will be randomly selected from all the users of the network. The judges read the litigants’ briefs and issue their judgements. Majority decisions determine the outcome of the dispute. If a judge ruled with the majority, they are rewarded monetarily; if not, they are punished with the loss of their bond. 2 appeals are possible. If either party disagrees with the judgment they may appeal by posting a larger bond with their argument. This opens a prediction market, where any user in the organization may become a judge by posting a bond. The arguments are read and all judges return their verdicts. Again, majority determines the result of the dispute, with rewards or punishments for judges are given based on whether they sided with the successful party. The final appeal is made to a panel of 9 “supreme court” judges comprising the most successful judges in the network. A larger bond is posted by the appellant at each stage to prevent the wasting of system resources.” El sistema está tan bien pensado, que podríamos utilizarlo en el mundo real…de allí el rotundo éxito en la venta de sus tokens.
[221] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute resolution, publicado en The Business Lawyer, Primavera 2019, p. 53.
[222] Confr. Nelson Rodriguez, ¿Qué son los contratos ricardianos? Guía completa, recuperado el 18/04/2020 en https://101blockchains.com/ es/contratos-ricardianos/. Los define como una forma de documentos digitales que actúan como un acuerdo entre dos partes sobre los términos y condiciones para una interacción entre las partes acordadas. Lo que lo hace único es que está firmado y verificado criptográficamente. Incluso cuando se trata de un documento digital, está disponible en un texto legible para personas que también es fácil de entender para aquellos que no son abogados. Es un acuerdo o documento legal único que se puede leer al mismo tiempo por los programas informáticos y por los humanos, pero también es un contrato legible para máquinas. En definitiva, los contratos ricardianos combinan contratos legales con tecnología de la blockchain. Unen a las partes en un acuerdo legal antes de la ejecución de las acciones en la red de blockchain. En contra, Kaal y Calcaterra afirman que “Because every single Ricardian Contract has an arbiter/notary connected with them to automatically, check the contract, and hold funds in escrow until the contract is validated, such contracts follow the established legal order for contracting to a significant extent.” El resaltado es mío.
[223] Confr. Stuart D. Levi y Alex B. Lipton, An introduction to Smart Contracts and their potential and inherent limitations, recuperado el 18/04/2020 en https://corpgov.law.harvard.edu /2018/05/26/an-introduction-to-smart -contracts-and-their-potential- and-inherent-limitations/. Véase también: Ian Grigg, The Ricardian Contract, recuperado el 18/04/2020 en https://iang.org/ papers/ricardian_contract.html.
[224] Confr. Wulf A. Kaal y Craig Calcaterra, Crypto transaction dispute resolution, publicado en The Business Lawyer, Primavera 2019, p. 51.
[225] Véase https://www.openlaw.io.
[226] Véase supra § 1.1.10 en relación al Blockchain 2.0.
[227] Confr. https://blog.ethereum.org/2014/05/06/ daos-dacs-das-and-more-an-incomplet e-terminology-guide/, recuperado el 21/04/2020.
[228] Confr. https://www.criptonoticias.com/ aplicaciones/solardao-y-la-inversion- estable-en-energia-solar/, recuperado el 16/04/2020.
[229] Confr. https://daostack.io recuperado al 27/04/2020.
[230] Confr. https://wingsfoundation.ch, recuperado el 22/04/2020.
[231] Confr. https://cryptoslate.com/ coins/xwin-cryptobet/, recuperado el 21/04/2020.
[232] Confr. https://decrypt.co/es/25405/ piedao-nueva-forma-manejar-fondos- criptomonedas, recuperado el 15/04/2020.
[233] Confr. Nathaniel Whittemore, Narrative watch: Why 2020 will be the year of the DAO, recuperado el 28/04/2020 en https://www.coindesk.com/ narrative-watch-will-daos-break-out-in-2020. Señala Whittemore casos de DAOs lanzadas en 2019, como MolochDAO (https://molochdao.com) y MetaCartel (https://medium.com/metacartel/ metacartel-dao-rises-e0646393718b).
También señala el autor que las DAOs serán una realidad cada vez más usual, ya que son formas muy flexibles de organizar colectivamente el trabajo de personas interesadas en desarrollar tecnología sobre la base de la CryptoEconomía. Además, las DAOs permiten estructurar nuevas formas de remunerar el trabajo remoto, en un mundo donde el trabajo comienza a transformarse digitalmente a ritmo muy acelerado, y permiten formas mucho más participativas de toma de decisión e inversión.
[234] Confr. José Maldonado, DeFi: qué es y su impacto en el criptomundo, recuperado el 01/05/2020 en https://es.cointelegraph.com/explained /defi-what-it-is-and-its-impact- on-the-crypto-world.
[235] Confr. https://makerdao.com/es/
[236] Confr. Laila Metjahic, Deconstructing the DAO: the need for legal recognition and the application of Securities Laws to decentralized organizations, publicado en Cardozo Law Review, vol. 39, número 4, disponible al 25/04/2020 en http://cardozolawreview.com/ wp-content/uploads/2018/07/METJAHIC.39.4.pdf.
[237] Ibid.
[238] Confr. Shawn Bayern, Of bitcoins, independently wealthy software, and the Zero-Member LLC, disponible al 21/04/2020 en https://scholarlycommons.law.northwestern.edu /cgi/viewcontent.cgi?article= 1009&context=nulr, p. 1495.
[239] El CCCN, en su Art. 148, define como personas jurídicas privadas a (1) las sociedades; (2) las asociaciones civiles; (3) las simples asociaciones; (4) las fundaciones; (5) las iglesias, confesiones, comunidades o entidades religiosas; (6) las mutuales; (7) las cooperativas; (8) el consorcio de propiedad horizontal; y (9) toda otra contemplada en disposiciones de este Código o en otras leyes y cuyo carácter de tal se establece o resulta de su finalidad y normas de funcionamiento. El resaltado es mío. 
[240] Confr. Sebastián Balbín, Manual de Derecho Societario, Ed. Abeledo Perrot, Bs. As., 2016, p. 1.
[241] Idem, p. 4.
[242] Idem, p. 5.
[243] Confr. Shawn Bayern, Of bitcoins, independently wealthy…o.c., p. 1495.
[244] Idem, p. 1493, presenta el siguiente ejemplo: “Suppose that an independently operating software program, which we might otherwise have classified as a computer virus, is designed to do something useful, like perform calculations or store backup copies of data for customers. Without Bitcoin, there is no legal, convenient way for that software to accept payment from customers unless it does so on behalf of an individual or legal entity, such as a corporation, partnership, or trust. Because of Bitcoin, however, this program may send and receive valuable digital tokens from anyone on the Internet, and so it can easily act, in functional terms, as an independent business, accepting payment for its services and paying for the resources it uses (such as computer processing and storage) in order to provide them. It can make these choices as functions of its own software, without ongoing input from humans, and then execute the choices using online digital currencies like Bitcoin. Importantly, an independently operating software program could likely do this—practically, very soon in the future, and indeed as a relatively minor engineering challenge—without special concessions from the law of any jurisdiction. So long as the inputs to its production are offered online in exchange for bitcoins, the program has no need for conventional financial institutions to pay its operational bills. So long as its customers are willing to pay the software with bitcoins, it needn’t use those institutions to manage its accounts receivable. Because of advances in computer-networking technology, software can even hide its physical location relatively well, so it might even be difficult to interdict an autonomous system whose only interaction with the world is to produce and consume digital services (like storage or information processing) in exchange for bitcoins. Intriguingly, once a system that provides online services is possible, there is little conceptual barrier to a similar system’s providing more conventional “offline” services beyond the Internet. So, for example, consider a network of vending machines. Someone needs to install the vending machines and continuously supply them. But from the perspective of the software operating the network, those tasks are simply another type of input to production, like disk space or network bandwidth. The software can pay someone to install or stock a new vending machine, verify that the task has been completed, and remit payment digitally using Bitcoin. Nothing prevents such services from interacting with each other and assuming a significant economic role.” El resaltado es mío.
[245] Confr. Reporte de la S.E.C., disponible al 24/04/2020 en https://www.sec.gov/litigation/ investreport/34-81207.pdf .
[246] Consultar en https://slock.it.
[247] Confr. Reporte de la S.E.C., p. 1.
[248] Confr. David J. Shakow, The Tao of TheDAO: Taxing an Entity that lives on a Blockchain, recuperado el 28/04/2020 en https://scholarship.law.upenn.edu/cgi/ viewcontent.cgi?article=3011& context=faculty_scholarship, p. 931, puntualiza la mecánica de inversiones y retiros: “The DAO structure allowed persons to transfer Ether (the Ethereum cryptocurrency, similar to bitcoin) to The DAO in exchange for The DAO tokens — items that were ownership interests in The DAO. Token owners voted to choose the investments to be made by The DAO and shared ratably in gains and losses of The DAO and voting was based on the number of DAO tokens owned. Some have questioned whether it might be more democratic if each holder had only one vote. Each token was recorded in the blockchain. The intention was that the collected funds would be invested in start-up companies. A proposal brought to The DAO would be voted on by the holders of The DAO tokens. If enough holders approved of the investment, the investment would be made by transferring Ether from The DAO’s account to the account of the successful applicant. Those who didn’t approve of the investment could choose to take their remaining Ether, leave The DAO’s main blockchain and collect their Ether, or create another blockchain. Besides their Ether, those who moved to the new blockchain would also receive “reward tokens.” Holders of the reward tokens would receive from The DAO their allocable portion of any distributions that The DAO received from investments made while the members of the new blockchain were still members of the original blockchain of The DAO, and from the proceeds of the disposition of those earlier investments. All of this — the tallying of the votes, the creation of a new blockchain, any distributions to disapproving holders, the investment of funds with successful applicants — could be effected through smart contracts, without the need for human intervention on behalf of The DAO. In its implementation, The DAO also made use of human “curators” who confirmed the identity of those who submitted proposals.”
[249] Confr. Reporte de la S.E.C., p. 9, nota 28.
[250] Confr. David J. Shakow, The Tao of TheDAO…o.c., p. 932, señala que, como el código del TheDAO –su estatuto social, mutatis mutandis– permitía que cualquier inversor se retirara de TheDAO si no estaba de acuerdo con una inversión decidida por la mayoría tenedores DAO Tokens –sería el equivalente a un derecho de receso en materia societaria–. El error de programación en el código permitía que se ejercieran estos recesos –i.e. se iniciara un smart contract–, sin que se actualizase el saldo restante del “capital social digital” en Ethers y sin que siquiera hubiera habido una inversión puesta a votación de los inversores que generase la facultad de retirarse. Alguien descubrió el error, y retiró rápidamente DAO Tokens por valor de 3.6 millones de Ethers, que en el momento equivalían a 40 millones de U$D. Los DAO Tokens producto de estos “falsos recesos” no eran de libre disponibilidad, sino que quedaban “congelados” por 27 días en una cuenta específica, y luego podían convertirse a Ether, esperando otros 34 días. Se sugiere la lectura directamente de sus fuentes: Dino Mark, Vlad Zamfir y Emin Gür Sirer, A call for a temporary moratorium on “The DAO”, recuperado el 15/05/2020 en https://docs.google.com /document/d/10kTyCmGPhvZy94F7VW yS-dQ4lsBacR2dUgG TtV98C40/edit#.
Confr. Emin Gün Sirer, profesor de la prestigiosa Universidad de Cornell en EE.UU., en Thoughts on The DAO hack, recuperado el 01/05/2020 en https://hackingdistributed.com/2016/06/17/thoughts-on-the-dao-hack/ afirma que: “It's clear that writing a robust, secure smart contract requires extreme amounts of diligence. It's more similar to writing code for a nuclear power reactor, than to writing loose web code.
Yet the current Solidity language and underlying EVM seems designed more for the latter. Some misfeatures are: (i) A good language for writing state machines would ensure that there are no states from which it is impossible to recover. (ii) A good language for writing state machines would make it painfully clear when state transitions can and cannot happen. (iii) A good language for maintaining state machines would provide features for upgrading the security of a live contract. (iv) A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read. The current language does not fulfill any of these commandments, and in fact, the last one, involving implicit recursive calls, is what did The Dao in. The SlockIt team even had the designer and implementor of Solidity perform a review of their code. If he cannot get something like The DAO to be secure, no one can.” El resaltado es mío.
[251] Ibid.
[252] Puede ampliarse en Alex Moskov, Ethreum Classic vs. Ethereum (ETC vs. ETH): What’s the difference? Disponible al 20/04/2020 en https://coincentral.com/ ethereum-classic-vs-ethereum/.
[253] Confr. Lucy Liu, The legality of The DAO, recuperado el 01/05/2020 en http://mbelr.org/the-legality-of-the-dao/.
[254] Confr. Reporte de la S.E.C., p. 11, en el sentido que eran específicamente un contrato de inversión. “An investment contract is an investment of money in a common enterprise with a reasonable expectation of profits to be derived from the entrepreneurial or managerial efforts of others. See SEC v. Edwards, 540 U.S. 389, 393 (2004); SEC v. W.J. Howey Co., 328 U.S. 293, 301 (1946); see also United Housing Found., Inc. v. Forman, 421 U.S. 837, 852-53 (1975) (The “touchstone” of an investment contract “is the presence of an investment in a common venture premised on a reasonable expectation of profits to be derived from the entrepreneurial or managerial efforts of others.”). This definition embodies a “flexible rather than a static principle, one that is capable of adaptation to meet the countless and variable schemes devised by those who seek the use of the money of others on the promise of profits.” Howey, 328 U.S. at 299 (emphasis added). The test “permits the fulfillment of the statutory purpose of compelling full and fair disclosure relative to the issuance of ‘the many types of instruments that in our commercial world fall within the ordinary concept of a security.’” Id. In analyzing whether something is a security, “form should be disregarded for substance,” Tcherepnin v. Knight, 389 U.S. 332, 336 (1967), “and the emphasis should be on economic realities underlying a transaction, and not on the name appended thereto.” United Housing Found., 421 U.S. at 849.” El resaltado es mío.
[255] Confr. Lucy Liu, The legality of The DAO…o.c.
[256] Confr. Laila Metjahic, Deconstructing the DAO: the need for legal recognition and the application of Securities Laws to decentralized organizations, publicado en Cardozo Law Review, vol. 39, número 4, disponible al 25/04/2020 en http://cardozolawreview.com/ wp-content/uploads/2018/07/METJAHIC.39.4.pdf.
[257] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1547.
[258] Confr. Sebastián Balbín, Manual de Derecho Societario, Ed. Abeledo Perrot, Bs. As., 2016, p. 424.
[259] Idem, p. 214.
[260] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1562.
[261] Confr. Sebastián Balbín, Manual de Derecho Societario, Ed. Abeledo Perrot, Bs. As., 2016, p. 144.
[262] En nuestro derecho, el capital social de las sociedades colectivas se divide en fracciones alícuotas, no necesariamente iguales, llamadas partes de interés, las que no son libremente cesibles. Son embargables las utilidades que correspondan al socio, pero no son ejecutables las partes de interés, debido al carácter esencial del socio colectivo. Confr. Sebastián Balbín, Manual de Derecho…o.c. p. 428.
[263] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1552.
[264] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1548.
[265] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1553.
[266] En nuestro derecho, podría sostenerse que TheDAO también podría encuadrar como un negocio en participación, regulado en los Arts. 1448 a 1452 del CCCN. Comparar ésta regulación, con la definición de joint venture para el common law: “Facts showing a pooling of funds or labor with a common purpose to attain a result for the benefit of all the parties, where each participant has a right in some measure to direct conduct, will tend to show a joint venture exists.” Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1560.
[267] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1561.
[268] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1566, in re SEC v. Trendon T. Shavers & Bitcoin Savs. & Tr., No. 13–CV–416, 2014 WL 4652121 (E.D. Tex. Sept. 18, 2014).
[269] Confr. Laila Metjahic, Deconstructing the DAO…o.c., p. 1564.
[270] Confr. en este mismo sentido, Lucy Liu, The legality of The DAO, recuperado el 01/05/2020 en http://mbelr.org/the-legality-of-the-dao/, citando a Reuben Bramanathan, Blockchains, smart contracts and the Law, recuperado el 28/04/2020 en https://blog.coinbase.com/ blockchains-smart-contracts-and -the-law-709c5b4a9895, quien sostiene: “No legal entity is in possession or control of the funds raised, and no legal entity manages the activities of The DAO. This might mean that the profits of the enterprise are not ‘solely dependent on the efforts of the promoter or a third party’ — because the profitability of The DAO would have depended on all of the token holders voting for profitable things to do with all that ETH.” El resaltado es mío.
[271] Confr. Konstantinos Christidis y Michael Devetsikiotis, en Blockchains and Smart Contracts for the Internet of Things….o.c., p. 2298.
[272] Ibid. Los autores dan interesantes ejemplos del blockchain-powered IoT devices: “Consider the following setup to get an understanding of how this could work. All the IoT devices of a manufacturer operate on the same blockchain network. The manufacturer deploys a smart contract that allows them to store the hash of the latest firmware update on the network. The devices either ship with the smart contract’s address baked into their blockchain client, or they find out about it via a discovery service. They can then query the contract, find out about the new firmware, and request it by its hash via a distributed peer-to-peer filesystem such as IPFS. The first requests for this file will be served by the manufacturer’s own node (also taking part into the network), but after the binary has propagated to enough nodes, the manufacter’s node can stop serving it. Assuming the devices are configured so as to share the binary they got, a device that joins the network long after the manufacturer has stopped participating in it, can still retrieve the sought- after firmware update and be assured that it is the right file. This all happens automatically, without any user interaction. Compare and contrast with the centralized scenario where the device polls the manufacturer’s server for an update and gets a 404 error. Furthermore, a blockchain network where cryptocurrency is exchanged provides a convenient billing layer and paves the way for a marketplace of services between devices. In the example above, devices that store a copy of the binary may charge for serving it, in order to sustain their infrastructure costs (or simply to make a profit). Other examples include: Filecoin which allows devices to ‘‘rent their disk space’’, and and EtherAPIs, which make it possible to monetize API calls – the caller needs to provide the necessary micropayment (in Bitcoin or Ethereum respectively) before requesting them. With a cryptocurrency in place, every device can have its own bank account on the Internet; it can then expose its resources to other devices (or users) and get compensated for their usage via microtransactions. This also facilitates the sharing of services and property in general. Slock.it works on smart electronic locks (‘‘Slocks’’) that can be unlocked with a device that carries the appropriate token. These tokens are bought on the Ethereum blockchain, a public blockchain network optimized for smart contracts that uses its own cryptocurrency, called Ether. The owner of a Slock that wishes to rent their house or car sets a price for timed access to that electronic door lock. An interested party can use a mobile app to identify the slock, pay the requested amount in Ethers, then communicate with the lock via a properly signed message (using the Whisper peer- to-peer communication protocol) to unlock it. Billing is simplified by having all the Slocks operating on the same blockchain. (…) in the energy sector, the integration of IoT with blockchains allows for a peer-to-peer market where machines can buy and sell energy automatically, according to user-defined criteria. For example, TransActive Grid is experimenting with the concept of a peer- to-peer market for renewable energy in a neighborhood in Brooklyn, NY. Solar panels record their excess output on the blockchain, and sell it to neighboring parties via smart contracts.” El resaltado es mío.
[273] Confr. Konstantinos Christidis y Michael Devetsikiotis, en Blockchains and Smart Contracts for the Internet of Things….o.c., p. 2301.
[274] Ibid.
[275] Confr. OpenLaw, The LAO: A for-profit, limited liability Autonomous Organization, recuperado el 05/05/2020 en https://medium.com/ openlawofficial/the-lao-a-for-profit-limited- liability-autonomous-organization-9eae89c9669c.
[276] Ibid.
[277] Confr. OpenLaw, The LAO: A for-profit, limited liability Autonomous Organization, recuperado el 05/05/2020 en https://medium.com/openlawofficial/ the-lao-a-for-profit-limited-liability- autonomous-organization-9eae89c9669c.
[278] Confr. https://www.coindesk.com/ former-polychain-partner-ryan-zurrer-is -leaving-web3-to-start-his-own-dao, recuperado el 23/04/2020. Puede verse el White Paper de la nueva DAO aquí: https://github.com/the-dao/ whitepaper, disponible al 23/04/2020.
[279] Para un análisis general de MolochDAO, véase https://concourseopen.com/ blog/moloch-dao-explained/, disponible al 25/04/2020. White Paper disponible, en la misma fecha, aquí: https://github.com/MolochVentures/Whitepaper/blob/master/Whitepaper.pdf
[280] Confr. White Paper de Moloch, disponible aquí al 25/04/2020: https://github.com/ MolochVentures/ Whitepaper/blob/master/Whitepaper.pdf
[281] Confr. Sebastián Balbín, Manual de Derecho Societario …o.c., p. 546 lo define como la potestad conferida al socio por ley o convención estatutaria, para que éste solicite la extinción del vínculo que lo une con la sociedad, en razón de la ocurrencia de algún supuesto que altere de manera sustancial su relación originaria con el ente. Habilita la salida del accionista disconforme, a cambio del reembolso del valor de sus acciones. La Ley General de Sociedades en su Art. 244, último párrafo, enumera nueve causales legales que habilitan el receso, a las que se pueden sumar las causales convencionales que los socios hayan pactado en el estatuto social. El Art. 245 regula el ejercicio del derecho, el que sólo corresponde a los que votan en contra de una resolución asamblearia y a los ausentes, y debe ejercerse dentro de un plazo de 5 o 15 días, según se trate de presentes que votaron en contra, o de ausentes. La sociedad puede celebrar otra asamblea posterior, dentro de los 60 días, para revocar lo decidido e inhabilitar el consecuente receso. Se trata de un derecho que no puede ser renunciado anticipadamente, y está prohibido por la ley agravar las condiciones de su ejercicio, aunque se admite su reglamentación.
[282] Véase por ejemplo los servicios ofrecidos por: https://chainsecurity.com/audits/; https://quantstamp.com; https://consensys.net/?utm_source=cryptobrowser.io. Para una descripción sobre el proceso de auditoría de smart contracts, véase Stefan Beyer, Smart contracts audits – the 12 steps to blockchain security, recuperado el 22/04/2020 en https://medium.com/cryptronics/smart-contract-audits-the-12-steps-to-blockchain-security-82543dc383cc.
[283] Confr. Christine Vasileva, Ethereum network not rolled back after DAO hack, recuperado el 26/04/2020 en https://bitcoinist.com/ ethereum-network-not-rolled -back-after-dao-hack/.
[284] Confr. Kapil Gauhar, Are smart contracts reversible? recuperado el 22/04/2020 en https://www.btcwires.com/ round-the-block/are-smart-contracts-reversible/.
[285] Ampliar en DelegatedCall: calling another contract function in Solidity, recuperado el 22/04/2020 en https://medium.com /coinmonks/ delegatecall-calling-another -contract-function-in-solidity-b579f804178c y en Contract ABI Specification, recuperado en la misma fecha de https://solidity.readthedocs.io/ en/develop/abi-spec.html.
[286] Confr. Legal statement on cryptoassets and smart contracts, recuperado el 22/04/2020 en https://35z8e83m1ih83drye280o9d1-wpengine.netdna-ssl.com/ wp-content/uploads/2019/11/6.6056_ JO_Cryptocurrencies_Statement _FINAL_WEB_111119-1.pdf.
[287] Confr. https://www.accordproject.org/ news/bsi/, disponible al 22/04/2020.
[288] Ibid. En particular, la propuesta de estándar hecha pública por el BSI fija los siguientes objetivos: “a) defining the necessary taxonomy and form for contracts that are both human-readable and machine-readable; b) providing a universal and extensible technical baseline foundation to aid the development of solutions and software utilising smart legal contracts in a technology agnostic manner to enable compliant implementations and standards to be developed across software platforms and industries; c) providing facts and use cases that demonstrate how smart legal contracts perform and can benefit users, legal professionals and other interested parties; d) establishing a minimum set of requirements for organizations to adopting and develop smart legal contracts; y e) to provide organizations with a technical framework within which to digitize new or existing legal contracts, connect them to data services, and deploy them across any technology platform (e.g. cloud or a distributed ledger platform), including determination of the scope of permissible contract codification.”
BSI afirma también que “contracts that are expressed only in natural language are unable to adequately respond to events pertaining to the contract that occur in the physical world, as well as on software systems…By contrast, smart legal contracts include computational components that enable a contract to communicate with software systems and respond to events that occur in the physical world. For example, a sales contract could calculate a price based upon the delivery status and conditions of goods and generate payment obligations based upon that state. That contractual state may be used to configure software systems (e.g. performing transfers of digital assets on blockchain systems, raising invoices on accounting systems) with a significant reduction in the need for resource-intensive external management. Smart legal contracts therefore improve the efficiency of managing contracts throughout their lifecycle, and remove the need to perform redundant data-entry to configure IT systems based on the terms negotiated within the contract. Moving contracts from purely textual documents, only accessible to humans, to documents containing structured data, accessible to computers, potentially allows contract users to reliably query, extract or integrate contract data with IT Systems. Smart legal contracts potentially enable contracts to transition from being static records of agreement, to dynamic pieces of IT infrastructure. Smart legal contracts potentially ensure that all contracting parties have a common view of the state of a contract and all events that might have modified the state of the contract. Smart legal contracts have an opportunity to create a more efficient way of transacting contractual obligations. The settlement of such obligations, as a baseline, can be done through traditional settlement means. Distributed ledger technology (DLT) can be used to distribute the state of a contract to the participants in a public or permissioned business network. Smart legal contracts can potentially remove the need to manually perform contract obligations, such as notification or payment that can often be error-prone and time-consuming manual processes. Further benefits arise when the settlement of the transacted obligations can happen via settlement native to a specific system (i.e. native tokens) on DLT systems.” El resaltado es mío.
[289] Véase infra nota 752.
[290] Confr. Christopher Clack, Vikram Bakshi y Lee Braine, Smart contracts templates: foundations, design landscape and research directions, recuperado el 23/04/2020 en https://arxiv.org/abs/1608.00771.
[291] Idem, p. 1.
[292] Confr. Pablo Salvador Coderch, El oficio de la buena prosa legal, recuperado el 25/04/2020 en https://indret.com/ el-oficio-de-la-buena-prosa-legal/.
[293] Confr. Christopher Clack, Vikram Bakshi y Lee Braine, Smart contracts …o.c., p. 6.
[294] Idem. Sostienen los autores, p. 7: “Deriving the set of code parameters may be complicated by three factors: (1) It is common for parameters to be embedded in the legal prose — such parameters would initially be identified visually, aided by a graphical user interface. (2) Some of the values identified as “parameters” in the agreement (or template) may not have an operational impact and therefore would not be passed to the smart contract code. (3) It is possible for a parameter to be defined (given a name) in one document, given a value in a second document, and used (e.g. in business logic) in a third document. Although parameters need not have values in a template, they must have values in a signed agreement. All of an agreement’s parameter values are a critical part of the contract as they directly reflect the business relationship between parties and those that are code parameters influence the automated operation of the contract. Most parameters in existing templates have simple types, such as date, number, etc. These are “base” or “primitive” types. It is not necessary for parameters to be restricted to base types. It is very likely that values of more complex types, such as lists, will also need to be transferred to the code. The passing of parameters to the code is necessary because of the desire to use standardised code. The number of parameters, and the complexity of the types of those parameters, will typically increase as the code becomes more generic. Beyond parameters with base types and more complex types such as lists, parameters can also be expressions containing references to other parameter names. Unless those other parameter names are defined within the expression, the expression is effectively a function. Where a function is passed as a parameter, this is known as a “higher-order” parameter and the receiving code is known as a “higher-order” function.” El resaltado es mío.
[295] Idem, p. 9.
[296] Ibid.