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.

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:

Hdoc=SHA256(LegalDocument.pdf)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... 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

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=ecrecover(Keccak256(DomainStructHash),v,r,s)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.

Last updated