What are the chances of TransferFrom being implemented in CIS?

I’ve already read this.
http://proposals.concordium.software/CIS/cis-2.html#no-token-level-approval-allowance-like-in-erc20-and-erc721

Supposing that contractA is a Fungible Token and contractB is a swapping module that exchanges A for some NFT.
In the above case, user X would call B’s swap() instead of A’s transfer(), and so B would need to call A’s transferfrom() in swap().

I understand how to implement transferfrom/approve to contract A, but not necessarily to implement it by ourselves. (I mean A and B may belong to different teams/orgs.) I am particularly concerned about the USDC case.
So it would be helpful if it is standardized.

Just to clarify, since I am a bit confused. CIS-2’s transfer function is more general than safeTransferFrom. Did you see CIS-2: Concordium Token Standard 2 - Interoperability Specifications ?

So as I see your example, as long as contract A implements CIS2, and the user makes B an operator of their token then it seems that what you need is already possible.

Thanks for your response.

Sorry for my lack of explanation. I know I can achieve something similar to Approve with using Operator, but I’m concerned that an Operator would have the same power as an Address Owner.

So if there is a mistake or malicious intent in the contract B, you could lose the entire amount, right?

Is there any way to check from the user side to see if there is a problem with the contract?

@abizjak
Excuse me for asking again and please let me make sure two questions.

  1. Does USDC follow CIS2 standards without additional features? If a code or standard already in place, it would be greatly appreciated if you could let me know.

  2. When implementing a contract like Dex, where the purpose is to exchange or swap, is it recommended to use operator rather than creating my own approve?

Regarding 1, if you are referring to the bridged then it is not expected to have anything else.

Regardin 2, we’ll get back to you shortly. We want to discuss internally since we had discussions about this in the past.

Regarding 2.

At the time of the design of CIS2 we thought that for a dex-type situation an approach that would have benefits, compared to approvals or operators, is that

  • user transfers tokens to the swap contract (so that they are owned by it)
  • swap is made

So at no point is an approval or operator concept needed. Is this something that would make sense in your case?

Thanks again,

so in this case, do you mean userX should call A’s transfer(), not B’s swap()?
If I am correct, how does B know how much X transferred and send back tokens in exchange to the user?