The role of the Ricardian Contract is to capture the contractual relationship between contracting parties to assist later performance of that contract by programs. In its contractual form, it is the recording of an offer from an issuer to a holder. The offer is signed digitally within the format by the offerer, typically using a plaintext digital signature such as provided by OpenPGP. The acceptance of the contract is typically formed by signing / agreeing to a transaction that refers to the hash of that contract. Within the context of a high performance payment system, a secure payment will cite the hash of the contract of the instrument being paid, as well as paying and payee parties and a quantity of units. In a smart contracts system, the acceptance would be performed by operating the contract's code to move the state of the agreement forward. Typically, the signing of the contract by any party is overtly performed by use of a private key. The original offerer's signature is typically over the original document, and is then appended to form a fully binding, readable offer for the assets described in the document. Later participation by parties in the contract such as payments or smart contract performance will typically sign over a hash identifier (as generated by a cryptographic hash function) over the signed original document. In contrast to the initial signature, the use of the hash of the contract within following transactions also signals intent, and forms a covert signature over the contract. Although private key signatures are well studied and are subject of legal frameworks such as the European digital signature directive, Grigg suggests that the trail of hashes - entanglement - forms a more effective evidence of intent  than a private key signature. As a pattern in design, the Ricardian Contract is like a reference - object tuple from the tradition of Object-oriented Programming. The reference is a cryptographic hash function, and the object is formed by writing classes that handle the type of contract needed; a Factory (object-oriented programming) would typically read enough of the text of the document to figure out which class type is involved, and then construct an object of that specific class over the text. Once an object is constructed, it can be interrogated for contents: the hash, name of issuer, nature of issue, keys and signature status. If the agreement is more complicated than a single document can describe, the documents can be chained: An acceptance of an offer can be a Ricardian Contract that includes the hash of the offer, or the acceptance can include the entire contents of the earlier phase, a design pattern known as Russian dolls  used by both OpenTransactions and OpenBazaar.