Blog

This guest post was authored by Strangelove Labs team members Reece Williams and MarkAnthony Vogel. Learn more about the authors at the end of this post.

The inception of IBC (the Inter-Blockchain Communication Protocol) marked a significant milestone in the blockchain space, bringing forth a protocol that allows for seamless communication and data transfer between blockchain networks. The early stages of IBC development have been rooted in the ibc-go repository, laying the groundwork for the interoperability that the protocol promises. As the scope and complexity of ibc-go expands, a natural need emerges—to distribute the evolving work across diverse teams actively contributing to IBC's growth.

In response, the IBC community introduces the ibc-apps repository, a centralized hub designed to enhance the discoverability of IBC-related applications. It functions as a pivotal platform where contributors can collaboratively work on IBC, fostering a more organized and accessible development environment.

Applications are self-contained units that handle specific tasks using their own set of rules. These tasks include functions like communication, security, and the organization of data. The core IBC handlers make sure that everything follows the rules of IBC, but they don't handle application-specific details. These IBC applications are categorized into two varieties: modules and middlewares. 

Modules enable data packet exchange between IBC-connected chains that support a protocol standard (Cosmos/IBC ICS standards). Instead of re-implementing core IBC details (such as clients, connections, and proof verifications), modules free you to focus on writing the IBC app logic. This app logic is then executed when a new packet is sent or received from a port (i.e., a connection between 2 chains) to be handled within the module’s specification. Current modules include interchain-accounts, async-icq, and token transfer.

Middlewares depend on a module and add extra processing between the packet data and the chain. Multiple middlewares can be chained together to expose the logic and interaction with the chain’s underlying features, like an API. Packet-Forward-Middleware is an example that extends the functionality of IBC’s ICS20 token transfer protocol. This middleware sits on top of the current token transfer’s module to re-emit packets if they are destined for another chain. This enables an IBC token to transfer from chain A -> B -> C with a single transaction signature. If other middlewares sit within those hops, other logic such as swapping or lending can be performed as shown in the diagram below.

Ibc-apps' primary function is to relieve core ibc-go contributors from the burden of maintaining non-core IBC Applications. Additionally, it extends support to publishers of those other IBC Applications, offering a unified location where apps can be discovered. IBC-Apps welcomes all users of IBC who aspire to unlock the complete spectrum of its capabilities and serve as a guide for past modules and middlewares built for the interchain.

As more IBC applications are produced, it is best for these features to be located in a single area and not within mainline IBC. Doing so allows for the IBC-Go repo to be treated as the protocol-only specification (i.e. the Kernel Space), and pushes any direct user-facing applications to IBC-Apps. Separation of these areas allows for easier maintenance and better discoverability for new additions, while keeping the core protocol lean and focused.

If you want to help out, check out the contributor’s guide on the Github repository! Core team members as well as external contributors can suggest changes or new features. A few things to know:

• Changes in one app won't hold up releases in others.

• Each app can manage its version without waiting for others.

• Teams can only apply changes to the apps they're responsible for, but we welcome contributions through pull requests.

• Each app has its own dedicated directory and continuous integration (CI) pipeline.

• All tickets live in the github issue board and are tagged with the proper project label.

Reece Williams (@reecepbcups_) is a Cosmos protocol engineer at Strangelove contributing to projects such as Local-Interchain, Proof of Authority, and Minecraft to Cosmos-SDK Java integration. Connect on GitHub (reecepbcups) or his website (https://reece.sh) for insights into Reece's ongoing contributions to blockchain engineering.

MarkAnthony Vogel, aka MAV, is part of the business development team at Strangelove, supporting growth across its Lab Services, Validator, and Relayer Businesses. Prior to joining Strangelove, MAV built out the business development function at Lilt.

Strangelove is a development shop and validator building the future of interoperable cryptographic systems for all users. They are core contributors to the IBC Protocol, developing the Go Relayer, the Interchain Test framework, Packet Forward Middleware, Async Interchain Queries, the Horcrux threshold signer, and have contributed to the 08-wasm client and other key releases. Strangelove maintains the ibc-apps repository on Github. Follow them on X at @Strangelovelabs and on Github as Strangelove Labs Inc.