L-1: Post-#105 dead weight: portfolio/nft_pda still marked writable in transfer-hook extra-metas

[v1ktorrr0x]

Bug

PR #105 (escrow-at-mint) removed the B-3 ownership CPI from the transfer hook. process_execute is now validation-only and performs no writes. Yet:

• ExtraAccountMetaList still declares entry 5 (PositionNft PDA) and entry 6 (Portfolio) as writable (processor.rs:655-658)
• RepairExtraMetas docs (instruction.rs:119-124) justify its existence entirely by: "the transfer hook CPIs into percolator-prog with TransferPortfolioOwnership (tag 72), which mutates owner… Without portfolio writable, the CPI fails."

That CPI no longer exists in the hook.

Source Impact

Not exploitable — the hook can't write the portfolio during a Token-2022 CPI anyway. But every NFT transfer now takes an unnecessary write-lock on the shared portfolio account, serializing against other portfolio transactions based on an obsolete requirement.

Fix

1. Flip entries 5 and 6 in build_extra_account_metas / RepairExtraMetas to read-only
2. Verify the wrapper no longer needs them writable for B-3 (which under escrow it shouldn't at transfer time)
3. Rewrite the RepairExtraMetas rationale to reflect Design: minting does not escrow the position — minter retains direct control until first NFT transfer (contradicts documented custody) #105's custody model

Labels: cleanup, performance

[dcccrypto]

Resolved — closing. One half was implemented; the other was correctly rejected by a later fix, and the deployed code now documents both.

Verified against deployed 215842e, EXTRA_META_ENTRY_FLAGS (processor.rs:260):

(false, true),  // 5: PositionNft PDA — writable (hook writes last_holder)
(false, false), // 6: Portfolio account — read-only (hook only reads)

Entry 6 (Portfolio) — your finding, applied. It is read-only now. The rationale at :258 matches yours exactly: "the hook performs no invoke/invoke_signed and never mutably borrows portfolio — it only reads it to check the NFT PDA binding."

Entry 5 (PositionNft PDA) — must stay writable, and this post-dates your report. You filed on 2026-06-24 against the post-#105 state, where process_execute was genuinely validation-only. #152/#153 subsequently added nft_state.last_holder = new_owner to process_execute, so the hook does write that account again — on every transfer that provably moved the token, including marketplace/orderbook CPI transfers. :251-256:

Entry 5 (PositionNft PDA) must stay writable: #105 removed the f_snap_at_mint write, but #152/#153 added nft_state.last_holder = new_owner in process_execute … A read-only meta there makes each such transfer fail.

So making entry 5 read-only today would break every transfer. Your premise was accurate when written; the code moved under it.

Worth noting the table is now shared between the mint path and RepairExtraMetas precisely so the two cannot diverge — RepairExtraMetas is permissionless, so a divergence would let any caller rewrite a live NFT's metas into a shape the hook cannot use.