I am currently also thinking about the authorization of AENS related actions when a different contract than the AENS wrapping contract owns the NFT 
let’s assume the NFT is being transferred to a marketplace contract. I guess in this case as I would want to avoid that the marketplace contract can perform actions on the AENS names wrapped in the NFT. the question in my head is if this needs to be prevented by the AENS wrapping contract or if actual users just need to make sure they check the marketplace contracts they use to avoid potential abuse
any thoughts/feedback on that? probably not much the AENS wrapping contract could to then as the marketplace contract becomes the owner of the NFT in that case and would - theoretically - have full control over it.
Yes, I think once the NFT contract gives up control of the name there is nothing more it can do - only interacting with well known contracts is probably the way to go 
2 Likes
Update
- completed all important tests, also the abort cases
- finished the implementation of the contract logic
- note: a migration path for Ceres is not considered yet, I am in contact with @hanssv.chain regarding that
- added scripts to unwrap a name and to burn the nft
- a new deployment of the contract is now available here:
before I will tackle the migration path, I want to provide scripts to interact with most important entrypoints.
also, I will work on a simple UI to allow using the contract from Superhero Wallet. the plan is that the UI also consumes contract events from the middleware in order to show as much meaningful information as possible about the contract 
in the meantime I encourage everybody to play around with the contract on testnet. additionally it would be great if some eyes could have a look at the source code and check if sth. needs to be fixed / improved:
feel free to just open a GH issue here:
3 Likes
Week 29 (Jul 17 - Jul 23)
Started to implement a basic UI and reported bugs / missing features. Following enhancement is highly desired and afaik @davidyuk is working on it now:
New commits:
I also have some uncommited stuff locally.
Deployment of the UI is available here:
Unfortunately we need to be able to sign delegation signatures with an active wallet connection in order to allow wrapping AENS names via UI. I can prepare some stuff but most likely I will switch focus to prepare the contracts for Ceres hardfork. Not sure yet.
Time spent: 15.00h
3 Likes
Week 30 (Jul 24 - Jul 30)
I started testing the new SDK version for delegation signature creation. Unfortunately there is still work to be done in the SH wallet in order to make the functionality available for the “average user”. I will continue to prepare the basic UI and look into a possible Ceres migration this week.
Time spent: 5.50h
2 Likes
today I deployed another instance of the contract here:
I want to make reward mechanism better testable and decided to deploy another instance of the contract with a max TTL of 3360 keyblocks. the regular max TTL is 180_000 keyblocks which means we’d have to wait quite some some time depending on the config of a specific user. 3600 keyblocks reflects ~ 1 week.
I share this here because I am curious of somebody will be able to grab the reward once the reward block window I have configured kicks in.
otherwise I will just test myself 
I will probably also create another 1-2 NFTs to test this.
do you guys think that it should be possible for the NFT owner to reward himself by extending his own names??? doesn’t really make sense to me, but I am not sure if we should prevent it.
4 Likes
I guess one should be able to reward themselves if they wanted to
Would users always need to wait 1 week for the reward or is this just now for testing purposes?
no, so generally it is always possible to extend all names that are wrapped in an NFT. it is up to each user to define if and in what block-window they allow others to receive a reward for extending the names included in an NFT.
of course the reward can only be paid if the user deposited AE to the contract. otherwise, even if defined, the reward for extending names will be zero.
in the example of the screenshot the name would expire in 3313 keyblocks, the regular reward block window would kick in once 960 keyblocks are left until expiration. if somebody extends the names between 960-481 remaining keyblocks, they would receive 2 AE for doing that. for extending between 1-480 block window, the user would receive 5 AE for extending the names 
note:
- if you want to wrap AENS names right now into NFTs using the hosted application, it currently doesn’t work with SH wallet because of the missing delegation signature support which will hopefully be added to SH wallet
- however, you can connect your wallet and extend AENS names of existing NFTs already if you visit the url directly. currently, following NFTs exist:
- on aeScan you can see that the contract currently has an AE balance of 21 which is the amount of AE I deposited into the contract. the contract also provides an entrypoint that returns the total reward distributed for extending names across all NFTs
1 Like
So there is a higher reward for extending names that are soon about to expire. Hopefully this way most AENS names will never expire again if the owners wrap them as NFTs and volunteers pick the NFTs with the highest reward opportunities
1 Like
it depends on the configuration and AE deposit of the NFT owners
I can also decide to provide a higher reward for people that extend “earlier” and a lower reward in case of “emergency”.
there could also be zero reward for extending names wrapped in the NFTs. of course community could also extend for free 
1 Like
it is also possible to define a specific NFT config which will “overwrite” the global defined user config. in case of an NFT transfer, the NFT specific will be removed.
this feature might be interesting in case people put some of their “unicorn names” into a NFT that they value much higher than others. so they could provide a higher reward for this specific NFT compared to others.
but in any case, AE needs to be deposited into the reward pool of the contract.
1 Like
Week 31 (Jul 31 - Aug 6)
Added possibility to set a global config via UI and to deposit/withdraw to/from reward pool in contract
Started experimenting with Ceres features, a branch with first experiments meanwhile exists here:
Independent of that I had a conversation with @michele about a possible integration of the AENS wrapping in aeScan where we identified an issue with using the AENSWrapping contract without caring about case sensitives AENS names which has already been fixed this week by making sure, that the contract internally handles the AENS names always in lower-case.
I also opened following issue in the SH wallet which is kind of a blocker for adoption by regular users, because they cannot use SH wallet to wrap their AENS names right now:
The previous issues reported to SDK in that regard have already been solved by @davidyuk and are included in the latest release v13.2.1.
I proposed new issues and bumped old issues to improve AENS handling in SH wallet:
This week I will continue to prepare the Ceres contract and introduce an easy way to migrate NFTs from the current contract to the future Ceres contract.
Time spent: 14h
1 Like
I just extended all names included in NFT with ID 1 on testnet
this is the tx on aeScan:
as you can see I got a reward of 5 AE for extending the names wrapped in the NFT
there are still NFT 2 and NFT 3 left to extend for a reward if you want to test:
you just need a SH wallet. extending names is not affected by the delegation signature blocker which is required to wrap names.
note: sometime the UI displays “NFT does not exist” even if it exists. one or multiple reloads of the page should show the NFT details. the NFTs with ID 1,2 and 3 definitely exist!
1 Like
Week 32 (Aug 7 - Aug 13)
I fixed the previously described issue with case sensitive AENS names so that the contract internally handles all AENS names lowercase:
reported a bug that produced bad_calldata when sorting needs to be handled correctly by calldata-lib:
the issue has already been fixed by @dincho.chain but needs to be included in a new release of the calldata-lib. this also requires a new release of the js-sdk afterwards by @davidyuk
I requested a feature to enable the verification of a global AENS delegation signature within a Sophia contract which currently is not possible. this is relevant for the Ceres contract I am preparing:
the feature has already been implemented by @hanssv.chain, but the PR is still open
I will continue to prepare the Ceres contract which allows to provide a smooth migration to a more simplified contract.
for the enduser stuff and actual testing by users we need to wait for the required features to be incorporated into SH wallet as mentioned in earlier posts.
Time spent: 6.50h
2 Likes
Hi Marco! 
In case it would have breaking changes (a major release), otherwise aepps can update calldata by themself in package-lock.json
2 Likes
Week 33 (Aug 14 - Aug 20)
I received some feedback of @hanssv.chain which I incorporated in the current implementation:
Time spent: 1.50h
1 Like
Week 34 (Aug 21 - Aug 27)
I updated the documentation of the project and started to prepare the migration from Iris (protocol v5) to Ceres (protocol v6).
The migration path required me to do some custom builds for the Sophia compiler and the aeternity node that enabled new features.
I also identified an issue in my contracts. The latest compiler version now includes a fix that has been introduced with the following PR: Unify typesigs when implementing interface funs by ghallak · Pull Request #469 · aeternity/aesophia · GitHub.
My contract actually used this “bad behavior” and I needed to define a separate namespace to correctly reference the types in the contracts.
Time spent: 18.00h
1 Like
