Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?


Failed to load latest commit information.
Latest commit message
Commit time
August 21, 2023 14:12
September 19, 2023 11:00
July 8, 2019 12:31
January 10, 2023 18:11
November 15, 2022 12:41


Haskell CI Nightly CI Haddocks handbook

This repository contains the core components of the network code for the Cardano node. It is a dependency when building the node from the cardano-node repository.

The following graph shows the dependency tree. The top-level package is ouroboros-consensus-diffusion which is part of ouroboros-consensus

  flowchart TD
    A[network-mux]                   --> B[network / Win32-network]
    M[cardano-ping]                  --> A
    D[ouroboros-network-framework]   --> A
    D                                --> E[ouroboros-network-api]
    E                                --> H[typed-protocols]
    G                                --> H[typed-protocols]
    G                                --> E
    F[ouroboros-network]             --> D
    F                                --> G[ouroboros-network-protocols]
    I[ouroboros-consensus-diffusion] --> F
    J[cardano-client]                --> F
    K[ntp-client]                    --> B

   click A "" _blank
   click M "" _blank
   click D "" _blank
   click E "" _blank
   click F "" _blank
   click G "" _blank
   click I "" _blank
   click J "" _blank
   click K "" _blank
   click H "" _blank
  • network-mux - implementation of a general network multiplexer.
  • ouroboros-network-api - shared API between network and consensus components.
  • ouroboros-network-framework - low-level network components, e.g. snockets, connection manager, inbound governor, handshake mini-protocol, network simulator.
  • ouroboros-network-protocols - implementation of all /node-to-node/ & /node-to-client/ protocols. Also contains a testing library which is implementing various applications for testing purposes.
  • ouroboros-network- top-level integration of all network components also defines node-to-node and node-to-client API. It contains the implementation of the outbound governor.
  • ouroboros-network-mock & ouroboros-network-testing - shared testing code.
  • ntp-client - an ntp client (used by cardano-wallet).
  • cardano-ping - a library which implements the core functionality of cardano-cli ping command.
  • cardano-client - a subscription for node-to-client which wants to connect to a cardano-node.


  • monoidal-synchronisation - a small standalone package which contains synchronisation primitives.

Ouroboros-Network Documentation

We have two documents which describe various levels of the networking layer of the Cardano Shelley implementation:

Work progress

On a biweekly basis, we publish updates on cardano-updates. We are also tracking our current work in the Ouroboros Network Project. Our quarterly goals are published in the [Cardano Node Product Backlog][cardano-node-backlog].

For Contributors

The contributing guide is available here. The style guide is available here. The code of conduct is available here.

Ouroboros-Network API

The API consists of three layers:

• mini-protocol APIs, which are GADTs for each mini-protocol under Ouroboros.Network.Protocol (defined in ouroboros-network-protocols package); this hides heavy type machinery of session types. One only needs the Peer or [PeerPipelined] type when one is using runPeer or [runPeerPipelined] function and each protocol exposes a function to create it (e.g. chainSyncClientPeer. There is also API which allows to run a Peer or [PipelinedPeer] with limits (i.e. per state timeouts & per message size limits).

• callback MiniProtocolCb. The callback is wrapped in OuroborosApplication GADT which allows to differentiate the initiator/responder (or client/server) callbacks.

• versioning which is a map from version numbers to the above callbacks and version data (the tricky part here is that version data type can be different between different versions; there is a simple way of building this map using a semigroup). You can use simpleSingletonVersion if your application does not depend on negotiated version data. However, Ouroboros.Network.NodeToNode and Ouroboros.Network.NodeToClient expose API which hides versioning from the caller.

Demo applications

Instructions To run a demo type:
cabal run <DEMO_NAME> --

After -- you will need to pass arguments, when a demo is run without arguments it will specify what arguments it needs.