Tagged: smart contracts Toggle Comment Threads | Keyboard Shortcuts

  • user 11:37 pm on October 27, 2016 Permalink | Reply
    Tags: , smart contracts,   

    Smart Contracts: A Spectrum of Possibilities 

    In-house counsel are going to be hearing a lot about smart contracts. They need to prepare themselves for the discussions that their business and commercial leads are going to want to have with them. That means quickly coming to grips with the key commercial, legal and regulatory issues that can give rise to.

    Smart contracts exist as code within blocks in a . They have the potential to automate performance of a transaction and are typically described as “self-executing” for this reason.

    In identifying the issues a business may face in a smart contract deployment, it is important to take on board that there is a spectrum of possibilities as to what a smart contract actually is. At one end of the spectrum, there is the “code is contract” model (which aspires to fully encode complex commercial contracts). At the other end of the spectrum, there is the automation of business logic and/or the automation of the performance of aspects of a conventional contract.

    The “code is contract” model is very challenging from a legal perspective. It puts into question an issue potentially relevant for all smart contracts: has a legally binding contract formed? The answer to that question may vary according to the applicable law determining the issue.

    In between the two extremes on the smart contract spectrum, it is likely that more modest but achievable use cases will emerge. A good example is the smart contract model developed by Barclays and R3, under which contracting terms (in the form of an ISDA master agreement in natural language) are connected to computer code via parameters (a smart contract template). These parameters feed into computer systems for execution.

    This is in effect a split (or so-called “Ricardian”) contractual model, which avoids some of the pitfalls currently associated with the “code is contract” model (for example, how do you encode concepts that involve judgement or degree, such as “reasonable endeavours” or “as soon as practicable”?)

    Any proposed smart contract deployment would need to consider regulation. However, to date, the responses of regulators globally to blockchain have been fragmented, and are (generally speaking) at quite an early stage.

    There is likely to be a lack of certainty and consistency in terms of the regulatory treatment of smart contracts and other applications of blockchain technologies for some time. In developing their regulatory responses, policy-makers will need to consider a number of key questions, such as: what should be regulated; which activities should be regulated; who should be subject to and responsible for compliance with the relevant obligations; and how should regulatory responses be pitched so as to avoid stifling innovation? In addition, policy-makers are likely to focus on how AML and KYC regulatory obligations can be credibly performed. Regulators will also be interested in how the use of blockchain and smart contracts affects firms’ risk profiles.

    As a matter of risk analysis, in-house counsel will need to consider the legal and operational consequences of transacting in an electronic context. Apart from the fundamental question about whether a legally binding contract is formed, it is important to bear in mind that smart contracts sit within blockchains operating over the World Wide Web. They are code. Code can contain bugs. Code may not always perform as the parties had intended. Messages transmitted over the Internet can be delayed or interrupted, and data can be corrupted in transmission. Private encryption keys can be obtained by hacking. The liability implications of these kinds of events need to carefully considered.

    It is likely that, once a model is demonstrated to work in a live environment, not only will it be adopted elsewhere, but smart contracts will, with developments in the underlying technology, incrementally become more sophisticated over time. It is quite possible that, in five years or ten years’ time, smart contracts will be doing significantly more than just automating aspects of the performance of contracts.

    However, some observers put the time horizon for a large-scale implementation of smart contracts within, say, the financial services sector at just 18 months. My own view is that it will probably take longer. Having said that, there is a great deal of technology and entrepreneurial “digital fuel” being thrown at this area at the moment, so in-house counsel would be wise to track developments and to ask to be involved in the consideration of a business’s use cases and proof-of-concept deployments for smart contracts at an early stage .

    Norton Rose Fulbright has a dedicated global team focused on blockchains, distributed ledgers and smart contracts. Follow the latest developments here.

    Sean Murphy is a Norton Rose Fulbright Partner in London. He co-chairs the firm’s global blockchain and distributed ledger practice group.

     
  • user 11:35 am on October 4, 2016 Permalink | Reply
    Tags: , , , financial service, , smart contracts,   

    Blockchain, Real Smart Contracts?! 

    aaeaaqaaaaaaaaixaaaajdk3otqxowjjltazmwytndk5ys1hzmu2lty4odringuyndjhzq

    and well integrated provide

    Real .

    Summary. The main blog, “Blockchain will change the world..?!”, proposes three fundamental research questions. In this blog and following blogs the third of these questions “How to apply blockchain?” or “How to do it..?!” is investigated.

    In order to apply blockchain well, it must be well understood what blockchain provides us and what not. In the blog “Blockchain, what does it provide us..?!” is shown by observation that blockchain is a notarization system, explicitly not a transaction system. But notarization of documents and transactions are closely related. In this blog the relations between DEMO (Design and Engineering methodology for Organizations) transactions, notarization and real smart contracts is explained. It “fits like a glove”.

    First the real world is observed to understand what transactions are and how they are related in the real world. Then the notions of Real Smart Contracts (RSC) and DEMO transactions are described. The functional perspective of a RSC is to represent the things in the real world by documents, transactions, contracts, communication, commitments, etc, with blockchain’s notarization capability, as good as possible. There are quality criteria defined.

    Finally some aspects of the construction of the RSC, the relation between all kinds of information that may be notarized and a transaction is described. The next blog “Blockchain, how to do it..?!” shows how enterprises can be engineered using DEMO and how blockchain notarization is supported.

    This blog and the related blogs are intended for the professionals, those who have to apply the blockchain and design better services and enterprises. In most cases they have a background in economics, management and not so often in engineering. This nature of the blogs is informal and explanatory, making clear what is available and what can be done with it. Much emphasis is placed on how good engineering works and on what good observation of the real world provides us.

    1. Introduction

    There is a widely accepted perception that the potential impact of blockchain for society is huge and a game changer for many industries. However, there are many touted benefits that are questionable and probably will not be realized if we do not understand well what it is. In the root blog “Blockchain will change the World..?!” it is discussed that these benefits will not be realized if state of the art modeling technologies are applied to develop systems. Further, three fundamental research questions have been postulated;

    1.1. What can we do with blockchain? The blog “Robust world financial blockchain systems..?!” states that society would probably benefit most from robust and fault tolerant financial systems in the world. The “Keeping the cyber criminal out” now enhanced with “Once the cyber criminal is inside, make sure that he cannot do much harm”, but doing it in a much better way than state of the art. Using a good engineering methodology to design and implement enterprises and applying the benefits of blockchain.

    1.2. What does blockchain provide us? In that blog has been argued that blockchain provides trust-less authenticity of documents, or notarization of documents. It is that and nothing more, but this is already very valuable. The blockchain technology is not a transaction executing system.

    Failure to understand this has serious consequences. First, blockchain experiments that apply blockchain as the core transaction system will be faced with large engineering problems, notably unmanageable complexity, and are therefor prone to failure. Secondly, a number of the promised and touted benefits of blockchain are based on the wrong assumption that blockchain is a transaction based system.

    1.3. Blockchain, Real Smart Contracts..?!. In this blog is shown that there is a close relation between notarization and transactions. Blockchain notarizes results of transactions, such as communication, commitments, contracts, transaction related documents and the production of a transaction etc. The DEMO methodology, part of the enterprise engineering discipline, is strongly based on transactions. DEMO transactions have sophisticated capabilities. We need both capabilities. So, a good alignment and integration of blockchain notarization and DEMO transactions provides us the Real Smart Contracts (RSC’s).

    2.  The world of actors, transactions, communication and commitments.

    As in most of these blogs, a careful and good observation of the things and their relations in the real world is mandatory if we want to build systems and enterprises that work well in that real world.

    2.1 The notion of an actor. An actor is “somebody”, either carbon-human or silicon-computer, who does “something” in the real world. An actor “acts”, which results in “facts” in the real world. Actors fulfill roles. A role is the fulfillment of a specific task that is part of a specific service to a specific customer. There is an abstraction between actor and a role. Multiple actors can fulfill multiple roles. At run time a role can be assigned to an actor. This is represented for example in natural language, “Joe, will you do this job for me?..”, which is a Request.

    2.2 The notion of a transaction. In this blog we do not use the notion of an economic transaction, with a transfer of products in one way and a matching transfer in finance the other way. An example of an economic transaction is the purchase and payment of a product. The notion of transaction applied here is an atomic or an elementary transfer. A purchase and a payment involve two elementary transactions. Any matching compensation for some payment or the delivery of some service may exist but is out of our scope of a specific transaction.

    Any (atomic) transaction involves two parties, or actors, with mutual communication, commitments and some exchange, typically some kind of production or transfer of value. The mutual communication is typically expressed in natural language and involves very important notions such as negotiations, commitments, obligations, intentions and more. Part of the communication in a transaction is a mutually binding agreement or commitment to deliver the ‘production’ of the transaction from one actor to the other actor. In a legal sense this is a binding contract. Contracts are important entities, trust-less authenticity of all commitments and contracts is clearly a valuable asset. Another important part is the finalization of the contract; both actors agree that the transfer has been made and accepted (or not, or not yet). Transactions may embed other transactions in an ever recursive way. For example, a transaction for the delivery of a car demands that the transactions for the production of the engine and the wheels must have been performed and delivered before the car can be assembled, which is another transaction. Only, then, after completion of all the previous transactions in production, the transaction for the delivery of the car can be finalized. We see that transactions are often organized in a tree structure. The notion of a DEMO transaction between two actors is a very suitable building block for enterprises. There is much empirical experience, good theory, proven results. This works very well.

    2.3 Observation of the world of transactions

    Our world of interest is composed of transactions, transactions are everywhere.

    An example: Assume that 2 people – actors communicate and agree to meet at the Liberty Statue on Thursday. There is a Request and a Promise and together that is a (legally or moral) binding contract, actually two contracts because each actor commits himself to the other to be there. They execute a transaction and the result of that transaction is that each of the two people actually meet there. The binding contract(s) may be fulfilled, or not, if one or both does not show up.

    Many other transactions must be fulfilled before the actors can fulfill their transaction. A ticket and a hotel room must be booked, more transactions. The aircraft carrier must fulfill many other transactions first, etc. We observe that the world is composed of transactions and that these transaction are highly structured and inter dependent in a hierarchical way. The “lower” transactions must be finished before the “higher” transactions can be fulfilled.

    This real world of transactions between individuals and enterprises is not much different from the world of transactions within enterprises. Within enterprises all the transactions are usually a bit better defined and organized, but there is no fundamental difference.

    With this notion of a transaction, all transactions between financial services, , insurance companies, customers etc. at a macro scale are captured. At a micro scale, within these enterprises, we also see an ocean of structured, nested and related transactions, in the finest details. The name of the game is to organize these transactions in such a way that the enterprise performs as good as possible.

    Our world of interest consists of transactions, transactions are related or embed other transactions. Transactions are everywhere! If we understand the notion of transactions very well then we can realize huge benefits.

    3.  Real Smart Contracts

    3. 1 The notion of a Real Smart Contract

    Real Smart Contract = Blockchain + DEMO

    Real. Refers to the requirement that all situations hat occur and all things that may happen around contracts in the real world around us, must be captured well. First the real world must be observed very well and well represented. Then must be shown that DEMO transactions provide the needed capabilities to capture the phenomena in the real world well.

    Smart. Refers to the qualities of the RSC:

    1. Captures all binding obligations related to the contract in any way;
    2. The RSC is much more than a contract. It captures the execution of any kind of transaction and relates to “everything” that is in some way connected to a transaction;
    3. It applies blockchain’s notarization capability to provide guaranteed completeness and correctness, with trust-less authenticity, of all information related to the transaction and the contract;
    4. RSC’s can be stacked like brick stones on each other to build any imaginable enterprise; they cooperate automatically with guaranteed formal correctness, controlled by a software engine, called the enterprise operating system.

    Contracts. The DEMO transaction captures communication and commitments that represent a contract and the fulfillment of that contract, plus much more. The RSC is a well aligned integration of a transaction, a DEMO transaction and the blockchain notarization capabilities.

    RSC’s are the building blocks of any enterprise that needs blockchain notarization.

    The DEMO methodology is the engineering way to build enterprises using RSC’s like brick stones.

    3.2  The notion of a DEMO transaction

    DEMO is based on communication and commitments. Typically the communication is in natural language, but not necessarily. Communication here is any exchange between two actors that creates binding commitments in some way. The seemingly simple question in a shop “Give me some of these flowers” has the effect that the shopkeeper must reply, either to Decline the Request and Promise the Request. Also the customer is now committed by this simple phrase. The power of social media shows us how important communication is. However, communication with binding commitments that must be kept, and will be kept with the help of a software engine, is probably a new paradigm.

    The picture on the left is an informal representation of a simple transaction. On the right is a formal representation in a conceptual language.

    The picture shows the most simple pattern of a transaction execution. The customer, initiator of the transaction, issues a Request for some flowers. The producer, the executor of the transaction issues a Promise to deliver the flowers. The Request and the Promise constitute a binding agreement, a contract. The fulfillment of the transaction is realized when the executor states that the flowers are there and the customer initiator accepts the flowers. Both actors agree that the initial contract has been fulfilled.

    A more precise version of a transaction pattern is followed when there is a negotiation between the two actors, The Request may be followed by a Decline, for example if there are no flowers. The contract will not be agreed upon. Similarly, there may be a dispute about the fulfillment of the contract; the customer initiator may decide that these flowers are not what he wanted, he may Decline the flowers. Also here is a negotiation and a dispute may follow.

    In an even more sophisticated transaction pattern the actors are also capable to revoke their earlier commitments. For example: the producer executor may first issue a Promise for the flowers – the contract has been signed by both actors – but decides for some reason that this was not a good decision. He revokes his earlier Promise and wants to issue a Decline, not bound to this contract. For this revoke, a contract termination, the permission from the other actor is needed. So, here is also a sophisticated communication pattern with negotiations.

    In this way, with the several transaction patterns, all events that occur around a transaction, the things that may happen in the real world, are quite well captured. If our RSC’s would not be that real smart, then the appropriateness of it would be affected. It is not that suitable anymore. Empirical evidence shows that these transaction patterns have a very good degree of appropriateness.

    3.3. The integration of blockchain notarization and a DEMO transaction

    Observation of the execution of a DEMO transaction shows which elements of that transactions can be notarized. Assume a transaction for some , provided by a bank for a customer.

    For each communicative act (a Request / Promise / Decline / State / Reject / Accept) usually some relevant documents that must be provided. A Request for a mortgage is typically accompanied with additional information such as the real estate, the identity of the customer, salary information etc. All these related documents must be notarized, together with the Request itself, at the moment the Request is issued.

    The production of the financial service is represented by a document – it is not yet a contract! – that contains things like calculations, obligations, commitments, legal texts, conditions that may occur the real world later, etc. This document must be notarized immediately after it becomes available, independent from any communicative acts, though they are closely related. The unsigned contract must be notarized first! Then the customer gets access to the document and may decide to commit and sign or or not.

    The contract is actually signed and agreed upon when the customer has confirmed his Request by placing his signature on the paper document and the service provider has confirmed his Promise also by signing the paper document.

    Often there are other related documents that are part of financial service that may be notarized, such as interest rate calculations, approval of supervisors. In fact, a mortgage is a fairly complex financial service that is composed of a number of structured supporting transactions, RSC’s. For each of these transactions may be specified at modeling time what should be notarized, or not.

    After signing, represented by a Request and a Promise by the parties, the contract must be fulfilled by the two parties. This encompasses in practice many other transactions, monthly payments, mandatory insurance, approvals, etc. In special cases some of these transactions may demand a partial roll-back, which must be carried out with formal correctness. Failure to realize this could result in a deadlock situation.

    This shows how DEMO transactions and blockchain’s notarization capability are closely related and well integrated into RSC’s. From a software engineering perspective the implementation of notarization in a transaction is even remarkable simple. It is a simple extension to the DEMO engine as will be shown.

    3.4. Some more capabilities of DEMO transactions

    Observing the real world we see that transactions are nested in a structured hierarchical way both between and inside enterprises. The “lower” level transactions must be completed before the production of a higher transaction can be completed. This defines a close relationship between transactions, transaction may be stacked like brick stones.

    Example: the delivery and manufacturing of a bicycle by a manufacturer. The transactions to produce wheels and a frame must be completed before the assembly of the bike can be done. After completion of the transaction for the assembly of the bike, only then, the bike can be sold and delivered via the transaction between customer and bike manufacturer.

    If one of the lower transactions cannot be completed – assume there is a problem at the wheel manufacturer. The wheel manufacturer cannot deliver the wheels. The bike can not be assembled. The bike can not be delivered to the customer. It means that the transaction tree must exhibit several kinds of roll-back capabilities with mathematical correctness. Any deadlocks or anomalies should not occur. Looking closer at the total number of different execution path’s in models of more than two transactions shows exponentially growing complexity, far beyond our small brains to capture this. This is the reason that models with more than two transactions should be calculated by a software engine, not by human programmers. It shows also why the industry standard BPMN (Business Processes Modeling Notation) is only suitable to model the simplest “happy flows” in production and fails to handle any exceptional conditions such as roll-back phenomena.

    DEMO transactions support business rules that control the execution of the transaction. An example is a Request from a customer to his bank for a loan. The bank must carry out all kinds of checks, each controlled by a transaction. A business rule could state that for an amount more than 1000,- USD the approval of a colleague must be given. The business rule would enforce the transaction with the colleague to be completed – approval given or refused – before the transaction with the customer may continue. This precise definition and control of each actor in the enterprise is of great importance to improve the quality of the daily operation.

    3.5. DEMO modeling provides high quality enterprise specifications

    DEMO theory provides also clear specifications of the notions of authority, competences and responsibilities for each actor role. The human actor who fulfills an actor role must meet these criteria. It supports the matching of employee competences to functions.

    The qualities of communication between actors are defined by claims of truth, claim of justice, and claim for sincerity, that are provided by the Habermas communicative theory. Actors are assumed to communicate the objective truth; be sincere though they can be mistaken (subjective); and should only communicate what is allowed.

    DEMO theory provides a methodology for constructional decomposition which provides clear specifications for each production part in production. This is typically a product blueprint with a BOM (Bill of Materials).

    The Real Smart Contracts have these capabilities to capture the real world well and to be a good building block for enterprises. The other part of the equation is the methodology to do this.

    4. Conclusions

    The alignment and integration of blockchain and DEMO models matches in a conceptual way very well, is very straightforward and offers great advantages when sophisticated enterprises have to be designed and modeled that apply blockchain well.

    The DEMO modeling methodology is very sophisticated and powerful. Instead of using DEMO transactions as the core building block of enterprises, the augmented Real Smart Contract is the building block of enterprises that need notarization.

    In the next blog “Blockchain, how to do it..?!” is shown how DEMO models of enterprises are modeled, what they provide, how blockchain notarization can be modeled and how enterprises are driven and controlled by DEMO models in production.

    More practical blogs on how to do it will be: “Banking transactions – PSD2 with blockchain” and “Co-creation and co-production in production chains using blockchain”.

    The author, Steven J.H. van Kervel, Ph.D. computer science, is with Formetis Consultants BV in The Netherlands. Formetis are enterprise engineers. They develop methodologies, tools and software systems for the engineering of enterprises with supporting IT systems, applying and supporting the blockchain technology. Formetis participates in the CIAO! community of scientists and engineers on the field of enterprise engineering.

    Formetis seeks partnerships to bring this technology to the real world.

    Contact: [email protected]


    is consultant at Formetis

     
  • user 7:36 am on August 20, 2016 Permalink | Reply
    Tags: axzz4CR0oiNB9, , , , , smart contracts, Taxes,   

    Smart Contracts, Cryptocurrency and Taxes 

    AAEAAQAAAAAAAAhQAAAAJDNkNDliOTJjLTJjNTMtNDJmMS1iMDM5LTBhZTZhN2UzMjY1OQ

    In a previous article I wrote about Ethereum and a prenuptial smart contract created in , I attempted to draw attention to how blockchain transactions could be analyzed under U.S. contract law.

    The prenuptial smart contract I used as a test was somewhat whimsical and didn’t address the more practical issues which could face, for example, a small business seeking to minimize financial transaction costs using this platform.

    Therefore, I would like to take the legal analysis a step further and apply it to a hypothetical small retail business with modest income and significant transaction fees paid to , merchant services companies, and credit card companies. Small businesses can be early adopters and present a huge market ripe for change. According to the Small Business Administration, there are 28 million small businesses in the United States and account for 40% of all retail sales.

    Under this hypothetical scenario, the merchant decided to use a popular online payment system to reduce costs, but soon discovered that fees intended to be avoided were again imposed once the merchant reached a certain sales threshold. In addition, the dreaded credit card processing fees were not eliminated entirely.

    In addition to credit card transaction fees, the merchant was faced with various state, local and federal . The merchant wanted to pay only those taxes for which the merchant was legally obligated and limit the exposure to greater financial management costs.

    This is an area where blockchain may prove to be at a great advantage — reducing transaction costs to small and medium sized businesses.

    Preliminarily, however, it may be useful to explain a little about the contracting process being proposed by , the substance of which is reproduced here and derived from my previous post:

    Virtual contracts are not new. What smart contracts (potentially) offer are streamlined and transparent transactions at a minimal and known cost. This contracting process runs without human intervention based on a sequence of coded events monitored and executed by a virtual distributed transaction-based and encrypted system. Blockchain is often described as an online decentralized ledger of financial transactions, the nature of which is transparent to others on the blockchain. Ethereum is a blockchain platform over which can be exchanged as well as smart contracts formed. Blockchain began as a transparent and public peer-to-peer financial ledger using cryptocurrencyand is at the beginning stages of transforming how the federal government, small businesses and financial services do business.

    Cryptocurrency evolved from the current fiat monetary system and has beencompared to the gold standard. These monetary forms rely on a belief that the currency (in whatever form) has an agreed upon, or market created, value. Similarly, consideration, a necessary legal contract element, relies upon the parties agreeing that the value exchanged (the consideration — whether money or promises) is sufficient for an enforceable contract. For the small business hypothetical, I will use the Ethereum platform and related smart contract formation.

    The Ethereum platform uses “ether” cryptocurrency, a competitor to the more familiar bitcoin. The smart contract manages a series of mini transactions (with the colloquial meaning, not the Ethereum definition), each of which build the agreement whole. Along the way, “fees” are paid for each interaction along the blockchain process. The fees pay the “miners” who process each transaction. This activity goes on separately from the over-arching contract’s performance. Fundamentally, there are two things going on — 1) smart contract transactions and 2) the real world contract performance, each are necessary to analyze as enforceable contractual transactions.

    Generally, a contract in the U.S. is enforceable if: 1) the parties can legally enter into the contract; 2) there is an offer and acceptance; 3) there is consideration; and 4) the subject matter/form is legal.

    When there is a discussion about the legality of smart contracts, it is generally about two things: 1) whether the smart contract is illegal because of its purpose, e.g., a smart contract to commit fraud is illegal, and therefore unenforceable or 2) the blockchain code itself may render the contract illegal. I suggest that each step be analyzed as a separate contract (because consideration is exchanged at every stage in Ethereum) to determine whether each transaction is legally enforceable, e.g., is there offer and acceptance? consideration? legal parties? proper form/legal? All would have to exist for a legally enforceable contract in the U.S.

    Thus, there are two legal landscapes over which a my hypothetical merchant must navigate — the umbrella contract itself as well as the individual transactions over the blockchain.

    The contractual disputes my hypothetical blockchain merchant may face are familiar — they differ only in format and understanding. If the merchant business and its customers do not read the contracts into which they enter, are they bound? Generally, yes, unless there was fraud, duress or coercion. Should customers and merchants be expected to read code? I think there is great room for improvement here.

    When a smart contract is created, there is frequently a document in human readable, ornatural language, form which is supposed to be the basis for the smart contract code. However, some process-related transactions which are required to operate under the software platform may not be included in the contract — for example, what happens if the transaction fails (no currency or no performance) or what happens when either the merchant or the buyer changes an account address after the parties have agreed to the transaction. This may be handled in the blockchain, but the terms may not be reflected in the natural language contract. These could become routine fixes because the problems are common in regular contracts, i.e., if one party breaches, identify the remedies in the contract (select breach remedy options to include in smart contract code); no changes without the parties’ permission (flag when anyone attempts to modify/change code). The mirror image rule would be useful under these circumstances.

    For my hypothetical small business, what problems may it face under U.S. regulation and tax laws?

    The Wall Street Journal has been very busy publishing articles on bitcoin. On July 19, 2016, it posted an article about whether nations should issue bitcoin. On June 24, 2016, it published an article about how bitcoin may be taxed. In my opinion, working through the kinks now will help shape policies and regulation later.

    The WSJ tax-related article identified issues which may be faced by virtual currency owners and investors. The author referred to a letter sent to the IRS by an accountants’ advocacy group, the American Institute of CPAs. Specifically, the author asked whether virtual currency owners and investors would face capital gains tax penalties each time virtual currency is sold. In 2014, the IRS’s answer was yes, if the virtual currency wasbeing held as an investment asset. If it is used as a substitute for currency, i.e., barter or trade, then anyone using the virtual currency would face the same tax liability as that related to earning regular income, regardless of the form in which the barter appears.

    Here is the IRS position copied from Notice 2014–21 under FAQs:

    “Q-7: What type of gain or loss does a taxpayer realize on the sale or exchange of virtual currency?

    A-7: The character of the gain or loss generally depends on whether the virtual currency is a capital asset in the hands of the taxpayer. A taxpayer generally realizes capital gain or loss on the sale or exchange of virtual currency that is a capital asset in the hands of the taxpayer. For example, stocks, bonds, and other investment property are generally capital assets. A taxpayer generally realizes ordinary gain or loss on the sale or exchange of virtual currency that is not a capital asset in the hands of the taxpayer. Inventory and other property held mainly for sale to customers in a trade or business are examples of property that is not a capital asset. See Publication 544 for more information about capital assets and the character of gain or loss.”

    In the U.S., taxpayers who trade services for goods, or goods for goods, are required to report the income value of the services or goods received. The letter referred to in the June 24 WSJ article asked for additional guidance from the IRS with regard to tax reporting in order to assist their members. However, for purposes of the hypothetical small business, it may be sufficient to consider that if cryptocurrency is being traded for goods or services, the tax laws would be applied in the same way as regular income, and not subject to capital gains tax penalties.

    So it appears that like most U.S. taxable events, the local/regional/state/country tax laws apply. As a point of reference, these issues have been addressed similarly for online transactions.

    Absent startling revelations about smart contracts or cryptocurrency, these tax obligations should be familiar to small business owners. If not, small business owners should familiarize themselves with the relevant tax laws or secure professional tax advice before accepting/trading cryptocurrency.

    As for the smart contracts, careful design, planning, and predictable dispute resolution remedies will assist in promoting smart contracts as a viable business tool for small and medium-sized businesses.


    [This article was posted previously on Medium on 7/26/16.]

    Cynthia M. Gayton is an attorney, educator and speaker. She has advised small and medium sized software development companies as well as arts and entertainment businesses and individuals. She has an undergraduate degree in international affairs with a concentration in science and technology as well as a J.D. Nothing in this article is purported to be legal advice. You can contact the author via email at [email protected].

     
  • user 6:00 am on June 29, 2016 Permalink | Reply
    Tags: , , , smart contracts   

    Tech Primer: What are Smart Contracts? 

    AAEAAQAAAAAAAAf9AAAAJDdkOTM5ODBlLWMxZDUtNDFiNy1hNGU4LWUwOWY2NzRlZDkwZg

     are computer protocols that facilitate, verify, or enforce the negotiation or performance of a  contract, or that make a contractual clause unnecessary.  Smart contracts usually also have a user interface and often emulate the logic of contractual clauses.” – Wikipedia

    Smart contracts seem to be all the rage right now, and there have been quite a few posts about them on Twitter, LinkedIn, and in the blogosphere recently.

    So… what are they?

    You have more than likely experienced a smart contract within the last 12 hours, either personally or as an unknowing (or knowing) participant: Digital Rights Management as an example, whether for music or movies; Hotel room key usage; Online gambling (I hope not); Mobile data usage and overage charges; Book/ship arrangements for service payments. The list goes on and on.

    More commonly, today, you are likely seeing these terms floating next to the words , Codius, or (who has been in the news of late due to a hack), or . None of these are required to have a smart contract, but they are likely culprits for increasing the buzz-wordiness of the concept.

    Smart contracts basically boil down to this (simplified) explanation: Two people, or entities, decide on an arrangement that can be both digitally validated and enforced. A trusted electronic system monitors the validation point(s) and when a criteria has been met, the system enforces the arrangement. Here’s an overly-simple example:

    • You want to rent a movie on DVD.
    • You swipe your credit card at a kiosk.
    • Your card is approved and rental funds are moved into the DVD owner’s account.
    • Upon receiving the funds, the movie is released from the mechanism and you may take it.
    • If you fail to return the movie within a time limit, you are billed the cost of the DVD.
    • Attempts to rent another movie while you have another rented are rejected.
    • Returning the movie — or a purchase transaction — frees you to rent another DVD.

    The smart contract says you are welcome to rent the movie as long as you pay a fee and agree to be charged for a purchase if you fail to return it. The mechanism of enforcement is built into the lock/holding mechanism and the trusted system (you do trust your movie vendor, right?)

    The example above is a physical implementation of DRM, the same process could be illustrated for digital locks on Pay Per View movies or downloadable content such as text-books or streaming music. The same IF THEN ELSE rules apply: IF something happens THEN do this, ELSE do this other thing.

    • IF it’s the first of the month THEN pay the rent
    • IF I am thirsty AND it’s 6pm on Friday THEN beer, ELSE water
    • IF VALUE(MyStock) < $5 THEN BUY(MyStock) ELSE SELL(MyStock)

    The Contract is Smart as long as the criteria can be electronically validated in some way that both parties trust and the enforcement can be done electronically and automatically.

    The key to why you’re seeing more and more talk about Smart Contracts is the interest in several frameworks and systems that are being built. Bitcoin and Ethereum, or Barclay’s use of R3’s Corda platform being prime examples of some of those systems.

    That’s it, Smart Contracts in a nutshell.

    ** Tech Primers are meant to be brief and to the point, they are by no means comprehensive. Want to learn more? A good book, your local technologist, Google, and/or Wikipedia are all great resources! ** 


    is IT executive at RagingWire Data Centers.

     
  • user 10:59 am on June 28, 2016 Permalink | Reply
    Tags: , , smart contracts   

    Ethereum’s Killer App: Freedom of Contract 

    In recent weeks, governance issues are a primary concern for the community as it deals with how to build that are useful as well as innovative.

    I am convinced of the viability of the Ethereum concept, if executed in a way that works for real human relationships. Business intelligence tells me that establishment players like and governments are convinced too. Today they lack the brainpower to duplicate Ethereum’s achievements, but in time they will manage to execute a world computer for mainstream commerce. A longtime commercial lawyer, I could just build toward that, taking from Ethereum its brilliance and giving nothing in return. But I am more than just a lawyer, I am a dreamer with a mission.

    The likelihood of wide-scale smart contracts adoption makes the development of effective commercial models for Ethereum even more important. Many of us aren’t the type to accept the dominant commercial paradigm easily. We want freedom of choice, of self-determination. We want to opt-out and do it our own way. With those freedoms comes the necessity of self-governance.

    Done well, smart contracts will unlock for everyday users the wonders of private law previously only available to the rich. Private law has as its fundamental underpinning “freedom of contract”, a common law concept that respects the will of the individual to bind one’s self to a promise. Courts come into play in private law only when parties fail to self-govern or damage others. Staying within the sphere of private law is desirable in building smart contracts, at least as a first step. Taking advantage of property and contracts law benefits while avoiding torts and regulatory pitfalls requires legal training, but it is possible.

    When humans learned to write on a wide scale, they began to record contracts, paper documents reflecting a previously oral process. They had the same questions of intent, governance, fairness and predictability as Ethereum developers as they developed ways to deal with the permutations of human contract. They saw in written contracts tool for building vehicles of unlimited potential.

    Freedom of contract is real, and as Ethereum smart contracts builders it is what will set us free.


      is Head of Legal Engineering, Eris Industries and this article was posted on linkedin.

     
  • user 7:35 pm on June 9, 2016 Permalink | Reply
    Tags: , dao, smart contracts   

    Crypto 2.0 Musings – Standards and Reference Data Governance DAOs 

    AAEAAQAAAAAAAAeJAAAAJDM5MjlkMjgzLTI0ZWEtNDJjNy1hM2Y4LWRjZmE4NzlmNGExNA

    Last few weeks has seen the rise of The – an organisation 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 – effectively all of the governance of this new entity is done by on Ethereum, so whereas before, humans outsourced worked to machines, the machines now outsource work to humans – 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 organisations.

    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 – 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 – 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 Foundation, or folks like International Organisation for Standardisation (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 – 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 – 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. 


    is Senior Innovation Manager and this article was originally posted it on linkedin.

     
  • user 10:40 pm on June 4, 2016 Permalink | Reply
    Tags: , smart contracts,   

    Making Sense of Blockchain Smart Contracts – CoinDesk 

    The idea has long been hyped to the public as a central component of next-generation platforms, and as a key capability for any practical enterprise application.

    The different definitions usually fall into one of two categories. Sometimes the term is used to identify a specific – code that is stored, verified and executed on a blockchain. Let’s call this type of definition “smart contract code”.

    Using the same term to refer to distinct concepts makes answering even simple questions impossible. For instance, one question I’m often asked is simply: what are the capabilities of a smart contract?

    , then the answer depends on the capabilities of the language used to express the contract and the technical features of the blockchain on which it operates.

    a binding legal agreement, the answer depends on far more than the technology. This answer depends on existing legal doctrine and how our legal, political and commercial institutions decide to treat the technology. If businesspeople don’t trust it, the legislature doesn’t recognize it and the courts can’t interpret it, then it won’t be a very practically useful “contract”.

     

     

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Close Bitnami banner
Bitnami