FA1.2 %transfer entrypoint case when from account equals to account

There are two possible options for how to deal with this case: either treat it as a NOOP (so allowance remains unchanged) or as a regular operation (thus updating the allowance). Should both be allowed? The informal spec is not clear on this.

Furthermore, in the case when from = sender, do we allow an implementation that nevertheless decreases the allowance?

I agree it should be specified more precisely. I propose to disallow that, but I don't have a strong reason for that, just my personal preference. I. e. state that when from address equals to SENDER allowance MUST NOT (or SHOULD NOT?) be modified.

Ok that sounds good.

By the way, this also appears in the %approve entrypoint: in the case when sender = spender, do we allow an implementation that nevertheless updates the allowance (of an account for itself) and can thus even fail when this entrypoint is called?

assigned to @gromak

ManagedLedger implementation included in this repo currently treats from == to case as special and never consumes allowance in this case. We had some discussions about that few months ago and concluded that:

1. There is no good reason to keep this case as special, and treating it as special adds a slight overhead.
2. FA1.2 says "In this case current number of tokens that sender is allowed to withdraw from the "from" address is decreased by the number of transferred tokens". It doesn't say anything about special treatment of the from == to case, so allowance should be decreased in this case.
3. It's indeed a bit unclear and specified imprecisely.

We have an old MR that updates ManagedLedger implementation to treat from == to as an ordinary case (and consume allowance). I propose to update FA1.2 to clearly state that allowance should be consumed in this case to remove ambiguity. I can do it, unless someone has a strong reason to do something different.

Okay that also resolves the issue. Thanks!

@ksojakova to give you an estimate when it will be done: we had some urgent stuff to do this week, I think we'll start working on FA1.2 issues next week and I hope they won't take long.

Thanks @gromak sounds good.

mentioned in issue camlcase-dev/fa1.2#2 (closed)

added FA1.2 label

mentioned in commit edac6fbc

mentioned in merge request !99 (merged)

mentioned in commit 74921fd4

mentioned in commit af597cda

mentioned in commit 05cfb16a

closed with merge request !99 (merged)