Tag: Smart Contract rules (Page 1 of 2)

Smart contracts are programs which have utility. In and of themselves, they are value-free and inherently neutral. From this perspective, the Shariah value assigned is of permissibility. The Islamic legal maxim states:

“Permissibility is the state of all things by default.” [al-ashbah Wal-Naza’ir]

A number of US states are passing specific blockchain and smart contract enabling legislation, including a law making blockchain records admissible in Vermont, and in Arizona in April 2018 which made clear that “writing” included blockchain records and both Arizona and Tennessee have passed laws which defined smart contracts as:

The moment where I saw this was when someone asked me about smart contracts and said,

“smart contracts are not really contracts, because there’s no way to enforce them. When a contract says ‘make all reasonable effort,’ how does a smart contract account for that.”

Developers can write the smart contract lines of code using the native language of a blockchain system. In Ethereum, developers use the Solidity native language. The contract codes can be used in various kinds of applications such as transferring money when certain sets of conditions have been met.

Even though, with such autonomous power, the possibilities are limitless, it’s mainly on how we choose to utilise them that defines the major use-cases of Smart Contracts.

Some of such use-cases of smart contracts are listed below:

Although the initial use of blockchain was for cryptocurrency such as Bitcoin, blockchain offers much more than just a record of transactions. In addition to trading cryptocurrencies, some implementations of blockchains offer the idea of smart contracts. In particular, the Ethereum is one such example. Like Bitcoin, Ethereum offers a cryptocurrency known as Ether, but it also turned all the nodes in the network into “Turing complete” computers. What this means is that you can write programs (known as smart contracts) and execute them on all the nodes on the network.

Ethereum implements an execution environment on the blockchain called the Ethereum Virtual Machine (EVM). Every node participating in the network runs the EVM as part of the block verification protocol. They go through the transactions listed in the block they’re verifying and run the code as triggered by the transaction within the EVM. Each and every full node in the network does the same calculations and stores the same values.

To understand how a smart contract is useful, let’s imagine the following scenario. You’re a musician and you want to protect your intellectual property, in this case, your music creations. You want to make sure that the lyrics of your songs are protected and that no one else can plagiarize them (especially before they are released). Because data stored on the blockchain is immutable and time-stamped, it’s a good platform to store the lyrics of your songs as the proof that you’re the original creator of the song. However, blockchain data are inherently public, so storing the lyrics of your creation on the blockchain isn’t practical. A good workaround for this case is to store the hash of the song’s lyrics. That way, you maintain confidentiality of your creation, and at the same time you can prove that the lyrics are written by you if you are able to provide the original lyrics to generate the original hash.

More detail: https://www.codemag.com/Article/1805061/Understanding-Blockchain-A-Beginners-Guide-to-Ethereum-Smart-Contract-Programming

In practical terms, smart contracts differ from conventional contracts in the following ways:

• The entire lifecycle of a smart contract, from formulation to execution, occurs online
• That lifecycle need not at any point involve any entity other than the contracting parties (since, for instance, payment can occur directly from bitcoin wallet to bitcoin wallet)

The concept of smart contracts is primarily based on the idea of blockchain technology. A blockchain is a decentralized network of a growing list of records (blocks) that are linked through cryptography. A blockchain network does not include a single central point like a conventional database.

The application of smart contract can greatly reduce transaction costs and improve transaction efficiency. The existing smart contract are expensive, single application scenario and inefficient. This paper aims to propose a new smart contract model to solve these problems.

We are at the nascent stages of smart contract adoption, best practices for implementing such code is still evolving. However, the checklist below should help developers design effective smart contracts and guide companies who plan to use them.

• For now, parties entering into any type of contractual arrangement would be best served using a hybrid approach that combines text and code. As noted, there are strong arguments that code-only smart contracts should be enforceable, at least under state contract law in the U.S. However, until there is greater clarity on their validity and enforceability, code-only smart contracts should be used only for simpler transactions. Parties will continue to want text-versions of agreements so they can read the agreed-upon terms, memorialize terms that smart contracts are not equipped to address and have a document they know a court will enforce.
• In a hybrid contract using text and code, the text should clearly specify the smart contract code with which it is associated, and the parties should have full visibility into the variables that are being passed to the smart contract, how they are defined and the transaction events that will trigger execution of the code.
• When relying on oracles for off-chain data, the parties should address what would happen if the oracle is unable to push out the necessary data, provides erroneous data or simply goes out of business.
• The parties should consider risk allocation in the event of a coding error.
• The text agreement accompanying the code should specify the governing law and venue, as well as the order of precedence between text and code in the event of a conflict.
• The text agreement should include a representation by each party that they have reviewed the smart contract code, and that it reflects the terms found in the text agreement. Although such a representation cannot force a party to examine the code, it will help the counterparty defend against a claim that the code was never reviewed. Parties may also choose to insure against the risk that the code contains errors. As noted, parties may need to involve third-party experts to review the code.

More detail: https://corpgov.law.harvard.edu/2018/05/26/an-introduction-to-smart-contracts-and-their-potential-and-inherent-limitations/