State of State Channel æpps. We need more!

Hello everyone,

I have been speaking with the dev team about state channels before and after Mainnet launch. The guys working on this feature have been to numerous conferences dedicated to state channels and have talked with other teams working on this tech (primarily from Ethereum). They are also participating in monthly (maybe more frequent) calls with teams that are working on state channels in other projects.

What I am being told is that æternity’s state channel implementation is much, much more advanced than anything that is currently available in the blockchain space. The primary reasons for this are:

  • State channels are implemented directly on the protocol level (Layer 1), not via smart contracts
  • All relevant research dedicated to state channels has been incorporated
  • State channels have been developed together with the Mainnet, resulting in more “native” interaction between off-chain and on-chain states
  • Other teams need to deal with issues and address problems that æternity’s state channel implementation simply does not have

With all that said, state channels are constantly being developed and we expect to have virtual channels by the time of the next scheduled protocol upgrade in May. Those will allow creating channels with other parities while off-chain. For example, if A has a channel with B, and B has a channel with C, A and C can connect without touching the main chain.

It pains me to see that there still aren’t that many developers who are looking into æternity’s state channels. I believe the reason for this is that we haven’t really showcased them yet by incorporating them into an application.


As far as I know, there are a few possible applications of state channels that the team has thought about. The first one is - incorporating them into the Base æpp, so users can use them for making AE token transfers between themselves. The second one could be accepted as an addition to the first - enabling peer-to-peer chat in the Base æpp through state channels (completely private!), as well as, pure P2P file transfers, and of course - transfers of AE tokens.

I would also like to see æternity’s state channels implemented in a decentralized exchange and I hope the WeiDex guys can do something in this respect.

Generally, I want to see applications! :slight_smile: I know the product team is currently focusing on developing nice dev tools, so we have more people building on AE, but I really, really, really want to see some showcasing of æternity’s technology.

I am convinced that æternity’s blockchain infrastructure is one of the most efficient, and if I may say, most elegant in comparison to anything that is out there.

We just need to demonstrate that to the world.



I created state channel successfully with websock and jsonrpc in local full node, it’s very impressive to do many interesting things in the channel. But later, I tried to create channel through remote full node, failed. And I stopped there.

Maybe a local full node is essential for a state channel aepp?

If we could establish channel through andy public node, even some public node, that would be much more convenient for developers.

1 Like

There are a few things going on in the ecosystem. This was a demo send to me a couple of days ago

Also upcoming is a demo aepp which still has an open PR

And just for nostalgic reasons i’m posting this here too, first state channel test ever:


Please report what failed so we can assist you and also help other people that face the same problem. I’m sure you’ll get support here. Maybe @dimitar.chain can help or someone from the JavaScript SDK team member (like @noandrea)

Edit: i’ve edited the forum title a bit @vlad.chain hope thats fine with you.

I think this is not good for security reasons. Currently the aeternity out-of-the-box implementation requires connecting to a trusted node. I am writing a post that touches that subject as well

1 Like

I also think connecting to any node (and having the option to connect to your own) is a good way forward. This is currently happening in the Lightning Netowork apps - upon installation you are connected to a node, but you can change the node address in settings.

I don’t think making each user run their own node is a good idea from an UX perspective, unless upon installation the aepp installs and runs a node without the user knowing and this happens very quickly.

This can easily be handled by a light client, for example a middleware


Yes, it’s insecure for a remote connection through websocket without encryption.

A proxy with auth could handle it better, I did not go further at this function and truned the basic network communication to ipfs.

State channels are quite complex and there are a ton of race conditions to be handled. A new update can be triggered by both parties, it can be canceled, internet connection can drop, a malicious participant can try to close the channel with some older state and etc. Those can happen any time, in any sequence of events and this imposes a big software development challenge. The Aeternity node’s channels implementation already provides gracefully handling of almost all of the above and solutions are being prepared for the rest as we speak. That’s why at the moment a client is supposed to connect to one’s trusted node via WebSocket connection and when an event happens - the node notifies the client for it. All a client must do is to handle the events that are fed to it.

@Vlad currently if someone wants to build a state channel’s app, one must take care for:

  • opening a channel - it is a set of events the node already handles but those must be handled client side
  • closing a channel - it is a set of events the node already handles but those must be handled client side
  • handling of all of the unexpected on-chain events like hey, Alice is closing the channel with some older state, do you want to do something about it?
  • handling of all off-chain events: Alice proposes a ContractX to be added to your state channels’ state. Do you agree? .
  • signing of both on-chain and off-chain transactions and handling of keys, wallets integration
  • persisting the state locally on the device so if your trusted node suddenly dies - you can still reopen the channel using the latest state

All of those are a lot of work and must be implemented again and again for every new application. What is even worse is various application can implement this in a different manner. In order for me to be sure the application I am using is not cheating me, I must either read its code (esp. disputes related parts) or trust it. I find both approaches bad as none of them takes advantage of Aeternity’s state channels being homogeneous and predictable in their mechanics.

The real issue is we don’t have a generic client.
Something that is going around in State Channels’ world (not just AE) is a generic app that handles all you state channels for you in a predictable manner. This will build proper user experience and no surprises. This is something like the Holy Grail of State Channels. And we can do it.

What we need is an application that is both BaseApp and State Channels aware and can close the gap between those two. We already have the SDK that handles the State Channel’s events so we need just to close the gap. I think the hardest nut to crack here is the user experience.

My suggestion is we extend the BaseApp into a mobile application that handles all the functionality that is already there. Let’s make it state channels’ aware. Imagine the following: you have a single app that handles sending of on-chain transactions and state channels. All Aeternity in a single app, all channels, for all of your accounts.
You want to open a state channel with me? Just scan my code and your application will connect to your node, which will connect to mine, which will connect to me. All easy, all smooth, all transperant. Then there is a pop-up that prompts you on your device to sign the opening transaction. So do I. Then we get another prompt when our state channel opening transaction has enough confirmations so we can start doing off-chain interactions in a safe manner.
Let’s play chess off-chain :slight_smile: We pick a game from a decentralized market and install it in the state channel with a single click. There is a prompt to sign and - voila - we can play chess off-chain now. Or bet on a certain Oracle’s responses.
Each off-chain state channel application can consist of a smart contract and one or more UIs. Although we do share the same contract - the chess that visualises on my phone can be different from the one on your phone and this is great actually. What is even better is an off-chain state channel developer will only write the Sophia smart contract and one or more user interfaces that call this contract’s functions. Just that. No state channels’ event handling, no key handling, no dispute handling. I think this will make it much easier to onboard and develop, while making off-chain applications much more secure and safe.

If I can make a metaphore: let’s build an iOS for state channels, let’s handle all the security issues, let’s handle all the race conditions and let Sophia developers do what they should - build on top of it.

Currently this is an idea that is growing inside my head for quite a while now, so I’d love to hear your thoughts about it.