CPS-???? | Canonical CBOR Serialization Standard

[HinsonSIDAN]

This CPS emerged from community feedback at events like Cardano Builder Fest 2025, where developers identified CBOR serialization fragmentation as a critical pain point hindering ecosystem maturity.

This CPS addresses the growing interoperability challenges caused by non-deterministic CBOR serialization across Cardano's tooling ecosystem. The same logical transaction or script can be encoded in multiple valid ways, leading to different hashes and breaking multi-signature workflows, cross-tool transaction building, and script reference consistency.

Ideally we can establish a canonical CBOR serialization standard that would be adopted across major libraries and wallets, ensuring predictable behavior and reducing the development friction that currently exists when working across different tools.

---

(rendered latest document)

[fallen-icarus]

Thanks for opening this discussion! This topic is outside my area, but I came across this comment (and this one) by @dcoutts a while ago which AFAIU explains the reasoning at the time. The entire Issue thread might be worth a read.

[GeorgeFlerovsky]

FYI @nau @fernweh0

[yHSJ]

Thank you for drafting a CPS about this. You're right, a lack of canonical encoding has definitely been frustrating for many of us Cardano developers, especially those of us working on alternative node implementations (I can speak to my experience working on Amaru primarily). I have only done a quick skim of the content so I won't comment on the particulars in the CPS here right now, but hopefully I will have more time later to sit down and reread it carefully.

But, to give some context:
At the first node diversity workshop, canonical representation of ledger state was heavily discussed since it's needed (or at least very helpful) for many things, including testing and bootstrapping.

Sundae Labs has started work on a conformance testing suite which currently uses the NewEpochState, encoded as CBOR, from the Haskell node but we're eager to conform with a reasonable and appropriate standard there. They currently live in the Cardano Blueprints project, where I assume a canonical ledger state specification would eventually reside, along with a CIP: https://github.com/cardano-scaling/cardano-blueprint/tree/main/src/ledger/conformance-test-vectors (cc: @Quantumplation)

Tweag has received treasury funding to work on exactly that actually, and they have a draft PR open already: #1083 (cc: @nc6 and @qnikst)

[rphair]

@HinsonSIDAN now that this is marked "Ready for Review" we'll add it as Triage which puts it on the agenda for our next CIP meeting (https://hackmd.io/@cip-editors/123).

In the meantime I think it'll be useful to get some co-review with this current CIP candidate (cc @qnikst @lehins @nc6 @Ryun1 @Crypto2099):

• #1083

[Ryun1]

Suggested change

	- Hardware wallets, which require the keys in every map to be sorted from lowest value to highest.

this is one Ive encountered, which was frustrating to figure out

[HinsonSIDAN]

@Ryun1 I did not put hardware wallets in since there is an active standard on it - https://cips.cardano.org/cip/CIP-0021. Perhaps you are referring to this one

[rphair]

@HinsonSIDAN we're leaving this Unconfirmed for now due to lack of current agreement & statements about why such serialisation would be considered "dangerous" (as per #1109 (comment)) even though the node itself is doing this all the time (cc @fallen-icarus @Crypto2099).

@colll78 we collectively recalled that you've posted some things about this issue on X... can you give us the gist of how you stand on the issue & any other points that the community has made about it?

[HinsonSIDAN]

@rphair I am drafting this CPS mostly due to the common perspective I gathered in 2025 Vietnam Builderfest and 2025 UPLC conference in edinburge. I believe it is a pain to vast majority of builders.

I am happy to keep this CPS unconfirmed indeed if that's not a too pain of an issue that people interested to put more comments in.

Tho one more comment / observation. It seems like this issue has bugged so many Cardano developers from junior to middle level, that scares away many potential talents for our community. However, when we get to more senior in Cardano dev, usually we are experience enough to figure out workaround on issues caused by this problem. Like we in SIDAN Lab & DeltaDeFi built some stupidly complicated dev tools for it, where we shared in 2025 Edinburgh UPLC conference

Eventually, no one got interested enough to solve it for others.

Sorry for this week CIP meeting I cannot squeeze time to attend, I would try to share more in next editor meeting. Appreciate the moderation!

[rphair]

@HinsonSIDAN since you've already volunteered to attend the next meeting (https://hackmd.io/@cip-editors/124) as per #1103 (comment), I've also added this one to the agenda: keep in mind that this agenda will be packed due to requests to recap the Leios status, but at least we should have time for you to review the relationships above & reassure the technically oriented editors & observers about the "safety" of CBOR conversion.