NIP Idea Contract, Covenant, or Agreement.

[xemuj]

NIP Proposal for Digital Contracts in Nostr

---

NIP-XX: Digital Contracts
Status: Draft
Type: Standard
Created: [Creation Date]
Author: [Your Name or Alias]

---

Abstract

This NIP proposes a new event type, kind:300XX, to represent digital contracts, covenants, and agreements within the Nostr protocol. These can be signed, verified, and referenced by other events in the protocol.

Motivation

As digital transactions, promises, and agreements become more prevalent, it's essential to have a standardized representation of contracts, covenants, and agreements in Nostr. This NIP aims to provide a structure and guidelines for creating, signing, and managing these within Nostr.

Specification

1. Types:

   • Contract: A legally binding agreement between two or more parties.
   • Covenant: A written promise or restriction within a contract or agreement.
   • Agreement: A mutual understanding between parties regarding their relative rights and responsibilities.

2. Format: Following NIP-23 (Long-form Content), the content should be in Markdown format to structure and present the content in a human-readable manner.

3. Metadata: Using NIP-78 (Application-specific data), specific application metadata fields can be added to the event, such as:

   • title: Title of the contract, covenant, or agreement.
   • parties: Parties involved.
   • signed_date: Date it was signed.
   • expiry_date: Expiration date, if applicable.
   • type: Whether it's a Contract, Covenant, or Agreement.

4. Timestamping with OpenTimestamps: Following NIP-03 (OpenTimestamps Attestations for Events), once signed, OpenTimestamps can be used to create a cryptographic proof of existence at a specific moment. This proof is stored on the Bitcoin blockchain, providing immutable evidence of the date and time of signing.

5. References and Linking: Can reference other events in Nostr, such as annexes, terms and conditions, or any other relevant document.

6. New kind: A new kind:300XX is introduced to represent digital contracts, covenants, and agreements. This kind is specific and should be treated differently from other event types in the protocol.

Example Event

{
  "kind": 300XX,
  "created_at": [Creation Timestamp],
  "content": "[Content in Markdown]",
  "tags": [
    ["title", "Service Contract"],
    ["parties", "User A, User B"],
    ["signed_date", "[Signing Date]"],
    ["expiry_date", "[Expiration Date]"],
    ["type", "Contract"],
    ...
  ],
  "pubkey": "[Signer's Public Key]",
  "id": "[Event ID]",
  "ots": "<base64-encoded OTS file data>"
}

Considerations

• Should be treated with a high level of security and privacy. Protect the private keys used for signing NIP24.
• Verifying the authenticity and integrity is crucial. Ensure the public key used to verify a signature genuinely belongs to the indicated signer.
• Recommended to consult with legal experts when using the Nostr protocol for these purposes.

[vitorpamplona]

Interesting. Don't we need a signing date per signature? You might also develop a regular event for the contract and then each party signs another event kind just with the date. In that way, the signature is cryptographically verifiable and not just a listed party in somebody else's event.

[brandenespinoza]

I think what you are proposing is right: One event for contracts, One event for the signing of contracts.

The nuance here is that there are several dates required.

1. The date the contract event is posted/created. This could include, but not be limited to, an OpenTimestamps hash.
2. An open date (optional) which strictly sets the earliest a party can validly sign. (OTS would not be useful here)
3. An expiration date (optional) which strictly sets the latest a party can validly sign. (OTS would not be useful here)

Regarding the "Parties". It gets squishy because various parties COULD have various signing windows for the contract.

So maybe something like this for the contract event:

{
  "kind": 300XX,
  "created_at": [Creation Timestamp],
  "content": "[Content in Markdown]",
  "tags": [
      ["title", "Service Contract"],
      ["type", "Contract"]
      ... add more tags as needed
      ],
  "parties": [
      {
      "name": "User A",
      "pubkey": "[Public Key of User A]",
      "open_date": "[Open Date for User A]",
      "expiry_date": "[Expiration Date for User A]"
      },
      {
      "name": "User B",
      "pubkey": "[Public Key of User B]",
      "open_date": "[Open Date for User B]",
      "expiry_date": "[Expiration Date for User B]"
      }
     ... add more parties as needed
  ]
  "id": "[Event ID]",
  "ots": "<base64-encoded OTS file data>"
}

