Æternity best current practices (AEXpansions)


I would totally agree to this, but I think from case to case this requirement may be dropped and for some types of proposals it should not be required at all. But I see this well described in the ABCP-1 Types. Pseudocode implementations should be fine as well, I’d assume.

In my opinion ABCP-1 looks great.


Is there a dedicated github repo where the proposals should go to?


Yes, there will be a proposals repo. The above defines the process on how things get accepted there. Feedback is welcome!


I’m asking myself how to deal with

Specification: should describe the syntax and semantics of any new feature and should be detailed enough to allow competing, interoperable implementations

If you are not a technical person. Writing syntax and semantics of any new features might be a show stopper for some people. Is it possible that less technical users write specifications in form of user stories for example or does it need to go down to protocol level and deep understanding on how it would be implemented in a later stage?

EDIT: i’ve copied the text from above, the INTRO and the ABCP-1 into a markdown editor here for better readability. I hope this is ok, i’ll delete if requested: https://hackmd.aepps.com/KwFgDAjMYEYCYFoDsA2CAOBI4gEwJhHQDMEBmHJY4lGCOGAYyA==?view


There is nothing stopping them from submitting a draft to the repository but with the proposed ruleset it would not be able to progress past the Draft phase.
Ideally a person with a good idea but not the required expertise to specify it properly should seek out collaborators with the required skills.

We want to encourage people to solicit feedback on their ideas before they submit a draft to the repository. That might be a good point at which they could convince others that their proposal is worth engaging with.


Is there any example of a feature or standard of any kind that is following the ABCP Standard already so i can get inspired / guided a bit?

I’m planning to write up specifications on a potential Open KYC Standard (connecting pubkeys with different stages of KCY from posting a signed message on your gist and social media profiles up to partnerships with KYC provider).

I’ve difficulties to start and could need some guidance. Should i just copy and paste the ABCP and create a new forum post or is it better do do that directly on github in a github issue or is this the complete wrong approach to it and i should first do it in private and post it when its more then just a raw draft with a few cornerstones and bulletpoints?



For our ABCPs we have no examples, yet. Looking at accepted ERCs/EIPs could help.

All of those are valid approaches. Based on how far you are with your ideas, I would recommend ordering the starting points as follows (from least to most progress):

Private|Forum -> github Issue -> github pull request


“Standards Track” ABCPs and “Informational” ABCPs are defined also in terms of “change or addition” and “issue”, that imply existence of preceding/seed normative content. It would be beneficial to issue an informational ABCP with outline and pointers to existing normative material in scope of ABCPs that ABCP authors are expected to be aware of.

For the rest, the proposal looks great.


I don’t necessarily think that »change or addition« implies prior existence, addition could be going from none to some but I’ll make the wording more explicit.

The second point is a good one, thank you


I’d like to mention here, even if its a bit late, that the majority of people voted for the name:

aexpansions during the aepps summit in Antalya. A naming could be

aex-1 or aexpansion-1

I prefer the shorter version AEX-1, AEX-2. Would you mind to adapt that (as there has been some kind of “small governance decision” on this already?).

Best regards

PS: i really like ABCP but it was not up for a vote back then. I’m not sure if we documented or communicated results from the aepps summit yet, which we should do.


I second that, as a disclaimer I was also part of the vote at the aepps summit and voted for aexpansions. For me Aeternity best current practices sounds a bit confusing. Also for the abbreviation I would also go with AEX-1.


I updated the first post with the changed name.


I updated the title wit (AEXpansions) i hope this is fine.

pinned #15


I will create the repository at the end of the weekend unless there are any more concerns voiced.

Just for the record, I don’t particularly like the name aexpansions, since an expansion—to me anyway—would imply changes to the protocol, e.g. taking the existing protocol and expanding it.

Could you elaborate? What is confusing about the concept of »best practices«?


I’m familiar with the term »best practices« and »best current practices« but the current in »best current practices« has a weird ring to it, this is just a personal opinion.


https://github.com/aeternity/AEXs is now live. This thread can still be used for discussions about the initial version of AEX-1. Anything beyond that should either happen in a separate thread or in the repository itself.


First AEX are coming in: https://github.com/aeternity/AEXs/blob/238daaa61a94e494bab338066aef7cf16103c3aa/AEXS/aex-2.md


“current best practices” reads right to me.


Where is the right place to brainstorm an idea for an AEXpansion?