Skip to content

docs: RFC for recurring scheduled payments via delegated authorization - #402

Open
Davidemulo wants to merge 1 commit into
tributary-protocol:mainfrom
Davidemulo:fix/issue-347-recurring-payments-rfc
Open

docs: RFC for recurring scheduled payments via delegated authorization#402
Davidemulo wants to merge 1 commit into
tributary-protocol:mainfrom
Davidemulo:fix/issue-347-recurring-payments-rfc

Conversation

@Davidemulo

Copy link
Copy Markdown
Contributor

Summary

Issue #347 is an expert-difficulty, multi-week epic whose own acceptance criteria requires "a maintainer-approved RFC with an explicit threat model before implementation" as the first gate. This PR delivers that RFC only — no contract code, keeper service, or SDK changes — per the issue's own stated process. Implementation should follow as a separate, later PR once this design is reviewed.

docs/rfc-recurring-payments.md proposes:

  • A Mandate lifecycle (create_mandate/execute_mandate/revoke_mandate/get_mandate) grounded in the existing SplitterContract's actual pay()/require_auth() conventions and id-counter pattern (read from the real contract source, not assumed).
  • Reusing the token's existing SEP-41 approve/transfer_from allowance mechanism for the "may not over-pull" guarantee, rather than inventing custom signature-delegation primitives — the allowance bounds the lifetime total, the mandate's own on-chain interval/runs-completed counters bound the rate. execute_mandate takes no caller-supplied timing/amount data, so a malicious or buggy keeper cannot spoof "it's due."
  • A threat-model table addressing early/over-execution, revocation finality, expiry, race conditions between concurrent keepers, and a griefing analysis for both withheld and malicious-but-harmless permissionless execution.
  • An explicit "skip, not catch-up" recommendation for missed intervals, with reasoning.
  • Open questions flagged for maintainer decision rather than silently assumed: allowance revocation UX after a mandate is revoked, controller/delegation scope, keeper fee responsibility, whether a due-list view function is worth adding, and the unbounded-mandate allowance ceiling.

Closes #347 (the RFC deliverable; full implementation is a follow-up gated on this review per the issue's own criteria)

Test plan

  • Maintainer review of the proposed design and threat model
  • Explicit decisions on the open questions in §5 before implementation begins

tributary-protocol#347)

Issue tributary-protocol#347 is an expert-difficulty, multi-week epic whose own acceptance
criteria requires "a maintainer-approved RFC with an explicit threat
model before implementation" as the first gate. This PR delivers that
RFC only — no contract code, keeper service, or SDK changes — per the
issue's own stated process.

The RFC proposes:
- A Mandate lifecycle (create_mandate/execute_mandate/revoke_mandate/
  get_mandate) grounded in the existing SplitterContract's actual
  pay()/require_auth() conventions and id-counter pattern.
- Reusing the token's existing SEP-41 approve/transfer_from allowance
  mechanism for the "may not over-pull" guarantee, rather than
  inventing custom signature-delegation primitives — the allowance
  bounds the lifetime total, the mandate's own on-chain
  interval/runs-completed counters bound the rate. execute_mandate
  takes no caller-supplied timing/amount data, so a malicious or buggy
  keeper cannot spoof "it's due."
- A threat-model table addressing early/over-execution, revocation
  finality, expiry, race conditions between concurrent keepers, and a
  griefing analysis for both withheld and malicious-but-harmless
  permissionless execution.
- An explicit "skip, not catch-up" recommendation for missed intervals,
  and open questions for maintainer decision: allowance revocation UX,
  controller/delegation scope, keeper fee responsibility, a due-list
  view function, and the unbounded-mandate allowance ceiling.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@Davidemulo
Davidemulo requested a review from Spagero763 as a code owner July 27, 2026 03:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Recurring scheduled payments via delegated authorization and an off-chain keeper

2 participants