[High] Anti-Griefing Controls for Accept-Without-Fill Behaviour

[james2177]

Description:
Detect and penalise solvers that repeatedly accept intents without filling (locking user funds for the fill window) via escalating cooldowns, capacity reductions, and reputation impact.

Problem Statement & Context:
A griefing solver can accept many intents to block competitors and users, paying at most one slash per intent. Pre-slash controls are needed to limit the blast radius.

Scope & Acceptance Criteria:

• Rolling unfilled-accept ratio per solver; thresholds trigger cooldown (no accepts for T), then reduced concurrency cap, then suspension.
• Controls enforced at accept time with clear error codes; all actions audited.
• Parameters configurable; dashboard metrics per solver.
• Out of scope: on-chain penalties beyond existing slashing.

Implementation Guidelines:

1. Key Files/Modules: src/intents/intents.controller.ts (accept), src/solvers/solvers.service.ts, src/intents/intents-sweeper.service.ts.
2. Design/Architecture: Policy engine object evaluated in the accept critical section.
3. Edge Cases/Constraints: Legitimate failures due to chain outages should be excludable by admin incident flag.
4. Testing: Simulation tests with a griefing solver; fairness tests with honest solvers.

Definition of "Done": Common DoD.

Resources:

• Design reference: N/A (backend-only)
• src/intents/intents.service.ts (getAcceptedCountBySolver)

---

Common Definition of "Done" (applies in addition to the criteria above):

• Code written, tested, and documented (TSDoc on public APIs, README/runbook/ADR updates where behaviour changes).
• All acceptance criteria met; npm run lint, npm run typecheck, npm test, npm run test:e2e pass in CI.
• PR follows .github/PULL_REQUEST_TEMPLATE, uses a Conventional Commit title (enforced by commitlint), includes test output / metrics screenshots, and references the issue.
• New env vars are added to .env.example variants and src/config/env.validation.ts (the check:env-drift script must pass).
• Reviewed and approved by at least one CODEOWNER.

[Naajih09]

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

Hi, I'd like to work on this issue. I've gone through the description and acceptance criteria and I'm confident I can deliver it. I'll make sure every acceptance criterion is met and submit a clean, tested PR. Please assign it to me.

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

[Demilade10]

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

Hi I can fix this

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

[drips-wave]

Congratulations, @Demilade10! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @Demilade10: 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 🌊