Summary
The feed create/update/delete processors call authorize(.., FEED_AUTHORITY | FOUNDATION), but FEED_AUTHORITY is not listed in AUTHORIZE_GATED_FLAGS (smartcontract/programs/doublezero-serviceability/src/authorize.rs:293-308).
Why it matters
AUTHORIZE_GATED_FLAGS drives doublezero permission audit and the RequirePermissionAccounts rollout. Per programs/CLAUDE.md, every flag any processor hands to authorize() MUST appear in this list, or the audit silently understates lockout risk.
Concretely, this is an activation precondition for the deferred permission append in the RFC-26 instruction-builder crate (crates/doublezero-serviceability-instruction/src/common.rs::build_with_permission): the feed builders route through build_with_permission, and once the append is enabled, feed-authority-only (non-foundation) keys must be guaranteed a Permission account. If FEED_AUTHORITY is not gated, the rollout won't cover feed, and activating the append would break those keys (authorize() hard-fails with InvalidAccountData when the appended Permission PDA does not exist onchain).
Fix
Add permission_flags::FEED_AUTHORITY to AUTHORIZE_GATED_FLAGS, and update legacy_keys_for_flags / check_legacy_any together per the checklist in smartcontract/programs/CLAUDE.md (a #[cfg(test)] test asserts they agree). Also revisit NON_MIGRATED_SUBSYSTEMS in smartcontract/cli/src/permission/audit.rs.
Tripwire
A canary test in crates/doublezero-serviceability-instruction/src/feed.rs asserts the gap currently exists (!AUTHORIZE_GATED_FLAGS.contains(&FEED_AUTHORITY)); closing this issue will fail that test, forcing the feed builder's doc note to be revisited.
Summary
The feed
create/update/deleteprocessors callauthorize(.., FEED_AUTHORITY | FOUNDATION), butFEED_AUTHORITYis not listed inAUTHORIZE_GATED_FLAGS(smartcontract/programs/doublezero-serviceability/src/authorize.rs:293-308).Why it matters
AUTHORIZE_GATED_FLAGSdrivesdoublezero permission auditand theRequirePermissionAccountsrollout. Perprograms/CLAUDE.md, every flag any processor hands toauthorize()MUST appear in this list, or the audit silently understates lockout risk.Concretely, this is an activation precondition for the deferred permission append in the RFC-26 instruction-builder crate (
crates/doublezero-serviceability-instruction/src/common.rs::build_with_permission): the feed builders route throughbuild_with_permission, and once the append is enabled, feed-authority-only (non-foundation) keys must be guaranteed a Permission account. IfFEED_AUTHORITYis not gated, the rollout won't cover feed, and activating the append would break those keys (authorize()hard-fails withInvalidAccountDatawhen the appended Permission PDA does not exist onchain).Fix
Add
permission_flags::FEED_AUTHORITYtoAUTHORIZE_GATED_FLAGS, and updatelegacy_keys_for_flags/check_legacy_anytogether per the checklist insmartcontract/programs/CLAUDE.md(a#[cfg(test)]test asserts they agree). Also revisitNON_MIGRATED_SUBSYSTEMSinsmartcontract/cli/src/permission/audit.rs.Tripwire
A canary test in
crates/doublezero-serviceability-instruction/src/feed.rsasserts the gap currently exists (!AUTHORIZE_GATED_FLAGS.contains(&FEED_AUTHORITY)); closing this issue will fail that test, forcing the feed builder's doc note to be revisited.