Cardano hands over core development work to independent team

A code warehouse, a bottleneck. If you have ever delivered software, you must be familiar with this routine. Cardano is trying a different ending.

Instead of having a single company driving core updates, core protocol work is handed over to multiple independent teams and governance guardrails are set up to maintain consistency. This is a major cultural shift for a chain known for its peer-reviewed research and prudent releases.

So what actually happens when the people writing nodes, ledger rules, and tools no longer belong under the same roof?

Editor's note: During the first quarter to the second quarter of 2026, I closely followed Cardano's code warehouse and governance forum, and communicated with two independent teams working on bidding wallets and ledgers. The atmosphere changed from "waiting for IOG" to "which working group has the specification and testing framework." Release notes and consistency kits are more important than branding. Some proposal requests took longer than bidders expected, but the teams I interviewed liked predictable review levels. From a market structure perspective, exchanges mainly require a clearer upgrade calendar and minimum versions, which tells me that coordination factors are still the key to success or failure. -- Darnell Whitaker

Cardano's next phase focuses not only on decentralized block production, but also on decentralization of underlying protocol decisions and implementation.

Historically, Input Output Global (IOG) led most core projects, while the Cardano Foundation and EMURGO were responsible for ecosystem and enterprise-level work. Now, the plan is to decentralize core responsibilities into independent teams that operate under clearer governance standards.

This shift aims to replace the efficiency of a single supplier with an alliance of professional teams, balancing redundancy, peer review and competition for ideas.

Two support frameworks support this transition. First, the governance blueprint called CIP-1694 outlines what on-chain governance will look like in practice, including the roles of principals, delegated representatives, and the Constitutional Council. The specification exists in Cardano's CIP warehouse and has become a touchstone for the community's move towards the so-called Voltaire era.

Second, Intersect-a membership organization designed to manage Cardano's long-term governance and development-is assuming coordination responsibilities, funding flows and working groups. The Cardano Foundation continues to advance standards, education and online health indicators from its nonprofit mission.

How Cardano got here: From IOG to multi-team model

Cardano's basic layer is the product of years of research and development. This pays off in terms of reliability, but also means that one company bears most of the operating burden. Community proposals, gatherings, and governance experiments have accumulated pressure to shift to a broader camp. Intersect was created to formalize this camp, creating forums and working groups that stand between community sentiment and actual code changes.

Governance basics

CIP-1694 outlines the mechanism for how communities, elected representatives, and the Constitutional Council propose and approve changes to the agreement. This is more than just a white paper; it is a set of interfaces that define how decisions flow into the implementation, audit, and release tracks.

Organization and Role

IOG remains important, especially in research and novel protocol work. But the long-term direction is to hand more core warehouses, components and maintenance tasks to teams that are not bound by a single roadmap. Intersect's responsibility is to coordinate, issue proposal requests and ensure that standards are met. The Cardano Foundation focuses on management, documentation and ecosystem reliability inspections.

In terms of tools, components like Mithril-the rapid boot and verification layer of the Cardano node-demonstrate how independent teams can improve functionality without directly touching on consensus. Similarly, Hydra-Cardano's homogeneous state channel stack-evolved while core development was being developed, aiming for edge scalability.

Who does what: Splitting the core protocol

When people say "core", they usually mean nodes (network, consensus, ledger), compilers and languages (Plutus, Marlowe), wallet stacks, and release processes. Splitting these responsibilities must be done with care to avoid users feeling the seams.

Technical Guidance and Ownership

envisions a technical guidance function responsible for setting compatibility requirements, testing standards, and release barriers, while implementation teams compete or collaborate to meet these requirements. Intersect's working groups and committees aim to formalize this function.

Old model vs new model

Domain-Old model (IOG-led)-emerging model (multi-team)

Node and ledger rules: mainly by IOG engineering and mergers-implemented by multiple teams; steering group approves interfaces and releases

Smart contract stack: Plutus/Marlowe roadmap set-language/runtime owned by domain teams; Backward compatibility checkpoints

Testing and Quality Assurance: Internal Pipeline, Community Test Network-Shared Test Framework; Public Proposal Requests for Audits and Fuzziness Testing

Funding and Authorization: Core Company Internal Budget-Authorization for Proposal Requests, Grants, and On-Chain Approval governed by Intersect

Standards and Documentation: Mixed ownership, ad hoc processes-Foundation-led standards with community review and versioning specifications

Governance track: Proposal, review and funding

Decentralized development is inseparable from track. The trajectory is the path through which ideas turn into code and then into policies.

How changes might flow:

An idea is drafted as a Cardano improvement proposal or a working group-wide proposal request.

Stakeholder feedback goes to the public warehouse and governance forum, where representatives express their opinions based on CIP-1694 roles.

Intersect coordinates independent reviews, sets testing requirements, and solicits bids from qualified teams.

Funds are allocated through predefined plans or on-chain decisions related to governance milestones.

Implementation is open; experimental logos are enabled on the test network.

Release candidates have undergone security review and backward compatibility checks.

Governance confirmation was released, and equity pool operators upgraded at a predetermined pace.

This does not eliminate the influence of IOG; it just creates space for other teams to gain influence under shared standards through high-quality work. This structure is visible in publicly available CIP warehouses and Intersect data.

From ideas to mainnet: Delivery without a single boss

The obvious concern is chaos. Multiple teams, multiple moving parts, and no single boss can lead to gridlock. Cardano's answer is to make the release pipeline boring, predictable and audited.

Test networks and release tracks

Cardano keeps multiple test tracks active. Preview is used for disruptive changes. Preprod is used to approach the main network. The track dedicated to governance testing has been used to drill on-chain processes before touching the main network. The focus is not on labeling, but that each change must withstand multiple environments before equity pool operators are required to upgrade.

Safety Net: Hydra and Mithril

Hydra provides builders with a way to extend user flow without waiting for base layer upgrades. This buys time and reduces the pressure to cram risky changes into nodes to meet throughput requirements.

Mithril helps nodes quickly boot and securely verify snapshots, which is especially important when changes are released and many operators need to synchronize from scratch. It is also an example of a discrete subsystem evolving on an independent roadmap while remaining within network-wide security assumptions.

The combination of the two makes it easier for independent teams to improve functionality in their own domain without undermining the stability of consensus.

Implications for builders, exchanges and users

For developers, multiple core teams may mean more frequent, targeted releases. Language updates may be independent of network adjustments, while tool gaps can be filled by professional bodies that respond to proposal requests.

Builder
The benefits are faster edge speeds and clearer specifications. The risk is fragmentation. If the two teams have different understandings of the interface, your decentralized application may work well in testing, but will crash with a small patch. This is where standards, consistency testing, and formal release notes become indispensable.

Exchanges and custodians
In terms of operations, you need to pay close attention to the release rhythm and abandonment schedule. As more teams deliver, the calendar gets busier. Expect stronger communication from the Cardano Foundation regarding upgrade windows and minimum supported versions.

Ordinary users
Most users should not notice much change, except for wallets and decentralized apps that are updated more frequently. The bigger story is resilience: If one team encounters delays, other teams can keep the pipes flowing.

Milestones to watch for the coming year

If you are tracking the handover process, here are practical signs of actual progress.

Milestones-What to Focus on-Why It Matters

Formalization of the Constitution/Council: Clear documentation of governance roles and veto/approval powers (Per CIP-1694)-Define who can block or approve changes

Independent proposal request grant: Intersect publishes core components Successful bidder (e.g. wallet API, ledger rules)-proving funds are tied to delivery code, rather than just proposals

Warehouse management diversification: Maintainer files show more non-IOG ownership in critical warehouses-demonstrating true decentralization of code paths

Coordinated mainnet release: Multi-team features implemented in a predictable upgrade without faults-Verify governance and test pipeline

Security review rhythm: Regularly publish third-party audit and fuzzy test reports before release-Prevent decentralization from weakening security

Risks and places where things can go wrong

Interface drift: The two teams implemented the same specification in a subtle incompatible way, causing abnormal behavior of decentralized applications.

Governance deadlock: Proposals stall between committees and representatives, causing delays in emergency repairs.

Funding mismatch: Critical maintenance work is lost to fancy features during the proposal request cycle.

Security regression: More mergers and faster pacing increase the attack surface, but not matching audit depth.

Operator fatigue: Equity pool operators face more frequent upgrades and unclear minimum versions, increasing the risk of chain splitting events.

Dispersion of responsibility: When problems arise, the owner is unclear, slowing down the event response.

Decentralization is not free. Without strict specifications, strong testing, and clear ownership, multi-team development can turn single points of failure into many glitches.

FAQs

Is IOG withdrawing from Cardano?
No. IOG remains a key research and engineering contributor. The change is to broaden core development to allow multiple independent teams to own various parts of the stack under shared standards, rather than having a single vendor do most of the work.

What is CIP-1694 and why is it important?
CIP-1694 is a governance specification that outlines how Cardano stakeholders, representatives and the Constitutional Council interact to approve agreement changes. It is the policy layer that makes the multi-team development model feasible.

Who coordinates the independent team?
Intersect, a membership organization, is positioned to coordinate working groups, issue proposal requests and help coordinate releases. The Cardano Foundation provides support through standards, documentation and ecological readiness.

Will development get faster or slower?
Both can occur. Independent teams can work in parallel and accelerate specific functions, but governance and compatibility checks can increase the time to final release. Over time, predictable rhythms usually emerge.

What impact does this have on decentralized application developers?
Expect clearer specifications and possibly more frequent SDK updates. The cost is keeping up with compatibility instructions and test vectors provided by the guidance group or maintainer.

What should equity pool operators and exchanges pay attention to?
Pay attention to official release notes, minimum supported versions, and upgrade windows. As more teams deliver, communication between the foundation and the steering group becomes even more important.

Is this unique to Cardano?
No. Several networks have shifted from single-company development to multi-team or fund-led models. Cardano is characterized by extensive use of formal norms and community-defined roles to maintain the conservatism of consensus change.