From 56e2612bb182e1157e3b5536650b68c7b76a651b Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 30 Aug 2026 18:40:42 +0200 Subject: [PATCH 1/2] docs: clarify backend guardrails for issue payouts --- README.md | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 0cef956..6d24e66 100644 --- a/README.md +++ b/README.md @@ -708,24 +708,22 @@ paths available where the contract supports them. See: ### Operational guardrails and backend responsibilities -This repo intentionally keeps the contracts narrow and stateless about -external business rules. The on-chain contracts do not attempt to -reconcile GitHub state, duplicate issue funding across products, or -recipient trustline validity before a payout. That means the following -points are important operational rules for the surrounding backend and -operator tooling: +This repo intentionally keeps the contracts narrow and focused on on-chain +money movement. The contracts do not attempt to reconcile GitHub state, +prevent duplicate issue commitments across product surfaces, or verify a +recipient can receive the token before a payout is submitted. + +That means the backend and surrounding operator tooling remain the first line +of defense for workflow integrity: - `mergefi-backend` should treat a GitHub issue as committed once, even if - the same underlying work could be routed through multiple contract - entrypoints in future; -- any payout path that depends on an external recipient being able to - receive the token should be preflight-checked before submitting the - on-chain transaction; -- any contract-level invariant that is enforced in code should be treated as - the minimum guarantee, not a substitute for the backend's own - bookkeeping and validation. + the same underlying work might later be routed through multiple entrypoints; +- any payout path that depends on an external recipient being able to receive + the token should be preflight-checked before submitting the transaction; +- contract-level invariants are the minimum guarantee, not a substitute for the + backend's own bookkeeping and validation. This keeps the contract surface easier to reason about while making the -job of the backend explicit: it remains the system-of-record for -workflow state and the first line of defense against accidental -double-commitment or invalid recipient conditions. +backend's role explicit: it remains the system of record for issue lifecycle +and the clearest place to catch accidental double-commitment or invalid +recipient conditions before they hit the chain. From f1487106c819215a3d6efc1765c73d8b5c9a0545 Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 31 Aug 2026 13:29:33 +0200 Subject: [PATCH 2/2] issues fixed --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index 6d24e66..6b011d1 100644 --- a/README.md +++ b/README.md @@ -727,3 +727,7 @@ This keeps the contract surface easier to reason about while making the backend's role explicit: it remains the system of record for issue lifecycle and the clearest place to catch accidental double-commitment or invalid recipient conditions before they hit the chain. + +## Recent Changes +- Ongoing improvements and fixes as part of active development. +- See commit history and open issues for detailed change tracking.