Function identity_create_from_shielded_extra_sighash_data 

pub fn identity_create_from_shielded_extra_sighash_data(
    identity_id: &[u8; 32],
    denomination: u64,
    send_to_address_on_creation_failure: &PlatformAddress,
    public_keys: &[IdentityPublicKeyInCreation],
    platform_version: &PlatformVersion,
) -> Result<Vec<u8>, ProtocolError>

Builds the transparent extra_data bound into an IdentityCreateFromShieldedPool’s platform sighash, with the byte layout identity_id (32) || denomination (u64 LE) || send_to_address_on_creation_failure (tag u8: 0=P2pkh, 1=P2sh || hash 20) || num_keys (u16 LE) || for each key in supplied order: key_id (u32 LE) || purpose (u8) || security_level (u8) || key_type (u8) || key_data_len (u16 LE) || key_data || read_only (u8) || contract_bounds (tag u8: 0=None, 1=SingleContract id(32), 2=SingleContractDocumentType id(32) name_len(u16 LE) name).

IdentityCreateFromShieldedPool carries NO platform identity signature: authorization is 100% the Orchard proof + per-action spend-auth signatures + binding signature over this sighash. The transparent, state-determining fields — the new identity id, the exit denomination, and the FULL public-key set — must therefore be committed into the Orchard sighash, exactly as the surplus_output field is committed into ShieldFromAssetLock’s ECDSA signature. Without this binding a relay or block proposer could take a valid bundle exiting a denomination and re-point it at a DIFFERENT identity id, or swap in DIFFERENT keys they control, stealing the credited balance (the per-key proofs-of-possession alone do NOT prevent this — a relayer keeps valid PoP sigs for their own keys while swapping the bundle). Binding (this spend → these exact keys → this id → this denomination) here makes the redirection atomic-or-invalid.

The signing (client/builder) and verifying (consensus) sides MUST produce identical bytes, so both call this single function. Unlike the fixed-length withdrawal/unshield helpers, the variable-length key list is fully length-prefixed (both the key count and each key’s data) so the preimage is unambiguous for any key set.