State channels and multy-signed contracts


Hey guys!

In different documents, we find discrepancies in the question of how many parties a state channel can have. The main document in the description of the protocol indicates a restriction of two parties. In posts on the forum and blog, as well as in earlier publications, several (more than two) parties are mentioned. Which option is correct? If there are two sides, how good and cheap is the opening / closing of the multiplicity (thousands and millions) of channels of states from the point of view of performance?
We are asking this in the context of the fact that we will need to redistribute some amout of tokens from one large set of users to one or more another large sets of users like functionality of multy-signed contracts.
Hash-lock mechanism like this is described in aeternity whitepaper, but we can’t find any information about its technical implementation.

Thanks for any help!


Hi @aiii,
You are right that some contradicting descriptions for channels can be found and those address current channels and the vision we have for them.

As for the main net launch - there will be channels with only two participants. There are plans to expand them to a couple of participants but this will be afterwards. Since every state change is to be co-signed by all participants in a channel - it would not be a good idea having millions of participants in a single state channel because if one of them goes offline - no off-chain update can be performed.

As for the price of opening a state channel - it requires a single on-chain transaction. Once opened - participants can enjoy the channel’s off-chain blazingly fast transactions. Closing it requires another on-chain transaction.


If I will create state channel and put there 10000 AE (I can add into this channel, smart contract from other users?)

This words from github AE

Channels can be multiplexed easily, given that each channel has a unique id, so re-using connection does not pose any problems.

This uniq_channel_hash_id I will use in next transaction. It could be real? or State Channel it is just Crypto-WebSocket (Peer to Peer)?

P.S. With respect from Russia)


Hey @Inpakeo,

Thank you for your question, it is forwarded to our dev team.

Best regards,
The AE Team


Hi @Inpakeo,
Thank you for your question.

Channels are much more than a peer-to-peer connection.
Yes, you can put tokens from your balance to the channel. You will be able to do it in a various ways - via a transaction or a contract for example. This will reduce your balance and the tokens will become part of the channel’s balance.
Once the channel is created - a uniq_channel_hash_id is created for it. You can think of it as the channel’s address. From then on, you are to use it in both your on-chain and off-chain transactions regarding this channel. Ex.:

  • The channel is a first class object in AE, so you have a couple of different on-chain transaction types that referrence the channel (by its uniq_channel_hash_id): you can deposit tokens to it, withdraw tokens from it, snapshot it, and close it in a various ways.

  • Off-chain you can transfer tokens to and from the other party, you can both call contracts and etc.

These all have the uniq_channel_hash_id involved, treating it as an independent on-chain entity (which it actually is). From the chain’s point of view the channel is a mutly-party account that has its own special rules for operations and distinct transaction types.

Now regarding WebSockets - channels have 2 parts:

  • Protocol for creating, updating and closing channels on-chain. Those are the expected transactions in order for one to operate a channel on-chain and enjoy its strong dispute resolution capabilities.
  • Various implementations of channels that comply with the bullet point above. These might or might not be based on WebSockets. The important thing is that you can sign a correct offchain transaction, the medium used is not enforced in any way. You could do it even on a piece of paper :slight_smile: Our implementation for channels does use encrypted WebSockets but this is not a requirement, you can use a channel implementation of your own.

If you have further questions, I remain at your disposal.

Best regards,
Dimitar Ivanov