Smart contracts y la Electronic Transactions Act 2010

Leer la edición en PDF (4 páginas)

¿Puede el código ser un contrato?

Un smart contract es un programa en una blockchain que ejecuta acciones predeterminadas cuando se cumplen determinadas condiciones. Que sea además un contrato en sentido jurídico depende de que en las relaciones entre las partes concurran los elementos ordinarios de oferta, aceptación, contraprestación (consideration) e intención de crear relaciones jurídicas. El derecho de Singapur no exige que un contrato esté redactado en lenguaje natural. La Electronic Transactions Act 2010 (ley de transacciones electrónicas) dispone que no se negarán efectos jurídicos a una información por el solo hecho de estar en forma electrónica y que los contratos pueden formarse mediante comunicaciones electrónicas. Un contrato formado por la interacción entre un sistema automatizado de mensajes y una persona física, o entre sistemas automatizados de mensajes, no pierde validez por el solo hecho de que ninguna persona física haya revisado cada acción.¹

La ley ofrece otros tres instrumentos. La sección 13 atribuye una comunicación electrónica a la persona que la envió o en cuyo nombre se envió, lo que permite atribuir al titular de la clave una transacción firmada con una clave privada.² La sección 16 permite a la persona física que comete un error de introducción de datos en un intercambio con un sistema automatizado de mensajes retirar la parte errónea. Las condiciones son que el sistema no le haya dado oportunidad de corregir el error y que la persona lo notifique con prontitud sin haberse beneficiado de él.³ La sección 16 es una norma de protección del consumidor de alcance limitado. No ayuda al operador que fija mal el precio de una orden en una plataforma que ofrecía una pantalla de confirmación. Las reformas de 2021 añadieron la Parte 2A sobre documentos transmisibles electrónicos. Esta parte incorpora la Ley Modelo de la CNUDMI sobre Documentos Transmisibles Electrónicos y permite que conocimientos de embarque, pagarés e instrumentos similares existan en forma electrónica cuando un método fiable acredite el control exclusivo.⁴ El Primer Anexo sigue excluyendo de las normas de reconocimiento de la ley los testamentos, la constitución de determinados trusts y poderes, y los contratos de disposición de bienes inmuebles, lo que es relevante para las cuestiones sucesorias del capítulo VII.⁵

Código, intención y texto rector

Hay tres problemas recurrentes. El primero es la intención. Muchas interacciones on-chain, como el intercambio de tokens en un creador de mercado automatizado (automated market maker), no implican una contraparte identificada ni otra comunicación que la propia transacción. Los tribunales de Singapur no han resuelto si surge un contrato entre el usuario y los proveedores de liquidez, entre el usuario y la entidad que gobierna el protocolo, o con nadie en absoluto. El análisis de las finanzas descentralizadas del Consejo Federal suizo, tratado en la Parte D, capítulo V, y en la Parte E, capítulo IX, concluye que en muchos casos no existe contraparte contractual. Si algo sale mal, al usuario solo le quedan entonces acciones por enriquecimiento injusto o por responsabilidad extracontractual (tort). A mi juicio, un tribunal de Singapur llegaría a la misma conclusión sobre los mismos hechos.

El segundo problema es la relación entre el código y las condiciones en lenguaje natural. Cuando una venta de tokens se documenta mediante un contrato de compraventa y se ejecuta mediante un smart contract, ambos pueden divergir. El contrato puede prometer un calendario de consolidación (vesting) que el smart contract no implementa, o el smart contract puede contener una función que permita al emisor acuñar más tokens, algo que el contrato prohíbe. La respuesta sensata en la redacción es una cláusula de jerarquía que indique cuál prevalece. A falta de ella, un tribunal interpretará el contrato y tratará el código como la forma de cumplimiento, de modo que una divergencia constituye un incumplimiento de la parte responsable del código. El tercer problema son los defectos del código. Un fallo que permite a un tercero vaciar un pool es un hecho que las partes no quisieron. Que la pérdida recaiga sobre el usuario, el desarrollador o la entidad rectora depende del contrato, cuando lo hay, y de la responsabilidad extracontractual cuando no lo hay (capítulo VI).

Notas

1. Electronic Transactions Act 2010, ss. 6 (reconocimiento jurídico de los registros electrónicos), 11 (formación y validez de los contratos) y 15 (uso de sistemas automatizados de mensajes para la formación de contratos). La sección 2(1) define el sistema automatizado de mensajes como un programa o medio automatizado utilizado para iniciar una acción o responder a mensajes de datos sin revisión por una persona física. ↩
2. Electronic Transactions Act 2010, s. 13 (atribución de las comunicaciones electrónicas). ↩
3. Electronic Transactions Act 2010, s. 16 (error en las comunicaciones electrónicas), que incorpora el art. 14 de la Convención de las Naciones Unidas sobre la Utilización de las Comunicaciones Electrónicas en los Contratos Internacionales de 2005. ↩
4. Electronic Transactions (Amendment) Act 2021, que introduce la Parte 2A (documentos transmisibles electrónicos) en la Electronic Transactions Act 2010 con efectos desde el 19 de marzo de 2021. ↩
5. Electronic Transactions Act 2010, s. 4 y Primer Anexo (materias excluidas). ↩

Solo a efectos de información general. Este artículo no constituye asesoramiento jurídico ni fiscal, no sustituye el asesoramiento en un caso concreto y no crea una relación abogado-cliente. Refleja la situación jurídica a fecha de octubre 2026.