Cardano IBC Client Adds Mithril Stake Verification

Cardano Foundation released version v0.1.6 of its experimental Cardano IBC light-client core on October 16. Every new client now starts from a Mithril-certified stake distribution, bringing authenticated stake data into infrastructure for cross-chain messages and token transfers.

Mithril Certifies Cardano Stake Distributions

A stake distribution records how much ADA is delegated to each stake pool. The IBC client uses that information when verifying Cardano blocks and assessing whether the conditions for accepting Cardano’s IBC state have been met.

Mithril certifies Cardano data through signatures from participating stake pool operators. In this implementation, its certificates authenticate the stake distribution associated with a particular epoch, a defined period in Cardano’s protocol.

According to the client documentation, stake amounts were the remaining unsigned component of its epoch data. A distribution supplied by a relayer, the service transporting information between networks, therefore carried a six-hour challenge window.

A certified distribution now takes precedence over an uploaded table. If a Mithril certificate contradicts previously accepted stake data, the client freezes. The release also aligns signature verification with Mithril’s reference implementation and introduces stricter proof checks.

How the Change Affects Cardano IBC Transfers

IBC, or Inter-Blockchain Communication, is a protocol for exchanging messages and tokens between blockchains. Cardano IBC Incubator develops Cardano’s implementation, including components supporting fungible token transfers.

A light client runs on the receiving chain and checks information from another network before an IBC message is accepted. For Cardano, this involves following blocks, verifying their producers, and gathering sufficient evidence through subsequent block production.

A matching Mithril certificate removes the stake-verification wait. Later epochs without that certification remain subject to the challenge process.

Other acceptance requirements continue to apply. The current model requires at least 24 blocks built after the observed block, at least five qualifying pools, and a specified stake threshold. Reaching the minimum block count alone therefore does not guarantee acceptance.

Individual transfer times still depend on block settlement, client updates, and IBC message processing.

Cardano IBC Deployment Remains Experimental

The repository continues to describe the project as experimental software that is incomplete and insufficiently tested for a production bridge. Developers can test token transfers, including test ADA, while the implementation’s security also depends on configured data sources and acceptance parameters.

A participating Cosmos chain must integrate the Cardano client and explicitly allow its use. The new core was released alongside adapters for two supported ibc-go versions.

Existing clients using the former inline storage format must be recreated before the host chain upgrades to the new module.

Operators establish an initial trusted Mithril configuration when creating a client. Initialization completes only after the imported stake distribution matches a verified certificate, making authenticated stake data a required starting point for the client’s subsequent cross-chain verification.