And the WIP documentation is here
Is the initial bid price of aens determined?
yes, both the bid price (technically name_fee
) and the duration of the auction are a function of the length of the name.
They are expressed in the documentation linked in the OP and by @hanssv.chain and the specific section is this (the link may break when the pr get’s merged)
what is the unit of the name_fee? in the code I see the multiplier is 100000000000000. so if the name_fee is e.g. 5 then this would be 0.0005 AE or am I calculating wrong?
this would mean that the initial price for a name with 12 letters would be 2.8657 AE correct?
I’ve put together a simple script in python:
from aeternity.aens import AEName
from aeternity.utils import format_amount
for i in range(13):
print(f"name length {i+1}, price {AEName.get_minimum_name_fee('x'*(i+1)+'.aet')} ({format_amount(AEName.get_minimum_name_fee('x'*(i+1)+'.aet'))})")
this is the result:
name length 1, price 570288700000000000000 (570.2887AE)
name length 2, price 352457800000000000000 (352.4578AE)
name length 3, price 217830900000000000000 (217.8309AE)
name length 4, price 134626900000000000000 (134.6269AE)
name length 5, price 83204000000000000000 (83.204AE)
name length 6, price 51422900000000000000 (51.4229AE)
name length 7, price 31781100000000000000 (31.7811AE)
name length 8, price 19641800000000000000 (19.6418AE)
name length 9, price 12139300000000000000 (12.1393AE)
name length 10, price 7502500000000000000 (7.5025AE)
name length 11, price 4636800000000000000 (4.6368AE)
name length 12, price 2865700000000000000 (2.8657AE)
name length 13, price 2865700000000000000 (2.8657AE)
so 2.8657AE looks right
The API Gateway for testnet has been upgraded to v5.0.0-rc.4 as by schedule
Important update
Today afternoon there was a last minute change in the aens implementation that was unplanned, the change is about the TLD, it was set to be aet
but it was changed late this morning to be chain
.
It was decided not to change the dates of the HFs, but of course there wasn’t enough time for the SDKs to test the change and release a compatible version today.
What does it mean in practical terms?
If you are currently not using the aens functionality, then the current Lima compatible versions available can be used without problems.
If you are using aens it means that you will have to upgrade to a newer release of the SDKs that implement the support for the new TLD. We will do our best to release the support for the new TLD in a timely fashion so please follow the aeternityTech to receive the latest updates.
can you elaborate a bit more about the reason behind using chain
instead of aet
?
I believe it is a purely “cosmetic” change - a more human-friendly extension. Sounds better to me. @emin.chain ?
Since the domain changes have created some chain effect in the availability of all the components needed to successfully upgrade an application, also the proposed schedule for release/deploy of SDKs and hosted infrastructure has changed.
In particular the API Gateway (at sdk-mainnet.aepps.com and mainnet.aeternity.io ) for mainnet will be updated to v5.0.0 on the 28th of October
both Py and Js SDKs have released an update that address the TLD change, Elixir and Go will follow soon
here the announcements:
https://twitter.com/aeternityTECH/status/1184851630300291073
https://twitter.com/aeternityTECH/status/1184849979870982144
Yes, as we only have one domain, most of the front-ends / gui’s will most likely not show any ending at all. Meaning emin.chain will be displayed only as emin
in most of the gui’s.
Great job, fast fix!
New Elixir SDK version is out with Lima support. You can find the newest version 0.4.0 here.
wrap up:
Node v5.0.0 (Lima HF) is out https://github.com/aeternity/aeternity/releases/tag/v5.0.0:
Supported by:
- Js Release 6.0.0 (2019-10-16) · aeternity/aepp-sdk-js · GitHub
- Py Release v6.0.0 · aeternity/aepp-sdk-python · GitHub
- Go Release aepp-sdk-go v6.0.0 · aeternity/aepp-sdk-go · GitHub
- Elixir Release Release 0.4.0 (2019-10-18) · aeternity/aepp-sdk-elixir · GitHub
Mainnet HF is on 30/10/2019
we from kryptokrauts are were also focusing to support Lima with the upcoming v2.0.0 release. you can follow the progress on our github repo:
v2.0.0 will be released in the near future and will also contain a major refactoring. you can already test the features with the actual snapshot. the documentation will also be updated in the near future and can be found here:
snapshot-integration with maven
<repositories>
<repository>
<id>oss-snapshot-local</id>
<url>https://oss.jfrog.org/artifactory/oss-snapshot-local</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>com.kryptokrauts</groupId>
<artifactId>aepp-sdk-java</artifactId>
<version>2.0.0-SNAPSHOT</version>
</dependencies>
snapshot-integration with gradle
repositories {
maven { url "https://oss.jfrog.org/artifactory/oss-snapshot-local" }
}
compile "com.kryptokrauts:aepp-sdk-java:2.0.0-SNAPSHOT"
we - especially @mitch_lbw - are also actively working on a code-generator which allows you to generate java-classes to interact with your smart contract written in sophia. under the hood those classes will make use of our sdk and provide a really convenient way to interact with smart contracts
yesterday we released a new version of the java-sdk that supports the Lima hardfork:
note: there are breaking changes and we will try to publish an article and an updated documentation as soon as possible