Add aex9_extensions entrypoint to IAEX9Minimal.aes about dex-contracts-v2 HOT 6 CLOSED

I think the new contracts contain the aex9_extensions prop but some old ones did not. Unfortunately they are out there now so I guess the mdw needs to ignore those for now.

from dex-contracts-v2.

I think adding aex9_extensions to the interface is ok but not necessary. it's read-only

from dex-contracts-v2.

The idea is that this is a hint for other services how to parse & deal with the contract. We have to decide if its a required field for AEX9 or not. If it is, it should be in the interface.

from dex-contracts-v2.

adding the aex9_extensions to IAEX9Minimal.aes can't make anyone force to implement it. The reason IAEX9Minimal.aes exists is to identify the minimal set of AEX9 entrypoints which the Router and the Pair are using there. So even if we add extra entrypoints in the IAEX9Minimal.aes the only way to prevent a missing implementation of it is for the Factory to artificially call all of them in order for the transaction to fail and eventually the Pair creation to fail also. I don't think is the DEX role to achieve such a AEX9 validation. This can be done by us , in the DEX-ui by not allowing "broken" tokens to enter in the official Aeternity token list.

LE: but even so, nobody can stop anybody to create his own AedexV2Pair with some weird pair of tokens. So the mdw , explorer or any other app developed by us should be prepared to ignore / deal with such scenarios

from dex-contracts-v2.

Good to hear that there are stronger ways validate it.

Please let us know in case the mdw should be permissive on aex9 classification for:
A. old contracts (before which height please)
B. old and new contracts
C. none (continue demanding the aex9_extensions for all)

Thank you

from dex-contracts-v2.

Is not for me to say, but C seems a reasonable way to me.

from dex-contracts-v2.