Cardano Updates

Signed-off-by: Akhil Repala <[email protected]>

Signed-off-by: Akhil Repala <[email protected]>

createCompatibleTx now takes [Exp.TxOut (ShelleyLedgerEra era)] plus an
explicit Map L.DataHash (L.Data ...) for supplemental datums, mirroring
how it already takes Exp.TxCertificates / Exp.TxVotingProcedures /
Exp.TxProposalProcedures. Supplemental datums were previously rescued
out of the legacy TxOut constructor inside convScriptData' and folded
into TxBodyScriptData; Exp.TxOut intentionally does not carry them
(only the hash; the full datum lives in the witness set), so callers
now thread them in explicitly.

Deletes the legacy bridge helpers from Experimental.Tx
(fromLegacyTxOut, legacyDatumToDatum, supplementalDatumFromLegacy,
toLedgerDatum, DatumDecodingError). They existed only to migrate
callers from legacy TxOut CtxTx era; with the Compatible API no longer
accepting that type, the bridges have no remaining callers inside
cardano-api. They were re-exported only via the experimental namespace,
whose stability contract permits breaking changes.

After this change, neither Cardano.Api.Compatible.* nor
Cardano.Api.Experimental.* references OldApi.TxOut / TxOut CtxTx era.
The legacy TxOut ctx era type itself stays in place — UTxO, Tx body
construction, fee/balancing, LedgerState, and Byron all still depend
on it.

CIP-158 was merged 2026-03 and is a sibling CIP-13 extension authority
(adamkdean / @adamKDean). The draft already cited CIP-45 (connect
authority) and CIP-162 (drep authority) as precedents for CIP-13
extensibility; CIP-158 (browse authority) belongs in that list.

Two small additions in the Relationship to CIP-13 section:

  - Family-of-extensions list: add CIP-158 alongside CIP-45 and
    CIP-162, with its grammar and a note that CIP-158 is explicitly
    navigation-only and scopes out signing flows / callback paths
    per its own Rationale.

  - Future minor-revision paragraph: note that the prospective
    web+cardano://cip30dl/v1/... form mirrors CIP-158's grammar
    precedent for the established CIP-13 extension shape.

Public conversation thread on this (Adam Dean raised the comparison
on X; we credit CIP-158's isolation-of-authorities framing back at
him for CIP-30-DeepLink sitting in its own namespace) is linked from
the Discussions: preamble.

Add token metadata for DERP

Signed-off-by: Akhil Repala <[email protected]>

added:
* github:input-output-hk/cardano-faucet/5666c819eab3bd19dc77d8a8a31aec95d203af28#packages.x86_64-linux."cardano-faucet:exe:cardano-faucet"
* github:input-output-hk/cardano-faucet/631bb6458af84bc52c5ad7c201b4cafc300e2202#packages.x86_64-linux."cardano-faucet:exe:cardano-faucet"
* github:input-output-hk/cardano-faucet/c218711f2162e77f94adab23bf91e1dbbb6e4409#packages.x86_64-linux."cardano-faucet:exe:cardano-faucet"
* github:input-output-hk/cardano-faucet/f97f352145d01bce3bbe21df9b846847f0ecc7f8#packages.x86_64-linux."cardano-faucet:exe:cardano-faucet"

Signed-off-by: Doc Holiday <[email protected]>

Signed-off-by: Doc Holiday <[email protected]>

Signed-off-by: Doc Holiday <[email protected]>

Signed-off-by: Doc Holiday <[email protected]>

Signed-off-by: Doc Holiday <[email protected]>

Signed-off-by: Doc Holiday <[email protected]>

Replace untyped `any[]` with properly typed SDJWTDisclosure interface.
Add validateSDJWTSubmission() function to validate structure at runtime
before passing to cryptographic verification routines. This prevents
malformed disclosures, missing claims, or incorrect algorithms from
silently passing through verification.

Fixes #630

Signed-off-by: A-Chronicle <[email protected]>

Signed-off-by: Doc Holiday <[email protected]>

Signed-off-by: Doc Holiday <[email protected]>

Collect errors from all attempted resolvers and include their details
in the failure message. This enables developers to diagnose resolution
failures (network errors, invalid DIDs, blockchain issues, etc.)
instead of receiving a generic error message.

Fixes #629

Signed-off-by: A-Chronicle <[email protected]>

Remove console.log() and console.error() calls that bypass the SDK's
logging configuration and could leak sensitive information in production.
These calls appear in critical error paths where exceptions are thrown,
and logging should be handled through the SDK's configured logger.

Fixes #628

Signed-off-by: A-Chronicle <[email protected]>

Faucet 11.0

Faucet 10.7