distribute-tokens
Skill20 starsChanged 25 days agoMITView on GitHub
Two-phase contributor rewards - plan builds a tier-priced payout from the repo's merged-PR ranking; send executes it on-chain via Bankr Wallet API with per-recipient idempotency and dry-run.
- Reads credentials
- Sends data out
3 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- aeonfun/aeonedited, first seen Oct 20, 2026
- MiroShark/miroshark-aeonword for word, first seen Oct 17, 2026
- aaronjmars/aeonedited, first seen Oct 8, 2026
Other versions3 projects use a version of this.
Word for word · 1
- MiroShark/miroshark-aeon★ 20100% same
Edited · 2
- aaronjmars/aeon★ 789100% same
- aeonfun/aeon★ 789100% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository88 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- aeonSkill
- action-converterSkill
- aeon-doctorSkill
- aeon-updateSkill
- articleSkill
- auto-mergeSkill
- autoresearchSkill
- auto-workflowSkill
- base-mcpSkill
- bd-radarSkill
- canister-auditSkill
- changelogSkill
- competitor-monitorSkill
- cortx-reliabilitySkill
- create-proveSkill
- create-skillSkill
- defi-overviewSkill
- deploy-prototypeSkill
- deploy-uni-hookSkill
- digestSkill
- executor-mcpSkill
- featureSkill
- fetch-tweetsSkill
- finance-district-mcpSkill
- fleet-controlSkill
- floviaSkill
- fork-fleetSkill
- github-filing-registrySkill
- github-monitorSkill
- github-trendingSkill
- glim-mcpSkill
- heartbeatSkill
- higgsfieldSkill
- holdingsSkill
- hunter-22Skill
- idea-forgeSkill
- idea-pipelineSkill
- inbox-triageSkill
- install-skillSkill
- investigation-reportSkill
- last30Skill
- memory-flushSkill
- mention-radarSkill
- monitor-polymarketSkill
- narrative-convergenceSkill
- narrative-trackerSkill
- onchain-monitorSkill
- operator-scorecardSkill
- pack-submitSkill
- picks-trackerSkill
- pm-manipulationSkill
- posthog-errorsSkill
- price-alertSkill
- pr-reviewSkill
- pr-triageSkill
- remotionSkill
- reply-makerSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
33 rules. About 0 are common, 5 are distinctive, and 28 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
28
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 52
If memory/distributions.yml is missing when the send phase needs it, bootstrap with a commented template (see Send Step 1) and exit cleanly …
- Very specific: line 100
Default token: USDC on Base.
- Very specific: line 104
Read memory/MEMORY.md and scan the last ~3 days of memory/logs/ for anything already reported (don't re-report the same signal).
- Very specific: line 118
Phase prefix: If ${var} starts with plan: → PHASE=plan, strip plan:.
- Very specific: line 151
If zero merged PRs in the window → log CONTRIBUTOR_REWARD_NO_MERGED_PRS — week ${TARGET_WEEK} to memory/logs/${today}.md, exit silently (no …
- Very specific: line 152
If the GitHub API is unreachable (see Network note for the gh api → WebFetch fallback) → log CONTRIBUTOR_REWARD_API_FAIL, notify the …
- Very specific: line 180
Look up base_amount from the tier table (rank 1→25, 2→15, 3→10, 4-5→5).
- Very specific: line 181
If first_pr_marker == "✨" AND login ∉ first_pr_bonus_paid → set first_pr_bonus = true, amount = base_amount + 5.
- Very specific: line 184
If weeks[TARGET_WEEK] already exists in state → this week was already processed.
- Very specific: line 186
If diffs are empty (same logins, same amounts) → log CONTRIBUTOR_REWARD_ALREADY_PROCESSED — week ${TARGET_WEEK}, exit silently (no notify).
- Very specific: line 189
If the plan is empty (zero eligible contributors after threshold + dedup) → log CONTRIBUTOR_REWARD_NO_ELIGIBLE and exit silently.
- Very specific: line 212
If MODE=dry-run (plan-only dry-run, i.e.
- Very specific: line 218
Read memory/distributions.yml.
- Very specific: line 251
If a list named contributors-${TARGET_WEEK} already exists in the YAML, replace it wholesale (the plan is the authoritative current state).
- Very specific: line 255
Verify the write by re-reading the file and confirming the list is present and has len(recipients) == len(plan).
- Distinctive: line 263
Write the whole updated JSON in one Write call (never piecemeal edits or a shell redirect) so partial writes can't corrupt state.
- Very specific: line 299
Read memory/state/distributions.json (if present) for send idempotency state before doing anything.
- Very specific: line 303
If the send target starts with dry-run:, set MODE=dry-run and LABEL=${target#dry-run:}.
- Very specific: line 304
If memory/distributions.yml missing → Bootstrap: write the example config from the Config section (commented out so it's inert), notify …
- Very specific: line 310
If BANKR_API_KEY not set → DISTRIBUTE_TOKENS_ERROR — BANKR_API_KEY not configured, log, exit.
- Very specific: line 350
After RESOLVE, print the plan to the console (and to the dry-run notification if MODE=dry-run):
- Very specific: line 362
If MODE=dry-run: notify the plan, log, exit DISTRIBUTE_TOKENS_DRY_RUN.
- Very specific: line 364
If 0 rows are READY (everything deduped/failed) → notify the plan, log, exit DISTRIBUTE_TOKENS_OK — nothing to send.
- Very specific: line 432
Run Phase A in execute mode (A1–A8).
- Very specific: line 433
If Phase A took a terminal early exit — CONTRIBUTOR_REWARD_NO_LEADERBOARD, _STALE_LEADERBOARD, _PARSE_FAIL, _NO_ELIGIBLE, or …
- Distinctive: line 437
Run Phase A in dry-run mode (A1–A5) to compute the plan — but per the A5 note, do not notify or exit here.
- Very specific: line 496
Idempotency is non-negotiable: Always read memory/state/distributions.json before sending.
- Distinctive: line 497
Treat the 24h Bankr rate limit (100/day standard) as a hard cap.
- Very specific: line 498
Never send if preflight balance is < total_required * 1.05.
- Distinctive: line 499
Never use the Agent API for transfers (deprecated).
- Distinctive: line 500
Never abort the RESOLVE phase on a single bad recipient — collect all errors, present them, then let the executor skip.
- Very specific: line 505
No silent overwrites of distributions.yml: If the file exists and is malformed, fail loudly rather than rewriting.
- Very specific: line 511
Add a Bankr Agent API "wallet-linked?" pre-filter in the plan phase so contributors without linked wallets are flagged in the notification …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- autoresearch: variation C — robustness via per-recipient idempotency state, two-phase resolve→execute, dry-run, retries, 403/429 handling, recovery. Merged: contributor-reward's tier-priced reward-computation folded in as the plan/input phase; the on-chain distribution stays the execute phase. -->${var} — Phase + target selector. Grammar:
[plan:|all:][dry-run:]<target>
- `` (empty) /
<label>/dry-run:<label>→ send phase: distribute a list frommemory/distributions.yml(empty = first list). [default — no prefix]plan:/plan:<week>/plan:dry-run/plan:dry-run:<week>→ plan phase only: compute rewards from the repo's merged PRs and write the list intomemory/distributions.yml.all:/all:<week>/all:dry-run/all:dry-run:<week>→ plan then send in one run.
<label>is a distribution-list label (e.g.contributors-2026-W17).<week>is an ISO week (2026-W17); empty<week>= most recent completed ISO week.dry-run:previews without side effects (no yml/state writes in plan; no transfers in send).
Why this design
This skill owns the whole contributor flywheel: who deserves what (plan) and moving the money (send). It is split into two phases that can run independently or chained.
Plan phase — the wiring the project was missing. Merged PRs already name the people moving the project, but shipped work had no path to a wallet credit. The plan phase is that wiring: it ranks contributors by the PRs they merged in the target week (straight from the GitHub API), prices each eligible contributor against a tier table, and writes a labelled list into memory/distributions.yml — the exact file the send phase reads. Keeping a human-visible diff on memory/distributions.yml between plan and execution is the cheapest possible audit trail when real money is involved: the plan lands in git, and the operator (or all: mode, or a chained step) runs the send next.
Send phase — this moves real money. The biggest failure mode is double-sending (re-runs, retries after partial failures, day-rollover bypass of "skip if today" logic) or sending into a black hole (no preflight balance, deprecated API path, missing handle resolution). The send phase therefore:
- Persists per-recipient idempotency state in
memory/state/distributions.jsonkeyed on(list, recipient, date_utc)with the txHash. A successful transfer is never re-sent within the same UTC day, even across re-runs or workflow restarts. - Two-phase execution: RESOLVE (validate config, key, balance, resolve all handles → addresses, build plan) → EXECUTE (send each transfer, persist state after each one). RESOLVE failures abort before any send.
- Dry-run mode outputs the full plan with no transfers.
- Wallet API only for actual transfers — Bankr's docs deprecate the Agent API for transfers. Agent API is used only for handle→address resolution.
The two phases stay decoupled by design: the send phase is the only sanctioned transfer path and owns the idempotency state file, so the plan phase never touches transfer state. all: mode simply runs plan then send in sequence (plan writes the list, send reads it), so nothing is re-implemented.
Config
Reads two independent config/state surfaces depending on phase:
memory/distributions.yml— the distribution lists (read by send, written by plan).- The plan phase computes its ranking live from the repo's merged PRs via the GitHub API — no input file (see Phase A).
memory/state/distributions.json— per-recipient send idempotency (read/written by send).memory/state/contributor-reward-state.json— plan idempotency + first-PR-bonus history (read/written by plan).
If memory/distributions.yml is missing when the send phase needs it, bootstrap with a commented template (see Send Step 1) and exit cleanly with DISTRIBUTE_TOKENS_OK — bootstrapped distributions.yml; edit and re-run.
# memory/distributions.yml
defaults:
token: USDC # USDC | ETH (Base only)
amount: "5"
chain: base
lists:
contributors:
description: "Weekly contributor rewards"
token: USDC
amount: "10"
recipients:
- handle: "@alice_dev" # Twitter/X — resolved via Bankr Agent API
amount: "15"
- handle: "@bob_builder"
- address: "0x742d...5678" # direct EVM address — preferred path
label: "Charlie"
amount: "20"Required secrets
| Secret | Phase | Purpose |
BANKR_API_KEY | send (and any dry-run send, which still preflights) | Bankr API key (bk_...). Must be read-write with Wallet API enabled. Read-only keys → 403. Not needed for plan: (pure local file I/O). |
Token addresses on Base
- USDC:
0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 - ETH (native):
tokenAddress: "0x0000000000000000000000000000000000000000",isNativeToken: true
Tier pricing (plan phase)
| Rank in leaderboard | Reward (USDC) |
| 1 | 25 |
| 2 | 15 |
| 3 | 10 |
| 4 | 5 |
| 5 | 5 |
First-PR bonus: +5 USDC, additive, applied once-ever per login (tracked in memory/state/contributor-reward-state.json). Rewards landing your first merged upstream PR — the highest-leverage signal in the leaderboard scoring.
Eligibility floor: score ≥ 10 AND the contributor must own a non-empty @handle (logins without @ prefix in the table are skipped — bots and parsing artifacts). A single merged upstream PR (+10) qualifies — the goal is to reward shipped work, not gate on volume.
Default token: USDC on Base. Operator can override per-recipient amounts in memory/distributions.yml after the plan is written if a special bonus is warranted.
Read memory/MEMORY.md and scan the last ~3 days of memory/logs/ for anything already reported (don't re-report the same signal).
Step 0 — Parse the selector and dispatch
Shell shape. Each Bash call is one allowed command (pipes are fine). The run refuses a call that sets a variable (today=$(date ...), JOB=$(./secretcurl ...), RESP=$(./secretcurl ...)), uses if / for / while or [ ... ] tests, calls sleep or sed, or joins commands with ;, && or ||, and each refusal costs a model turn. So get a date with a bare date call and write the printed value into later commands; write the repo, week bounds, logins, handles, job ids, addresses and amounts into each command literally (the <TODAY>, <JOB_ID>, <ADDR> style placeholders in the snippets); poll a Bankr job by repeating one call, never a loop; wait with a one-line python3 -c "import time; time.sleep(N)" call; create and change files under memory/ with Write/Edit.
Resolve time anchors up front with one bare call:
date -u +%FIt prints today; today_utc is the same value. Later steps write it in literally as <TODAY> (shown as ${today} / ${today_utc} in the templates below).
Parse ${var}:
- Phase prefix. If
${var}starts withplan:→PHASE=plan, stripplan:. Else if it starts withall:→PHASE=all, stripall:. Else →PHASE=sendand do not strip anything (the remaining legacy grammar is parsed by the send phase itself). - Dry-run. For
PHASE=plan/all: if the remainder starts withdry-run(optionallydry-run:), setMODE=dry-runand strip that token; elseMODE=execute. (ForPHASE=send, the send phase parsesdry-run:itself — see Send Step 1.) - Target.
PHASE=send: the (unstripped) var is the send target —dry-run:<label>or<label>or empty.PHASE=plan/all: the remainder is an optional<week>. If it matches^\d{4}-W\d{2}$, setTARGET_WEEK=<week>; else rundate -u +%G-W%Vas its own Bash call and take the printed value asTARGET_WEEK(ISO-8601 week-numbering year + week -%G/%Vnot%Y/%U, so Monday-anchored weeks roll over correctly across years).
Dispatch:
PHASE=plan→ run Phase A only.PHASE=send→ run Phase B only.PHASE=all→ run Phase C (A then B).
Selector examples: `` → send first list · contributors-2026-W17 → send that list · dry-run:contributors-2026-W17 → dry-run send · plan: → plan most recent leaderboard · plan:2026-W17 → plan that week · plan:dry-run → plan preview · all: → plan + send most recent · all:dry-run:2026-W17 → full end-to-end preview for that week.
Phase A — Plan (reward computation)
Ranks the target week's merged-PR authors (GitHub API) and turns that ranking into a tier-priced list in memory/distributions.yml.
A1. Determine the target week and repo
REPO- the running instance's repo. Runecho "$GITHUB_REPOSITORY"as its own call; if it printsowner/repo, that isREPO. If it prints an empty line, rungit config --get remote.origin.urlas its own call and take theowner/repopart of the URL yourself (drop the host prefix and any trailing.git).TARGET_WEEKcomes from the selector; empty = the most recent completed ISO week (the last full Mon–Sun). Compute its UTC boundsWEEK_START..WEEK_ENDas ISO datetimes (YYYY-MM-DDT00:00:00Z).
A2. Rank contributors by merged PRs in the week
Compute the ranking directly from GitHub — no upstream skill or article required.
- Fetch every PR merged inside the window, by author (one call, with
REPO,WEEK_STARTandWEEK_ENDwritten in literally):gh api -X GET search/issues -f q="repo:<REPO> is:pr is:merged merged:<WEEK_START>..<WEEK_END>" --paginate --jq '.items[].user.login' - Drop bot authors (
*[bot],dependabot*,github-actions*). Count each remaining login's merged PRs →score. Rank byscoredescending; tie-break by earliest merge time, then login ascending. - First-PR ✨ per ranked login - did they have any prior merged PR to the repo? One call per login, the login written in literally:
gh api -X GET search/issues -f q="repo:<REPO> is:pr is:merged author:<LOGIN> merged:<<WEEK_START>" --jq '.total_count'→0means this is their first-ever merged PR (setfirst_pr_marker = ✨). - If zero merged PRs in the window → log
CONTRIBUTOR_REWARD_NO_MERGED_PRS — week ${TARGET_WEEK}tomemory/logs/${today}.md, exit silently (no notify). Nothing shipped, nothing to reward. - If the GitHub API is unreachable (see Network note for the
gh api→ WebFetch fallback) → logCONTRIBUTOR_REWARD_API_FAIL, notify the operator, exit.
A3. Load plan idempotency state
// memory/state/contributor-reward-state.json
{
"weeks": {
"2026-W17": {
"written_at": "2026-04-26T09:00:00Z",
"label": "contributors-2026-W17",
"source": "github:merged-prs",
"rewards": [
{ "login": "alice_dev", "rank": 1, "score": 47, "amount": "25", "first_pr_bonus": false },
{ "login": "bob_builder", "rank": 2, "score": 31, "amount": "20", "first_pr_bonus": true }
]
}
},
"first_pr_bonus_paid": ["bob_builder", "carol_eng"]
}Bootstrap with {"weeks": {}, "first_pr_bonus_paid": []} if the file doesn't exist.
A4. Compute the plan
For each ranked login with rank ≤ 5 AND score ≥ 1 (at least one merged PR):
- Look up
base_amountfrom the tier table (rank 1→25, 2→15, 3→10, 4-5→5). - If
first_pr_marker == "✨"ANDlogin ∉ first_pr_bonus_paid→ setfirst_pr_bonus = true,amount = base_amount + 5. Otherwisefirst_pr_bonus = false,amount = base_amount. - Build row:
{ rank, login, score, base_amount, first_pr_bonus, amount }.
If weeks[TARGET_WEEK] already exists in state → this week was already processed. Diff the current plan against state.weeks[TARGET_WEEK].rewards keyed on login:
- If diffs are empty (same logins, same amounts) → log
CONTRIBUTOR_REWARD_ALREADY_PROCESSED — week ${TARGET_WEEK}, exit silently (no notify). Idempotent re-run. - If diffs exist (leaderboard re-ran after first reward write — late tweet bumped a score, etc.) → flag
RE_PROCESS. Continue but don't re-pay anyone already instate.weeks[TARGET_WEEK].rewards; add only the deltas. New entries get full reward; existing entries with bumped amounts get the delta (e.g. moved from rank 3→2 = additional 5 USDC top-up). Demoted entries are not clawed back.
If the plan is empty (zero eligible contributors after threshold + dedup) → log CONTRIBUTOR_REWARD_NO_ELIGIBLE and exit silently.
A5. Render the plan
Contributor Reward Plan — ${TARGET_WEEK} (${MODE})
Source: ${LEADERBOARD_FILE}
Tier: rank 1=25, 2=15, 3=10, 4-5=5 USDC; first-PR bonus +5 once per login.
✓ #1 @alice_dev score 47 → 25 USDC [NEW]
✓ #2 @bob_builder score 31 → 20 USDC (15 + 5 first-PR)[NEW + BONUS]
✓ #3 @carol_eng score 24 → 10 USDC [NEW]
✓ #4 @dave_ops score 18 → 5 USDC [NEW]
↻ #5 @eve_hax score 14 → 5 USDC [DEDUP — already in state]
Total to write: 60 USDC across 4 new entries.
Total in state for ${TARGET_WEEK} after write: 5 entries, 65 USDC.
Next: distribute-tokens "dry-run:contributors-${TARGET_WEEK}" (preview)
distribute-tokens "contributors-${TARGET_WEEK}" (execute)If MODE=dry-run (plan-only dry-run, i.e. plan:dry-run...): notify this plan with header *Contributor Reward Plan — ${TARGET_WEEK}* — DRY RUN, log to memory/logs/${today}.md, exit CONTRIBUTOR_REWARD_DRY_RUN. Do not touch memory/distributions.yml or the state file.
all:mode note: when this phase runs as part ofall:withMODE=dry-run, do not notify here and do not exit — hand the computed plan rows straight to Phase B (see Phase C). Whenall:runs withMODE=execute, continue through A6–A8 normally but replace the trailingNext:line in the A9 notification withDistributing now (phase=all)….
A6. Update memory/distributions.yml (skipped when MODE=dry-run)
Read memory/distributions.yml. If missing → bootstrap with the standard header (matching the send-phase bootstrap style):
# memory/distributions.yml
defaults:
token: USDC
amount: "5"
chain: base
lists:Compute the new list block:
contributors-${TARGET_WEEK}:
description: "Weekly contributor rewards for ${TARGET_WEEK} (auto-generated from merged-PR ranking)"
token: USDC
amount: "5"
recipients:
- handle: "@alice_dev"
amount: "25" # rank 1
- handle: "@bob_builder"
amount: "20" # rank 2 + first-PR bonus
- handle: "@carol_eng"
amount: "10" # rank 3
- handle: "@dave_ops"
amount: "5" # rank 4Recipient ordering matches plan order (rank ascending). Per-recipient amount is required so the send phase picks up the tier-priced value rather than falling back to the list default.
Update strategy:
- If a list named
contributors-${TARGET_WEEK}already exists in the YAML, replace it wholesale (the plan is the authoritative current state). - Otherwise append the block under
lists:(preserving existing lists — never rewrite them). - Use a YAML-aware update: first check the existing file parses with one call,
python3 -c "import yaml; yaml.safe_load(open('memory/distributions.yml'))", then make a careful block replacement with Edit keyed on the^ contributors-<TARGET_WEEK>:$line (or insert the block underlists:with Edit). If YAML parse fails on the existing file → log error, do not write, notify the operator (file is hand-edited; auto-edit would clobber).
Verify the write by re-reading the file and confirming the list is present and has len(recipients) == len(plan).
A7. Update plan state file (skipped when MODE=dry-run)
Atomically write the updated state JSON to memory/state/contributor-reward-state.json:
- Set
weeks[TARGET_WEEK]={ written_at: now_utc, label, source: "github:merged-prs", rewards: [{login, rank, score, amount, first_pr_bonus}, ...] }(full replacement on RE_PROCESS, otherwise additive). - Append any logins where
first_pr_bonus == truetofirst_pr_bonus_paid(deduplicated).
Write the whole updated JSON in one Write call (never piecemeal edits or a shell redirect) so partial writes can't corrupt state.
A8. Notify (plan-only execute)
*Contributor Reward Plan — ${TARGET_WEEK}*
Wrote ${N_NEW} new entries (${TOTAL_USDC} USDC) to memory/distributions.yml as `contributors-${TARGET_WEEK}`.
Top of plan:
#1 @alice_dev — 25 USDC
#2 @bob_builder — 20 USDC (✨ first-PR bonus)
#3 @carol_eng — 10 USDC
#4 @dave_ops — 5 USDC
${IF_DEDUP}
Source: ${LEADERBOARD_FILE}
First-PR bonuses awarded: ${LIST_OR_NONE}
Next: run `distribute-tokens dry-run:contributors-${TARGET_WEEK}` to preview, then drop the `dry-run:` prefix to execute.
Plan: https://github.com/${GITHUB_REPOSITORY}/blob/main/memory/distributions.ymlSuppress the ${IF_DEDUP} line when no entries were deduped. Use $GITHUB_REPOSITORY env var for the link target. Send via ./notify.
Significance gate: notify only when N_NEW ≥ 1. Re-process runs that produced zero new entries (RE_PROCESS with all rewards already paid) → silent log only. (In all: execute, skip this notify per the A5 note; the send-phase summary carries the report.)
Then log (see Log) and exit CONTRIBUTOR_REWARD_OK.
Phase B — Send (on-chain distribution)
Reads a list from memory/distributions.yml and executes transfers via Bankr Wallet API. This phase moves real money — idempotency and preflight are non-negotiable.
Read memory/state/distributions.json (if present) for send idempotency state before doing anything.
B1. Parse the send target and load config
- If the send target starts with
dry-run:, setMODE=dry-runandLABEL=${target#dry-run:}. OtherwiseMODE=executeandLABEL=${target}. (When entered from Phase C,LABELandMODEare set by Phase C instead — see Phase C.) - If
memory/distributions.ymlmissing → Bootstrap: write the example config from the Config section (commented out so it's inert), notifyDISTRIBUTE_TOKENS_OK — bootstrapped distributions.yml; edit and re-run, log, exit. - Parse YAML. If
LABELempty, use the first list. Else find the matching list. If not found → notifyDISTRIBUTE_TOKENS_ERROR — list '${LABEL}' not found, log, exit. - (
today_utcwas resolved in Step 0.)
B2. Pre-flight: key, write access, balance
If BANKR_API_KEY not set → DISTRIBUTE_TOKENS_ERROR — BANKR_API_KEY not configured, log, exit.
./secretcurl -fsS "https://api.bankr.bot/wallet/me" -H "X-API-Key: {BANKR_API_KEY}"It prints the /wallet/me body (ME); on an HTTP error, curl's -fsS prints the status code instead.
- HTTP 403 →
DISTRIBUTE_TOKENS_ERROR — API key is read-only; needs wallet write scope, exit. - HTTP 429 →
DISTRIBUTE_TOKENS_ERROR — rate-limited at /wallet/me; aborting, exit. - Network failure → use WebFetch fallback. If still failing →
DISTRIBUTE_TOKENS_ERROR — Bankr /wallet/me unreachable, exit.
./secretcurl -fsS "https://api.bankr.bot/wallet/portfolio?chain=base" -H "X-API-Key: {BANKR_API_KEY}"It prints the portfolio body (PORTFOLIO).
Extract sender's balance for the target token. Compute total_required from the recipient list (sum of per-recipient amounts, applying overrides). If balance < total_required * 1.05 (5% headroom for any failed retries) → DISTRIBUTE_TOKENS_ERROR — insufficient balance: have X, need Y ${TOKEN}, exit. Do not start a partial run.
B3. RESOLVE phase — build the plan
For each recipient, build a row: {key, type, amount, token, target_address, label, status} where key = sha256("${LABEL}|${recipient_id}|${today_utc}") and recipient_id is the handle (lowercase) or address (lowercase).
Idempotency check (before resolving): if memory/state/distributions.json contains key with status=completed → mark row SKIPPED_DEDUP, carry forward the prior txHash.
Handle resolution (@username): use Bankr Agent API to look up the linked wallet. One call per handle, the handle written in literally:
./secretcurl -fsS -X POST "https://api.bankr.bot/agent/prompt" \
-H "X-API-Key: {BANKR_API_KEY}" -H "Content-Type: application/json" \
-d '{"prompt":"What is the EVM address linked to <HANDLE> on Base? Respond with only the address."}' | jq -r '.jobId'It prints JOB_ID. Then poll the job: repeat this one call, with JOB_ID written in literally, until its .status is completed or failed, at most 15 times (the old every-2s, max-30s budget):
./secretcurl -fsS "https://api.bankr.bot/agent/job/<JOB_ID>" -H "X-API-Key: {BANKR_API_KEY}"It prints the job body (R). If .status is still pending, wait 2 s with one python3 -c "import time; time.sleep(2)" call, then repeat. After the 15th call without completed or failed, stop polling and treat the handle as unresolved (below).
Extract the address from the response (regex 0x[a-fA-F0-9]{40}). If extraction fails → mark row RESOLVE_FAILED with reason NO_LINKED_WALLET. Do not abort the whole plan; let the executor skip this row.
Address resolution (0x...): validate format ^0x[a-fA-F0-9]{40}$. If invalid → RESOLVE_FAILED reason BAD_ADDRESS.
After RESOLVE, print the plan to the console (and to the dry-run notification if MODE=dry-run):
Plan for list '${LABEL}' (${today_utc}):
✓ @alice_dev → 0x1234... — 15 USDC [READY]
✓ Charlie → 0x742d... — 20 USDC [READY]
↻ @bob_builder → 0xabcd... — 10 USDC [SKIPPED_DEDUP] (tx 0xprev...)
✗ @inactive → ? [RESOLVE_FAILED: NO_LINKED_WALLET]
Summary: 2 to send (35 USDC), 1 deduped, 1 unresolvable. Sender balance: 100 USDC.If MODE=dry-run: notify the plan, log, exit DISTRIBUTE_TOKENS_DRY_RUN. Do not proceed.
If 0 rows are READY (everything deduped/failed) → notify the plan, log, exit DISTRIBUTE_TOKENS_OK — nothing to send.
B4. EXECUTE phase
For each READY row, send via /wallet/transfer (the only sanctioned transfer endpoint per Bankr docs). One call per row, with that row's address, token address, amount and native flag written in literally:
./secretcurl -fsS -X POST "https://api.bankr.bot/wallet/transfer" \
-H "X-API-Key: {BANKR_API_KEY}" -H "Content-Type: application/json" \
-d '{"recipientAddress":"<ADDR>","tokenAddress":"<TOKEN_ADDR>","amount":"<AMT>","isNativeToken":<IS_NATIVE>}'It prints the response body (RESP), or curl's HTTP error code under -fsS. The sleeps below are each one python3 -c "import time; time.sleep(N)" call; a retry is the same transfer call again.
Outcome handling:
- HTTP 200 +
success: true→ statusCOMPLETED, storetxHash. Persist the state file immediately (write after every recipient, not at the end — survives mid-run crashes). - HTTP 200 +
success: false→ statusFAILED, storeerrorfield as reason. - HTTP 403 → status
FAILEDreasonREAD_ONLY_KEY. Abort remaining rows (key won't suddenly gain write access). Persist state. - HTTP 429 → status
FAILEDreasonRATE_LIMIT. Sleep 60s, retry once. If still 429, abort remaining (rolling-window quota exhausted). Persist state. - HTTP 5xx or network error → retry once after 10s. If still failing, status
FAILEDreasonAPI_ERROR. - Any other → status
FAILEDreasonHTTP_${code}.
State file shape (memory/state/distributions.json, append/upsert):
{
"contributors|@alice_dev|2026-04-20": {
"list": "contributors",
"recipient": "@alice_dev",
"address": "0x1234...",
"amount": "15",
"token": "USDC",
"status": "completed",
"txHash": "0xabc...",
"timestamp": "2026-04-20T12:34:56Z"
}
}B5. Build summary notification
Top line is a verdict: COMPLETE (all READY succeeded) / PARTIAL (some failed) / FAILED (none succeeded) / DRY_RUN / NOTHING_TO_SEND.
*Token Distribution — ${today_utc}* — VERDICT
List: ${LABEL} (${description})
Token: ${TOKEN} on Base
Sent: ${total_sent} ${TOKEN} to ${n_success}/${n_attempted} recipients
Skipped (already sent today): ${n_dedup}
Unresolvable: ${n_unresolved}
✓ @alice_dev — 15 USDC ([tx](https://basescan.org/tx/0xabc...))
✓ Charlie (0x742d...) — 20 USDC ([tx](https://basescan.org/tx/0x123...))
↻ @bob_builder — 10 USDC (already sent: [tx](https://basescan.org/tx/0xprev...))
✗ @inactive_user — RESOLVE_FAILED: NO_LINKED_WALLET
Sender balance after: ${remaining} ${TOKEN}Suppress empty sections (no Skipped: line if n_dedup=0, etc.). Send via ./notify. Then log (see Log) and exit with the send verdict code (DISTRIBUTE_TOKENS_COMPLETE / DISTRIBUTE_TOKENS_PARTIAL / DISTRIBUTE_TOKENS_OK for nothing-to-send).
Phase C — All (plan then send)
Runs Phase A, then feeds it into Phase B in one invocation. TARGET_WEEK and MODE come from Step 0.
all: execute (MODE=execute):
- Run Phase A in execute mode (A1–A8). It writes
contributors-${TARGET_WEEK}intomemory/distributions.yml+ state and posts the plan notification (with the A5-note tweak: trailing line becomesDistributing now (phase=all)…). - If Phase A took a terminal early exit —
CONTRIBUTOR_REWARD_NO_LEADERBOARD,_STALE_LEADERBOARD,_PARSE_FAIL,_NO_ELIGIBLE, or_ALREADY_PROCESSEDwith zero new entries — stop: there is nothing to send. Log and exit with that Phase A code. - Otherwise set
LABEL="contributors-${TARGET_WEEK}",MODE=execute, and run Phase B (B1 reads the just-written list frommemory/distributions.yml; B2–B5 as normal). The send-phase summary is the final notification.
all: dry-run (MODE=dry-run): full end-to-end preview, no writes, no transfers.
- Run Phase A in dry-run mode (A1–A5) to compute the plan — but per the A5 note, do not notify or exit here; hold the computed plan rows in memory.
- Enter Phase B with an in-memory recipient list built from the plan rows (
handle="@${login}",amount=<tier amount>) instead of readingmemory/distributions.yml; setLABEL="contributors-${TARGET_WEEK}",MODE=dry-run. Run B2 (preflight — this still calls Bankr/wallet/me+/portfolio, soBANKR_API_KEYis required for this preview; if absent, reportDISTRIBUTE_TOKENS_ERROR — BANKR_API_KEY not configuredfor the send preview but keep the rendered plan) and B3 (RESOLVE + print). B3'sMODE=dry-runbranch notifies the combined preview and exitsDISTRIBUTE_TOKENS_DRY_RUN. No state or yml is written by either phase.
Log
Append to memory/logs/${today}.md under one heading (the health loop parses this shape). Always use ### distribute-tokens; the Phase/Mode discriminator lines say which branch ran.
### distribute-tokens
- Phase: plan | send | all
- Mode: execute | dry-run
# --- plan phase (present when Phase A ran) ---
- Plan mode: execute | dry-run | already-processed | no-merged-prs | api-fail | no-eligible
- Week: ${TARGET_WEEK}
- Source: GitHub merged PRs for ${TARGET_WEEK}
- List label: contributors-${TARGET_WEEK}
- Entries written (new): ${N_NEW} | deduped: ${N_DEDUP} | total USDC planned: ${TOTAL_USDC}
- First-PR bonuses: [list or "none"]
# --- send phase (present when Phase B ran) ---
- List: ${LABEL} | Token: ${TOKEN}
- Verdict: ${VERDICT}
- Sent: ${total_sent} ${TOKEN} to ${n_success}/${n_attempted}; deduped: ${n_dedup}; unresolved: ${n_unresolved}
- Failures (if any): @x — REASON, @y — REASON
- State file: memory/state/distributions.json (${total_keys} entries)
- Notification sent: yes/noOmit the block for whichever phase did not run.
Exit codes (for downstream automation)
Plan phase (Phase A):
CONTRIBUTOR_REWARD_OK— plan written, notification sentCONTRIBUTOR_REWARD_DRY_RUN— plan rendered, no writes, notification sentCONTRIBUTOR_REWARD_ALREADY_PROCESSED— week already in state with identical plan, silent exitCONTRIBUTOR_REWARD_NO_MERGED_PRS— no PRs merged in the target week, silent exitCONTRIBUTOR_REWARD_API_FAIL— GitHub API unreachable (gh api+ WebFetch both failed), notifiedCONTRIBUTOR_REWARD_NO_ELIGIBLE— zero contributors above threshold, silent exitCONTRIBUTOR_REWARD_ERROR— file I/O or YAML write failure, notified
Send phase (Phase B):
DISTRIBUTE_TOKENS_OK— nothing to send (everything deduped or list empty), or bootstrapDISTRIBUTE_TOKENS_COMPLETE— all READY rows succeededDISTRIBUTE_TOKENS_PARTIAL— some succeeded, some failedDISTRIBUTE_TOKENS_DRY_RUN— dry-run completed, no sendsDISTRIBUTE_TOKENS_ERROR— preflight or config failure, no sends attempted
For all:, the terminal exit code is the send phase's code (or the Phase A early-exit code when the plan produced nothing to send).
Network note
- Plan phase (A): ranks contributors via
gh api search/issues(ghhandles GitHub auth internally, so no secret ever lands on the command line). Ifgh apifails, fall back to WebFetch on the publichttps://api.github.com/search/issues?q=…URL. Also reads/writesmemory/state/contributor-reward-state.json,memory/distributions.yml,memory/logs/${today}.md. No postprocess scripts required. - Send phase (B): every Bankr call is auth'd, so make it with
./secretcurlusing the{BANKR_API_KEY}placeholder — never a bare$BANKR_API_KEY(the Bash permission layer refuses a secret on the command line) and never plaincurl./wallet/transferis an irreversible money-movement write; it runs in-run as the executor's final action (Phase B4), behind the B2 balance preflight and the per-recipient idempotency inmemory/state/distributions.json(persisted after every send, so re-runs never double-pay). There is no deferred/postprocess step — a failed transfer is recorded (FAILEDwith its reason) and the run continues to the next row. Never silently drop a transfer.
Constraints
Send (money movement):
- Idempotency is non-negotiable. Always read
memory/state/distributions.jsonbefore sending; always persist after every transfer. Never batch state writes to end-of-run. - Treat the 24h Bankr rate limit (100/day standard) as a hard cap. Lists >50 recipients should be split.
- Never send if preflight balance is <
total_required * 1.05. - Never use the Agent API for transfers (deprecated). Agent API only for handle→address resolution.
- Never abort the RESOLVE phase on a single bad recipient — collect all errors, present them, then let the executor skip.
Plan (reward computation):
- Idempotency is per-(week, login). Re-runs in the same week add only deltas; demotions never claw back already-paid amounts.
- First-PR bonus is once-ever per login. Track in
first_pr_bonus_paid; never re-award even if the same person appears as ✨ in a later week (which they shouldn't, since ✨ means first ever merged PR — but defend against API drift). - No silent overwrites of distributions.yml. If the file exists and is malformed, fail loudly rather than rewriting.
- Eligibility floor stays low (≥ 1 merged PR) by design. A single PR merged in the week qualifies — reward shipped work, not volume.
Future iterations
- Schedule
all:directly (weekly, after the week closes) for full hands-off payout — the plan computes its own ranking from merged PRs, so no upstream skill or chain wiring is needed. - Add a Bankr Agent API "wallet-linked?" pre-filter in the plan phase so contributors without linked wallets are flagged in the notification (prevents the send phase from logging RESOLVE_FAILED rows on every run).
- Tier table should become operator-configurable via
memory/contributor-reward-config.ymlonce the first month of runs reveals the right curve. Hardcoded for v1.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

