Fixes CIP links to https://cips.cardano.org/cip/CIP-...

doc/babbage-features.md

@@ -14,7 +14,7 @@ This document is a reference/explainer for the new CTL APIs introduced for Babba
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 ## Reference Inputs
 
-[Reference inputs](https://cips.cardano.org/cips/cip31/#referenceinputs) allow looking at an output without spending it in Plutus scripts.
+[Reference inputs](https://cips.cardano.org/cip/CIP-0031#reference-inputs) allow looking at an output without spending it in Plutus scripts.
 
 There are two ways to use an input as a reference in the constraints API:
 
@@ -28,7 +28,7 @@ There are two ways to use an input as a reference in the constraints API:
 
 ## Reference Scripts
 
-[Reference Scripts](https://developers.cardano.org/docs/governance/cardano-improvement-proposals/cip-0033/) allows the use of scripts without attaching them to the transaction (and using a reference instead).
+[Reference Scripts](https://cips.cardano.org/cip/CIP-0033) allows the use of scripts without attaching them to the transaction (and using a reference instead).
 
 Reference scripts can be utilized in CTL by first creating a reference point for the script to be used later via `mustPayToScriptWithScriptRef` (or its variants).
 
@@ -40,14 +40,14 @@ Then, `mustSpendScriptOutputUsingScriptRef` (or its variants) can be used to use
 
 ## Inline Data
 
-[CIP-32](https://developers.cardano.org/docs/governance/cardano-improvement-proposals/cip-0032/) introduces the inline data feature that allows storing datum values directly in transaction outputs, instead of just the hashes.
+[CIP-32](https://cips.cardano.org/cip/CIP-0032) introduces the inline data feature that allows storing datum values directly in transaction outputs, instead of just the hashes.
 
 In CTL, alternating between datum storage options can be achieved by specifying a `DatumPresence` value with constraints that accept it, like `mustPayToPubKeyWithDatum`.
 
 [Usage example](../examples/PlutusV2/InlineDatum.purs)
 
 ## Collateral Output
 
-[CIP-40](https://cips.cardano.org/cips/cip40/) introduces explicit collateral output. On validation failure, previously the entire collateral was consumed. Now, if excess collateral is supplied, even with native assets, the surplus can be returned on validation failure.
+[CIP-40](https://cips.cardano.org/cip/CIP-0040) introduces explicit collateral output. On validation failure, previously the entire collateral was consumed. Now, if excess collateral is supplied, even with native assets, the surplus can be returned on validation failure.
 
 Collateral output is automatically added to transactions in CTL. To trigger a collateral return, the `mustNotBeValid` constraint should be explicitly specified, otherwise a script error would be detected earlier and the transaction will not be sent.

doc/cip-25-nfts.md

@@ -2,6 +2,6 @@
 
 # CIP-25 NFT Metadata standard
 
-CTL includes [CIP-25](https://cips.cardano.org/cips/cip25/) (v2) domain type definitions that enable creation of standard-compliant applications with ease. The definitions abstract away conversions between PlutusData and PureScript types.
+CTL includes [CIP-25](https://cips.cardano.org/cip/CIP-0025) (v2) domain type definitions that enable creation of standard-compliant applications with ease. The definitions abstract away conversions between PlutusData and PureScript types.
 
 See [`Contract.Metadata`](https://plutonomicon.github.io/cardano-transaction-lib/Contract.Metadata.html#t:Cip25MetadataEntry) module.

doc/key-management.md

@@ -11,7 +11,7 @@
 
 # Key Management
 
-The process of going from private key menmonic to a set of addresses that the wallet can use is well specified in [CIP-1852](https://cips.cardano.org/cips/cip1852/).
+The process of going from private key menmonic to a set of addresses that the wallet can use is well specified in [CIP-1852](https://cips.cardano.org/cip/CIP-1852).
 
 For an address to be built, the user must provide some entropy for private key derivation and a *derivation path*, that specifies a list of cryptographic operations to perform on the "parent" or "root" key to get the "child" private key that can be used for signing.
 

doc/query-layers.md

@@ -21,7 +21,7 @@ In CTL context, the following query layers can be used, depending on backend cho
 - [Ogmios](https://ogmios.dev/) ([CTL backend](./runtime.md#ctl-backend))
 - [Kupo](https://cardanosolutions.github.io/kupo/) ([CTL backend](./runtime.md#ctl-backend))
 - [Blockfrost](https://blockfrost.io/) ([Blockfrost backend](./blockfrost.md))
-- [CIP-30 light wallet browser extensions](https://cips.cardano.org/cips/cip30/) (any backend)
+- [CIP-30 light wallet browser extensions](https://cips.cardano.org/cip/CIP-0030) (any backend)
 
 ## Wallet/Backend Inconsistency
 
@@ -36,7 +36,7 @@ Thus, the goal of the developers is to ensure that the set of UTxOs available to
 CTL tries to be smart when dealing with the issue, and it aims to let the user work with both query layers as if it was one. To achieve this guarantee, CTL follows three simple rules:
 
 - **Rule 1** Whenever there is a *wallet operation* the result of which depends on the set of available UTxOs, CTL delays the execution until it reaches a state where *all wallet UTxOs are known to the backend*. These operations are assumed to be `getWalletUtxos`, `getWalletCollateral` and `getWalletBalance`.
-- **Rule 2** Whenever there is a transaction *`signTx`* [CIP-30](https://cips.cardano.org/cips/cip30/) call, the execution is delayed until all transaction inputs that come from one of the addresses controlled by the wallet *are known to the wallet*.
+- **Rule 2** Whenever there is a transaction *`signTx`* [CIP-30](https://cips.cardano.org/cip/CIP-0030) call, the execution is delayed until all transaction inputs that come from one of the addresses controlled by the wallet *are known to the wallet*.
 - **Rule 3** Whenever CTL is asked to await for *transaction confirmation*, the execution is delayed until the *UTxOs that the transaction creates at wallet addresses* are visible to the wallet.
 
 The rules are implemented as 3 callable functions, which we call *synchronization primitives*: