The six major components include the following. > DONs (Distributed Oracle Network) > CCIP (Communication Layer) > RMN (Risk Management Network) > RL (Rate Limiting) > (Lock & Mint / Burn & Unlock) || Burn & Mint > Message "blessing" > Lanes: defined routes from source and dest.

The concept of rate limiting and the L&M / B&U || B&M are more related to ways Hera's utility token can be present on multiple networks at once, as well as ways $Hera's interchain aggregation could utilize CCIP owned lane liquidity for large $ETH transactions. More on that later.

Today I will be primarily talking about DONs, CCIP, RMN, and Message blessing.

Here are some technical details you might find interesting for its messaging. It differs from a single oracle and relayer strategy that other organizations like Layer Zero are implementing. LZ's default solution for their oracle is also another topic for a separate discussion.

If you are interested in those points you can read them from the post linked here. Without further adieu, onwards!

Now that we have covered the important acronyms, lets discuss the life of an arbitrary message / transaction with an attached message, and how it is handled by $LINK's CCIP.

First, the committing DONs pick up the message after finality has been reached on the source chain. It then commits to that message by creating a Merkle tree plus root and puts that into the hash of that message on the contract of the destination side.

The Risk Management Network with its own unique node operators must independently arrive at the same root as the committed DON to "bless" a message before passing it.

If it does not, it invalidates it and prevents it from proceeding. This protects people from security risks such as if the DON is compromised. One example of this is committing a message that never happened to be executed on the destination chain, this isn't possible with CCIP.

An easy step-through can be explained by the following; It waits for source chain finality (independent networks come to consensus) on the source, verifying, validating, and then executing separately. On-top of this...

The RMN acts as risk assessment compliment, which is constantly looking at destination networks, as well as for violations in any of the roles of CCIP, inevitably flagging any discrepancies. It can pause the tx potentially to protect users if necessary.

This is what the risk management network does, it makes sure that the messages are exactly right.

There are two roles which have to come to consensus (The committed DONs and the RMN) to process and agree on a "Blessed Merkle Root," to pass it to the commit store, then to the off ramp contract, and only afterwards will execution happen on the destination side.

At the end of the day transactions are only valuable if the data is accurate and messages can be provably authentic. @HeraAggregator believes that this breakthrough in interoperability can allow for our new use case to blossom and lead the flagship of decentralized swap txs.

There is a bright future ahead for new applications and ideas to be built. Interoperability and frameworks connecting more off-chain services such as AI are radically enhancing as well as unifying what was once isolated networks. The best new apps will sit between all-chains.

If you found this post informative or helpful, please let me know. Thanks everyone!