[v2][subscription_renewal] Anti-griefing limits on renewal lock acquisition

[Calebux]

Context

acquire_renewal_lock(env, sub_id, lock_timeout) can be called by anyone who can name a sub_id. An attacker can hold the lock for the maximum timeout, release it and immediately re-acquire, permanently preventing a legitimate renewal — a cheap denial of service against a specific user's subscription.

Scope

• Restrict lock acquisition to the subscription owner, a registered agent (via agent-registry scope Renewals), or admin.
• Add a cooldown so the same caller cannot re-acquire immediately after releasing.
• Emit an event on rejected acquisition attempts so griefing is observable off-chain.
• Cover the attack in a regression test.

Acceptance criteria

• Only the owner, a scoped agent, or admin can acquire a renewal lock.
• A re-acquire within the cooldown window returns a typed error.
• A test reproduces the lock-grief loop and asserts it now fails.
• Rejected acquisitions emit an event carrying the caller and sub_id.

Files / areas

contracts/contracts/subscription_renewal/src/lib.rs, contracts/contracts/agent-registry/src/lib.rs

---

Part of the SYNCRO v2 rewrite. Epic: B — Per-contract rewrites.

[CollinsC1O]

@CollinsC1O has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I will love to take on this issue, and provide implementations that will fully resolve it.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @CollinsC1O to this issue.

[testimonyblockchain]

@Nobody426 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer pls assign this task to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Nobody426 to this issue.

[drips-wave]

Congratulations, @CollinsC1O! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @CollinsC1O: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[Calebux]

Reopening this issue for tracking.

PR #1365 has been merged and the contribution is credited — that is settled and nothing here affects it.

The code for this issue is not yet in main. The branch predates the global error-code registry (#1371) and the current contract APIs, so its diff would have reverted attestation and stealth-announcement to 1..n error codes and changed register / init_sub / acquire_renewal_lock signatures across twelve contracts. The merge was therefore resolved to main's tree.

main today validates lock_timeout bounds but still lacks the caller authentication and per-caller limits this issue asks for.

@CollinsC1O — a rebase onto current main, keeping the existing error-code registry, is all this needs. Apologies that the PR was closed rather than reviewed.