Constant SHIELDED_UNSHIELD_ADDRESS_STORAGE_BYTES 

pub const SHIELDED_UNSHIELD_ADDRESS_STORAGE_BYTES: u64 = 222;

Calibrated effective storage-byte cost of the single AddBalanceToAddress write an Unshield performs, crediting the net (unshielding_amount − fee) to the output platform address.

Like the other pool-paid transitions, an Unshield writes its change notes and nullifiers — but it ALSO credits a transparent platform address with AddBalanceToAddress. In the new-address worst case that write touches the address subtree (the address path plus its balance/nonce entries), a real, GroveDB-metered cost of ≈6,239,100 credits (≈222 of those bytes are storage) that is FLAT regardless of the bundle’s action count (the address write is the same size whether the unshield spends one note or sixteen).

compute_minimum_shielded_fee prices only the per-action note/nullifier storage and the per-bundle ZK compute, so it does NOT cover this address write. We therefore add the address cost to the Unshield fee as a flat BYTE-BASED component, sized at SHIELDED_UNSHIELD_ADDRESS_STORAGE_BYTES effective bytes priced at the SAME per-byte storage rate the per-action note storage uses (disk + processing credits/byte).

The constant is the storage portion of the address write: the metered AddBalanceToAddress op costs ≈6,239,100 credits total, of which the storage part is ≈6,075,000 ≈ 222 effective bytes at the storage rate. We size the component to that storage figure — because it is a bytes × per_byte_rate term it is booked as storage, so it should match the address write’s storage cost, not its total. The small remaining op-processing (~164K) is already covered by the per-action processing fee. Pricing it off the same rate means it tracks the storage rate as it evolves, exactly like the per-action note storage does. See compute_minimum_shielded_fee::compute_shielded_unshield_fee.