Hello Indigo maintainers,
I am developing read-only historical indexing and research tooling for Indigo V3 and would appreciate clarification of an apparent configuration inconsistency. This is a request for canonical semantics, not a claim of an exploit or current protocol failure.
The current Indigo MCP source loads the official mainnet-system-params-v3.json configuration. In that configuration:
validatorHashes.versionRegistryHash is ea84d625650d066e1645e3e81d9c70a73f9ed837bd96dc49850ae744.scriptReferences.versionRegistryValidatorRef.input is 40f186ab184a96706c75696ec2e782e0b44c2305007aa4b65b9cb46d0297c464#0.- A hash-anchored, read-only DB-Sync lookup resolves that reference output to a Plutus V3 script with hash
288fea77a0f674c6080aadd8ed3ca42cd5a920bf1f00c0d3e63306e4.
- The official V2 upgrade source and SDK V2 fixture associate
ea84... with the Plutus V2 version-registry validator.
- The official V3 SDK validator source and initialization code derive and use the distinct Plutus V3 registry validator represented by
288fea....
Could you please clarify:
- Is retaining
ea84... in the V3 validatorHashes.versionRegistryHash field intentional compatibility behavior, or is that field stale or mislabeled?
- What are the intended consumer semantics of
validatorHashes.versionRegistryHash and scriptReferences.versionRegistryValidatorRef in V3?
- Which identity should V3 indexers and historical-data consumers treat as canonical when classifying version-registry activity?
- Is there a canonical source or configuration commit that documents this relationship?
The reproducible evidence, exact source pins, Cardano script-hash derivation, and bounded SQL results are recorded here:
Until clarified, the downstream historical export remains fail-closed rather than substituting either identity by assumption. Thank you.
Hello Indigo maintainers,
I am developing read-only historical indexing and research tooling for Indigo V3 and would appreciate clarification of an apparent configuration inconsistency. This is a request for canonical semantics, not a claim of an exploit or current protocol failure.
The current Indigo MCP source loads the official
mainnet-system-params-v3.jsonconfiguration. In that configuration:validatorHashes.versionRegistryHashisea84d625650d066e1645e3e81d9c70a73f9ed837bd96dc49850ae744.scriptReferences.versionRegistryValidatorRef.inputis40f186ab184a96706c75696ec2e782e0b44c2305007aa4b65b9cb46d0297c464#0.288fea77a0f674c6080aadd8ed3ca42cd5a920bf1f00c0d3e63306e4.ea84...with the Plutus V2 version-registry validator.288fea....Could you please clarify:
ea84...in the V3validatorHashes.versionRegistryHashfield intentional compatibility behavior, or is that field stale or mislabeled?validatorHashes.versionRegistryHashandscriptReferences.versionRegistryValidatorRefin V3?The reproducible evidence, exact source pins, Cardano script-hash derivation, and bounded SQL results are recorded here:
Until clarified, the downstream historical export remains fail-closed rather than substituting either identity by assumption. Thank you.