Core contributor pathway is underspecified — gaps, missing resources, and structural feedback

[disassembler]

The pathway does good work mapping the dApp builder and infrastructure operator journeys. This issue focuses on a specific gap: the path to becoming a core protocol contributor is largely absent, and what little exists is structurally misleading. The following is a detailed audit with concrete suggestions.

---

1. "Core protocol" is buried as an afterthought, not a parallel track

The current structure places CORE under ADVANCED, which itself sits after MAINNET → COMMUNITY → CATALYST. The implied message is: build a dApp, ship it, get funded by Catalyst, become famous in the community, then become a core contributor.

This is backwards for a significant category of developer. Systems engineers, compiler writers, protocol researchers, formal methods practitioners, and Haskell developers don't start by shipping a dApp. They start by wanting to understand the machine at a deep level and contribute to it directly. There is no entry point in this diagram for that person.

Suggestion: Add a parallel track from WEB2 [Haskell/FP or Rust or Systems] → Core protocol contributor that exists alongside the smart contract, frontend, and infrastructure tracks — not downstream of them.

---

2. The Haskell path terminates at Plutus, not at the ledger

The diagram maps Haskell/FP → Plutus Pioneer Program → Core protocol contributor. This conflates two entirely different things. The Plutus Pioneer Program teaches you how to write on-chain validators. It does not teach you:

• How cardano-ledger is structured
• The STS (small-step semantics) framework that governs all ledger rules
• How consensus, ledger, and network layers interact in cardano-node
• How to navigate the cardano-ledger, ouroboros-consensus, or cardano-api repositories
• How to write a meaningful first PR to any of these repos

A developer who completes the Plutus Pioneer Program and then tries to contribute to cardano-ledger will find themselves completely unprepared. The Plutus Pioneer Program is, at best, a prerequisite for one narrow kind of dApp work. It should not be represented as the entry point to core protocol contribution.

Suggestion: Distinguish clearly between "Plutus smart contract developer" and "ledger/consensus protocol contributor." These are different jobs with different knowledge requirements. The latter needs its own resources.

---

3. The formal specification is completely absent

Cardano has formal specifications: the Shelley, Mary, Alonzo, Babbage, and Conway ledger specs (LaTeX/PDF), the Ouroboros family of papers, and ongoing formalization work. These documents are the ground truth for what correct behavior looks like. Any core contributor working on the ledger or consensus layer needs to be able to read them.

There is no mention of these documents anywhere in the pathway or resources. For a would-be core contributor, not knowing these exist is a serious gap. Not knowing how to read them — or that reading them is even necessary — is worse.

Suggestion: Add a "Formal specifications" entry in the Advanced / Core section pointing to the ledger spec PDFs and Ouroboros papers. Even a brief note explaining their role ("these define correctness; the Haskell implementation must match them") would help orient newcomers.

---

4. The CIP process is listed as an outcome, not a learnable skill

"CIP author" appears as a label on the CORE node — something you become, not something you learn how to do. In practice, writing a CIP is a distinct process with its own conventions, stages (Proposed → Candidate → Active), editors, working groups, and political dynamics. Many valuable core contributions take the form of a CIP rather than code.

There is also no explanation of what kinds of things become CIPs versus what goes through the normal PR/issue process on cardano-ledger or ouroboros-consensus. This ambiguity is a real barrier: contributors don't know whether their idea belongs in a CIP, a GitHub issue, an Intersect working group, or a Discord thread.

Suggestion: Add "How to contribute a CIP" as a distinct learning resource. The CIPs repository has a process document, but it assumes familiarity with the ecosystem. A guided explainer — what CIP categories exist, what stage-gate criteria look like, who reviews them, how long it takes — would significantly lower the barrier.

---

5. Intersect MBO is named but not explained

"Intersect MBO" appears twice in the diagram (Advanced/Core and Governance). There is no explanation of what Intersect is, what its working groups do, or how an external developer engages with it. Someone reading this pathway for the first time has no idea whether Intersect is a company, a DAO, a standards body, or a GitHub org.

More concretely: Intersect runs working groups that directly shape which CIPs get prioritized, which protocol changes get funded, and how community voices are collected before hard forks. This is a significant entry point for core contribution that doesn't require Haskell fluency, yet it's invisible in the pathway.

Suggestion: Add a brief description of Intersect's working groups and how to find and join them. The intersectmbo.org link exists in the resources but without any context.

---

6. The Rust-track core contribution path is misclassified

The diagram places Pallas and Dolos under "Advanced / L2 / ZK" alongside Hydra, Mithril, and zero-knowledge proofs. This is wrong in two ways.

First, Pallas and Dolos are not L2 technologies. They are Rust implementations of core Cardano protocol components — a node, a chain sync implementation, CBOR codec, ledger types. They are infrastructure, not L2.

Second, for a Rust developer wanting to contribute to the core of Cardano, Pallas is the most accessible entry point — more accessible than cardano-node (which requires Haskell) and more accessible than ouroboros-consensus (which requires deep Haskell and academic background). Hiding it in an advanced L2 bucket means Rust developers looking for a core contribution path simply won't find it.

The same logic applies to a growing set of projects: alternative node implementations, chain indexers that implement ledger rules, conformance test harnesses written in non-Haskell languages. These are legitimate core contributions and have no representation in the pathway.

