+ Law, Science and Technology MSCA ITN EJD n. 814177 MOATcoin: - - PowerPoint PPT Presentation

+

MOATcoin: Exploring Challenges and Legal Implications of Smart Contracts Through a Gamelike DApp Experiment

Biagio Distefano

Universität Wien • Università di Bologna • Università di Torino

Nadia Pocher

Universitat Autònoma de Barcelona • Università di Bologna • KU Leuven

Mirko Zichichi

Universidad Politécnica de Madrid • Università di Bologna • Università di Torino

Law, Science and Technology MSCA ITN EJD n. 814177

+

Problem Scenario

2

+

• A group of people decide to abide by a certain set of rules
• They stipulate a contract, formalizing the rules
• They decide that there should not be a hierarchy between the

parties

• They decide to remain peers

3

+

• Violations need to be recorded in a transparent fashion
• Violators need to be dealt with and face the consequences of

their violations

• There is the need for a dispute resolution system
• The governance needs to be seamless

4

+

• To address these issues we created a gamelike experiment
• Twenty Law, Science and Technology Joint Doctorate

candidate were involved

• The experiment is still ongoing

5

+

MOATcoin

6

+A game of forbidden words

Rules of the game:

• Work-related keywords are

forbidden outside of the office premises

• These keywords are: BIG DATA,

AI, BLOCKCHAIN, PRIVACY, GDPR, IoT, IPR etc…

• If someone says one of these

keywords outside of the office, they have to pay a penalty

• The penalty is… to buy a BEER

7

+A game of forbidden words

Okay, but there are a few problems:

• There are 20 of us… who’s going to

police?

• How do we incentivize people to

participate?

• How do we avoid cheating?
• How do we handle dispute

resolution?

• How do we keep track in a fair and

transparent way?

8

+System architecture

• LAST-JD candidates sign up

contacting a telegram bot

• Upon signing up, they are given 20

Tokens to start playing

• If someone says a forbidden word
• utside of the office, another

candidate can accuse them

• The accusation can only happen in

the group chat, for transparency reasons

9

+System architecture

• The accusation is stored on the

blockchain

• The accusation costs one Token,

that the accuser puts at stake on the accused candidate

• The accused candidate has two

choices:

• Buy a beer to another

candidate

• Challenge the accusation

10

+System architecture

If the accused chooses to buy the beer:

• A different candidate must

testify on that in the group chat

• The action is stored on the

blockchain

• The staked Token is returned to

the accuser

• Reward tokens are issued to the

accused, the accuser and the witness

11

+System architecture

If the accused chooses to challenge the accusation:

• The Stake gets paused
• A trial is opened
• The challenge is stored and
• pened on the blockchain
• A poll is created in the group chat
• The accused is now a defendant

12

+System architecture

• Each candidate can cast their vote
• n the group chat’s poll
• Every vote is stored on the

blockchain

• Each candidate’s vote weighs as

much as the number of Tokens they have

• At the end of the voting window,

the sentence gets auto-executed

13

+System architecture

If the defendant is found GUILTY:

• The Stake gets un-paused
• They will have to buy the beer

If the defendant is found NOT GUILTY:

• The accuser loses their Stake
• The accuse/Stake is removed

from the blockchain

• The defendant will not have to buy

the beer

14

+

ARCHITECTURE

15

+

16

+

17

+

18

+

19

+

Tech & Legal Issues

20

+

Technical Insight

WHY THIS MATTERS

• Despite being this just a game, it

showcases some important implications that apply to the real world

• In particular, we have to question the

actual level of decentralization of the so called DAPPs

• Then, we have to ask what the software

architecture implies under a legal standpoint

• What are the problems
• What could be the solutions

BLOCKCHAIN TECH:

• Solidity ^0.5.3
• Custom ERC20 Token
• Truffle
• Ganache for development
• Ropsten testnet for

“production”

INTEFRACE / BOT TECH:

• Python3.7.4
• Django==3.0.4
• web3==5.7.0
• aiogram==2.6.1
• Sqlite3 for development
• PostgreSQL for production

21

+

• How decentralized is it, actually?
• In order to play, you need MOAT coins
• To get MOAT coins, you have two possibilities:
• You can get them from @moatbot, that controls the

address that is the owner of the smart contract

• Someone you know sends you some of their MOAT

coins

• It is not completely decentralized, then: it’s a

