Constant zebra_chain::parameters::network::ZIP_212_GRACE_PERIOD_DURATION

const ZIP_212_GRACE_PERIOD_DURATION: HeightDiff = 32_256;

The ZIP-212 grace period length after the Canopy activation height.

Consensus

ZIP-212 requires Zcash nodes to validate that Sapling spends and Orchard actions follows a specific plaintext format after Canopy’s activation.

[Heartwood onward] All Sapling and Orchard outputs in coinbase transactions MUST decrypt to a note plaintext , i.e. the procedure in § 4.19.3 ‘Decryption using a Full Viewing Key (Sapling and Orchard)’ on p. 67 does not return ⊥, using a sequence of 32 zero bytes as the outgoing viewing key . (This implies that before Canopy activation, Sapling outputs of a coinbase transaction MUST have note plaintext lead byte equal to 0x01.)

[Canopy onward] Any Sapling or Orchard output of a coinbase transaction decrypted to a note plaintext according to the preceding rule MUST have note plaintext lead byte equal to 0x02. (This applies even during the “grace period” specified in [ZIP-212].)

https://zips.z.cash/protocol/protocol.pdf#txnencodingandconsensus

Wallets have a grace period of 32,256 blocks after Canopy’s activation to validate those blocks, but nodes do not.

There is a “grace period” of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte 0x01 MUST still be accepted [by wallets].

Let ActivationHeight be the activation height of this ZIP, and let GracePeriodEndHeight be ActivationHeight + 32256.

https://zips.z.cash/zip-0212#changes-to-the-process-of-receiving-sapling-or-orchard-notes

Zebra uses librustzcash to validate that rule, but it won’t validate it during the grace period. Therefore Zebra must validate those blocks during the grace period using checkpoints. Therefore the mandatory checkpoint height (Network::mandatory_checkpoint_height) must be after the grace period.