Dear Kusama Council,

We are moving forward at lightning speed, twelve parachains already in. We want to take the next steps, to bring some chaos and create meaningful cross-chain use-cases.

As we know, parachains currently only support HRMP to communicate with each other. However, the current parachain configuration requires each parachain to bond funds for the duration of the opened channel. This bond prevents spam and unnecessary channel opening since the relay chain processes each channel and its message queues before being passed back to the parachains.

To gain access to bi-directional communication between two parachains, both need to open outbound and accept an opening of an inbound hrmp channel. The cost of opening such a channel is roughly 67 KSM. That means 67 KSM for an outbound and 67 KSM for an inbound channel. Both parachains need to post this bond for a total of ~270KSM.

All of the people we were talking with agree that cross-chain communication should be a part of the base functionality of a parachain in some way or form. However, with almost $900 000 000 in value locked for the slots, asking for the additional bond from teams seems like an unnecessary expense that could be used for the development.

The current messaging implementation, however, asks for some antispam protection.

To understand the problem, let's look at the measures HRMP messaging uses to keep in line. There are five settings in total. *hrmp_max_parachain_outbound_channels* and *hrmp_max_parachain_inbound_channels* corresponding to max number of channels parachains can open regardless of the bond size, *hrmp_channel_max_capacity*, *hrmp_channel_max_message_size* and *hrmp_channel_max_total_size* correspond to maximum amount of queued messages and max message byte size and the total size of queued messages in one channel. There are additional limits on the message queue size from one parachain imposed by the relay chain. Given the currently set constraints, it seems like Kusama will handle the load just fine.

That being said, the bonds for the parachain slots should be more than enough to provide guarantees for chains not to misbehave or keep their users and functions in check.

**Therefore, in the name of the Kusama parachain teams, we propose to lower the bond required to 5 KSM for each channel, respectively.**

**We would love this proposal to be fast-tracked to start utilizing the channels as soon as possible.**

This bond, in our opinion, will still make chains think about opening a channel. In combination with the limits set above, this should make a safe playing field for conducting an optimal amount of chaos. Once we start seeing problems, we can change these settings with another proposal. Until then, let's do what we came here for.

Looking into the future, parathreads are a different beast. These do not put any collateral into an auction and should be posting security bonds for opening channels. This bond should be calculated based on the cost of spamming the relay chain or other parachain.

We've also compiled a list of possible upgrades to these mechanics that should make this more transparent and fair, some of which should not be hard to implement:

- The bond should not be static. We should instead create a bond that is based on throughput: message size * queue size (or max total size)
- The channel number should not be limited. The limit or price of extra slots should be based on the channel throughput and crowdloan bond of the parachain
- We should allow parachains to lease their unused messaging space to each other. In this case, parachains that don't need so many channels will not waste space for parachains that need to communicate with everybody.

- The Kusama Council wants to create cross-chain use-cases and improve communication between parachains.
- Currently, opening a channel between parachains requires a bond of 67 KSM for each direction.
- The Council proposes to lower the bond required to 5 KSM for each channel.
- They believe this lower bond will still make chains think about opening a channel and create a safe playing field.
- They also suggest possible upgrades to make the system more transparent and fair.

#1056 HRMP Channel configuration