docs: RFC for recurring scheduled payments via delegated authorization - #402
Open
Davidemulo wants to merge 1 commit into
Open
docs: RFC for recurring scheduled payments via delegated authorization#402Davidemulo wants to merge 1 commit into
Davidemulo wants to merge 1 commit into
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.mdproposes:Mandatelifecycle (create_mandate/execute_mandate/revoke_mandate/get_mandate) grounded in the existingSplitterContract's actualpay()/require_auth()conventions and id-counter pattern (read from the real contract source, not assumed).approve/transfer_fromallowance 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_mandatetakes no caller-supplied timing/amount data, so a malicious or buggy keeper cannot spoof "it's due."Closes #347 (the RFC deliverable; full implementation is a follow-up gated on this review per the issue's own criteria)
Test plan