"Contract" terminology - a dissenting opinion

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.


I believe it is proposed to replace basically all regular transaction terminology.

I.e. Instead of “grin-wallet send x” it would be “grin-wallet contract new send x” or something.

  1. Confusion with Smart Contracts. It was previously taken for granted by us and I think still is by most users that a Contract in crypto refers to a Smart Contract.
1 Like

If I put my blinders on and simply search for applicable words then I agree with you on Draft. It is linguistically more applicable. But if I step back I think that would still be getting too esoteric.

The simplest way to incorporate “sign” would be:


I would say the transaction of buying a donut is a buying-contract too. Even if nothing is written or spoken, the action of the participants can imply their intention and expectance. So a contract is a construct of Geisteswissenschaften (sciences of mind). The form it is physical represented and the complexity can vary. Also the donut buying example could become complex, if the expectations of the transaction-flow differ or the transaction-flow becomes interrupted.

I would agree, that the word contract implies the participants understand what it is about. A physical representation of the contract needs to include obligations if obligations exist. If a good enough representation of the result is possible, this can substitute the cryptographic understanding. But it is important that it is really good enough for all cases.

What is the picture with the bikes is about?

Are there examples how a payment-proof could look like?

Here’s a prototype

The main goal of it is to unify two flows (payment and invoice) into a single one and generalizing transaction building to more than 2 parties. There’s a couple of other things that I mention in the post.
The word contract is not set in stone, it’s something I found descriptive enough and went with it to proceed with the prototype implementation. I think the way this is going to play out is that the community is going to try a few different ways of building transactions and we’ll eventually agree on what we believe makes the most sense.

Yes a implied contract exists for the donut, but it doesn’t exist in the money. The money is just a component of the contract. I prefer a more strictly cash like system where the cash is just cash. Cash is also interactive but it is not a contract.

The bike shed is a tongue in cheek reference, Ignotus warned against bikeshedding and this post borders on that.

1 Like

Not sure this accounts for the reverse flow though… RSR, unless the originator would say “receive” alternately, but that would introduce two words for the same action.

It Also does not lend itself to the “sign, sign” as applicably as “draft.” Maybe we want to utilize grin’s uniqueness in this regard, showcasing its potential use cases.

The first step can also be receive, so send is not a good choice imo. One could argue that send means “send an offer” or smth similar but that would imo be too confusing for people since if you don’t know how it works you assume you’re sending the money in the first step. Draft always feels like something that’s unfinished, so signing a draft sounds confusing to me.

Cash is a currency like grin. Exchange of cash is a contract, it’s just that many times it’s not written but verbal instead. Even if i give you cash for free that’s a contract where you don’t need to do anything.

1 Like

The reason I like draft is specifically because it is the first step of an unfinished document. Lol it informs that there are next steps required such as the sign, sign.

If a generic term for both send and receive is desired then I would advocate for transaction.

Only by some philosophical or labored legal theory is buying a donut with cash a contract. By all common parlance it is called a transaction.

1 Like

Does transaction usually also describe items/service that you’re paying for?

Yes I think so, when I check my bank balance I see a list of “recent transactions” and it shows payer, payee, memo, etc.

Many of these payments are made according to a contract, but the payment itself is called a transaction everywhere I look. At the end of the day a cashier balances their cash drawer based on the list of transactions. If I were to refer to a payment as a contract anywhere in my daily life I would only be met with confusion.

Or see this Wikipedia article for Receipt painted with references to transaction, and not a contract in sight.


Thanks for sharing and thanks for the effort you put into this idea!

In general I share @Trinitron 's objection to the terminology for all the reasons he gave, but I see value in unifying the workflows. It’s nice to see the community alive with innovation :slight_smile:

1 Like

This is the same conclusion I was coming to. Any party may “propose”/“draft” a new transaction, and then all parties must sign the transaction.

Importantly, the outcome of this multiparty process is a transaction which the network will accept, so I think its logical and most intuitive for it to be called as such.

So… That’s my preferred color for the bike shed :sweat_smile:

I’m not sure if it’s intuitive that both parties need to sign a transaction. Besides i think grin transactions (when memo will be added) are more descriptive than regular transactions since, at least in my mind, memo could contain list of items you’re paying for etc which makes it look more like a contract to me. However if memo is just an identifier then it seems more like a reference in a regular bank transaction. I’m fine with transaction and with contract words. In fact there was a time when i though “transaction contract” was a good idea but it felt too long

If I were introducing someone to grin I would have to explain it either way, there’s no way they would just get it automatically. That could be:

  1. “In grin a transaction has to be signed by the sender and receiver”


  1. “In grin a transaction is called a contract, and it has to be signed by the sender and receiver”

Contract only adds to what must be explained in my opinion.

“Transaction contract” makes more sense than just contract to me, but it feels redundant.


I think there will always be this confusion for new users. We can combine the workflows, so the user doesn’t need to use different commands for the same “effect” (receiving coins or sending coins), but no amount of terminology will make it intuitive to users why both parties need to sign a transaction.

Functionally, a user will want to send coins or receive coins. No matter what we call it, they will need to learn that is an interactive process.

I agree, but when he asks you “why is it named a contract and not transaction” you can say “because you commit also to the content, not only to amount like in other coins” which sounds reasonable to me

But why bother regular users with the internal working principle of Grin? I can use Cash without knowing how this money gets printed, issued, or flows back to the bank and how the bank store it. Why bother the regular user to know all details? As a user of Grin, I don’t care about all the details. I want to use it as Digital Cash, to buy goods, pay rent, etc.