Transaction Round Naming Challenge

The current wallet uses these round names

send
receive
finalize

for regular (sender-signs-last) flow, and

invoice
pay
finalize

for invoice (receiver-signs-last) flow.
These names are somewhat arbitrary, and finalize has been criticized for not being an obvious necessity.

For invoice flow, the following names are more descriptive:

request-payment
offer-payment
accept-payment

Is is possible to replace “payment” by another word that would be appropriate for regular flow?

I thought “invoice” might work, but hesitate to use that word in the non-invoice flow:-(

How about expense?

Btw, I hope that invoice flow becomes the standard, and reserve regular flow for cases where a high-volume transactor, such as an exchange, insists on being last-to-sign to minimize output locking.

3 Likes

This is a great point. Nice catch. I like your suggestions for alternatives, they do make more sense.

How about the word ‘grin’ instead of payment?

1 Like

And grinloss (or loss for short) for regular flow?
When senders finalize, they are accepting their loss of grin…

1 Like

I dunno but I found that the 7 and 6 letter words that begin with ‘in’ are a goldmine for play-on-words with the word ‘grin’.

Go with your gut, trust your grintuition.

1 Like

Did the word mutation came across? It is commonly used in accountancy when writing in ledgers.

2-step flow doesn’t seem to be “around the corner” so we can definitely improve our current 3-step flow.
I think request, offer, accept are definitely better words for invoice flow and the ‘finalize’ now actually makes sense.
Would be nice if we found names that fit both flows

1 Like

Definitely in favor of using request - offer - accept.

Personally I think it does not matter much whether grin or payment is used, but grin is shorter and therefore might sound better.
In case of two steps, it matters of course who initiate what naming would be correct.
offer - accept
would be most fitting if the sender initiates,
request - send
would be best in the case of the invoice workflow, I mean offer would not make sense here since the transaction is automatically accepted.

Most coins use send receive, this would be most ideal, make it magic happening in the background (yes I know the receive part is much different from coins with adresses, not important).
Request - send in the case of invoice. The problem is that slatepacks require the user to be conscious about the number of steps in which case for three step transactions other terms are needee

1 Like

Invoke request:

  1. Request grin
  2. Accept to pay grin
  3. Finalize Transaction (and reseive grin)

Invoke payment:

  1. Offer grin
  2. Accept grin
  3. Finalize Transaction (and transfer grin)

I think the words send and receive should be avoided for naming, because they can confuse users to think that the transaction is completed after sending an amount.
The finalize step should be eliminated if possible, because from a UX perspective it does feel bureaucratic - in the first two steps a transaction is invoked and accepted, so from a user’s perspective everything is already said, but grin still requires a finalization step. As long as that cannot be eliminated, I think finalize is already the best name for that step.

1 Like

The problem here is that the word “accept” in your 2nd step suggests that you already got the grins, when you really have 1 more step to do. This is the main confusion with the current 2nd round name (receive/pay) because their names suggest that the flow is finished which is why the last step “finalize” is confusing

Maybe something along the lines of Allow other party to deposit amount X on your account and Allow other party to withdraw amount X from your account. Much longer though.

I dont think accept means you already have it. If you accept a collect phone call the next step is connecting the call, if you accept a new job you are not instantaneously working there. It means you approve of the circumstances and want to move forward.

Maybe but it also doesn’t mean that there’s something more to do. You can accept an apology and nothing needs to be done after. I’m not a native english speaker so this could be an issue on my part, but I’d be confused if I agreed with someone to send me 2 coins, then I said “accept” to these 2 coins and the 2 coins were not there. Accept as a word on its own doesn’t imply a next step, while “offer” does I think.

I think that offer and accept are the perfect words to describe the (first) signing and the counter-signing of a transaction, since an offer is never complete without acceptance.

1 Like

Agree, this is what I had in mind when I said that offer implies a next step

request-payment-acceptance
offer-payment-acceptance
accept-payment-acceptance

request-acceptance
offer-acceptance
accept-acceptance

request-receival
offer-receival
accept-receival

request-collection
offer-collection
accept-collection

I agree, Accept works as alternative to finalize IMO and is perfect for both 3 step invoice.

request-offer-accept (on chain)

and perfect for normal 2 step transaction

offer-accept (on chain)

For 2 step invoice I would suggest
request-send (on chain)

For 3 step transaction
offer-accept-send (on chain)
-a bit confusing since accept in this context does not broadcast the transaction🤔

To make thing more clear just add the explenation that send and accept involve publishing/broadcasting the transaction, putting the transaction on chain.
The only downside is that there are now two words for putting a transaction on chain while with finalize we only need one word since there is no directionality involved. Other words that share this characteriatic with finalize are publish and broadcast.
Still I think using accept and send is more intuitive to most users.

I expect 2 step transactions will become standard and 3 steps will be used by more knowledgeable Grin users for who the names are not that important. Or is the plan to switch to 2 step transactions altogether for transaction monotonicity?

2-step and 3-step don’t impact tx monotonicity, they just have a different way of creating a tx, but the txs keep the same rules.

There is no agreed on plan for a 2-step solution as far as I’m aware, we just seem to agree that 2-step is better. We’ll hopefully research further the ideas that have been shared for 2-step👍

Request -> Approve Request -> Collect
Offer -> Approve Offer -> Release

This maybe?

I suggest using request - offer - accept for the three steps, in combination with one of these word pairs to distinguish the invoice vs regular flow:

pay vs bill
grin vs loss
gain vs loss
credit vs debit
payin vs payout
income vs outgo
proceeds vs expense

1 Like

I like the first one pay vs bill, it seems simple to understand and both words are short