Skip to content
cccskills
FreePublished on GitHub

funding-update

Update Pharos funding donations by reconciling inbound transfers, rejecting wallet self-activity and spam, pricing receipt-time value, and appending user-approved rows.

The English summary is being prepared. Showing the original description.

Works withCoinGecko
See how to install

Files included (1)

  • SKILL.md7.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Read docs/editorial-style.md before writing; its technical-evidence register governs prose.

Funding Donations Update

Maintain shared/data/funding/donations.json for the pharos-watch.eth Safe at 0x5d698362edb8aea1c2b2483096bdee3265d860db on the chains admitted by DonationSchema in shared/lib/funding/schema.ts (the source file wins). Never edit shared/data/funding/costs.json or historical donation rows without explicit approval. When an approved correction leaves an address with less than $10 in qualifying stablecoin donations, the operator must also deactivate the donor API key issued to that address (docs/api-reference-admin.md); eligibility is checked only at claim time, so the ledger edit revokes nothing by itself. Preserve its claim row to prevent reissuance. Later Safety Score changes alone do not revoke already-issued keys.

For pinned RPC reads and provenance, follow Pinned On-Chain Evidence.

Safety And Inputs

  • Check ALCHEMY_API_KEY, ETHERSCAN_API_KEY, and COINGECKO_API_KEY by name in the process environment, ignored root .env.local, and documented provider source. Never print, copy, execute, or place secrets in URLs/process arguments; use request headers or stdin.
  • Use web fetch, RPC/API requests, and browser inspection by capability; see docs/process/agent-artifacts.md#harness-configuration.
  • Every candidate requires transaction/receipt reconciliation and user approval. A clean-looking inbound transfer can be the Safe swapping or bridging its own funds.

Reconciliation

  1. Read donations and derive the highest block_timestamp per chain. Read costs only to report current funding context. If source coverage widened since the prior run, also scan the affected chain below its cursor and report candidates; cursors otherwise hide missed history.
  2. Query currently supported provider APIs for inbound native, internal, and ERC-20 transfers on every admitted funding chain. Determine supported categories at run time, record every coverage gap, consume error bodies, and honor status/rate-limit retry guidance. A failed or partial query is unavailable, never an empty result.
  3. Keep rows newer than each chain cursor and normalize chain, lowercase transaction hash and sender, timestamp, decimal amount, and symbol. Record the token contract as token_address on every appended row — lowercase 0x plus 40 hex for ERC-20 transfers, null for native assets (ETH on any chain, POL/MATIC, xDAI) — immediately after asset_symbol. Record from_address as the asset-transfer sender: the ERC-20 Transfer.from or the internal call's from, never the transaction signer, relayer, or bundler. Payout, router, bridge, and splitter contract senders are kind: "pool"; wallet senders stay community.
  4. For every candidate, fetch the transaction and receipt. Reject Safe execTransaction calls to the wallet and any transaction with an outbound native or ERC-20 leg from the wallet. Report these as self-activity, not donations or spam.
  5. Compare full sender addresses and token contracts to detect address-poisoning and ticker spoofing. Present survivors to the user; discard rows they identify as spam. Never auto-approve.
  6. Resolve stablecoin identity by (chain, token_address) with resolveDonorKeyQualifyingStablecoin in shared/lib/funding/donor-eligibility.ts, and write the qualifying ledger symbol only on a match. Any other contract keeps its uppercased on-chain ticker; if that ticker equals a qualifying symbol, suffix it with the first 4 hex characters of the contract (for example USDP-0x1456) so it can never be mistaken for the qualifying coin. Never infer identity from token name, ticker, peg, or price.
  7. Price qualifying USD-pegged stablecoins at 1:1 only after the contract match. Price EURC at the ECB EUR/USD reference rate for the UTC receipt date: GET https://api.frankfurter.dev/v1/{date}?base=EUR&symbols=USD, then usd_at_receipt = round(amount_decimal × rates.USD, 6) and price_note = "ecb-eurusd-{response.date}@{rate}" using the rate date actually served, which can precede a weekend or holiday receipt. Never price EURC at 1:1 or a current rate; hold the row when the lookup fails. Price ETH/MATIC/WBTC from CoinGecko history on the UTC receipt date. For any other token, require user-supplied USD value and source; never auto-resolve an unknown contract through CoinGecko.
  8. Reuse an existing donor label. Otherwise reverse-resolve ENS and forward-resolve it back to the exact address; if either step fails, store the address. Founder and pool labels require prior ledger evidence or user confirmation.