Then for the signing event

{
  "kind": 300XY,
  "timestamp": "[Timestamp of the signing]",
  "contract_id": "[Reference to the original contract, e.g., Event ID from the previous JSON]",
  "signing_statment": "[Content in Markdown]",
  "ots": "<base64-encoded OTS file data for this signing event>"
}

Note: I know signing statements or addendums are sometimes used to clarify intent or state of mind at the time of signing, without impacting the content or terms of the contract itself. This might be a good place for that.

[brandenespinoza]

Also, perhaps an optional nested Witness signatures as well? Just a thought. Not sure how necessary they would be.

• Contract
  • Party A Signature
    • Witness A1 Signature
    • Witness A2 Signature
  • Party B Signature
    • Witness B1 Signature
    • Witness B2 Signature

[vitorpamplona]

Ok, how about this:

"Contract Signing Invitation" type:

{
  "kind": 900,
  "created_at": [Creation Timestamp],
  "content": "[Content in Markdown]",
  "tags": [
    ["title", "<Contract Title>"],
    ["summary", "<Short Description>"],  // Optional: Short Description for preview
    ["valid_from", "Timestamp"], // Optional: Start date of the contract 
    ["valid_to", "Timestamp"],   // Optional: End date of the contract 
    ["p", "<party's 1 pubkey>", "party"]
    ["p", "<party's 2 pubkey>", "party"]
    ["p", "<party's 3 pubkey>", "party"]
    ["expiration", "<Time stamp limit to sign>"],
  ],
  "pubkey": "[Signer's Public Key]",
  "id": "[Event ID]",
}

"Signature" (in legally-binding agreement) Type:

{
  "kind": 901,
  "tags": [
    [ "e", "<Contract's (kind:900) Event ID>" ]
  ],
  "pubkey": "[Party's Public Key]",
  "created_at": [Creation Timestamp],
  "content": "",
  "id": "[Event ID]",
}

"Signing Witness" Type:

{
  "kind": 902,
  "tags": [
    [ "e", "<Contract's (kind:900) Event ID>" ]
    [ "e", "<Signature (kind:901) Event ID>" ]
  ],
  "pubkey": "[Party's Public Key]",
  "created_at": [Creation Timestamp],
  "content": "",
  "id": "[Event ID]",
}

"Contract Execution" type:

{
  "kind": 903,
  "created_at": [Creation Timestamp],
  "content": "<Stringified JSON of the signed kind:900>",
  "tags": [
    ["title", "<Contract Title>"],
    ["summary", "<Short Description>"], // Optional: Short Description for preview
    ["valid_from", "Timestamp"], // Optional: Start date of the contract 
    ["valid_to", "Timestamp"],   // Optional: End date of the contract 
    ["e", "<Contract's (kind:900) Event ID>" ] // Base text. 
    ["p", "<party's 1 pubkey>", "party", "Stringified JSON of the signed kind:901"]
    ["p", "<party's 2 pubkey>", "party", "Stringified JSON of the signed kind:901"]
    ["p", "<party's 3 pubkey>", "party", "Stringified JSON of the signed kind:901"]
    ["p", "<party's 4 pubkey>", "witness", "Stringified JSON of the signed kind:902"]
    ["p", "<party's 5 pubkey>", "witness", "Stringified JSON of the signed kind:902"]
    ["p", "<party's 6 pubkey>", "witness", "Stringified JSON of the signed kind:902"]
  ],
  "pubkey": "[Signer's Public Key]",
  "id": "[Event ID]",
}

On the last one, all signatures MUST match the contract invitation event ID.

[brandenespinoza]

