Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
2017 March 28 LegalHackNight ProjectNotes
Notes related to kick-off March 28, 2017 Legal Hack Night:
This page is for Legal Hack Night notes: https://www.meetup.com/Massachusetts-Legal-Hackers/events/238624120/
In advance of the hack night, we'll use the space below for gathering examples or samples of legal terms relevant to blockchain-backed individual identity apps, platforms, services and other systems, including click-through terms, user authorizations, B2B contract provisions, legal notices and other relevant system rules.
We'll assume a digital signature capability linked to digital identity provided to individual "Members" (account holders) by a US Federally Chartered Credit Union and legally deemed to be owned and controlled by the Member.
- Use Case: Alice sells a refrigerator to Bob and both use the blockchain-backed digital signature technology to digitally sign a contract making the agreement legally enforceable.
Legal Use Case and Scenario:
- We assume this is a standard UCC Article 2 "Sale of Goods" transaction covered by a standard legal contract under general law of the US (Restatement of Contracts, etc) and if specificity is needed, the laws of the Commonwealth of Massachusetts will be applied to evaluate likely legal results parties can expect from using this technology in the assumed business context.
Example Legal Rules
We identified the following blockchain wallet terms that a "user" (the signers in our use case):
What are the roles and relationships we will assume for this use case and business context?
What agreements and other rules will we assume?
More specifically, what agreements would parties have with the presumed third party trusted to provide the technology and other trust services? We are assuming this is a fiduciary agent of each signer. The "lawyer" roles in the Toronto technology, which is more like a digital notary, or the Federal Credit Union role in the initial use case are examples of this role. For a lawyer a client representation agreement of some type would likely govern. For a Credit Union member, we would look to the Membership Agreements and other contracts related to the financial and digital products or services provided to the member by the Credit Union (eg digital wallet, mobile banking app, etc).
Technology Context: Open Source from Toronto Legal Hackers
Thanks to Toronto Legal Hackers for the open source code we will focus on for this legal hack!
From Toronto Legal Hackers' Matthew Rappard:
I've uploaded to Github with a MIT license at https://github.com/TOLegalHackers/StonePaper
...I moved it all to Embark for you, this means you should have a web gui to walk you through as well as Test to show how it's supposed to work.
Embark is here
You can follow the instruction and install it easily... I hope. After which you should install the Embark demo with
Overwrite the files with these and it should run, simply type "Embark Simulator" in the command prompt to load the Simulator and "Embark Run" to run the simulation. You can also run "Embark Test" to test all the functions.
For security I don't think a Lawyer should ever directly modify the contract, I think it should always be done through another contract or a sub wallet, that has separate security or is maintained by a proper provider.
The solidity contract that run everything is under /app/contracts/StonePaper.sol . At the last minute I commented out some lines so it's a little messy.
The meta function is implemented in Tests but not in Embark project and many of the StonePaper's function aren't set up for proper testing but you should get the idea.
Last issue, in the web app for security reason you can only run many of the contract functions once. If you run them a second time it will throw a console error.
GodAddress which is button 2, is required for Get Lawyer which is button 4.
Prototype Business/Legal/Technical Success Metrics
The business test for this prototype at the end of our series of development and testing Legal Hack Nights we will do a full transaction walk through to test the sufficiency of this technology for meeting minimum expectations for the purpose of conducting the stated transaction in the assumed business and legal contexts.
We will seek to initially ensure a base-level test of this technology by doing a straight walk through and seeing if each party can perform each necessary action (eg can sign the agreement, can check the signature of other parties, etc).
We will do a second level test at the end of the series of five hack night by conducting the transaction but then assuming something went wrong (meteor hit the fridge, one party tried to defraud other, etc) and then test whether we have created and preserved the necessary information in a form that is admissible as evidence and that is the relevant evidence needed to prove the elements of the relevant cause of action (eg breach of contract, fraud, etc). We will do this by working with a litigator in Mass Legal Hackers around the test table to go through each key step needed for a party seeking to enforce the contract to access and enter the publicly verifiable data into evidence in order to recover from the problem with the transaction.
Media from Marc 28 Legal Hack Night:
The video of our initial hacknight can be found at: https://www.youtube.com/watch?v=TeIo8LEc2zA
Photos of the team and whiteboard can be found at: https://github.com/MassachusettsLegalHackers/BCID/tree/master/Media/2017-March27-LegalHackNight