Creator close rights and rent recovery

Close behavior is part of product correctness

Many systems treat close actions as housekeeping. In protocol infrastructure, close semantics are part of correctness because they determine lifecycle completion, account ownership, and rent recovery behavior.

Ambiguous close authority creates confusing states for users and operations teams, especially when business closure and on-chain closure are not synchronized.

Why creator-bound close rights are cleaner

Assigning close authority to the payment creator gives one deterministic actor responsibility for terminal lifecycle execution. This simplifies both governance and support workflows.

• Single accountable actor for close instruction execution.
• Rent recovery aligned to lifecycle owner.
• Lower chance of competing close attempts and UI confusion.

Business-state closed vs PDA closed

A payment can be closed from a business perspective while the PDA still exists on-chain. These are separate facts and should be tracked separately in history and detail views.

• Business closure reflects settlement finality.
• PDA closure reflects successful close instruction execution.
• Only successful close instruction should flip pdaClosed to true.

Operational impact on history views

History tables should model closure states in a way that matches chain truth and actor rights. Creator-based filtering is critical for actionable close queues.

• Require Close lists should filter by creator and pdaClosed=false.
• Status badges should avoid implying closure when only business state changed.
• Close CTA should appear only for authorized creator context.

Support and diagnostics

Explicit close semantics reduce support ambiguity. Agents can quickly distinguish unresolved settlement issues from pending lifecycle cleanup.

• Track close-ready age and failure reasons.
• Log signer identity for close attempts.
• Expose deterministic reason codes for failed close operations.