semi-permissioned ecosystem built on top of a permissionless blockchain

LET’S TALK ABOUT MOATcoin

22

+

• How decentralized is it, actually?
• For convenience reasons, @moatbot controls your private

key, aka your wallet

• This means @moatbot will perform (sign) transactions on

your behalf

• This includes: stake on someone (accusing); testifying on

someone; voting; sending MOAT coins; sending ETH

• When using the app, then, you’re not truly the owner of your

tokens, the app is just a service you use to access the blockchain

• The developers could strip you of all of your tokens and

ETH

LET’S TALK ABOUT MOATcoin

23

+LET’S TALK ABOUT MOATcoin

• Who built it?
• It’s “open source” by default, because it’s on the

blockchain [not necessarily true]

• You could audit the code
• But if you’re not a programmer, you have to trust the

programmers who built it

• Does it matter?

YES!

24

+ HOW DO WE KNOW THAT THE SMART CONTRACT’S

CODE REFLECTS FAITHFULLY WHAT WE AGREED UPON OFF-CHAIN?

• As of now, we don’t.
• You have to trust the coders. This is a problem
• We need a way to allow for a quick, formal, logically sound

legal validation of the contract’s provisions against the smart contract’s code

How can we achieve this?

25

+ Akoma Ntoso, Legal Ontologies,

LegalRuleML

• The first step would be to write (markup) the contract in Akoma Ntoso
• The second step would be to build an Ontology to operate with the contract
• The third step would be to markup the provisions of the contract in LegalRuleML
• The human-readable contract would now be machine-readable, too, and the smart

contract’s logic correspondence with the contract’s provisions can be formally validated For further readings, see:

• Cervone, Luca, Monica Palmirani, and Fabio Vitali. "The Intelligible Contract."

Proceedings of the 53rd Hawaii International Conference on System Sciences. 2020

• Decode Project:

https://decodeproject.eu/publications/decode-legal-ontology-smart-c

• ntracts

26

+

Auditability and Trust

auditability gains value only in three cases: (a) when the user can perform it (which is rarely the case); (b) when it is performed by an expert (yet another shift of trust); (c) when performed by the Open Source Community (OSC).

27

+

Auditability and Trust

trust is not eliminated, it is just spread across the liquid texture

• f the OSC

what DLTs and DApps truly allow for is not the elimination of the need of trust in institutions or third parties, rather, they enable a virtuous cycle of trust empowerment with OSCs

28

+OKAY, BUT WHAT IS MOATcoin?

• Technically speaking, it is a custom ERC20 Token, with custom

rules of minting

• The players serve as some sort of oracles, but not quite
• It is similar to a Decentralized Autonomous Organization, but it is

not, strictly speaking

• The voting system is not democratic, rather meritocratic:
• Your vote weighs as much as the number of coins you have
• You can earn more coins only playing by the rules
• Unjustly accusing someone will cost you a coin and your voting

power will decrease accordingly

• Your vote is not secret and cannot (technically) be

29

+IS IT A CONTRACT, LEGALLY

SPEAKING?

• Being ioci causa, of course, it is not. But what if it were not

ioci causa?

• In our case, the agreement was formed between the

participants before the smart contract was coded and deployed

• n the blockchain
• In this case it would be safe to argue that MOATcoin is not a

contract by itself

• MOATcoin is just a tool that we use to track, transparently

and permanently, the events that are relevant to the contract

• Most real world applications fall within this classification

30

+ DOES IT MATTER?

If a smart contract is a legal contract per se:

• What jurisdiction?
• What law do we apply?
• Who’s liable for bugs or security flaws?

31

+ FOR THE ARGUMENT’S SAKE, LET’S

SAY IT IS A CONTRACT

Let’s say that none of us knew each other, that we all lived in different parts of the world, and that we enter into an agreement with each other solely via the smart contract. Theoretically, smart contracts are made in a way that should prevent litigation… some say that the code is the contract, with all its rules and possible bugs Still, there is margin for disagreement. See for example the DAO hack in 2016 that caused a hard fork of the Ethereum blockchain (and the Ethereum Classic [ETC] blockchain was born) Plus… people like to sue.

32

+ Code as contract: linguistic limitations

and their consequences

