⚠️ This EIP is not recommended for general use or implementation as it is likely to change.

EIP-5289: Ethereum Notary Interface Source

Allows Smart Contracts to be Legally Binding Off-Chain

AuthorPandapip1
Discussions-Tohttps://ethereum-magicians.org/t/pr-5289-discussion-notary-interface/9980
StatusDraft
TypeStandards Track
CategoryERC
Created2022-07-16
Requires 165

Abstract

Currently, the real-world applications of smart contracts are limited by the fact that they aren’t legally binding. This EIP proposes a standard that allows smart contracts to be legally binding by providing IPFS links to legal documents and ensuring that the users of the smart contract have privity with the relevant legal documents.

Motivation

NFTs have oftentimes been branded as a way to hold and prove copyright of a specific work. However, this, in practice, has almost never been the case. Most of the time, NFTs have no legally-binding meaning, and in the rare cases that do, the NFT simply provides a limited license for the initial holder to use the work (but cannot provide any license for any future holders).

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

See IERC5289Library.

Requesting a Signature

To request that certain documents be signed, revert with the following reason:

string.concat("5289:", libraryAddress1, "-", documentId1OfAddress1, "-", documentId2OfAddress1 ",", libraryAddress2, "-", documentId1OfAddress2, ...)

NOTE: If an address begins with one or more zeros, they may be omitted. Addresses are represented in base 64. NOTE 2: The document IDs are represented in base 64.

Example:

"5289:1-1-2,hElLO/0-7b+A"

Base 64

From RFC 4648:

                  Table 1: The Base 64 Alphabet

 Value Encoding  Value Encoding  Value Encoding  Value Encoding
     0 A            17 R            34 i            51 z
     1 B            18 S            35 j            52 0
     2 C            19 T            36 k            53 1
     3 D            20 U            37 l            54 2
     4 E            21 V            38 m            55 3
     5 F            22 W            39 n            56 4
     6 G            23 X            40 o            57 5
     7 H            24 Y            41 p            58 6
     8 I            25 Z            42 q            59 7
     9 J            26 a            43 r            60 8
    10 K            27 b            44 s            61 9
    11 L            28 c            45 t            62 +
    12 M            29 d            46 u            63 /
    13 N            30 e            47 v
    14 O            31 f            48 w         (pad) =
    15 P            32 g            49 x
    16 Q            33 h            50 y

NOTE: Padding is NOT used.

Here is a TypeScript snippet to convert Number objects into base 64 strings and back.

const digits = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+/";

function toB64(x: Number): string {
    return x
      .toString(2)
      .split(/(?=(?:.{6})+(?!.))/g)
      .map(bin => parseInt(bin, 2))
      .map(digit => digits[digit])
      .join("");
}

function fromB64(x: string): Number {
    return Number.parseInt(
      x.split("").reduce((bin, digit) => bin + new Number(digits.indexOf(digit)).toString(2).padStart(6, '0'), ""),
      2
    );
}

Signing a Document

When a signature is requested, wallets MUST call legalDocument and fetch the file off of IPFS, and render that file to the user. If the user agrees, the wallet MUST call signDocument. Using a form of account abstraction is RECOMMENDED.

Rationale

  • uint64 was chosen for the timestamp return type as 64-bit time registers are standard.
  • uint16 was chosen for the document ID as 65536 documents are likely sufficient for any use case, and the contract can always be re-deployed.
  • signDocument used to take a signature, but due to account abstraction being imminent, this was deemed unnecessary.
  • IPFS is mandatory because the authenticity of the signed document can be proven.

Backwards Compatibility

No backwards compatibility issues found.

Reference Implementation

See ERC5289Library.

Security Considerations

No security considerations found.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Pandapip1, "EIP-5289: Ethereum Notary Interface [DRAFT]," Ethereum Improvement Proposals, no. 5289, July 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5289.