Status: Approved on the 23.03.2023, submitted on the 17.02.2023 Last updated: 17.02.2023 Submited by: Marco Team: Marco Approved Budget (in h): 200.00 Used Budget (in h): 200.00
Planned Delivery of Phase 1 (Scope Definition): ~4-6 weeks after start Planned Delivery of Phase 2 (Smart Contract Development): ~4-6 weeks after scope definition is finished Planned Delivery of Phase 3 (Frontend, hosted via gh-pages): ~4-6 weeks after contract development is finished
Specify the funding category
Open Source Development
Community Growth
Application Title
Wrapping AENS names into AEX-141 NFTs to allow batch transfers, batch updates and batch trades
Applicant
Marco
Value Application
Provide a way for the community to better manage their AENS names
Enable batch-actions for AENS names
Allow strangers to extend AENS names and get rewarded for that
Definition of Terms
Wrapping AENS names into NFTs will make it easy to perform batch-actions on the names and enable new use cases. NFT trading is also highly anticipated and is another topic to tackle in that regards.
Status Quo
No batch actions (updates, transfers) for AENS names are possible
This proposal here differs a lot from the other approach because trading would be enabled via a regular NFT marketplace where the wrapped AENS names could be exchanged
Users still suffer from name expiration as they fail to consistently track name expiration
Required Work
1. Scope Definition
Although I have already a quite clear picture in my head this phase is very important to make sure I am developing the solution in the best way possible to serve the needs of various members in the community. It is a very good chance for everybody to get involved and drive the solution into the right direction
Tasks:
Create different diagrams to discuss and define a clear scope
Topics to cover for the big picture:
Wrap AENS names into AEX-141 NFTs
Allow batch-actions (updates, transfers) on AENS names wrapped in the NFT
Provide a way for anybody to perform those updates and get rewarded for doing so
Consider an AENS DAO with its own AEX-9 token to handle changes on various parameters which might be defined in some contracts (e.g. a certain percentage of the update rewards could be moved into the DAO and distributed based on decisions taken by the DAO)
Iterate on the scope & diagrams based on public discussion with community
General design decision to take:
Should contracts be deployed in a way they could be upgraded later on to enable new features like e.g. the reward mechanism and the AENS DAO
Deliverables:
Different diagrams that define a clear scope for phase 2+3
2. Smart Contract Development & Deployment
Tasks:
Analyse how many batch-actions can be performed on AENS names to prevent out of gas issues and possibly limit the amount of AENS names to be wrapped into a single NFT
Development (incl. tests) of Smart Contracts required to cover the defined scoped
Deployment of the contracts
Documentation of contracts & deployment(s)
Deliverables:
Sophia Smart Contracts with test coverage
3. Frontend
Deliverables:
A frontend that does not rely on a custom backend (mainly using hosted mdw) and allows to interact with all entrypoints of the developed smart contracts.
Estimate
1. Scope Definition
Delivery: ~4-6 weeks after starting to work on it
Working hours: ~80-120
2. Smart Contract Development
Working hours: ~100-150 (can vary depending on the scope defined in phase 1)
The better the scope definition, the faster the development can be
3. Frontend
Working hours: ~100-150 (can vary depending on the scope defined in phase 1)
Known Limitations
I already provided a request to make the wrapping of AENS names more convenient here:
I would ignore this limitation for the moment and later on apply for another smaller grant to update all components once this feature is implemented and activated on testnet and mainnet.
Outlook
Publication of a detailed blog article
Live presentation for the community
Make the NFTs tradable
NFT marketplace
NFT auction platform
…
Publishment
Research and development will be published free of any proprietary license (open-source, open-access)
I confirm that my research and code will be maintained with bug fixing free of charge for one year after publishing it.
Disclaimer: I cannot give any ETA for bugfixes as this will always depend on my availability. I will guarantee to fix problems as soon as possible.
This does not include new updates & features. If e.g. the mentioned limitation is fixed, I will apply for a follow up grant that allows me to update the services accordingly.
Looks really good, I support this! I wouldn’t wait on the resolved limitations, rather propose something thats finalizable, then make a follow up once possible.
Dear @marco.chain, thanks for the interesting application. Can you please contact me for the details? Please note the maintenance should be at least one year provided.
My proposal has different phases where maintenance might not be so much relevant. I think most important is Phase 1 and 2. For phase 2, the contracts I do not see much relevance for maintenance. It would be more like new features to be added (e.g. delegation of all AENS names once this is possible).
The maintenance part would be more relevant for Phase 3 / 4. I am not even sure if I want to apply for Phase 4 of this proposal. There might be another team that could tackle this part as I am neither a designer, nor a good frontend developer. Phase 3 could be easily handled by me with a just functional UI that allows to interact with contracts.
I think it should be clear what kind of maintenance is expected. As @philipp.chain outlined it could be a tiny effort, but it can also be a bigger effort if there are breaking changes in SDKs for example.
Dear @marco.chain,
thanks for the explanation. Please put project hours per scopes in order to estimate the cost. Since the scopes are depending on each other and some are optional please specify the deliveries of the scope 1. and scope 2. for any user. A discussion in the forum on the known limitation and diagrams of your project can be recommended before the start of the project.
The maintenance requirement for the software project is needed to provide a quality software and documentation at least for a year. Some of the Chinese developers even confirmed and are doing the maintenance for several years. The goal of the software maintenance is to keep the software system working for the users. If a developer feels not responsible for the bugs created by him/her and requires at least double payment for the same task it arises the question for whom the broken software can be useful (who controls at the end the project cost). Please feel free to contact us under the Email: [email protected]
I just updated my grant application and also provided and approximate amount of hours on each phase. As I am solo developer on this I removed phase 4 and made phase 3 non-optional. I think a UI that allows to interact with all available contract entrypoints is mandatory for people to actually use it.
The estimates for phase 2 and 3 are very vague as long as phase 1 is not finished. It heavily depends on how many features we want to cover and how complex the proposed solution will be.
Right now the most important thing for me is to clarify the scope. We can consider A LOT of stuff which might be cool, but to achieve it the right way I need to get as much feedback as possible. Otherwise I will probably have to stick to a minimalistic approach to avoid unnecessary overcomplication of tasks.
I will shortly summarize the most important questions to address and discuss:
Do we want to introduce a mechanism to reward other users for extending AENS names of others? Personally I think this would be cool and this has always been in my mind
What reward-mechanism do we prefer?
NFT owners define their own reward (in Æ coins) for users
We create an AEX-9 token (e.g. AENS DAO) which rewards users based on various criteria (to be defined)
I already noted some ideas in the mindmap about the AEX-9 token, but if we create such token we should also discuss its utilities (e.g. voting, staking, …)
Both?! → IMO, if we decide to introduce an AEX-9 token, we should focus on that
Do we want to allow transfers of AENS names between NFTs? Shall this only be possible if the user is owner of both NFTs? I would say yes
Logic for extending AENS names wrapped in NFTs (and possibly corresponding reward-payout logic)
Always extend all names? (most simple solution, especially when it comes to rewards. but not really efficient)
Select a set of names to extend?
Select a single name to extend?
Do we want to limit the amount of AENS names that can be wrapped into NFTs to ensure that batch-updates & batch-transfers are always possible for all wrapped names? Or should we allow an unlimited amount of names to be wrapped where users/devs would have to take care to not exceed limits in batch updates?
How to deal with “spent” or “accidentially received” AENS names? The Smart Contract would not be able to know who sent the AENS name to its account, so there are following options:
Sell
who should receive the sale proceeds?
Listing vs. auction
Fixed price vs. dynamic price
Make claimable by anybody (first to claim gets the name)
Let expire
In case we decide to introduce an AEX-9 token we will have to discuss a lot more details. But these are the “big questions” I have currently in mind which I want to discuss with you.
I think I definitely want to provide some incentive mechanism for users to extend AENS names of other people.
the key question is then what route to choose:
let AENS owners pre-fund NFTs with AE and define a reward for extending names
introduce a new AEX-9 token and implement some protocol to reward active users
the first option would definitely the more straight forward solution and NFT owners can then define how much it is worth for them if others extend AENS names on their behalf.
introducing a mechanism to issue a new AEX-9 token for the reward system comes with a lot of additional questions I am not sure if we’d be able to address right now. it’s probably better to think about this at a later stage if we see that there is a lot of demand for the application in general.
currently I think it’s best to go on with the route to let all NFT owners decide themselves how to reward other users.
the other topic I am a little bit struggling with is how to deal with AENS names and different expiration times. probably it would be best to always keep them in sync, so that all names have the same expiration time. this would also mean that if additional names are added to an existing NFT, all names associated with this NFT would automatically have to be extended along with the name(s) to be added.
in this case I would also prefer to only allow extending all wrapped AENS names at once for reasons of simplicity & to keep expiration time in sync.
only following explicit actions for single AENS names or a set of AENS names would then be possible:
transfer from one NFT to another NFT, which in turn would then automatically extend all AENS names wrapped in the target NFT
claiming back AENS names from an NFT to a specific account
setting individual pointers
extending names would only be allowed for all AENS names at once. this also means that we have to introduce a limit of AENS names that can be wrapped in an NFT. we need to ensure the actions to update all names do not exceed the gas limit.
I’d love to see an AENS DAO with an AEX-9 token here, probably with multiple functionalities that allow to burn such token. I’m wondering if it could be a DAO with a staking business model given that this is an ACF grant or maybe it’s not relevant at all.
I think it should be possible even if the user doesn’t own both NFTs.
Always extend all names at all I would say, else it becomes too many steps for the user I believe. Ideally try to have a smooth UX for end consumers. In any case users should be able to see at a quick glance how much it would cost to extend all names of one NFT or another.
Unlimited amount, but always given that users can see the costs for batch extending names for each given NFT.
Hmm maybe this should be decided via voting in the DAO model. I’d personally prefer the first come first, serve model to allow people to claim names they lost by accident
I’d personally prefer the second route in a DAO model with staking incentives, I know it’s more complicated to develop, but will allow more user engagement I believe.
I agree in general, I would also love to see this. but I somehow doubt that we will be able to iron out all the details within the scope of this grant. too many questions to answer which I am not sure how to deal with:
when will new tokens be issued?
will there be a cap of tokens or will there be an infinite (but reasonable) inflation as incentive to participate in the system
how to prevent “cheating” (mass-creation of tokens) in case of usage based issuance
what can the token ultimately be used for? what is the utility?
if we aim for DAO capability it might anyway be good to wait for the results of the running hackathon
if there is no utility for the issued token which is rewarded to accounts when extending other accounts, why would they want to extend the names then? so this is a very crucial aspect in that regards.
for this reason I tend to choose the other route first, letting NFT owners define a reward for extending names. of course the system can be improved in the future and maybe we can then introduce the AEX-9 issuance and establish a DAO for this. right now I feel there are too many open questions and uncertainties I mean in the end I wanna ship the solution as soon as possible and additionally we don’t know yet how many people are really interested in using this. I hope and assume there will be at least some demand
can you name examples where you would expect that to be possible? maybe the NFT owner could define a flag if he accepts AENS names of other accounts to be wrapped into an existing NFT he owns
I can definitely imagine that some people would want to avoid this. otherwise I could spam AENS names into other users NFTs.
regarding costs: this would be the default network fee for the transaction. in fact, the user is anyway expected to get a reward (only if the user is not owner of the NFT of course). the more names are wrapped in the NFT, the higher the tx-fee.
actually I think we have to introduce a limit. if there are too many AENS names wrapped in an NFT, extending names tx could exceed the gas limit. that would be a flaw in the contract then. of course I would perform tests and allow as many AENS names as possible to be wrapped.
I don’t think DAO will be doable in the scope of this grant as explained above. I agree that first come, first serve model is best.
maybe we can introduce a fixed fee for claiming that name and send the AE to the BRI wallet to support the work of the foundation although I doubt this scenario will happen a lot
I currently favor the first route as I outlined above. but I am open to hear more opinions on that. we still have some time to discuss before I finish the diagrams and aim to start developing. independent of that any idea is welcome and we can introduce a DAO model at a later stage
I think besides the Nft attribute, Aens also needs to be considered as an identity and domain name. From a domain level perspective, I hope .chain can replace.com in the future. You can use Aens as a fully decentralized website (ideally not attacked or blocked by government or other entities), I also hope that all dapps on aeternity can be accessed through .chain and from an identity perspective, I hope that Aens can be used as a social media account (such as for logging into superhero）, or an email account (such as a decentralized email system based on Aeternity for account login), game account, or game character name, etc
setting arbitrary strings as pointers will be possible once Ceres hardfork is activated. definitely the naming system can support a lot of use cases, but it is up to developers and businesses to utilize this feature
I have updated the diagrams and I am currently aiming for the “simple” approach which allows any user to set a global reward config as well as an NFT specific reward config.
read more about rewarding users for extending names here:
Waiting for more feedback now. Will define the concrete contract interface based on the current state early next week and if nobody raises concerns I would start with the implementation right after that. At least I will analyze the max. amount of AENS names that can be wrapped into an NFT based on the current proposal.
Maybe there will be some iterations required in development, but I think that’s ok.
Alchemix has build a solution for ENS that allows users to never lose their ENS names again. This is actually sth. I would also like to focus on here. But let’s start with a simple solution first and get it out in the hands of the users
I mean in the end I wanna ship the solution as soon as possible 