The structure you use for the "Contract Signing Invitation" type assumes all parties are subject to the same validation window. This may not be the case for every contract. Some contracts may give different parties different signing windows. Ex. If I am an offeror I may build into a contract a tight window for the offeree, but I do not hold myself accountable to the same window. I think I still recommend approaching it the way I suggested prior (minor edits to parallel your terms 'valid_xxxxx') :

 "parties": [
      {
      "name": "User A",
      "pubkey": "[Public Key of User A]",
      "valid_from": "[Open Date for User A]",
      "valid_to": "[Expiration Date for User A]"
      },
      {
      "name": "User B",
      "pubkey": "[Public Key of User B]",
      "valid_from": "[Open Date for User B]",
      "valid_to": "[Expiration Date for User B]"
      }
     ... add more parties as needed
  ]

Other thoughts:

• Power of Attorney: There are individuals that act as agents of a corporation or other legal entity or person. Probably has some impact on this
• Jointly and Severally/In the alternative: if a company grants signing authority to both Person A and Person B such that either one of them can sign on behalf of the company without the other's signature, the authorization might specify that they can sign "jointly and severally" or that they can sign "in the alternative." This would imply we need AND/OR and IF/ELSE function when identifying signors. It could get funky: Alice, Bob, and Charlie are executives at ACME, Inc. The contract states Alice is identified as a sole signer on behalf of ACME if she signs within x window. However, Bob and Charlie can sign on behalf of ACME if they sign within y window.
• Nullifying signer (this isn't common) - there could be contracts that identify individuals that if they sign, it nullifies either the contract or removes/blocks the authority of the other identified signers in the contract.

I'm not saying we need to explicitly enable these edge cases, but rather we need to make sure the approach is general enough to account for them. I'm not sure the current proposal enables it.

[vitorpamplona]

Interesting! Thank you for the review.

The time windows is an issue that I don't know if Nostr can solve. Anyone can sign messages in the past (or in the future) so, coding the window is not actually doing much, if anything. I assume the window is also described in the text itself. Which is what the justice system will look at to enforce these windows.

Power of Attorney

We can do a variation for this and use the .content of the signature to describe the details of the case/person.

{
  "kind": 902,
  "tags": [
    [ "e", "<Contract's (kind:900) Event ID>" ]
    [ "on_behalf_of", "<Name/Title for the Contract>" ] // optional for Power Of Attorney
  ],
  "pubkey": "[Party's Public Key]",
  "created_at": [Creation Timestamp],
  "content": "<Name/Title for the Contract>",
  "id": "[Event ID]",
}

Jointly and Severally/In the alternative

There is no code to determine when the contract was executed. In a 2 of 3 signature contract, the author of the contract can just select the two that signed first and write the kind:903 to execute it. It's up to the author to determine when to call that. The author can, of course, delete the contract and do a new one if there an error is made and they need another signature.

Nullifying signer (this isn't common)

This feels like semantics we don't need to code. I assume this would be written in the text of the contract. What Nostr needs to do is to offer a way for people to sign. The type of signature is less relevant because it is dependent on the semantics of the text in the contract.

[xemuj]

Excellent! Which NIP number should I utilize?

[xemuj]

I will use 79 as the atomic number of gold

[xemuj]

https://github.com/xemuj/nips/blob/DigitalContracts/79.md

[brandenespinoza]

Should we continue commenting here, or work directly within the nip GIT PR process now?

[xemuj]

I really don't know it's my first time contributing in GitHub 😅😬

[benichu]

@xemuj I am watching you go along the process...
Amazed and inspired 🤩

[xemuj]

What if a party wishes to sign but doesn't agree with the terms of the contract?

[xemuj]

I'm thinking of something like how a bill works in Congress, where the majority has to be either for or against it.

[vitorpamplona]

We should not use gov votes as contracts. I would just create a different voting scheme for congress/boards/etc.

[xemuj]

I was thinking something useful in corporations too where a shareholder of a company can vote

[xemuj]

Could NIP-24 be utilized for secret voting? Let's discuss this here: #758