Approval And Write

Show each proposed row with chain, transaction, asset/amount, receipt-time USD value/source, donor display/kind, plus rejected self-activity and incomplete coverage. After explicit approval, append rows in ascending timestamp order and update last_updated_at. If no approved rows remain, make no edits.

Also list the addresses whose approved rows bring their qualifying lifetime total to the inclusive DONOR_API_KEY_MIN_USD threshold in shared/lib/ops-limits.ts, using receipt-time USD and excluding pool rows. Native assets and unreviewed contracts do not count; founder stablecoin rows can count. Only externally-owned wallets can claim; smart-contract wallets cannot claim yet. Eligibility resolves (chain, token_address) against DONOR_KEY_QUALIFYING_STABLECOINS in shared/lib/funding/donor-eligibility.ts; that reviewed contract list wins over ticker or bridge/native assumptions. Reuse summarizeDonorKeyEligibility or sumEligibleDonationsByAddress with current accepted grades and isEligibleDonor for the threshold. New coins or deployments need curation review plus the drift-test update in the focused funding suite. donorKeyGradeStatus owns the qualifying A/B grade bands. Claims require a current non-held canonical accepted Safety Score publication; missing or held publication pauses claims with 503. Values remain USD at receipt, not claim-time prices, and later grade changes do not revoke or alter an issued key. Report potential beneficiaries, not guaranteed eligible wallets: the edited ledger must ship in a release and grades are checked at claim time. The Worker embeds the committed ledger and reads grades from the current accepted publication; include that release requirement with the list.

Validate the actual edited file through the same schema used by the funding page, then run the focused funding suite (it includes the committed-ledger consistency test):

node --import tsx --input-type=module <<'NODE'
import { readFileSync } from "node:fs";
import { DonationsFileSchema } from "./shared/lib/funding/schema.ts";
DonationsFileSchema.parse(JSON.parse(readFileSync("shared/data/funding/donations.json", "utf8")));
NODE
npx vitest run shared/lib/funding

Run npm run build when page rendering changes or an explicit production-build rehearsal is requested. Schema validation does not replace transaction reconciliation or approval of each proposed row.

Report approved additions, rejected/self/spam rows, pricing/ENS uncertainty, coverage gaps, and check results. Publishing is a separate pharos-release-runner task.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Review the retained annotation candidate queue and curate per-coin editorial history. Use weekly during active event periods, monthly otherwise, or on queue-health warnings; this does not restore the retired live chart overlay.

The English summary is being prepared. Showing the original description.

TokenBrice/pharos-watch24Updated Oct 21, 2026

Generate a weekly changelog entry from git history, filtering operational noise and producing editorial summary, field notes, statistics, and a bounded commit manifest. Stops for review unless commit was explicitly requested.

The English summary is being prepared. Showing the original description.

TokenBrice/pharos-watch24Updated Oct 21, 2026

Research and populate tracked stablecoin compliance sidecars for the U.S. GENIUS Act, EU MiCA, or both. Use when adding or auditing authorization, applicability, pathway, or disclosure evidence.

The English summary is being prepared. Showing the original description.

TokenBrice/pharos-watch24Updated Oct 21, 2026

Use when adding, reviewing, squashing, deploying, or rolling back Pharos D1 migrations or schema cleanup.

The English summary is being prepared. Showing the original description.

TokenBrice/pharos-watch24Updated Oct 21, 2026

Drain the Pharos Dependency Map coverage-audit queues into evidence-refreshed edges, reviewed target dispositions, or documented deferrals. Use monthly after weekly production dependency audits, after dependency coverage drops, or when reviewing adapter gaps, material unlinked slices, symbol leads, duplicate/split groups, or unverifiable published edges.

The English summary is being prepared. Showing the original description.

TokenBrice/pharos-watch24Updated Oct 21, 2026

Draft a short, prioritized questionnaire for a collaborating stablecoin team when public evidence cannot resolve important Pharos data or confidence gaps.

The English summary is being prepared. Showing the original description.

TokenBrice/pharos-watch24Updated Oct 21, 2026

See all skills by TokenBrice

Report a problem with this skill