• Added comprehensive Cardano mainnet specification with 150+ REST API endpoints
• Configured Cardano preprod testnet as derived specification inheriting from mainnet
• Defined compute units, block parsing, and API categories for all endpoints
• Implemented chain verification and archive extension support

Complete Cardano mainnet and testnet specification

• Created new Cardano specification file with complete mainnet configuration
• Defined CARDANO mainnet spec with 150+ REST API endpoints covering accounts, addresses, blocks,
 assets, epochs, governance, pools, scripts, transactions, and utilities
• Added GET and POST API collections with compute units ranging from 10 to 100
• Configured chain verification (network magic 764824073) and archive extension (5x CU multiplier
 for blocks before 8192)
• Defined CARDANOT preprod testnet spec that inherits all APIs from mainnet with chain-id
 verification value of 1
• Set reliability threshold, block finalization parameters, and minimum stake requirements for both
 specs

specs/mainnet-1/specs/cardano.json

Description

Cardano REST endpoints that take a block identifier in the path (e.g. /blocks/{hash_or_number} and
subpaths) use block_parsing DEFAULT with parser_arg ["latest"], so the requested block is always
tagged as LATEST_BLOCK even when querying a specific block number. This can break requested-block
tracking used for data reliability/QoS for historical block requests.

Code

specs/mainnet-1/specs/cardano.json[R519-525]

+                                "name": "/blocks/{hash_or_number}",
+                                "block_parsing": {
+                                    "parser_arg": [
+                                        "latest"
+                                    ],
+                                    "parser_func": "DEFAULT"
+                                },

Evidence

In the new Cardano spec, /blocks/{hash_or_number} (and related /next, /previous, /txs paths)
hardcode block_parsing to DEFAULT+"latest". The REST chain parser derives the request’s
"requestedBlock" from api.BlockParsing via ParseBlockFromParams, and the DEFAULT parser always
returns the first parser_arg value ("latest"), so requests for specific blocks will still be treated
as "latest". Other REST specs demonstrate the expected pattern: for block-height path params they
use PARSE_DICTIONARY_OR_ORDERED to extract the placeholder from RestMessage.GetParams().

specs/mainnet-1/specs/cardano.json[519-633]
protocol/chainlib/rest.go[115-152]
protocol/parser/parser.go[248-264]
protocol/parser/parser.go[509-513]
specs/mainnet-1/specs/aptos.json[212-220]
specs/mainnet-1/specs/cosmossdk.json[756-764]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Cardano block-specific REST endpoints (e.g. `/blocks/{hash_or_number}` and related endpoints) currently set `block_parsing` to `DEFAULT` with `parser_arg: ["latest"]`, which forces the requested block to always be treated as `latest`.

### Issue Context
`RestChainParser.ParseMsg()` computes `requestedBlock` using `parser.ParseBlockFromParams(restMessage, api.BlockParsing, ...)`, and `DEFAULT` parsing returns the first `parser_arg` value.

### Fix Focus Areas
Update `block_parsing` for endpoints that include `{hash_or_number}` in the spec path to extract the actual path parameter (matching how other REST specs parse `{height}`):
- specs/mainnet-1/specs/cardano.json[519-633]

Recommended config shape (example):
- set `parser_func` to `PARSE_DICTIONARY_OR_ORDERED`
- set `parser_arg` to `["hash_or_number", "=", "0"]`

Apply similarly to `/blocks/{hash_or_number}/next`, `/previous`, `/txs`, `/txs/cbor`, etc. so the placeholder is consistently parsed into `requestedBlock` when it’s numeric.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.