Discussion at [CIP meeting 113](https://hackmd.io/@cip-editors/113) (Tuesday 10 June 2025 (4PM UTC))
- notes taken by @rphair - please correct & modify as necessary

### by topic & speaker (not always chronological)

on basis of coming from Amaru: "frustrations" (Josh is working on Ledger for Amaru)

- sparse documentation on changes to the Ledger: not indicated when in hardforks
- not documented before - often only after the hardforks
- solution \[already seen on Forum\] Hardforks should be "list of CIPs"
- each CIP is self-descriptive, and will provide both consensus and announcement of any changes.
- Ledger & Consensus & Network would be "shared resources" that are easy for those teams to contribute CIPs for.

standards process changes?

- ERCs are a specific "category": ERC are application standards, while EIP are core/protocol standards.
- Josh finds "split" useful because core and application stuff isn't mixed together...
- In theory we would have a (third?) category for Ledger with its own documented processes around hard fork element documentation, etc.
- Ideally, "everything should be a CIP" but convincing Ledger to do exactly that would be a problem... therefore Andre's notion of categorisation might be only way to make it work in practice.

my own proposal, two-fold:

- get complete taxonomy & process, if different from mainstream, applied to each one
- get list of committed subject matter experts (Matthias comment = "champions") to provide the \*real\* peer review component, which is *review*.

what will make it work?

- IOG needs to buy into this process... "if not, then 'all this work is for nothing'" and we have to rely on opt-in.
- Community standards are inherently opt-in, but but core/protocol changes opt-in is considered more mandatory (according to Josh... while Thomas says it's more flexible)
- Thomas also feels confident IO has been supporting the CIP process all along with commitment to produce CIPs and to honour them.

Thomas: Naturally has check & balance of governance process:

- IO is open to community "flagging" difference between proposals & their implementations
- Hard forks themselves also require (from multiple sources like dReps) endorsement... which is effectively an "opt-in"
- IO is also in the process of improving things... and likewise it's understood Josh & others suggesting "reform" is not "combative"
- therefore, changing the CIP process might not be what actually causes things to get better... but just time, maturity, and increased involvement from key workers.
- Results of more determined CIP participation is apparent in Leios & Peras CIP/CPSs which contain formal descriptions but also common language equivalents.

Adam points out additional problem: academics vs. engineering (seen long time in Cardano)

- Academically a standard may appear trouble-free but still have divergences between details of each implementation.
- Therefore even if specs didn't change, the engineering process produces changes.
- Ethereum has bit of advantage in *periodic* hard forks, rather than forking around particular features... which for Cardano would help to keep the multi-node environment "all on the same page" at periodic intervals.

#### Resolutions (things that were generally agreed & not disputed):

- We can see improvements by increased engagement / usage of the CIP process as it already exists, even if the process isn't changed.
- We can look out for non-CIP processes to communicate better about changes.