Clickwrap contracts are functionally the same as the shrink wrap method in software licenses and other product offerings, but formed in the digital world. A clickwrap contract allows the purchaser to read the terms of the agreement before accepting the product.
Clickwrap or “clickthrough” contracts are the most commonly formed web-based contracts . Such contracts may start with a web-based advertisement (an invitation to treat) or some other collateral offer for consideration. Such web-based orders are generally included when the customer “clicks” an acceptance button (such as one labelled accept, submit, proceed to check out, or some other similar phrase). Clickwrap Internet contracts  have their own issues, but they still mirror many of the technologies that have preceded them.
As the response to the offer or acceptance immediately displays on the customer’s web browser, web-based communications fulfil the requirements of an instantaneous transaction. There are some possible avenues of dispute with such an analogy. For instance, what happens when a customer accepts to finalise the transaction, but their Internet link drops before they receive the reply? To answer the question, we need to look at the case of Entores Ltd v Miles Far East Corporation .
Lord Denning at 333  explains the position of the law with regards to contracts conducted via telex: “It is not until his message is received that the contract is complete…”
From Lord Denning’s analogy, we may see that a “contract is only complete when the acceptance is received by the offeror: and the contract is made at the place where the acceptance is received.”  Thus, the contracting parties are under an equitable obligation to notify each other of any failure. In cases where communications have failed and one of the parties is left believing that the contract was successfully negotiated, the other party would be stopped from denying the contract if it had not taken reasonable steps to notify the other party of the failure.
In cases where both of the contracting parties normally reside and contract within the European Union, additional statutory requirements apply. The electronic commerce regulations  as introduced by Parliament in the UK in 2002 override the postal rule in some instances, and may require a separate acknowledgement through means such as e-mail for web-based transactions. Paragraph 11, for instance, explains: “The order and the acknowledgement of receipt will be deemed to be received when the parties to whom they are addressed are able to access them.”
Although the directive does not change in the position of contracts negotiated solely by e-mail , it does set the boundaries required for web-based transactions.
As an immutable evidence system, Bitcoin solves many of such problems. In web-based and email-based communications, methods always exist to allow individuals to bypass controls and even to argue that they have not agreed to all terms. Using Bitcoin, we can remove such a level of uncertainty in contracting.
Clickwrap and Metanet
And, we can extend the idea to allow for contractual negotiations within Bitcoin and by extension the Metanet. Clickwrap followed from the use of shrink wrap contracts in physical software and media purchases (such as CDs and DVDs). The inclusion of a notice that says, “by opening the packaging you have agreed to the terms,” results in the purchaser being legally bound to the terms of the license or contract.
Using the recent Court of Appeal decision in Golden Ocean Group v. Salgaocar Mining Industries  confirming that the courts would treat a series of ongoing electronic communications both to be writing and as signed documentation per the Statute of Frauds (1677) with cases such as WS Tankship II BV v The Kwangju Bank Ltd , where the parties accepted that the word “signed” in the Statue of Frauds (in the judge’s words) “does not necessarily involve signature by an individual using pen and ink and that it suffices that the guarantor’s name is written or printed in the document,” leads to the reasonable argument that a transaction made on a distributed ledger (such as Bitcoin) is made in writing.
In the US case of Williams v America Online Inc , some of the difficulties that may occur with online contracting were demonstrated. In the given case, Mr Williams started proceedings in Massachusetts stemming from a class action over the installation of AOL software. AOL asserted that the proceedings must commence in Virginia as the terms say Virginia was the exclusive jurisdiction of any claim. Mr Williams, though, argued that alterations to his computer came about before he agreed to the conditions. Mr Williams described the complicated process by which he had to “agree” to the conditions after the configuration of his computer had already occurred.
Then, Mr Williams demonstrated he was able to click “I agree” without seeing the terms of service — which meant that the actual language of AOL’s terms of service failed to display on the computer screen unless the customer specifically requested it, overriding the default settings. The court rejected AOL’s assertions . Although it was a contract case, the difficulties posed through the media add additional burdens to an already burdened system. So in this case, the license associated with the disseminated content was subverted by the ineffectiveness of the means distributing it.
A smart-contract solution
We can solve problems such as the one in Williams v America Online Inc using smart-contract features in Bitcoin. It is not necessary to definitively prove that a party has comprehended a set of terms but rather that parties have downloaded it and agreed to be bound. One such means of doing so would be to require the contracting party to provide the hash of the terms and conditions, which can be implemented as a standard Bitcoin hash puzzle.
Before Alice is given the unlock code for media or a program that she has purchased, a smart contract can be configured that requires that she gives the solution to a hash puzzle based on the terms.
The unlock script can require that Alice provides the following information:
Hash(“Terms and Conditions” || “I agree”)
In doing so, Alice now has to download the terms and conditions and construct the solution to a hash puzzle based upon the downloaded data. The application can be configured to display it upon the user screen allowing her to type “I agree” into a custom wallet that can then provably show that Alice downloaded the terms and conditions. More importantly, it demonstrates that she has viewed the terms.
The same can be extended by incorporating the hash of the terms into personally identifiable information that remains pseudonymous. It could even be as simple as just using the hash of Alice’s key:
Hash(“Terms and Conditions” || “I agree” || <Bitcoin Address>)
Where Bob and Alice are negotiating for a file or other media source, the hash puzzle can be incorporated into the payment exchange. In doing so, Alice can agree to be bound by clicking or typing “I agree” into a custom application that incorporates the address she is using to be bound under the contract. Such a wallet or custom application would enable the exchange of the terms and conditions and the addresses, and could be set up using a derived key linked to a certified key and known by the parties (see “Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys”)
A business opportunity…
Integrating either native bitcoin or tokenised fiat for payment against tokenised goods, a developer would be able to provably exchange contract terms and conditions over the Bitcoin (BSV) network. In saving the encrypted terms and conditions directly within the OP_Return field attached to a Bitcoin transaction, the parties to the transaction would now have irrefutable proof of the exchange. The final terms and conditions could be encrypted using a shared common secret as described in the process above, and an application that calculates a validation-level hash puzzle would allow for the creation of evidence proving the acceptance of the terms.
 Dunn (2001); Durtschi et al (2002)
 Reed, 2004
 Entores Ltd v Miles Far East Corporation  2 QB 327 (Court of Appeal, United Kingdom)
 Entores Ltd v Miles Far East Corporation; Lord Denning at 333 “Suppose a clerk in a London office taps out on the teleprinter an offer which is immediately recorded on a teleprinter in a Manchester office, and a clerk at that end taps out an acceptance. If the line goes dead in the middle of a sentence acceptance, the teleprinter motor will stop. There is obviously no contract. The clerk at Manchester must get through again and send his complete sentence. But it may happen that the wine is not go dead, yet the message does not get through to London. Thus, the clerk at Manchester may tap out his message of acceptance and it will not be recorded in London because the ink at the London end fails, or something of that kind. In that case, the Manchester clerk will not know of the failure but the London clerk will know of it and will immediately send back a message ‘not receiving’. Then, when the fault is rectified, the Manchester clerk will repeat his message. Only then is there a contract. If he does not repeat it, there is no contract. It is not until his message is received that the contract is complete…”
 Statutory Instrument 2002 №2013; ELECTRONIC COMMUNICATIONS, The Electronic Commerce (EC Directive) Regulations 2002
 Ibid, Para 9 (4) “The requirements of paragraphs (1) and (2) above shall not apply to contracts concluded exclusively by exchange of electronic mail or by equivalent individual communications.”
 MARK WILLIAMS and another (1) vs. AMERICA ONLINE, INC. 2001 WL 135825 (Mass. Super., February 8, 2001)
 “The fact the plaintiff may have agreed to an earlier terms of service for the fact that every AOL member enters into a form of terms of service agreement does not persuade me that plaintiff’s … have notice of the forum selection cause in the new terms of service before reconfiguration of their computers.”