Update arc-0200.md

[temptemp3]

Lines 42, 45:
Fixed typo: bytes -> byte

Line 56:
Propose changing arc200_decimals return type to uint64 for improved compatibility with compiled smart contracts that do not have uint8 available

Change return type of transfer, transferFrom, approve from bool to byte

Describe what non-readonly methods return values should be.

Describe decimals return value

[SudoWeezy]

Can you give more explanation on why you want to Change return type of transfer, transferFrom, approve from bool to void?

[jannotti]

What does this mean?

compiled smart contracts that do not have uint8 available

uint8 is the ABI type. If you have a number between 0 and 255, you can use itob; extract 7 0 to produce a single byte as an ABI uint8.

[temptemp3]

Three reasons: 1) The return value is trivial, on success it returns true otherwise fails 2) Simulator can be used desired result 3) Reach compiled contract does not allow return type of bool but instead uses bytes between 0 and 1 (May be available later) 2023年10月24日(火) 2:49 Stéphane ***@***.***>:

…

Seems to be some good improvement. Just, can you give more explanation on why you want to Change return type of transfer, transferFrom, approve from bool to void? — Reply to this email directly, view it on GitHub <#253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQ4AW4OTZA26IX3ODDLDTTYA56JFAVCNFSM6AAAAAA6KLYD6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWG44DOOJWGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[temptemp3]

Reach compiled smart contract does not allow for return type of uint8, only uint64 and uint256. I assumed it would work but it appears it doesn't. This may change in the near future. If push comes to shove I might be able to experimentally modify the resulting teal program to: 1) Update the selectors to include uint8 instead of uint64 2) Produce a uint8 from uint64 by hand 2023年10月24日(火) 6:52 John Jannotti ***@***.***>:

…

What does this mean? compiled smart contracts that do not have uint8 available uint8 is the ABI type. If you have a number between 0 and 255, you can use itob; extract 7 0 to produce a single byte as an ABI uint8. — Reply to this email directly, view it on GitHub <#253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQ4AWYT3SD4YGVCF5X6LCTYA62YBAVCNFSM6AAAAAA6KLYD6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZXGE2DOMBVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[temptemp3]

I may be able do the same things here as the case of uint8 but it would be by hand 2023年10月24日(火) 2:49 Stéphane ***@***.***>:

…

Seems to be some good improvement. Just, can you give more explanation on why you want to Change return type of transfer, transferFrom, approve from bool to void? — Reply to this email directly, view it on GitHub <#253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQ4AW4OTZA26IX3ODDLDTTYA56JFAVCNFSM6AAAAAA6KLYD6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWG44DOOJWGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[temptemp3]

Can you give more explanation on why you want to Change return type of transfer, transferFrom, approve from bool to void?

Sry this is outdated. I considered void but changed it to byte afterwords. My mistake for not noticing.

[temptemp3]

It should be less than it equal to 256. This is because type uint256 is used. I’ll fix this mistake soon.

…

Sent from my iPhone

On Oct 26, 2023, at 12:57 AM, Stéphane ***@***.***> wrote:  @SudoWeezy commented on this pull request. In ARCs/arc-0200.md: > The methods `arc200_transfer` and `arc200_transferFrom` MUST emit a `Transfer` event. A `arc200_Transfer` event SHOULD be emitted, with `from` being the zero address, when a token is minted. A `arc200_Transfer` event SHOULD be emitted, with `to` being the zero address, when a token is destroyed. The `arc200_Approval` event MUST be emitted when an `arc200_approve` or `arc200_transferFrom` method is called successfully. +The methods `arc200_transfer` `arc200_transferFrom`, and `arc200_approve` SHOULD return byte `1` on success and byte `0` on failure. + +The method `arc200_decimals` SHOULD return a value less than or greater than uint64 `256` I don't understand this line. Why should it be Less OR Greater than uint64 256? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[SudoWeezy]

For interoperability, I would keep bool & uint8. Changing the standard based on Reach implementation of things is not right.

How do you handle https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md tokens? Do you also return bytes & uint64?

[temptemp3]

What does this mean?

compiled smart contracts that do not have uint8 available

uint8 is the ABI type. If you have a number between 0 and 255, you can use itob; extract 7 0 to produce a single byte as an ABI uint8.

Thank you for the advice. I may be able to use this.

[temptemp3]

For interoperability, I would keep bool & uint8. Changing the standard based on Reach implementation of things is not right.

How do you handle https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md tokens? Do you also return bytes & uint64?

For sure. I'll figure something out.

[temptemp3]

@SudoWeezy @jannotti I have retract proposed abi changes that will not move forward. Kindly accept changes in this PR as they address known issues, there is a type in the abi. Thx!

[temptemp3]

extract 7 0

Work great. Thanks for the tip! @jannotti

[temptemp3]

@jannotti any tip on how I might return a bool instead of byte in transfer, approve, transferFrom method?
Currently the txnResult.logs looks like this

  Uint8Array(5) [ 21, 31, 124, 117, 1 ]
]
ABIMethod {
  name: 'arc200_transfer',
  ...

Last byte is 1 indicating success.
I am wondering if it will just work if I were to update the methods selectors to match the abi spec? For example,
Instead of

    {
      "name": "arc200_transfer",
      "desc": "Transfers tokens",
      "readonly": false,
      "args": [
        {
          "type": "address",
          "name": "to",
          "desc": "The destination of the transfer"
        },
        {
          "type": "uint256",
          "name": "value",
          "desc": "Amount of tokens to transfer"
        }
      ],
      "returns": { "type": "byte", "desc": "Success" }
    },

Use

    {
      "name": "arc200_transfer",
      "desc": "Transfers tokens",
      "readonly": false,
      "args": [
        {
          "type": "address",
          "name": "to",
          "desc": "The destination of the transfer"
        },
        {
          "type": "uint256",
          "name": "value",
          "desc": "Amount of tokens to transfer"
        }
      ],
      "returns": { "type": "bool", "desc": "Success" }
    },
    ```

    Any thoughts?

[jannotti]

I believe that will work. I think a single bool would be encoded exactly the same way a byte would be.

[temptemp3]

Okay. I’ll give it a try. Thanks!

…

Sent from my iPhone

On Oct 30, 2023, at 10:14 AM, John Jannotti ***@***.***> wrote:  I believe that will work. I think a single bool would be encoded exactly the same way a byte would be. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[temptemp3]

I believe that will work. I think a single bool would be encoded exactly the same way a byte would be.

Thanks @jannotti it just works