These are chat archives for Nethereum/Nethereum

11th
Jan 2019
Juan Blanco
@juanfranblanco
Jan 11 09:12
@janezkranjc yes a there is generic Message Signer without the prefix and the EthereumMessageSigner with the prefix
Daniel Moos
@d-moos
Jan 11 09:25
@Shammah @juanfranblanco I see. so technically I could simply check if the contract implements e.g. safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;. If so that would mean that its an 721 Token right?
(or the decimalsfunction might be better, since it's already implements in the EIP20 Contract definitions?)
Roy
@Shammah
Jan 11 09:38
Technically it means the contract just implements safeTransferFrom. You can only be sure if it's 100% ERC721 compliant if you check whether it implements all ERC721 contract functions.
I think there's an open Ethereum issue regarding making this easier
Daniel Moos
@d-moos
Jan 11 09:43

Im currently querying the assets from coinmarketcap where they retrieve the platform where the asset does belong to (for example, all assets on the ethereum platform do have a 'Ethereum' as platform value).
What I do not know is, which type of token it is (since it does not return that information).

So I would say that those assets are either ERC20 or ERC721. So I feel like I just have to differ which one it is (for example by comparing a property which does only exist on one side, just as decimals in ERC20).

I don't think I have to check if it's a ERC20 / ERC721 Contract in general (because I think it is required to be at least one of them due to the CMC Listing).

Daniel Moos
@d-moos
Jan 11 09:55

I did some kind of testing and wrote a PoC 'OwnerOf'-Function which only (should be) implemented in 721:
[Function("ownerOf", "address")]
public class OwnerOfFromFunction : FunctionMessage
{
[Parameter("uint256", "_tokenId", 1)]
public virtual string TokenId { get; set; }
}

If I call this on an ERC721 Contract I receive a valid response (e.g. 0x00000000000000000000).
However, when I call this on an ERC20 Contract I receive null (which equals to function does not exist on contract?)

await c.GetFunction<OwnerOfFromFunction>().CallAsync<string>() // 0x000000000000000000000000000000
await c2.GetFunction<OwnerOfFromFunction>().CallAsync<string>() // null

Do you think I can proceed with this routine to check whether a contract is erc20 or erc721 (given that it has to be one of these 2)

(sorry, not sure how to format code correctly here)
Roy
@Shammah
Jan 11 10:04
You can use backticks ` ;)
Daniel Moos
@d-moos
Jan 11 10:06
oh I see thanks! :)
Roy
@Shammah
Jan 11 10:06
But I'm not sure if checking for the owner function is a good heuristic. Back in the day even, and even sometimes now, people write owner functionality in ERC20 contracts.
So you might get false positives
Oh actually, disregard what I said
I got myself confused with owner and ownerOf
Ofcourse you can't be 100% sure if you don't check all functions, but if this works well enough for you I guess it's fine
Daniel Moos
@d-moos
Jan 11 10:11
yeah I mean I do have to fix a minority manually somtimes anway so I think I should be okay (it's a scheduled import task anyways).
I feel like most (if not all) tokens returned by CMC are currently erc20 anyways. I don't see ERC721 having any reason to be traded asset-wise like erc20 right now.
But I just wanna make sure I don't miss anything.
Roy
@Shammah
Jan 11 10:19
If it works it works :D
Juan Blanco
@juanfranblanco
Jan 11 10:23
@d-moos one thing to note is that many contracts whilst not part of the standard add other information https://theethereum.wiki/w/index.php/ERC20_Token_Standard
that includes the "real" interface
so yes ownerOf might be a simple validation
Kevin Small
@KevinSmall
Jan 11 10:26
@d-moos @Shammah the issue about determining if a token implements an interface is ERC-165 here: ethereum/EIPs#165. In the specific case of ERC-721, it is supposed to support ERC-165 already, so there may be a quick way to check, see: https://stackoverflow.com/a/53352634
Juan Blanco
@juanfranblanco
Jan 11 10:27
I hate the "event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);" as it is not the same as Transfer from ERC721
great point @KevinSmall !
Roy
@Shammah
Jan 11 10:30
Yeah, that's the one I was talking about.
Juan Blanco
@juanfranblanco
Jan 11 10:30
ah cool!
Roy
@Shammah
Jan 11 10:30
Didn't know it was "ready to use" yet
Ah, it is, but apparently a lot of contracts don't implement it yet, so it's not yet reliable enough
Daniel Moos
@d-moos
Jan 11 10:34
oh thank you a lot for the heads up. I think I'll keep an eye on it but roll with the 'simple validation' for the moment.
Good to see that the community is already proposing some solutions for that
cloverme
@clovermebitcoin
Jan 11 20:05
I need to work with a contract where the transfer function in the contract requires a 3rd variable, will I be to call that function using nethereum thru web3/rpc?