Function shield_extra_sighash_data 

pub fn shield_extra_sighash_data(
    inputs: &BTreeMap<PlatformAddress, (AddressNonce, Credits)>,
    platform_version: &PlatformVersion,
) -> Result<Vec<u8>, ProtocolError>

Extra sighash data of a credit pool Shield bundle: its kind tag and a digest of the platform addresses that fund it. See credit_pool_output_only_extra_sighash_data_v0 for why the credit pool’s outputs-only bundles bind anything at all.

A Shield has no identity, so its owner is its funding: the SHA-256 of its input addresses, each in its 21-byte encoding (PlatformAddress::to_bytes), in the order the inputs map holds them. That order is part of the wire format. It is the map’s key order, which is also the order the transition serializes its inputs in, so a client that assembles the same set in any other order still binds the same bytes.

The nonces and the contributed amounts are deliberately left out. The owner answers “who funds this”, not “which transition carries it”, exactly as ShieldFromIdentity binds its identity and not its nonce: the preimage is there to stop somebody else from re-wrapping the bundle. Binding the nonce would not stop the funder’s own duplicates either, because a sender can rebuild the same notes under any preimage (see credit_pool_output_only_extra_sighash_data_v0); closing that would need the bundles’ dummy nullifiers recorded and checked, which consensus does not do. Adding the nonce later would change the layout under every bundle already built for this one.

Dispatches on dpp.methods.credit_pool_bundle_binding, which the client builder and the consensus verifier both read: None binds nothing (the empty preimage every shipped verifier expects), Some(0) binds tag (1) || funding digest (32).