Cardano Updates

Per @rphair at the 2026-05-26 CIP editors meeting: this proposal was
accepted as Candidate and assigned CIP number 186 (rphair pushed
header update in 5c645d2). Follow-up: rename CIP-deeplink-signing/
to CIP-0186/ and update the schema $id / README $schema URLs that
referenced the old path.

The CIP-30-DeepLink protocol name itself remains as the friendly
identifier per the spec's Title field; only the on-disk directory
and the path component of canonical URLs change.

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

Co-authored-by: Ryan <[email protected]>

Co-authored-by: Ryan <[email protected]>

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

Removes paragraphs and sections that are non-normative noise under the
R-canonical derivation:

  - The "TextEnvelope encoding mistakes" warning in Address Derivation:
    irrelevant under R, which never goes through cardano-cli text
    envelopes — implementers compute applied bytes directly from
    bytestring concatenation, not from a serialised wrapper.
  - The Tx3 paragraph in Public API and Transaction Shapes and the
    "Generated bindings (supplementary)" subsection: Tx3 was a
    non-normative reference file that was never published; the mentions
    added noise without normative or informative value.
  - The "L2 Interoperability" subsection: a disclaimer paragraph noting
    cross-ledger semantics are out of scope; the Versioning section
    already establishes scope.

Condenses two redundancies:

  - The repeated MUST NOT in Datum and Redeemer Schema becomes a single
    cross-reference to Definitions — TOA deposit, which already
    establishes the normative rule.
  - "What lives where" no longer restates content-hashing strategy
    already covered in Mandatory Normative Artifacts; the two bullets
    naming the CIP folder contents are preserved.

Updates two orphan references left behind: the "outside Tx3" sentence
in Address derivation helper, and the "any toa.tx3 file" mention in
Reference Artifacts — Normative components.

Net: 22 deletions, 5 insertions; 611 → 593 lines.

Keeps the conformance-vs-documentation cut agreed in PR review
discussion r3293465306 (https://github.com/cardano-foundation/CIPs/pull/1200#discussion_r3293465306):
conformance gates stay inline in the CIP; schema documentation lives
in en7angled/[email protected]:test-vectors/README.md (referenced by content
hash).

Changes inline in the CIP:
  - Clarifies that per-vector fields `params_cbor_hex`,
    `applied_script_cbor_hex`, `applied_script_bytes`, and
    `flat_body_length` are diagnostic aids; conformance for category
    (a) is determined by `expected_script_hash`,
    `expected_address_mainnet`, `expected_address_testnet`.
  - Adds the CBOR-threshold rationale paragraph: lengths 23 and 24
    bracket the single-byte vs length-prefixed CBOR bytestring header
    transition, and lengths 31 and 32 cover the upper boundary of the
    permitted asset_name domain.
  - Adds two coverage MUST bullets: single-policy_id-change vector
    pairs and single-asset_name-change vector pairs, useful for
    isolating which region of R depends on which input.

The schema documentation for the new `flat_body_length` field is
in en7angled/[email protected]:test-vectors/README.md, already content-hashed
in the preceding paragraph.

Implements cerinta section 3.4 under the conformance-vs-documentation
cut.

Adds:
  - Rationale entry "Why is the canonical address derivation specified
    at the byte level (R) rather than via apply_params?" — explains why
    on-chain executability + non-Haskell implementability justify the
    byte-level specification, and documents the empirical precondition
    (byte-aligned decomposition of the applied flat-encoded script).
  - Open Question #6 "Stability of FLAT_PREFIX_TOA_V1 and
    FLAT_SUFFIX_TOA_V1" — frames byte-aligned decomposition as a
    property of the compiled artifact, not of the Plinth source;
    recompilation requires a new toa_version.
  - Acceptance Criteria items for canonical R implementation and for
    toa-verify-reconstruction passing on every artifact release.

Also adjusts the high-level Specification intro to be neutral about
which procedure produces the applied script bytes (R reconstructs
them rather than calling apply_params).

Implements cerinta sections 3.5, 3.6, 3.7.

Motivation: under the previous apply_params-based derivation, the TOA
address could not be derived on-chain (Plutus V3 exposes no primitive
for apply_params + ledger serialisation), and off-chain implementations
in TypeScript, Rust, Python, etc. had to depend on Plutus tooling. R
removes both obstacles: it is implementable on-chain using only
standard Plutus V3 builtins (appendByteString, consByteString,
lengthOfByteString, serialiseData, blake2b_224) and off-chain in any
language with bytestring concatenation and blake2b-224. The semantic
identity of TOA v1 remains anchored in the same compiled validator
artifact -- the byte-level constants are extracted from it -- but
conformance is now expressed in a form that is verifiable uniformly
on-chain and off-chain.

Replaces the apply_params-based derivation procedure with the byte-level
function R, executable on-chain via standard Plutus V3 builtins and
implementable off-chain in any language with bytestring concatenation
and blake2b-224.

The compiled UPLC artifact and template hash become audit references;
FLAT_PREFIX_TOA_V1 (528 B), FLAT_SUFFIX_TOA_V1 (1 B), the CBOR
bytestring-header encoder, and the canonical PlutusData CBOR parameter
encoder become the normative derivation inputs, pinned at
en7angled/[email protected] with blake2b-256 content hashes.

The reference recipe wraps params_cbor in a single-chunk
chunked-bytestring frame (1-byte length prefix + paramCbor + 0x00
terminator), matching the flat-encoded UPLC layout the validator
expects when applied via a Constant Data UPLC term (cardano-api
applyArguments semantics).

Implements cerinta sections 3.1, 3.2, 3.3, 3.8.