Files
pyre/infra/status
RogueWave b98b904896 feat(fee+burn+essence): 5% transparent fee, burn→close, Essence ledger + dashboard
Monetization (design Rev 4, §3.1) — transparent in-tx fee, non-custodial:
- @pyre/core: computeFeeBreakdown (single source of truth, BigInt) + FeeBreakdown
  threaded through close/burn previews; fee tests.
- @pyre/config: PYRE_TREASURY_WALLET / PYRE_FEE_BPS (500) / swap fee / max contribution.
- @pyre/solana: close-empty + burn→close now append ONE System transfer of exactly
  the disclosed fee to the treasury; rent/authority/feePayer pinned to wallet.
  buildBurnTx re-validates EVERY account on-chain and value-gates via the classifier
  (classic SPL + Token-2022) — never burns protected/valuable/NFT/unsupported;
  ignores client amount (burns real balance); whole-build rejection.
- @pyre/api: close-empty/burn endpoints carry the fee + bounded optional contribution;
  /api/receipt persists (cleanup_receipts) and records the on-chain treasury fee as
  Essence; GET /api/essence; startup migrate(). Best-effort DB (never fails receipts).
- @pyre/db: Postgres Essence ledger (rounds, cleanup_receipts, essence_contributions),
  idempotent migrations, parameterized + u64-safe.
- @pyre/web: fee preview ("reclaim · feeds the PYRE · you net" + treasury) + optional
  "feed more" slider; burn flow w/ destructive confirm; decode+match verifies the fee
  transfer (treasury + exact lamports) before signing; public "🔥 fed the PYRE" panel.

Built by agents (2 waves) + 2 audits. Security audit found a HIGH — buildBurnTx
didn't value-gate CLASSIC spl tokens (a direct API caller could burn USDC/an NFT);
FIXED (classify classic accounts too) + 2 regression tests. Integration: SHIP.
typecheck 8/8, core 91, solana 30, web build green. Live: burn preview on the dust
token shows 5% → treasury; non-empty/non-owned/valuable rejected. Nightly DB backup
cron enabled.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-05-31 06:11:00 +00:00
..

PYRE Status Dashboard

A static, self-contained dark "ember"-themed page the team uses to track PYRE MVP progress. It is a snapshot, not live telemetry.

Files

  • status.json — the single source of truth. All content on the page (phases, checklists, infra, dates, links) comes from here.
  • index.html — the prebuilt rendered page. Committed so the page works even before anyone runs the generator. Self-contained: inline CSS, no external requests, no JS.
  • README.md — this file.

Editing & regenerating

  1. Edit status.json — flip an item's "done" to true, update a phase "state" (todo / in_progress / done), or bump "updated".

  2. Regenerate the page from the repo root:

    node scripts/gen-status.mjs
    

    The generator is dependency-free (plain Node ESM, no npm install). It reads infra/status/status.json and rewrites infra/status/index.html, recomputing the overall % complete from the item done-counts. It prints the output path when finished.

  3. Commit the regenerated index.html alongside the status.json change so the prebuilt page stays consistent with the data.

Deployment

The provision script deploys infra/status/* to /var/www/feedthepyre/status, and nginx serves it as the site root (feedthepyre.com) until the real PYRE app ships. Because index.html is prebuilt and self-contained, deployment is a plain file copy — no build step or generator run is required on the server.