Token minting's recipients - AEIP19

[samuelmanzanera]

This is a discussion for the AEIP19 located at: https://github.com/archethic-foundation/aeip/blob/main/AEIP-19.md

[Neylix]

I think this AEIP should not require AEIP-2.
Currently there is 2 AEIPs that allow user to create tokens, AEIP-2 and AEIP-18. One part of the AEIP-18 create a new structure for token minting which does not rely on AEIP-2.
As it, your AEIP require AEIP-2 structure, AEIP-18 could not uses it and we would need to create another AEIP for it.

I think your AEIP should be more generalist by saying that any token transaction could also add a recipient field to send new minted tokens.

So any other standard to create token without relying on AEIP-2 could also require this AEIP

[Neylix]

There's only one part of AEIP-18 that uses AEIP-2, the part which add the new field allow_mint.
But the new token transaction structure is

{
  "aeip": [8, 18],
  "supply": 1000,
  "token_reference": "0000C13373C96538B468CCDAB8F95FDC3744EBFA2CD36A81C3791B2A205705D9C3A2"
}

This is not compliant with AEIP-2 this there is no type, properties, name ... as mentionned in the aeip list, 2 is not used

So this structure could not have the recipients field as you described since it's not AEIP-2 compliant

[samuelmanzanera]

Ok then we can just have a requirement of AEIP2 or AEIP18

[Neylix]

Why wouldn't you apply this rule for all token transaction ?
Let's say we create a new token minting standard in future AEIP, it could be interesting it can require this AEIP as well

[samuelmanzanera]

Yes indeed we can.
I'm just wondering if the AEIP could some form of inheritance or just JSON schema validation.... 🤔

[samuelmanzanera]

Let's keep it as JSON definition with required fields.
I have updated the AEIP to be more generic letting the validation nodes to ensure token validation.