Cardano Updates

Co-authored-by: Robert Phair <[email protected]>

Co-authored-by: Robert Phair <[email protected]>

Co-authored-by: Robert Phair <[email protected]>

Hands-on verification against Aiken stdlib v3.1 output revealed that
the same blueprint emits both forms in `title`:

- `Option<X>` -> title "Option"  (unparameterized — matches the rule)
- `Tuple<<A,B>>` -> title "Tuple" (unparameterized)
- `Pairs<A,B>` -> title "Pairs<A, B>" (parameterized, with space)

A MUST-rule that says "title is the unparameterized name only" would
declare real Aiken output non-conformant for one specific case while
adding no interop benefit — type identity is carried by the definition
key and `$ref`, not by `title`.

This change:

- Downgrades the title rule from MUST to SHOULD, with a MAY for the
  parameterized form.
- Adds a normative consumer rule: consumers MUST NOT use `title` to
  distinguish entries; type identity comes from the definition key /
  `$ref`. This is the actually-load-bearing constraint.
- Adds a consumer-side tolerance rule: consumers MUST tolerate either
  form on read.
- Rewrites the rationale to explain *why* the rule is SHOULD rather
  than MUST — `title` is not interop-critical.

No change to the definition-key, `$ref`, or tuple grammar rules, all
of which remain MUST.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Future readers of CIP-57 should be able to read the parametric-type
section as part of the original specification, not as an amendment
narrative. Three changes:

1. Drop the intro paragraph that framed the rule as "earlier
   revisions did not prescribe a syntax". The rule is now stated
   directly, as the rest of the CIP states its rules.

