Image source The new kid on the block is IEO (Initial Equity Offering). I coined that phrase because neither IPO or ICO fits. – IPO (Initial Public Offering) implies listing shares on a regulated Stock Market such as NYSE, Nasdaq, LSE, SIX etc. – ICO (Initial Currency Offering) implies issuingRead More
Bank Innovation
Last few weeks has seen the rise of The DAO – an organization like no other. Part VC fund of about 170 million USD, part crowdfunding platform, part machine. The machine part is the novel piece of the puzzle &8211; effectively all of the #governance of this new entity is done by smart contracts on Ethereum, so whereas before, humans outsourced worked to machines, the machines now outsource work to humans &8211; machines invite humans to fund them and then vote on, and monitor investments on their behalf.
Read my PALE blog for more details behind the concept of distributed autonomous organizations.
Whereas before, humans outsourced worked to machines, the machines now outsource work to humans
Whilst the idea of machine governance is truly exciting, in the case of a VC fund, folks like BitShares, who have been running a less public but none the less similar scheme for a bit now, have raised concerns such as effective engagement &8211; people like the idea and invest in a fund, but do not have the time or expertise to manage it, so without a clear leader, good decision making is absent &8211; of course on the other hand we have seen plenty of leaders make very bad decisions and whole concept of crowd wisdom argues that even relatively uninformed people, in sufficient numbers will make better decisions than a well informed individual.
The same concept of automated governance e.g. voting, can in my opinion be easily transplanted to many other areas, including #standards bodies. Think open source foundations like Apache Software Foundation, Linux Foundation, Ethereum Foundation and Bitcoin Foundation, or folks like International Organisation for Standardization (ISO) and BSI Group.
Whilst standard setting activity is far less glamorous than managing a multi-million fund, in my opinion it faces a far smaller risk of rejection &8211; very few people I suspect get excited about operating governance procedures, so automation here is a form of pain relief. The other issue with blockchains today is lack of transaction amount privacy, which may be an issue for VC funds in some cases, but a must-have feature for a standards body.
Assuming that either a standards body will be comfortable using virtual currencies or fiat money will be on-chained, a Governance DAO will even be able to manage it’s own funds to pay human staff wages, office leases etc.
And here comes the double whammy &8211; if the standards body is managing #reference #data, take ISO 4217 currency codes for example, both the codes and their metadata i.e. a living locally stored and replicated document, as well as governance rules like votes for change, can be managed on-chain by smart contracts.
Any change is replicated in near real-time to anyone running a node, to make use of as appropriate inside their firewall. Given the importance of reference data and today’s reconciliation issues, a Governance DAO sounds to me like a great value proposition.
Source: https://www.linkedin.com/pulse/crypto-20-musings-standards-reference-data-daos-alex-batlin
The post Alex Batlin’s Briefing of Crypto 2.0 Musings – Standards and Reference Data Governance DAO appeared first on Fintech Schweiz Digital Finance News – FintechNewsCH.
Nick Szabo proposed the idea of smart contracts back in 1997
Satoshi Nakamoto incorporated the idea of a smart contract in his Bitcoin: A Peer-to-Peer Electronic Cash System whitepaper. Instead of a vending machine safe keeping snacks and cash, and dispensing snacks plus change in exchange for cash, a distributed ledger, controlled by smart contract code, keeps account of how many bitcoins are held by which account and determines if new coins can be issued or existing ones transferred.
So what happens when the vending machine fails to give you back the right change? Most likely you look for a sticker on the vending machine with a phone number to call. You call the number, tell the operator the machine number, they pull up the instructions on what to do in case of failure, based on clauses of the vending machine legal contract, and hopefully proceed to solve the issue.
Wait, hold on, the operator follows instructions based on legal contract clauses! So there is an overall legal contract, some of contract clauses are performed by the vending machine’s smart contract code, others are performed by people. #Bitcoin’s design deliberately focused on a pure digital asset exclusively controlled by distributed-consensus-seeking smart contract code, which means that all legal clauses are covered by smart contract code, and hence there is no need for an encompassing legal contract, but for most real world use cases, including vending machines, you do need an overarching legal contract, and autonomous agents – be they humans, organizations or smart contracts, distributed or centrally operated, to ensure performance of one or more legal clauses.
Traditional legal contracts are unstructured paper or electronic documents that are not machine-readable, not surprising given they were only designed for human consumption. They also tend to be declarative, not procedural in nature i.e. they specify what should happen, not how.
That is why often there are operating instructions and procedures that describe how humans should do what things in order to comply with legal clauses. It is therefore useful to think of smart contracts as procedural code that is executed by a centralized or distributed-consensus-seeking platform in order to enforce performance of one or more declarative legal contract clauses, but in order to do that, the legal contract’s automation salient details must be machine readable.
This is where Ian Grigg’s idea of Ricardian Contract comes in
Whilst the focus of a Ricardian Contract is in recognizing that financial instruments e.g. currencies, bonds, shares should be issued as human and machine readable contracts, same principles can be in my opinion applied more broadly to any kind of legal contract, so as to be fully or partially enforced by both human and smart contract autonomous agents.
This is by no means a new idea. Primavera de Filippi published an excellent Legal Framework For #Crypto-Ledger Transactions post about integrating legal and smart contracts. She cites CommmonAccord, a global legal contract template system, as a means to create Ricardian Contracts.
Eris proposes an alternative eris: legal system, based on legal_markdown templates and CommonForm renderer, for what they call cryptographically-certain duel integration process:
#Blockchain smart contracts are by no means the only way to enforce Ricardian Contract clauses. Open-Transactions project, see whitepaper, implements financial instruments as Ricardian Contracts, processed by a transaction server based on cryptographic proof instead of trust, allowing any willing parties who wish to contract with each other to enjoy the benefits of a server without needing to trust it &8211; a solution that demotes transaction servers to mere notaries, only able to counter-sign contracts that have first been signed by their clients. Barclays’ Dr Lee Braine recently presented yet another alternative vision when he demonstrated an ISDA Master Agreement proof of concept on R3’s Corda &8211; a blockchain inspired platform lead by Richard Gendal Brown &8211; R3’s CTO.
One of the issues I foresee with the emergence of many different template and markup standards is the very plurality of standards. How do you know that the term in contract A is same or different in contract B. How can you create a nice looking document, yet mark it up in such a way as to make it machine readable. Turns out most of these questions have already been solved by the Semantic Webproject in the form of RDFa standard that embeds Linked Data in HTML, an extension to HTML5 that helps you markup things like People, Places, Events, Recipes and Reviews.
It builds upon standard Web technologies such as HTML, HTTP, RDF (allows creation of unambiguous structured data taxonomies) and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a way that can be read automatically by computers. RDFa was originally designed for Search Engines and Web Services to use this markup to generate better search listings and give users better visibility on the Web, so that people can find websites more easily, but in my opinion can be applied without alteration to Ricardian Contracts.
Let’s provide a simple example – a Ricardian Contract for weather insurance. Here is what a user would see in their web-browser:
—-
Example:
I, Alex Batlin, authorise the transfer from address ‘abcdwerr&8217; to address &8217;24dsfrg3434′ using smart contract agent address &8217;24dsfrg3434&8242; of &8217;10&8217; unit(s) of GBP pounds held by smart contract address &8216;4854398578934&8217; on the condition that website &8216;Weather.com&8216; confirms that &8216;0.5&8217; cumulative inches of rain did indeed fall between start date &8216;9:00AM UTC 10th of March, 2015&8217; and finish date &8216;9:00AM UTC 11th of March, 2015&8217; in country &8216;GB&8217; and postcode &8216;EC2Y 0RT’.
&8212;-
Hopefully pretty much self-explanatory, but on first glance not very useful for machine consumption. Let’s have a look at the underlying HTML:
&8212;-
<html>
<head>
<title>Example <a href=”http://reference.com/master-agreement-123&#8243;>Weather Insurance</a> Ricardian Contract</title>
</head>
<body prefix=&8221;rc: http://batlin.com/ricardian#&8221;>
<h1>Example Weather Insurance Ricardian Contract</h1>
<p typeof=&8221;rc:RicardianContract&8221;>
<span>I, Alex Batlin, authorise the transfer</span>
<span property=&8221;rc:hasTransferAuthorisation&8221; typeof=&8221;rc:TransferAuthorisation&8221;>
from address &8216;<span property=&8221;rc:hasFromAddress&8221;>abcdwerr</span>&8217;
to address &8216;<span property=&8221;rc:hasToAddress&8221;>24dsfrg3434</span>&8217;
using smart contract agent address &8216;<span property=&8221;rc:#hasAgentAddress&8221;>24dsfrg3434</span>&8217;
of &8216;<span property=&8221;rc:hasInstrumentUnits&8221;>10</span>&8217; unit(s)
of GBP pounds held by smart contract address &8216;<span property=&8221;rc:hasInstrumentAddress&8221;>4854398578934</span>&8217;
</span>
<span property=&8221;rc:hasTransferCondition&8221; typeof=&8221;rc:TransferCondition&8221;>
on the condition that
website &8216;<a href=&8221;https://www.weather.com&8221; property=&8221;rc:hasOracleUrl&8221;>Weather.com</a>&8217;
confirms that &8216;<span property=&8221;rc:hasCumulativeInchesOfRainDetected&8221;>0.5</span>&8217; cumulative inches of rain
did indeed fall between start date &8216;<span property=&8221;rc:hasStartDate&8221; content=&8221;2016-03-10T09:00:00<“>9:00AM UTC 10th of March, 2015</span>&8217; and
finish date &8216;<span property=&8221;rc:hasFinishDate&8221; content=&8221;2016-03-11T09:00:00<&8220;>9:00AM UTC 11th of March, 2015</span>&8217;
in country &8216;<span property=&8221;rc:hasCountryCode&8221;>GB</span>&8217;
and postcode &8216;<span property=&8221;rc:hasPostCode&8221;>EC2Y 0RT</span>&8217;.
</span>
</p>
</body>
&8212;-
You will notice that many HTML tags have additional attributes like property and type. When the same document is parsed through an RDFa parser, the following structured data (for this example in Turtle format) is extracted:
&8212;-
@prefix rc: <http://batlin.com/ricardian#> .
[] a rc:RicardianContract;
rc:hasTransferAuthorisation [ a rc:TransferAuthorisation;
rc:hasAgentAddress &8220;24dsfrg3434&8221;;
rc:hasFromAddress &8220;abcdwerr&8221;;
rc:hasInstrumentAddress &8220;4854398578934&8221;;
rc:hasInstrumentUnits &8220;10&8221;;
rc:hasToAddress &8220;24dsfrg3434&8221; ];
rc:hasTransferCondition [ a rc:TransferCondition;
rc:hasCountryCode &8220;GB&8221;;
rc:hasCumulativeInchesOfRainDetected &8220;0.5&8221;;
rc:hasFinishDate &8220;2016-03-11T09:00:00<&8220;;
rc:hasOracleUrl <https://www.weather.com>;
rc:hasPostCode &8220;EC2Y 0RT&8221;;
rc:hasStartDate &8220;2016-03-10T09:00:00<&8221; ] .
&8212;-
You will notice that at the top there is a link to the taxonomy definition file, which means every single property, is completely unambiguous. In fact you can define many different taxonomies or use many shared ones within the same document, which promotes re-use and efficiency, and you can use your client to also pull-in descriptions, labels, additional facts and any rules associated with a property. See if you can read the extract below, from the http://batlin.com/ricardian taxonomy file:
&8212;-
<rdf:Description rdf:about=&8221;http://batlin.com/ricardian#hasAgentAddress&8221;>
<rdfs:label xml:lang=&8221;en&8221;>Agent Address</rdfs:label>
<rdfs:comment xml:lang=&8221;en&8221;>Address of the smart contract responsible for doing the actual condition transfer.</rdfs:comment>
</rdf:Description>
&8212;-
Pretty powerful stuff! It’s worth pointing out that many financial vocabularies or taxonomies like ISO20022 are already expressed in XML Schemas, which can be easily converted to RDF schemas. In another words you do not need to re-invent how create your legal documents, just write them in HTML, which even MS Word supports, you don’t need to re-invent structured data serialization – use RDF, you can use RDFa to mark-up HTML with RDF, and you can reuse existing taxonomies like ISO20022 either by converting them from XML Schema or writing them native in RDF Schema or OWL.
So ok, you have defined your Ricardian Contract as RDFa marked-up HTML document that grants someone the right to withdraw some money from someone’s account based on a pre-specified condition, now what?
This is where I get inspired by Bitcoin – it defines a distributed ledger that safe keeps bitcoins and defines in a smart contract the generic transfer and issuance rules e.g. only allow someone who possesses the correct private key to spend only the ones what they own etc. If I try and create a more generic pattern, lets say on Ethereum, I end up with what I called the Instrument Smart Contract (ISC) – something that defines the procedural rules linked to one or more contractual clauses of a financial instrument Ricardian Contract and keeps ledger of ownership.
Bitcoin actually specifies some of it’s transfer rules via scripts attached to transactions – default one being that a specific key is required to spend the transactions, whilst double spend prevent etc. rules are hardwired into the protocol code. Scripts can support more advanced conditions like multisig. To create a more generic and re-usable pattern, I propose the idea of an Agent Smart Contract (ASC)– something that encapsulates more user specific conditions in procedural code to achieve the declarative end state, again linked to legal clauses.
In effect, the Weather Insurance ASC is granted permission to transfer value held in the GBP ISC from issuer to beneficiary if it is presented with sufficient evidence by the beneficiary. In this example, proof-of-contract and proof-of-weather (a form of proof-of-condition) will be required as evidence. Proof-of-contract is the digitally signed Ricardian Contract expressed as RDFa marked-up HTML document. Proof-of-weather is in this case a digitally signed JSON response from a RESTful API service by Weather.com with contract matching parameters. It could as easily be a smart contract controlled by a smart oracle – if on-chain notary is an advantage.
Here is a, not at all well thought out, process to claim your insurance and get paid:
Note, the ASC may itself be an ISC – meaning that for instance if you buy a bond, the bond gives you the right to get paid coupons from the issuer’s money smart contract. In this way you can implement complex atomic swaps spanning multiple instruments e.g. Delivery vs. Payment, Payment vs. Payment. In fact the ASC may be a good place to implement Interledger’s notary services, as long as the ISC supports ledger-provided escrow. Interledger is a protocol for payments across payment systems. It enables secure transfers between ledgers and allows anyone with accounts on two ledgers to create a connection between them. Ledger-provided escrow removes the need to trust these connectors. Connections can be composed to enable payments between any ledgers, creating a global graph of liquidity or Interledger.
The ASC can also be a good place to implement state (micropayment) channels and off-chain oracles. Many contracts never get exercised e.g. options, insurance – so recording them on-chain is a waste of resource – good enough security can be achieved without use of on-chain smart oracles or storage of contract instance if proof-of-contract and proof-of-condition (in this case weather) is submitted to ASC when the claim needs to be made. Another advantage of this approach versus bundling all logic into the instrument code is flexibility – code can be kept tight and implement core logic, and allow many claim conditions e.g. if the holder of a bond fails to collect coupon payments, but has a credit default swap, this can be activated and money collected from underwriter.
Source: Content from https://www.linkedin.com/pulse/crypto-20-musings-combining-ricardian-smart-contracts-alex-batlin and Image from http://www.lyntonweddingvenue.co.uk/hands.jpg
The post Alex Batlin’s Briefing of Crypto 2.0 Musings &8211; Combining Ricardian and Smart Contracts appeared first on Fintech Schweiz Digital Finance News – FintechNewsCH.
More than 15 members of #Congress met with representatives of the #blockchain #technology industry this week in Washington, DC.
fintech techcrunch
Reply