A new subscription can be implemented by this module: SendTx confirmed. Tx send by the SendTx module that are confirmed (or finalized) are notified on this subscription.
It avoids to call getSignatureStatuses in a pull mode.
### SendTx
Manage the whole send Tx process. Represent the current Lite RPC process.
Implements the sendTx call.
### History
Manage history function like getBlocks.
A special use case is the getSignatureStatuses because on process its the Consensus module that provide tha data.
### Cluster
Manage cluster information.
Implement the call: getClusterNodes
Provide the subscription: cluster info.
### RPC
It's an entry point for all call and dispatch the call to the right function.
Module organization can change depending on the deployment needed. For example several validator node can be started to add reliability. To ease this association between module and server installation, module communication will be done mostly via asynchronous message. This message propagation and routing will done by the Stream module.
Module register to it to get notifified and send new message to specific entry point.
The logic organization will be.
```mermaid
flowchart TD
SendTx("Send Tx
[Module]
Send Tx to cluster")
History("History
[Module]
Get Block and Tx")
Cluster("Cluster Info
[Module]
Cluster data")
Consensus("Consensus
[Module]
Manage realtime produced data
by the validator")
Stream("Stream
Manage message routing
between module.")
Consensus-- "Send Full Block" -->Stream
Consensus-- "Send Block Info" -->Stream
Consensus-- "Send Slot" -->Stream
Consensus-- "Send Leader Schedule" -->Stream
Consensus-- "Send Epoch info" -->Stream
Consensus-- "Send Sent Tx confirmed/finalized" -->Stream