Thinking about State Channels


Hi everyone!

Within æternity, we have put an extra focus upon an important feature of the æternity Blockchain: State Channels. We would love to hear your ideas regarding possible use cases, implementations and maybe even possible partnerships! :muscle:

State Channels are two-way interaction channels between two parties. State Channels make it possible to execute smart contracts off-chain, without fees, while keeping the same level of security that the blockchain already provides. Find more information how to use State Channels in our Introduction to State Channels here.

You can think about use cases regarding messaging, payments, streaming, gaming, etc. If you think you have a good idea, don’t hesitate and comment here! :slight_smile:

Best wishes,


Streaming is very promising. There are a lot of players in the world. It would be interesting


Awesome~how about off-chain file transfering?

Is there a test for the stability and efficiency of file transfer in channel?


Is privacy achieved if I open a state channel to send one transaction? I know what happens inside is private but are the end result addresses shown publicly?


Yes, I agree! What kind of streaming service you think would be interesting?


Well, the old whitepaper mentions API micropayment as an application of state channels… for Ethereum there are similar systems such as machinomy. Some concerns I have about this are:

  • What is the advantage of micropayment channels from the API provider’s perspective, compared with the traditional solution of paid API accounts + a constant authorization token being sent with each request?

  • One naiive way to implement API micropayment with AE is: First the customer opens a channel with the service provider, and then with every API request, customer sends a new signed channel state, which grants the provider the total cost for all previous requests plus the current one. Provider also keeps track of the amount the customer owes him and processes a request if the request grants him more than the provider thinks he is owed. Problem here is it turns something stateless - a HTTP request / reply - into a stateful network protocol. The process making the request needs to know how much the provider is owed in total.

  • Alternatively, on each API call the user could send a payment token (a string), whose hash is hardcoded into a contract that lives in the channel. The provider could redeem the tokens at the contract, in any order, for payment. One token would be worth one call. The problem here is that a force progress is likely to cost more than a payment is worth… so this only kicks the can down the road… the parties still need to exchange signed channel states that represent how much the service provider is owed… so its the same as the above option just more complicated?

  • The old WP says something about “API micropayments enabling new types of business”. I wonder what you had in mind then?


Hi @Liu
Since an encrypted network connection is persisted between participants, it should be really stable but since data is split into messages and every message is encoded and subsequently decoded onn the other side, it will require some more computing power than just sennding the file.
This is not tested so I don’t have any numbers :slight_smile:


In order to open a state channel off-chain, you need to lock some tokens in it. To do so you are posting an on-chain transaction with your pubkey, the amount you’re dedicating to the channel, the pubkey of the other party and the their initial channel’s balance. So yes, currently the other participant’s pubkey is shown publicly. This is to change once we have virtual channels and a channel’s network - then you would be able to open channels in a more private manner.

Note that although channels do provide a certain level of privacy, at this point they shall not be considered private: if a dispute arises between the parties and one of them decides to use the blockchain as an arbiter - the latest off-chain state becomes public. This could be further improved with some zero-knowledge proofs, but those are yet to be discussed.


Hi @bakkhos

I find micropayments a really exciting feature. You are completly right that at any point of time both the user and the service provider must know their balances inside the channel, but this is part of the channel’s protocol anyway. In order to make this practicle, the:

  • client needs some software that handles this for him. Think of a wallet
  • the service provider needs software that is channel’s aware that produces tokens on demand

So whenever the client requests a new API token, this request consists of a some sort of a micropayment inside the channel: modifying participant’s balances or/and some off-chain contract’s balances. This is co-signed off-chain transaction. Then the service provider makes another off-chain transaction providing the requested new token and claiming the amount locked for it. It is a matter of a business model if this token can be used a couple of times or just once.

You are completly right that in some cases when there is just a few aettos locked in an off-chain contract, a force progress will be too expensive and might not be viable. It is a similar situation if one wants to force progress a really big contract - this could require much more gas to store it on-chain than one might eventually get out of the contract itself. This is up to the participant to decide.

Regarding the new types of business - I was not part of the team writing the paper, so I can speculate what they had in mind. From talks with them, I could think of some examples:

  • Video/music on demand where you pre-pay for the next few seconds
  • Paying/Getting paid for services per second
  • Paying your rent/mortage/bills per second

All the things we are used to pay/get paid on a regular basis could easily be broken down into smaller intervals. The only reason one gets a paycheck once a month is it is too cumbersome to make it every day for example. But with channnels it is easy to achieve.


That’s nice, thank you!

Your design is imaginative~ I’m learning deeper.