Is there an updated roadmap? Some people have been asking in telegram chat and it would be nice to have.
8 Likes
Good question. I would be interested in having ANTs (æternity native tokens). I saw on GitHub we already worked on the specification of ANTs on a specific branch: protocol/tokens.md at native_tokens · aeternity/protocol · GitHub
I would like to bring up that topic again. For me AEX-9 is interesting but as far as I know it won’t be possible to deposit/withdraw AEX-9 based tokens into/from our native state channel implementation. That’s why I hope we will see ANTs in the foreseeable future 
But before that happens I hope to see [Withdrawn] State Channel mobile client being implemented
The 2nd thing I would like to discuss is the possibility to become a registrar of subdomains in the naming system.
It might also be good to think about a better/improved auction mechanism for AENS names. For short names it could take years for auctions to be finished right now and we always see the current bid. If possible we could introduce a vickrey auction mechanism as mentioned in the documentation:
These are the main topics for me personally right now 
Edit:
- the main priority in my point of view should be to provide tools to make the usage of state channels as seamless as possible and production ready
4 Likes
That is some good tech to be working on. It would be good to lay it out in an easy-to-understand way so average people who come across AE can see the direction and that the development is going strong
1 Like
Hi, marc0olo .ant is the upgraded version of aex-9, or the two independent versions?
There is a fundamental difference between ANTs and smart contract based tokens like e.g. the AEX-9.
ANTs:
- part of the core protocol (like names and oracles)
- the rules what functionality such tokens can have is defined in the core protocol (mint, burn, …)
AEX-9:
- created by deploying a smart contract
- very flexible because you as developer can define your own rules and add custom logic
Now why do I want ANTs? I think it will be important to be able to deposit/withdraw tokens (not only AE) to/from aeternity state channels.
As we know aeternity state channels are also part of the core protocol. Therefore the implementation has no knowledge about AEX-9 and other smart contract based tokens and thus it won’t be possible to deposit AEX-9 tokens into (native) state channels.
As far as I know this could only be achieved if we introduce aeternity native tokens (ANTs).
3 Likes
this would also be the case with the proposed native tokens: Native tokens RFC WIP by happi · Pull Request #416 · aeternity/protocol · GitHub
3 Likes
yes in regards to rules we would still be quite flexible that’s true. I just meant it wouldn’t be possible to introduce additional custom logic or would even that be possible by linking smart contracts to the ANT?
exactly, they can work a little bit like generalized accounts, or could even be wrapped in other contracts
5 Likes
wow, that would be amazing!!!
I see superhero is asking for suggestion with regards to the next topic. I think you would be a good speaker and it would be a topic i would like to watch
1 Like
I second that notion
1 Like
I definitely vouch for the native tokens, too, and proposed the oncept of attaching contract logic to ANTs to people that are unfortunately not longer with us one year ago, but currently, we unfortunately we do not have technical expertise for this anymore. ANTs would allow us to create and transfer an amount of tokens on mainnet that is high enough to be considered scalable, as the gas costs are estimated to be a tenth of what a contract-based token now takes to transfer. The fact that on such basis a stable token could be created allows the state channels to be actually useful for payments, because the currency everything is settled with in the channel is not subject to value fluctuation. You and your favourite supermarket could have a statechannel open forever, just withdrawing every now and then. For your daily purchases, you would just pay using the channel and that’s it.
The vision that people were promised originally: Decentralized scalable payments via blockchain.
sad to hear that. is there a chance that they will dive into that topic again?
Hyperchains, Hyperchains, Hyperchains
Much better than any native token anyways
totally different topics? hyperchains have nothing to do with native tokens?! are core-protocol state channels useful without being able to use native tokens in your opinion?
1 Like
honestly said I can’t understand why we are talking about hyperchains without having state channels production ready yet.
1 Like
Well, they are production ready to a specific degree. The developer adaption ecosphere isn’t just there yet. Like with the Sophia language - was there since 2018, but a tool to program stuff with it in a productive manner came a bit later… 
yes they need to be usable on mobile e.g., too. currently there are too many unknowns for the people that might be interested in jumping in and developing applications that make use of state channels
I get your point and I have resigned myself to it. I just don’t understand why we switch the focus to another solution like hyperchains when devs still aren’t able to make use of state channels in a convenient way. and at this point we aren’t talking about ANTs which are far away at the moment.
I’m afraid people won’t be able to take these developments (even if they are cool and necessary on the core level) seriously anymore if already existing features can’t be used properly.
1 Like
So hyperchains aim to replace state channels to some extent? Why do we need state channels then?
Do you think state channels are still required then? If so what’s the purpose of state channels if I can “only” deposit and withdraw the native token of the respective (hyper)chain to them?
I also liked the idea of virtual state channels. But it seems like we are dropping that idea now, right?
Where does the need for hyperchains come from? Starfleet projects?
1 Like