Suggestion: Move Pallas/Dolos into the Infrastructure track with a note that they are Rust re-implementations of core protocol components. Add a distinct entry under "Core" for "Alternative implementations / conformance testing" with Rust and other language paths.

---

7. Testing and conformance infrastructure are completely absent

One of the highest-value and most accessible forms of core contribution is writing tests — particularly property-based tests (QuickCheck, Hedgehog) and conformance tests that verify an implementation matches the formal spec. The cardano-ledger repository has substantial test infrastructure, and there are ongoing efforts to build cross-implementation conformance test suites.

None of this appears in the pathway. There is no mention of:

• Property-based testing with Hedgehog or QuickCheck in the ledger context
• The conformance testing effort (testing that alternative implementations match Haskell)
• How to run the test suite for cardano-ledger
• What "good first issues" in the testing area look like

This matters because testing is often where new contributors start. A contributor who is not yet confident enough to implement a new ledger rule can still write a test for an existing one. Without this being visible as an entry point, contributors skip it.

Suggestion: Add "Testing / conformance" as a named contribution type under Core, with links to the relevant test infrastructure and a note about property-based testing as a specific skill.

---

8. The governance contribution path conflates tooling and protocol

The pathway has a Governance track (DRep, Intersect, DAO builder) and separately lists GovTool and Agora as governance tooling. These are merged in a way that obscures an important distinction:

• Governance participation (being a DRep, voting, forming opinions) is a non-technical activity
• Governance tooling (GovTool, wallet integrations, on-chain scripts for DAOs) is application development
• Governance protocol (CIP-1694 implementation in cardano-ledger, the Conway era ledger rules, DRep pulsing, ratification logic, committee expiry) is core protocol work

The third category is entirely invisible in the pathway. Yet someone who understands the Conway era ledger rules well enough to contribute to them has a very different profile from someone who wants to use GovTool to vote as a DRep. These paths diverge early and have almost nothing in common.

Suggestion: Separate governance into its three layers explicitly: governance participation (DRep, Intersect WGs), governance application development (GovTool, Agora, wallet integrations), and governance protocol work (CIP-1694 implementation, ledger rules, test coverage for Conway era).

---

9. There is no "time to first PR" guidance for core repositories

The resources table has useful time estimates for dApp work:

First Aiken contract: 1 week
Full-stack dApp: 4–8 weeks
Plutus/Haskell: 3–6 months

There is nothing equivalent for core contributions. In practice, making a first meaningful contribution to cardano-ledger or ouroboros-consensus typically requires setting up a working development environment, understanding the overall module structure, reading the relevant formal spec section, understanding the STS rule framework, finding an approachable issue, and getting through code review from a small, specialized team.

This is realistically a 6–12 month journey for someone starting from general Haskell competence. Not documenting this creates false expectations and contributor churn: developers attempt it, get lost, and give up without the pathway having been honest about the required investment.

Suggestion: Add realistic time estimates for core contributor entry. Be honest that this is a longer path than dApp development. Include environment setup and repo orientation as explicit learning milestones rather than assumed prerequisites.

---

10. The dependency graph for core projects is nearly impossible to resolve without Nix — and this is never explained

Every core Cardano repository — cardano-node, cardano-ledger, ouroboros-consensus, cardano-api, Pallas, Dolos — has a complex, non-trivial dependency graph. GHC version constraints, C library dependencies, cryptographic primitives, build tool versions, and cross-platform linker flags all interact. Attempting to resolve this manually is not a matter of running the right package manager commands — it is genuinely difficult to near-impossible depending on your operating system and distribution.

Nix solves this problem. A nix develop or nix-shell invocation drops you into an environment where everything is pinned, present, and working. On NixOS specifically, non-Nix builds often do not work at all because the system doesn't expose libraries in the standard filesystem paths that conventional build tools expect — this is by design, not a misconfiguration.

The pathway doesn't mention any of this. A developer who arrives at cardano-ledger, reads "it's Haskell," sets up GHC and cabal via ghcup, and starts trying to build will hit a wall of dependency errors that have nothing to do with their Haskell ability. There is no indication in the pathway that this wall exists, and no guidance that Nix is the tool that makes it tractable. Most developers will attribute the build failures to their own inexperience and give up.

Suggestion: Add a note in the Core and Infrastructure tracks that these projects have complex dependency graphs that are practically resolved through Nix. Frame it accurately: Nix isn't a requirement imposed arbitrarily — it's the tool that makes an otherwise near-intractable dependency problem manageable. Point to nix-installer or devenv as accessible starting points, and note that Nix development shells are the standard working environment for contributors to these projects.

---

Summary

The pathway is well-designed for its primary audience: dApp builders, smart contract developers, and frontend engineers. The gaps for core contributors are systematic, not incidental. They reflect a broader pattern where core protocol knowledge has historically lived inside IOG and has not been made legible to external contributors.

The five highest-impact additions would be:

1. A parallel Core track that is a first-class path, not a post-dApp specialization
2. Separation of "Plutus dApp developer" from "ledger/consensus protocol contributor"
3. The formal specifications as named, linked resources
4. The dependency/environment problem (and Nix as its solution) made explicit for all core tracks
5. Testing / conformance infrastructure as a named, accessible entry point for new contributors