Identifying the contract type in contract-related events

[lukeromanowicz]

We are working on aeScan - a blockchain explorer that exposes critical blockchain information in approachable way. We would like to know the type of contract to show the aeScan users what a given activity with a token really means (e.g. collection minted, token minted, token burned, etc). Right now we can only show that there was a ContractCreateTxEvent or ContractCallTxEvent without specifying what it actually means or does.

I was wondering if is there any way to reliably tell if a ContractCreateTxEvent or ContractCallTxEvent is referring to a contract that is AEX-9, AEX-141 or something custom?

To give you some examples:

• First record on the list is an event that implements FROST AEX-9 token https://mainnet.aeternity.io/mdw/v2/accounts/ak_3n5eTrEzg2VDQK7Y2XJdShVeaDsdpZggA8JvpukGpwEKkiorv/activities?cursor=484405-25678005-0&limit=10&rev=1
• In the middle of this list there is a ContractCreateTxEvent implementing an AEX-141 token https://mainnet.aeternity.io/mdw/v2/accounts/ak_uQuBvVNEFnMBBzLkg8CSVtRoc8x971258aNjGoeDzc7tP7FF6/activities?limit=10
• Here we have interaction with a custom contract. I think it's a survey contract: https://mainnet.aeternity.io/mdw/v2/accounts/ak_kFZkYQMsU47oQsTxEimTybAWUozSVmCXJBNZwetEr87hG3M1z/activities?cursor=799489-52477057-0&limit=10&rev=1

From the initial discussion with Rogerio it looks like:

aexn_type field could be added to the ContractCreateTxEvent and ContractCallTxEvent. However as an AEX- contract might be created from a contract call, there might be a situation where the called contract is not an AEX- but the child contract is. So I think we should have another field to indicate the type of the child contract so that the aexn_type refers always to the called contract.

[jyeshe]

On /v2/contracts/ solved by #1518

[janmichek]

@jyeshe @lukeromanowicz Seems like this has been fully resolved, or should I take care of some followup? If not, please close this issue

[jyeshe]

@jyeshe @lukeromanowicz Seems like this has been fully resolved, or should I take care of some followup? If not, please close this issue

Not yet, the field needs to be added to the activities as well. On next release.

[jyeshe]

For contract create and call txs (including ContractCreateTxEvent and ContractCallTxEvent) handled by #1591

[jyeshe]

@lukeromanowicz if still needed, please provide a list of custom contracts that are relevant for the aescan, along with the pattern of detection as well.

[lukeromanowicz]

@janmichek took over the task. Jan, could you, please discuss with Rogerio and Michele what else could potentially be helpful for us?

[janmichek]

From my understanding it's these 2 contracts https://github.com/aeternity/dex-contracts-v2#aeternity-deployed-contracts (Factory and Router) Testnet respectively

[jyeshe]

From my understanding it's these 2 contracts https://github.com/aeternity/dex-contracts-v2#aeternity-deployed-contracts (Factory and Router) Testnet respectively

What matters here are these official contracts, right? At these very same addresses. In this case I would leave the responsibility for the aescan to detect it specially because the new field is for AEXN types. Can you confirm it @michele-franchi ? Is the requirement to classify multiple factories and routers or initially these 4 on these addresses would suffice?

[janmichek]

@michele-franchi ping

[janmichek]

From my understanding it's these 2 contracts https://github.com/aeternity/dex-contracts-v2#aeternity-deployed-contracts (Factory and Router) Testnet respectively

What matters here are these official contracts, right? At these very same addresses. In this case I would leave the responsibility for the aescan to detect it specially because the new field is for AEXN types. Can you confirm it @michele-franchi ? Is the requirement to classify multiple factories and routers or initially these 4 on these addresses would suffice?

these 4 on these addresses should suffice