# 7.1 Ricardian Contracts

Definition: A Ricardian contract is a way of recording agreements in digital document form, possessing a dual nature:

Human-Readable: It is standard legal prose, understandable to lawyers and judges.

Machine-Readable: It contains a unique cryptographic identifier that smart contracts can recognize and execute.

OmniPact leverages this mechanism to ensure that every on-chain transaction is not merely a transfer of tokens, but also the digital execution of a legal contract.

#### 7.1.1 Hash-Linking Legal Prose to Smart Contract Code 

To prevent discrepancies between the "signed version" and the "executed version," we employ Cryptographic Hash Linking technology to achieve an atomic binding between legal text and the smart contract at a mathematical level.

1\. Architecture Flow

* Step 1: Templating

  The legal agreement was written as a Markdown or PDF template containing variables.

  * *Example*: "I, \[Seller\_Name], agree to sell \[Asset\_ID] to \[Buyer\_Name] for \[Amount]..."
* Step 2: Instantiation & Hashing

  When a user fills out an order on the DApp frontend, a template is populated to generate a unique legal document instance (PDF). The frontend calculates the SHA-256 hash value of this document:

$$
H\_{doc} = \text{SHA256}(\text{LegalDocument.pdf})
$$

* Step 3:On-Chain Anchoring

  $H\_{doc}$ It is passed as an immutable parameter to the `createEscrow()` function and permanently stored in the smart contract's state variables: Solidity

  ```
  bytes32 public constant AGREEMENT_HASH = 0x...; // Stores H_doc
  string public constant AGREEMENT_URI = "ipfs://Qm..."; // Points to the file
  ```

2\. Integrity Proof

Non-repudiation：

* If either party attempts to modify the contract terms afterward (even by changing just a punctuation mark), the document's hash value... $$ $H'\_{doc}$ $$ An avalanche effect will occur, along with on-chain storage. `AGREEMENT_HASH` Mismatch.
* Judicial validity: In a real court setting, the chain of evidence provided by OmniPact (on-chain transaction hash + original PDF) can prove that a specific version of the contract was signed by both parties at a specific time, and has extremely high electronic evidentiary value.

#### 7.1.2 Digital Signature Verification Standards (EIP-712) 

Simply anchoring the hash is insufficient; users must sign the hash to obtain "informed consent." Traditional blockchain signatures ( `0x8f2a...`)This is legally flawed because users can argue that "I don't know what I signed."

OmniPact fully implements the EIP-712 (Typed Structured Data Hashing and Signing) standard, bridging this "semantic gap".

1\. Structured Data Definition

We defined a clear data structure in the contract, rather than Ethereum's native binary stream.

Solidity

```
// EIP-712 Domain Separator prevents replay attacks across chains
struct EIP712Domain {
    string name;
    string version;
    uint256 chainId;
    address verifyingContract;
}

// The Business Logic Struct
struct CommercialAgreement {
    address buyer;
    address seller;
    uint256 price;
    string deliveryTerms;
    bytes32 legalDocHash; // Links to the Ricardian Prose
}
```

2\. Wallet Presentation

When a user clicks "Sign," MetaMask or the hardware wallet will display a fully readable card, instead of gibberish.

> Signing Request
>
> * Buyer: 0x123...
> * Seller: 0x456...
> * Price: 1000 USDT
> * Terms: "CIF Incoterms 2020"
> * LegalDocHash: 0xabc123... (Verified)

3\. On-Chain Verification

The OES contract uses \_hashTypedDataV4 to recover the signer's address, ensuring that the signature is indeed for the current context.

$$
Signer = \text{ecrecover}(\text{Keccak256}(\text{Domain} \parallel \text{StructHash}), v, r, s)
$$

Technical Significance: EIP-712 not only enhances the user experience, but more importantly, it fulfills the legal requirement of "informed consent." By including the legalDocHash in the structured signature, the user's acceptance of off-chain legal terms is cryptographically locked in the on-chain signature, achieving isomorphism between on-chain behavior and off-chain intent.

***

> OmniPact is more than just a geek toy; it's a robust legal technology infrastructure capable of handling complex business contracts.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.omnipact.io/developers/omnipact-technology-white-paper/readme/rwa-and-legal-engineering/7.1-ricardian-contracts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.