KLYNTAR has a high degree of parallelization due to its architecture. In this regard, interaction with hostchains fits perfectly into this paradigm. We tried to divide the functionality into units, the separate existence of which would seem justified.
Connectors are the first and main component. Thanks to them, the symbiote interacts with the hostchains. A connector is essentially a module that exports the functions necessary to work with the hostchain.
For example, one connector allows you to commit a symbiote to some EVM chain using the smart contract's .makeCommit(symbiote_hash,block_index) function and then check the inclusion using the .checkCommit(symbiote_hash,block_index) function.
The other connector provides functions for working with Solana and an API for working with Solana programs. The third connector will work with Bitcoin and its forks for commits to Bitcoin-like chains using the features of the stack language.
Monitors are the second component. Monitors are your eyes in hostchains and symbiotes. Again, they work in parallel with the core (it can be a separate process, or you can even run the monitor on another machine or container) and monitor the events of other blockchains.
Technically, no sense to split functionality. You can write a single module to interact with hostchain and it can be used by appropriate workflows