2. Rewrite the Rationale "Parametric type naming" subsection from
   change-narrative voice ("we chose", "the original revision did
   not standardize", "reflects what current implementations already
   do") to evergreen design rationale ("Angle brackets are the
   parametric-naming delimiter for three reasons", etc.).

3. Drop the closing paragraph that said the amendment does NOT
   standardise shared types. Mentioning shared types only to
   exclude them brings them into the scope of CIP-57 sideways;
   the section is about generic-type *syntax* and does not need
   to disclaim adjacent topics.

No normative content changes; only framing.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Link the upstream Aiken issue where the parametric-naming convention
was discussed by implementors, rather than the meta-PR proposing the
amendment itself. This matches the pattern of the existing
aiken-lang/aiken#972 link already in the Discussions list.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Per CIP-1 § Header Preamble, the Discussions field "must include a
link to the pull request that created the CIP and any pull request
that modifies it." This is the single front-matter update mandated
by the CIP process for a normative amendment.

No explicit Versioning section is added: CIP-1's Versioning rule
applies to the Specification's *defined artefact*, not to the CIP
text itself ("this does not apply to the CIP text, for which
annotated change logs are automatically generated... as a history of
CIP files and directories"). CIP-57 has no Specification-versioning
section today, and this amendment is purely additive — it neither
introduces a Specification version concept nor changes any existing
schema. PR history + Discussions list are the change record.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

The original CIP-57 names specific implementors only in the
front-matter list, the discussion link, and the "Example(s)" /
"Path to Active" sections — never in the normative spec body or
rationale prose. The first draft of this amendment violated that
pattern by attributing the historical divergence to Aiken (`< v1.1`,
`>= v1.1`) and Scalus directly, and by labelling the keys example
"from real-world Aiken stdlib v3 blueprints".

This commit cleans those up:

- Intro paragraph of the new section drops the (Aiken …) / (Scalus)
  attributions on the two emitted forms.
- Keys-example list label is no longer attributed to a specific
  producer.
- Tuple rule's "match what current Aiken implementations emit"
  justification is removed; the disambiguation rationale stands
  alone.
- Two example keys / $refs that used the `aiken/...` module prefix
  now use a neutral `my_contract/...` prefix.
- Rationale section condenses three mentions of Aiken/Scalus to a
  single neutral "current major producers already emit the
  angle-bracket form" sentence.
- Legacy form attribution changes from "Aiken `< v1.1`" to
  "emitted by some early producers".

No normative content changes; only attribution / framing.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

The whole purpose of standardising the syntax is to remove producer
discretion, so the format-conformance rules are now MUST:

- Producers MUST follow the angle-bracket key grammar.
- Producers MUST use Tuple<<...>> for n-tuples.
- title MUST hold only the unparameterized constructor name.
- Consumers MUST accept the modern form.

Legacy handling is explicitly optional:

- New producers MUST NOT emit the dollar-separator form.
- Consumers MAY support legacy forms for back-compat but are NOT
  required to. A consumer that rejects legacy-form blueprints outright
  is still conformant.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Adds a normative section that specifies how parametric type
instantiations are named in the `definitions` registry, how `$ref`
references them under RFC 6901, and how `title` should be populated.

Codifies the angle-bracket form (`Option<Int>`, `List<ByteArray>`,
`Pair<Int,ByteArray>`, `Map<K,V>`, `Tuple<<A,B>>`) that Aiken stdlib v3
and Scalus already emit, and acknowledges the legacy `$`-form from
Aiken < v1.1 as something consumers should tolerate but new producers
should not emit.

Motivation: without a spec, every new producer (Scalus, OpShin, plu-ts,
PlutusTx, future tools) is free to invent its own convention, which
breaks code-generators (e.g. cardano-client-lib's annotation processor
has carried dual `<>` / `$` parsing for two years). Adds a Rationale
subsection explaining why angle brackets over the alternatives. Adds
cardano-client-lib to the Implementors list.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

§Response signing canonical-form step 2 says
"Append <scheme>://<host_lowercased><path>" but does not specify
whether an explicit port is part of the canonical authority. Different
URL libraries disagree on default-port omission (RFC 3986 §3.2.3 says
default ports are equivalent but not identical). Pin: include port iff
it appears literally in the URL authority; default ports (443/80) MUST
NOT be emitted. Keeps canonical subject byte-deterministic.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The aux-data consistency rule requires BLAKE2b-256(canonical-cbor(...))
without pinning what produces canonical-cbor. CBOR canonicalisation
has multiple incompatible interpretations (deterministic-only vs
strictly-deterministic, definite-vs-indefinite length, sort orders for
non-text keys). Pin to cardano-ledger (Haskell), pallas-codec (Rust),
or cardano-multiplatform-lib (JS/Rust). Conformance against any is
sufficient.

Also clarify the contrast with tx_body extraction: tx_body is
byte-literal (commit binds to the ledger-validated source bytes), aux
data re-canonicalises (verifying a chain-recorded hash, not extracting
chain-validated bytes).

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Spec mandates re-serialise under RFC 8949 §4.2 canonical encoding, but
this contradicts the chain's tx_id rule: chain's tx_id is BLAKE2b-256
over the source body bytes the ledger validated. If the wallet
re-canonicaliser disagrees with the source encoder (definite-vs-
indefinite length, non-text-key map sort order), wallet's commit
diverges from chain's tx_id and every downstream hash-pin breaks.

Pin to literal-bytes extraction. dApp MUST supply Conway-era canonical
CBOR (per RFC 8949 §4.2) so the extraction is well-defined; wallets
MAY but need not check source canonicity.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Spec inherits CIP-30:343-347 partialSign verbatim but does not say how
the dApp merges a wallet-returned partial witness_set into an
in-flight transaction_witness_set that already carries co-signer vkey
witnesses. Two readings: (a) replace the map's vkey_witnesses array
(silently drops prior co-signers), (b) array-append (correct). Pin to
(b) for vkey_witnesses (map key 0) and extend to native scripts (key 1),
Plutus scripts (keys 3/6/7), datums (key 4), redeemers (key 5). Add
SHOULD-reject on wallet returning non-empty entries for keys the dApp
did not authorise (anti-injection).

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>