"Contract" terminology - a dissenting opinion

I am writing this post to disagree with the proposed use of the term “contract” for transactions or anything else in Grin.

I don’t think it is so important that it will affect the success of grin, and I am confident that even if this “contract” terminology is adopted and then Grin does become popular it will eventually be ripped out in any case because of how inapplicable it is.

The OED definition of contract is:

a written or spoken agreement, especially one concerning employment, sales, or tenancy, that is intended to be enforceable by law.

The Wikipedia article for contract begins with:

A contract is a legally enforceable agreement that creates, defines, and governs mutual rights and obligations among its parties. A contract typically involves the transfer of goods, services, money, or a promise to transfer any of those at a future date.

My disagreement with contract being an applicable term is a gut reaction first, the term simply isn’t applicable to Grin’s functionality. I have to pick apart my gut reaction to try to turn it into a logical argument.

  1. Mutuality. A contract is basically always used to define a two way agreement. Goods for money, money for services, money for money. On at least one side of a contract is always an obligation, it is an agreement to fulfill something. Grin specifically only contains transactions of money, it does not contain goods, services, or any obligation beyond the transaction of money. No one ever signs a contract in real life that simply says “I will pay you X” without defining an obligation in return.

  2. Nonexistent complexity. Say that I am buying a donut and I would like to pay in Grin. There is no practical basis, especially to a layman, to imply that a contract is involved in any way. It is a direct exchange of payment for donut without any outstanding obligations created. Even if you were to complicate it by paying for the donut with a check (or cheque) that involved two party signatures, nobody would ever bring the word “contract” into this exchange. It is called a transaction.

  1. The idea that calling it a “contract” makes it any clearer to a new or nontechnical user does not make sense to me. Chances are you are unfamiliar with the details of US paper check payments, if I were to say to you “think of it as a contract” that would do almost nothing to explain to you how to actually use one. You would still need to do some basic research about how to use the specific payment method and you would need to understand that a signed check remains valid and held by the receiver until deposited. It’s not a hard concept to grasp. Calling it a contract wouldn’t help.

I’m glad to see a serious discussion against it. The reason we picked contract was because you sign it. There are things that bother me as well with the word. What word would you use to describe this? I’m thinking what could fit the model below that would go together with the following usage:

<word> new
<word> setup
<word> sign

Any suggestions?

And Grin payments are no different. They will nearly always be payments for something (donations excepted). Which is exactly what payment proofs are for. They state the purpose of payment so that the payer has some recourse when the payment recipient fails to hold up their end of the bargain. Which, by signing the contract, the receiver has committed to.

Most people would agree that increased use of payment proofs is a good thing for Grin. And if use of the term contract helps incentivize that, then I’m all for it.

Perhaps this unsatisfying to many, but I suggest no change. tx or transaction. Users can do the bare minimum to learn what they are doing. The transaction will show as pending in their wallet. Easy to use safe cancel functionality is key.

But the obligation is outside the scope of Grin, Grin cannot enforce the other end nor does it encompass any specific legal agreement.

There is a implied contract in that the donut seller will hand me the donut, but that contract is not contained in the payment. Whether I hand them cash, or a check without stated purpose, or a check with “donut” written in the memo, the payment itself is not the contract, the conceptual contract exists outside of the payment in common law.


No; but the use of payment proofs with clear statements of payment purpose provide the best possible tool for settling disputes outside of the blockchain. And those can still be said to be contract disputes.

I prefer a strictly cash like system with payment proofs only serving the purpose of proving a payment, but I see what you are saying.

One of the problems we face is that people do not understand the process of creating transactions. Users are not aware of why they have to interact with others to make transactions. Interactivity is something that seems to be kind of hidden behind Tor, now I’ve realized that instead of making things simpler it’s bringing more confusion.

I think using better wording helps and also introducing some changes to the UI.

1 Like

I think that when users are faced with it like on Tradeogre then interactivity naturally presents itself. They are prompted with a slatepack or to provide one and then the next action is up to them.

The fact that Gate confuses users with Tor/Memo deposits is a Gate problem, let Gate support deal with the consequences of that.

If I was trying to explain any of this to my mom the word Contract would only add confusion. “Now you sign for the transaction and send it back to them” is simple, easy to explain, and does not come with the weird implication of obligation that contract does.


And users are not understanding that is happening with they copy and paste the slatepack messages.

I think you should read the RFC-0015.

What do you want me to read in that RFC? People are free to use or misuse Grin however they want and so is Gate.

Gate and TO are both partially following the RFC.

When users are “just copying & pasting” the Slatepack messages they are not fully aware of what they’re doing. When users use Tor they are less aware of what is happening.

Do we want users to understand what is actually happening?

Users/merchants/exchanges don’t have to follow an RFC. If it’s not enforced by the pow/cryptography then they can do what they want.

I don’t think calling it a Contract will lead to any greater understanding, it will just be another term they don’t understand and either don’t care to, or will do the research to understand. The outcome is the same.

In a replay or play attack or whatever they’re called, I don’t think it changes things either. If a user is gullible to resend a transaction then they are just as likely to believe that a “contract didn’t go through” and sign another one.


Yes, they have to follow the RFCs, all of them.

Who’s going to make them, the Grin police?


No, your mom could be.

My mom certainly doesn’t care what an RFC says.

We probably agree that sign/sign leads to better understanding of safe-cancel usage. I always thought that if we name it contract then together with payment proof that should be enough to prove payment in the court. Is this how things work? I don’t know, but i surely hope such proofs can be used in court since it’s a mathematical proof. If it can be used then i would say that contracts are binding to the amount, add memo and i don’t see any difference between a written contract and grin contract (I’m probably missing something, but you probably understand now how i look at this)

I understand people’s hesitation with the term “contract” for standard transaction process since it has certain legal denotations. I also like that it connotes finality, security, And of course would be instructive for the “sign, sign” steps.

In this vein, something less formal but with the same instruction?



I think draft has a home in financial instruments w/ drafting checks, bank drafts etc

1 Like

Sorry for the dumb question, but who is proposing calling WHAT a contract? Is there a new contracting feature being proposed? Or renaming existing functionality?

Sorry, I’m not on Keybase or Telegram, so I think I missed the impetus for this post.