fix: infer DRep type from CIP-129

[Sotatek-DucPhung]

Summary

• Infer drep.type from CIP-129 header byte (0x22 = key_hash, 0x23 = script_hash) when omitted in /construction/preprocess and /construction/payloads
• Validate consistency when both type and CIP-129 prefixed id are provided (existing behavior preserved)
• Keep drep.type required for raw 28-byte ids and for abstain/no_confidence types
• HTTP 500 is preserved for all errors per Rosetta specification (only defines 200/500 responses)

Motivation

CIP-129 compliant hex identifiers encode the credential type in their header byte. Requiring clients to redundantly specify drep.type when the information is already embedded in the drep.id creates unnecessary friction.

References:

• Issue: CIP-129 header byte should allow inferring DRep type #657
• CIP-0129: https://cips.cardano.org/cip/CIP-0129
• DRep Delegation guide: https://cardano-foundation.github.io/cardano-rosetta-java/docs/user-guides/drep-delegation/

Changes

OpenAPI Spec

• api.yaml — Removed type from required list in DRepParams schema. Updated descriptions to document CIP-129 inference behavior.

Core Logic

• ProcessConstructions.java — Added inferDrepTypeFromCip129Header() method:
  • Reads first byte of 29-byte drep.id hex
  • Validates top nibble is DRep (0x2_)
  • Maps 0x22 → KEY_HASH, 0x23 → SCRIPT_HASH
  • Called only when drep.type is null; sets type on DRepParams before normal processing
  • Raw 28-byte ids without type still fail with error code 5040

Behavior Matrix

drep.id format	drep.type	Result
CIP-129 prefixed (29 bytes, 0x22)	omitted	Inferred as key_hash, proceeds normally
CIP-129 prefixed (29 bytes, 0x23)	omitted	Inferred as script_hash, proceeds normally
CIP-129 prefixed (29 bytes, 0x22)	key_hash	Match → proceeds normally
CIP-129 prefixed (29 bytes, 0x22)	script_hash	Mismatch → 500, error 5045
CIP-129 prefixed (29 bytes, 0x12)	omitted	Non-DRep header → 500, error 5037
Raw hash (28 bytes)	omitted	Type required → 500, error 5040
Raw hash (28 bytes)	key_hash	Proceeds normally (existing behavior)
N/A	abstain	Proceeds normally, id not required
N/A	no_confidence	Proceeds normally, id not required

Backward Compatibility

This change is fully backward-compatible:

• All existing requests with explicit drep.type continue to work identically
• The only new behavior is accepting requests that previously failed (missing type with CIP-129 prefixed id)
• Error codes in the response body remain the same; HTTP 500 status preserved per Rosetta spec

Test Plan

• All existing API tests pass (0 failures, 0 errors)
• New CIP-129 inference tests pass for both preprocess and payloads
• Negative tests verify correct error codes for raw-id-without-type, invalid headers, and mismatches
• Manual testing: send /construction/preprocess with CIP-129 prefixed drep.id and no type
• Manual testing: verify HTTP 400 status code is returned for DRep validation errors
• Verify documentation update for DRep Delegation guide (follow-up)

[github-actions]

❌ Preprod Tests: FAILED

📊 View Detailed Test Report

🔗 Action Run #188

Tests run against preprod network with live blockchain data

[github-actions]

❌ Preprod Tests: FAILED

📊 View Detailed Test Report

🔗 Action Run #189

Tests run against preprod network with live blockchain data

[matiwinnetou]

Even though it is not correct and not according to REST API, I believe we actually HAVE to do HTTP 500 in Rosetta on various errors. The whole Rosetta works like this now. I would not change this or if we can change this, we have to change this on all errors.

It would be best if you check if I am right according to Rosetta specification but that will be a separate refactoring task.

[Sotatek-DucPhung]

You're right! There is no 400 response defined anywhere in the spec. Every endpoint in our local api.yaml follows this same pattern. only 200 and 500, no 4xx codes at all.

[matiwinnetou]

Let's keep HTTP 500 error even though is incorrect according to REST specs.

[github-actions]

✅ Preprod Tests: PASSED

📊 View Detailed Test Report

🔗 Action Run #191

Tests run against preprod network with live blockchain data