If no other logic is used, e.g., legal deontic and defeasible logic: ■ Clauses containing contractual obligations, when simply written in if-then form (or equivalent, e.g., “require()”), may fall within the scheme of conditional clauses, being de facto stripped of their obligatory nature ■ This would leave contracting parties without any legal action to protect their interests; in fact, there would never be “non-performance”, but simply “inaction”, which does not trigger the conditional clause. ■ In other words, when the contractual performance is undertaken into condition, there cannot be a contractual breach in its respect.

33

+ but… what is a MOATcoin?

★ Virtual items still suffer from an insufficient level of definition ; ★ The concept of TOKEN is at the core of debates concerning the ontological and ever-evolving features of these instruments ; ★ Being unable to identify the box into which an entity can be placed causes: ○ uncertainty concerning legal treatment ; ○ lack of standardization ■ cross-industry effects ; ■ detrimental effects on technological development ; and ■ failure of interdisciplinary collaboration ; ★ Problem: finding a balance between : ○ getting lost in pointless – teleologically speaking – definitional differences ; ○

• versimplifications.

34

+

Tokens and crypto-assets: from industry-specific definitions...

there is a general agreement that “tokens” are “crypto-assets” “a cryptographically secured digital representation of value or contractual rights that uses some type of DLT and that can be transferred, stored or traded electronically” (FCA 2019)

35

+

Tokens and crypto-assets: … to cross-industry taxonomical efforts

★ non-fungible vs. fungible vs. hybrid ★ different behaviours & property sets

= rules for how tokens behave = labels that refer to a

transferable / non transferable; divisable / descriptive value that indivisable; singleton; mintable; burnable has external meaning

★ native vs. non-native ★ tokens vs. coins

36

Basic components

• f tokens [verbally

represented by “artifacts”] :

Token Taxonomy Initiative Token Taxonomy Framework

general features of tokens : valuable, representative, digital, discrete, authentic common ground between technologists, business people, regulators and consumers

❖ Base Types, ❖ Behaviors, ❖ Behavior Groups, ❖ Property Sets, ❖ Token Templates.

+

The value of flexible frameworks

Financial Conduct Authority, Bank of England. 2018

➔ HYBRID TOKENS ➔ APPLICATION / PLATFORM TOKENS

MOATcoin

37

trying to sum up … categories in relation to the PURPOSE of each asset :

★ smart contracts like ours can be used to control “digital assets” ; ★ when a token is created to be used on a DApp, like in the MOATcoin case, its purpose depends on the application itself

+

So … is a MOATcoin a coin?

38

MOATcoin

To behave like money, a token must have roles that are definable and assignable and be: ★ delegable ★ transferable ★ holdable ★ compliant ★ burnable ★ mintable

? ? ? ?

★ whether a specific “token” is also a “coin” is far from straightforward, but ★ every “digital coin” is arguably a token ;

★

everything depends on what we mean by “coin” and “token”

+

Tokens as regulatory targets

➔ “far from being just a means of payments, tokens are the critical data structure that could underpin every aspect of the future society” [Skalex 2019] ; ➔ from a regulatory perspective there is a call to pay more attention to the concept of regulating “tokens” rather than “DLTs” ; ➔ Liechtenstein’s “Blockchain Act” focuses on “tokens”, treated as “containers of rights”; it creates a dedicated framework for their ownership and transfer ; ➔ if it is through tokens that DLTs can unfold their potential to create new categories of assets -> approach regulation through the prism of tokens ; ➔ the European Commission has identified the “tokenization” domain as lacking legal certainty -> focus on tokens’ legal framework – i.e. issuance/trading – when they are not considered as financial instruments .

39

+CONCLUSIONS

40

• In this paper, we have presented a gamelike DApp, based on

smart contracts, for the governance of social interaction between PhD candidates.

• We considered a real life use case to specifically focus on issues

arising in the areas of decentralised governance, legal relevance and token classification.

• The proposed experiment showed how in any “de- centralized”

application, whichever architecture it entails, trust gets shifted but is never eliminated.

• After highlighting possible legal impacts, we finally focused on the

crucial role of sound taxonomical conceptualizations in the ever-evolving landscape of “tokens”, from both a technological and regulatory perspective.

def end_presentation(MOATcoin): return "Thank you"

biagio.distefano@univie.ac.at nadia.pocher@uab.cat mirko.zichichi@upm.es 41 Legal Blockchain Lab http://lbl.cirsfid.unibo.it/ LAST-JD-RIoE https://www.last-jd-rioe.eu/