# Managing a Shared Ledger: New CIP-Like Process? **URL:** \ **Category:** Node Development\ **Created:** [28 April 2025 11:47 UTC](https://forum.cardano.org/t/managing-a-shared-ledger-new-cip-like-process/145575 "2025-04-28T11:47:35Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![JSHyCS](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/jshycs/32/84804_2.png) [@JSHyCS](https://forum.cardano.org/u/JSHyCS)\ **Post date:** [1 May 2025 13:36 UTC](https://forum.cardano.org/t/managing-a-shared-ledger-new-cip-like-process/145575/7 "2025-05-01T13:36:12Z")
> [@ch1bo](#): > > @JSHyCS Do you know about [CIP-84](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084) (and linked CIPs)? I didn’t and just read it now! > > I think it does a very good job of characterizing how ledger changes need to be a CIP or not. See section for example [What merits a ledger CIP?](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084#what-merits-a-ledger-cip) Yes, I am familiar with CIP-84, I reviewed it when submitting my own CIP candidate for a ledger change recently. To be clear, I am not suggesting that we totally abandon CIPs for ledger changes. I think ledger changes can be documented as CIPs, I just think that the process for review/approval would be significantly different enough from non-ledger CIPs it may make sense to identify them separately. > [@ch1bo](#): > > I think the key issue at hand is that **changes not covered by a CIP** are not easily available for standardization across multiple implementations. In my ideal world, any change to the ledger would be covered by a CIP. In practice that may be hard to achieve, but I think we should strive to have hard fork change logs simply be a list of implemented CIPs (or whatever name we give a new process, if different enough). > [@ch1bo](#): > > I’d like to propose the [Cardano Blueprint](https://cardano-scaling.github.io/cardano-blueprint/) initiative to incubate an improvement to the non-CIP part of maintaining a ledger. While it is in it’s early stages (especially the ledger parts), the aim would be to have neutral ground to experiment with how we could try to avoid issues like [CIPs#1028](https://github.com/cardano-foundation/CIPs/issues/1028). So far I know of these two relevant issues: Yes, please! I (as you know) am a big fan of the blueprint project and I believe we should really put a lot of effort into maintaining it as a central place for knowledge sharing. > [@ch1bo](#): > > What other steps could we take to create an **accessible** , **consistent** view of how the ledger should work in an **implementation-indepent** way? That is an excellent question which I think will have constantly evolving answers. @arnaud has organized a poll to select a time for a first “Node Show and Tell” meeting where node maintainers can meet to discuss open-space style topics. I think this meeting is a great place to start to define a process for this kind of a process, as well as identifying other steps we can take to support node diversity. I hope anyone reading this that is passionate about node diversity attends! > [@Node diversity workshop - April 2025](https://forum.cardano.org/t/node-diversity-workshop-april-2025/145248/5): > > I have created a poll to select a date and time in the second half of May for an online follow-up workshop. My idea is to facilitate this just like an open-space, with topics being proposed asynchronously before the event starts and filling the allocated time slot. The main difference being there will be a single track. I have proposed 2 time slots per day that should accommodate Europe and America TZs. If there’s a need, we could try to cover APAC in a future session? The exact times can be ch… --- _[View the full topic](https://forum.cardano.org/t/managing-a-shared-ledger-new-cip-like-process/145575)._