@ballkidz/defifa 0.0.41 → 0.0.43

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ballkidz/defifa",
-  "version": "0.0.41",
+  "version": "0.0.43",
   "license": "MIT",
   "engines": {
     "node": "25.9.0"
@@ -13,28 +13,19 @@
     "url": "git+https://github.com/BallKidz/defifa.git"
   },
   "files": [
-    "src",
-    "script",
-    "lib/base64/base64.sol",
-    "lib/typeface/contracts/interfaces/ITypeface.sol",
-    "README.md",
-    "ARCHITECTURE.md",
-    "ADMINISTRATION.md",
-    "AUDIT_INSTRUCTIONS.md",
-    "CHANGELOG.md",
-    "CRYPTO_ECON.md",
-    "RISKS.md",
-    "SKILLS.md",
-    "STYLE_GUIDE.md",
-    "USER_JOURNEYS.md",
     "foundry.toml",
-    "remappings.txt"
+    "references/",
+    "remappings.txt",
+    "script/",
+    "src/",
+    "lib/base64/base64.sol",
+    "lib/typeface/contracts/interfaces/ITypeface.sol"
   ],
   "dependencies": {
-    "@bananapus/721-hook-v6": "^0.0.54",
+    "@bananapus/721-hook-v6": "^0.0.55",
     "@bananapus/address-registry-v6": "^0.0.26",
-    "@bananapus/core-v6": "^0.0.59",
-    "@bananapus/permission-ids-v6": "^0.0.26",
+    "@bananapus/core-v6": "^0.0.60",
+    "@bananapus/permission-ids-v6": "^0.0.27",
     "@openzeppelin/contracts": "5.6.1",
     "@prb/math": "4.1.1",
     "scripty.sol": "2.1.1"

package/references/operations.md

@@ -0,0 +1,32 @@
+# Defifa Operations
+
+Use this file when the task is about launch config, phase timing, governance windows, or deciding whether a symptom is operational drift or runtime logic.
+
+## Deployment Surface
+
+- [`src/DefifaDeployer.sol`](../src/DefifaDeployer.sol) is the first stop for launch-time config, phase queueing, and post-ratification fulfillment.
+- [`script/Deploy.s.sol`](../script/Deploy.s.sol) and [`script/helpers/DefifaDeploymentLib.sol`](../script/helpers/DefifaDeploymentLib.sol) are the deployment entrypoints when the task is about current wiring rather than game mechanics.
+- [`src/structs/`](../src/structs/) and [`src/enums/`](../src/enums/) define launch data, phase types, and other inputs that often drift from remembered assumptions.
+
+## Change Checklist
+
+- If you edit lifecycle timing, verify phase transitions, no-contest triggers, and the governor's attestation windows together.
+- If you edit hook settlement logic, re-check fee accounting and mint-cost invariants.
+- If you touch governance thresholds or attestation behavior, inspect the governor tests before assuming the change is local.
+- If you touch token metadata or rendering, verify whether the bug belongs in the resolver instead of settlement code.
+- If you touch anything supply-sensitive, inspect the review tests around pending reserves and quorum before relying on current intuition.
+
+## Common Failure Modes
+
+- Game-state issue is blamed on the hook even though the deployer queued the wrong phase or timing.
+- Governance behavior looks wrong, but the real issue is stale launch configuration.
+- Settlement changes accidentally affect fee distribution or redemption accounting.
+- Resolver issues get misdiagnosed as hook or governor problems because they surface through NFTs.
+- Review-style failures around reserve dilution or attestation counting are treated as isolated math issues even though they cross deployer, hook, and governor boundaries.
+
+## Useful Proof Points
+
+- [`test/Fork.t.sol`](../test/Fork.t.sol) for live-integration assumptions.
+- [`test/TestRegressionGaps.sol`](../test/TestRegressionGaps.sol) and [`test/TestQALastMile.t.sol`](../test/TestQALastMile.t.sol) for pinned edge cases.
+- [`test/BWAFunctionComparison.t.sol`](../test/BWAFunctionComparison.t.sol) and [`test/DefifaUSDC.t.sol`](../test/DefifaUSDC.t.sol) when currency or accounting context matters.
+- [`test/regression/`](../test/regression/) when a change touches pending reserves, registry alignment, quorum griefing, or double-counting.

package/references/runtime.md

@@ -0,0 +1,43 @@
+# Defifa Runtime
+
+Use this file when `defifa/SKILLS.md` has already routed you here and you need to reason about the game as a state machine rather than as isolated contracts.
+
+## Contract Roles
+
+- [`src/DefifaDeployer.sol`](../src/DefifaDeployer.sol) launches games, manages phase progression, fulfills commitments, and triggers safety exits such as no-contest.
+- [`src/DefifaHook.sol`](../src/DefifaHook.sol) manages the NFT game pieces, delegation, and settlement-side cash-out behavior.
+- [`src/DefifaGovernor.sol`](../src/DefifaGovernor.sol) handles scorecard submission, attestation, quorum, and ratification.
+- [`src/DefifaTokenUriResolver.sol`](../src/DefifaTokenUriResolver.sol) renders game-card metadata.
+- [`src/DefifaProjectOwner.sol`](../src/DefifaProjectOwner.sol) is the ownership helper for the fee project.
+
+## Lifecycle
+
+1. Countdown before minting opens.
+2. Mint phase where players buy outcome NFTs and can delegate attestation power.
+3. Optional refund phase if the launch configuration allows it.
+4. Scoring phase where scorecards are submitted, attested, and ratified.
+5. Complete or no-contest settlement depending on governance outcome and safety checks.
+
+## High-Risk Areas
+
+- Scorecard ratification and quorum assumptions: changes here directly affect who can settle the pot.
+- No-contest and refund behavior: these paths are economic safety valves, not edge-case garnish.
+- Fee accounting and commitment fulfillment: payout ordering and accounting drift can change final redemption value.
+- Hook/governor/deployer coupling: many bugs come from changing one layer while assuming the others are passive.
+- Pending reserved supply and snapshot assumptions: settlement and quorum logic can drift if supply-sensitive views are taken at the wrong time.
+- Scorecards that miss quorum do not naturally “finish.” New scorecards can still be submitted until no-contest logic takes over, so do not assume a clean defeated terminal state.
+
+## Common Misdiagnoses
+
+- A settlement bug is blamed on [`src/DefifaHook.sol`](../src/DefifaHook.sol) even though the wrong phase or grace-period state was created in [`src/DefifaDeployer.sol`](../src/DefifaDeployer.sol) or [`src/DefifaGovernor.sol`](../src/DefifaGovernor.sol).
+- A governance bug is blamed on the governor even though attestation power or delegation semantics were wrong in the hook layer.
+- An NFT-facing bug is blamed on settlement code even though the problem is resolver output in [`src/DefifaTokenUriResolver.sol`](../src/DefifaTokenUriResolver.sol).
+- A Defifa-specific payout result is patched in this repo when the real bug is shared 721 or core protocol behavior upstream.
+
+## Tests To Trust First
+
+- [`test/DefifaGovernor.t.sol`](../test/DefifaGovernor.t.sol) for governance flow.
+- [`test/DefifaNoContest.t.sol`](../test/DefifaNoContest.t.sol) for safety exits.
+- [`test/DefifaFeeAccounting.t.sol`](../test/DefifaFeeAccounting.t.sol) and [`test/DefifaMintCostInvariant.t.sol`](../test/DefifaMintCostInvariant.t.sol) for economic correctness.
+- [`test/DefifaHookRegressions.t.sol`](../test/DefifaHookRegressions.t.sol), [`test/regression/GracePeriodBypass.t.sol`](../test/regression/GracePeriodBypass.t.sol), [`test/regression/FulfillmentBlocksRatification.t.sol`](../test/regression/FulfillmentBlocksRatification.t.sol), and [`test/regression/AttestationDelegateBeneficiary.t.sol`](../test/regression/AttestationDelegateBeneficiary.t.sol) for pinned regressions.
+- [`test/DefifaSecurity.t.sol`](../test/DefifaSecurity.t.sol), [`test/DefifaGovernanceHardening.t.sol`](../test/DefifaGovernanceHardening.t.sol), [`test/DefifaAdversarialQuorum.t.sol`](../test/DefifaAdversarialQuorum.t.sol), and [`test/regression/`](../test/regression/) for adversarial and regression-derived cases.

package/ADMINISTRATION.md

@@ -1,82 +0,0 @@
-# Administration
-
-## At A Glance
-
-| Item | Details |
-| --- | --- |
-| Scope | Game launch configuration, scorecard governance, no-contest recovery, and optional fee-project ownership locking |
-| Control posture | Permissionless launch, then collective governance plus bounded contract-controlled lifecycle paths |
-| Highest-risk actions | Launching with wrong immutable game settings, misconfiguring governance thresholds, and misunderstanding no-contest handling |
-| Recovery posture | Mostly replacement or documented no-contest handling; there is no broad post-launch owner override |
-
-## Purpose
-
-`defifa` is unusual because game creation is permissionless but ongoing game control is intentionally narrow. The main administration job is understanding what is fixed at launch, what collective governance can still do, and what the deployer must do to finish settlement.
-
-## Control Model
-
-- `launchGameWith(...)` is the real governance commitment. Core game shape is fixed there.
-- `DefifaGovernor` controls scorecard submission, attestation, and ratification.
-- `DefifaHook` controls phase-aware mint and cash-out behavior but does not expose broad admin mutability.
-- `DefifaDeployer` still owns structural lifecycle duties such as fulfillment and no-contest queuing.
-- `DefifaProjectOwner` is an optional irreversible sink for the fee-project NFT.
-
-## Roles
-
-| Role | How Assigned | Scope | Notes |
-| --- | --- | --- | --- |
-| Game creator | Calls `launchGameWith(...)` | Launch only | Does not receive broad runtime admin power afterward |
-| Scorecard participant | Holds or receives attestation power | Per game | Can submit, attest, revoke, and help ratify |
-| Ratification path caller | Any caller who meets the documented conditions | Per game | Finalizes a valid scorecard |
-| Fulfillment path caller | Any valid caller once ratified | Per game | Must run the completion commitment path |
-| `DefifaProjectOwner` holder | Project NFT sent into sink | Per fee project | Irreversible ownership lock |
-| `DefifaDeployer` owner | Constructor `initialOwner` (typically the Defifa multisig) | Global referral-attribution surface | Single privilege: call `setReferralProjectId` to repoint the fee-volume credit |
-
-## Privileged Surfaces
-
-- `launchGameWith(...)` fixes phase timing, tiers, fee routing, and governance shape
-- `submitScorecardFor(...)`, `attestToScorecardFrom(...)`, `revokeAttestationFrom(...)`, and `ratifyScorecardFrom(...)` govern outcome selection
-- `fulfillCommitmentsOf(...)` turns a ratified scorecard into real settlement
-- `triggerNoContestFor(...)` moves failed games into the documented recovery path
-- `DefifaDeployer.setReferralProjectId(projectId, chainId)` — `onlyOwner`; retargets the fee-volume referrer credited on every `sendPayoutsOf` call this deployer makes from `fulfillCommitmentsOf`. Stores the packed `(chainId << 48) | projectId` value `JBMultiTerminal` expects on its `referralProjectId` argument. Defaults to `(1, DEFIFA_PROJECT_ID)` at construction so credit lands on the Defifa project on Ethereum mainnet regardless of which chain a game runs on. Passing `(0, 0)` disables the credit entirely. Bounded so the pack is lossless: `projectId <= type(uint48).max`, `chainId <= type(uint208).max`. Does not affect game economics — only where fee-volume attribution accrues.
-
-## Immutable And One-Way
-
-- Game phase timing is fixed at launch.
-- Scorecard timeout, minimum participation, and default delegation choices are fixed at launch.
-- `setTierCashOutWeightsTo()` is effectively one-way once final weights are installed.
-- `cashOutWeightIsSet` permanently closes the score-setting path after success.
-- `DefifaProjectOwner` permanently locks the project NFT it receives.
-- `fulfillCommitmentsOf()` and `triggerNoContestFor()` are single-use style lifecycle paths.
-
-## Operational Notes
-
-- Validate game timings, tier setup, fee routing, and attestation settings before launch.
-- Treat `launchGameWith()` as the real admin commitment.
-- During scoring, follow the submission, attestation, and ratification flow rather than looking for discretionary overrides.
-- Use `triggerNoContestFor()` only when the game has actually entered the documented no-contest condition.
-- Treat the fee-project ownership proxy as a burn-lock mechanism, not a recoverable custody tool.
-
-## Machine Notes
-
-- Do not infer ongoing admin power for the game creator; launch is permissionless but not an ongoing authority grant.
-- Treat `DefifaDeployer`, `DefifaGovernor`, `DefifaHook`, and `DefifaProjectOwner` as the minimum source-of-truth set for authority review.
-- If scorecard state, quorum assumptions, or timeout state differ from the expected lifecycle, inspect the current phase before documenting the next action.
-- If a game launched with wrong immutable economics, timing, or split assumptions, do not guess at an in-place fix.
-
-## Recovery
-
-- If a scorecard never reaches a valid ratification path and timeout conditions are met, use the documented no-contest flow.
-- If a game launched with wrong immutable economics, timing, fee routing, or tier design, recovery is usually a replacement deployment.
-- If fee-project ownership was transferred into `DefifaProjectOwner`, there is no recovery path for that NFT.
-- There is no broad owner override that can pause, cancel, or rewrite a live game after launch.
-
-## Admin Boundaries
-
-- No one can change tier prices, timing, payment token, fees, or split configuration after launch.
-- No one can unilaterally set scorecard weights without the documented governance path.
-- No one can manually pause, cancel, or rewind a game phase.
-- No one can set cash-out weights twice.
-- No one can fulfill commitments twice.
-- No one can recover the project NFT from `DefifaProjectOwner`.
-- The `DefifaDeployer` owner can repoint `referralProjectId` but cannot change anything else about an in-flight or past game — game economics, fees, and settlement remain bounded by the immutable launch configuration.

package/ARCHITECTURE.md

@@ -1,131 +0,0 @@
-# Architecture
-
-## Purpose
-
-`defifa` builds phased prediction games on top of Juicebox and the 721 hook stack. A game is a Juicebox project with a custom NFT hook, a scorecard governor, and a deployer that launches the project and later fulfills the economic commitments that make completion real.
-
-## System Overview
-
-`DefifaHook`, `DefifaGovernor`, and `DefifaDeployer` form one game-state machine even though they are deployed separately. The hook owns game-piece NFT behavior, attestation delegation, and phase-sensitive cash-out weighting. The governor owns scorecard submission, attestation, quorum, and ratification. The deployer owns game launch, phased ruleset setup, and commitment fulfillment after governance decides the outcome.
-
-## Core Invariants
-
-- The game is economically coherent only if deployer, governor, and hook agree on phase progression.
-- Ratification is the only path that should install final cash-out weights for the complete phase.
-- Attestation power should reflect tier semantics, not raw circulating supply.
-- Refund, scoring, complete, and no-contest behavior must be mutually coherent.
-- The deployer's post-ratification fulfillment path is mandatory economics, not optional housekeeping.
-- Completion-phase cash outs must account for already redeemed tokens and pending reserve dilution correctly.
-
-## Modules
-
-| Module | Responsibility | Notes |
-| --- | --- | --- |
-| `DefifaDeployer` | Launches games, sets phased rulesets, clones hooks, initializes governance, and fulfills commitments | Launch-time and completion-time runtime surface |
-| `DefifaHook` | NFT minting, delegation, game-phase-aware cash-out behavior, and completion claims | Main game-facing runtime hook |
-| `DefifaGovernor` | Scorecard submission, attestation weighting, quorum, grace periods, and ratification | Governance surface |
-| `DefifaHookLib` | Shared validation and weight math extracted from the hook | Bytecode-management helper |
-| `DefifaTokenUriResolver` | Dynamic token metadata and SVG rendering | Metadata layer |
-| `DefifaProjectOwner` | Irreversible project-owner sink that preserves selected operator permissions | Governance-sensitive helper |
-
-## Trust Boundaries
-
-- Canonical treasury accounting, project ownership, rulesets, terminals, and payout mechanics remain in `nana-core-v6`.
-- Tier storage, reserve minting mechanics, and generic ERC-721 behavior come from `nana-721-hook-v6`.
-- `DefifaGovernor` is trusted to ratify scorecards only through its quorum, grace-period, and timelock rules.
-- `DefifaDeployer` is trusted to convert governance output into the final completion envelope.
-
-## Critical Flows
-
-### Launch Game
-
-```text
-creator
-  -> deployer validates mint/refund/start timings
-  -> deployer predicts the game project ID and clones a game hook deterministically
-  -> deployer builds phased rulesets and optional fee splits
-  -> controller launches the project
-  -> governor is initialized for the game
-  -> hook ownership and project ownership are transferred into the intended long-term shape
-```
-
-### Mint During Open Play
-
-```text
-player
-  -> pays the game project during the mint window
-  -> hook mints the selected game-piece NFT tier
-  -> delegation state and total mint-cost accounting are updated
-  -> reserved mints and pending reserves continue to affect later completion claims
-```
-
-### Scorecard Governance
-
-```text
-attester or proposer
-  -> governor accepts a scorecard candidate
-  -> attestation power is computed from tier-relative holdings
-  -> quorum, grace period, and timelock gates are enforced
-  -> governor ratifies exactly one winning scorecard
-```
-
-### Fulfill Commitments And Complete
-
-```text
-authorized completion path
-  -> deployer reads the ratified outcome
-  -> deployer fulfills the game's promised commitments and queues the final ruleset
-  -> hook installs final cash-out weights
-  -> holders burn pieces during complete phase to reclaim their weighted share of the pot
-```
-
-## Accounting Model
-
-This repo does not replace `nana-core-v6` treasury accounting. Its critical economic state is:
-
-- phase timestamps and game ops data in the deployer
-- scorecard and attestation state in the governor
-- tier cash-out weights, redeemed-token tracking, mint-cost totals, and delegation state in the hook
-
-The hook's completion math is intentionally phase-sensitive:
-
-- before completion, cash-out behavior is refund or fallback oriented
-- after ratification and fulfillment, cash-out weights become the game outcome
-- completion claims use minted cost, redeemed tracking, and pending-reserve-aware dilution together
-
-## Security Model
-
-- The primary risk is semantic drift across hook, governor, and deployer.
-- Ratification and fulfillment are separate steps; a ratified scorecard without correct fulfillment still leaves the game economically unfinished.
-- Attestation weighting is part of game fairness, not just governance plumbing.
-- Pending reserves and reserved-mint behavior affect both quorum fairness and completion-time claim dilution.
-- Phase transitions are safety-critical. A timing bug can enable refunds, scoring, or completion in the wrong order.
-
-## Safe Change Guide
-
-- Review `DefifaHook`, `DefifaGovernor`, and `DefifaDeployer` together for any nontrivial change.
-- If phase semantics change, re-check mint, refund, scoring, ratification, fulfillment, and completion cash-out behavior together.
-- If attestation math changes, inspect tier semantics, delegation, quorum, and ratification thresholds together.
-- If completion claim math changes, re-check redeemed tracking, pending reserve dilution, and fee-token side claims in the same review.
-
-## Canonical Checks
-
-- governor state transitions and scorecard handling:
-  `test/DefifaGovernor.t.sol`
-- fulfillment and ratification coupling:
-  `test/regression/FulfillmentBlocksRatification.t.sol`
-- pending reserve effects on completion fairness:
-  `test/regression/PendingReserveSnapshotBypass.t.sol`
-
-## Source Map
-
-- `src/DefifaDeployer.sol`
-- `src/DefifaGovernor.sol`
-- `src/DefifaHook.sol`
-- `src/libraries/DefifaHookLib.sol`
-- `src/DefifaTokenUriResolver.sol`
-- `test/DefifaGovernor.t.sol`
-- `test/DefifaHookRegressions.t.sol`
-- `test/DefifaFeeAccounting.t.sol`
-- `test/regression/FulfillmentBlocksRatification.t.sol`
-- `test/regression/PendingReserveSnapshotBypass.t.sol`

package/AUDIT_INSTRUCTIONS.md

@@ -1,100 +0,0 @@
-# Audit Instructions
-
-Defifa is a staged prediction-game system built on Juicebox and the tiered 721 stack. Audit it as a governance-and-settlement protocol, not just an NFT game.
-
-## Audit Objective
-
-There is a billion dollars of well-meaning projects' money in the Juicebox Money Engine, growing exponentially. Your job is to hack it before anyone else. Whoever hacks it first saves/steals the money, and you are obsessed with being this winner, while also being a steward of the protocol and wanting it to keep growing safely.
-
-Suggestions of where to look:
-
-- let players extract more than their fair share of the game pot
-- break the game-phase lifecycle or allow actions in the wrong phase
-- corrupt scorecard submission, attestation, quorum, delegation, grace-period, or ratification logic
-- miscompute tier cash-out weights or fee-token distribution
-- leave a deployed game misconfigured through deployer or owner-helper mistakes
-
-## Scope
-
-In scope:
-
-- `src/DefifaDeployer.sol`
-- `src/DefifaGovernor.sol`
-- `src/DefifaHook.sol`
-- `src/DefifaProjectOwner.sol`
-- `src/DefifaTokenUriResolver.sol`
-- `src/libraries/DefifaHookLib.sol`
-- enums, interfaces, structs, and deployment helpers
-
-## Start Here
-
-1. `src/DefifaGovernor.sol`
-2. `src/DefifaHook.sol`
-3. `src/DefifaDeployer.sol`
-4. `src/DefifaProjectOwner.sol`
-
-## Security Model
-
-High-level lifecycle:
-
-- deploy a game as a Juicebox project
-- sell outcome NFTs during the mint phase
-- optionally allow refunds or no-contest handling
-- run scorecard governance through submissions and attestations
-- ratify one scorecard
-- update cash-out weights so winning pieces can redeem the treasury
-
-The contracts split responsibility as follows:
-
-- `DefifaDeployer` launches the project and wires lifecycle configuration
-- `DefifaHook` handles minting, burning, fee accounting, and game-specific cash-out math
-- `DefifaGovernor` owns scorecard governance and ratification
-- `DefifaProjectOwner` acts as a project-owner helper where governance needs a stable admin surface
-- `DefifaTokenUriResolver` handles game NFT metadata
-
-## Roles And Privileges
-
-| Role | Powers | How constrained |
-|------|--------|-----------------|
-| Game deployer or owner path | Configure a game's initial lifecycle and helper wiring | Must not retain hidden post-launch powers |
-| Governor participants | Submit, attest to, and ratify scorecards | Must remain bounded by phase, quorum, and delegation rules |
-| `DefifaHook` | Determine mint and final redeem economics | Must not over-credit players or under-account fees |
-| Project owner helper | Stand in for project ownership where configured | Must not diverge from the intended governance authority |
-
-## Integration Assumptions
-
-| Dependency | Assumption | What breaks if wrong |
-|------------|------------|----------------------|
-| `nana-core-v6` | Treasury accounting, rulesets, and cash-out surfaces stay coherent | Pot settlement and redeem math become unsound |
-| `nana-721-hook-v6` | Tier issuance and reserve behavior match Defifa's game logic | Voting power, supply, and cash-out weights drift |
-| Owner-helper and deployer patterns | Launch-time authority fully converges to the intended game authority | Games remain misconfigured or over-privileged |
-
-## Critical Invariants
-
-1. Pot conservation.
-2. Governance phase safety.
-3. Quorum and grace-period correctness.
-4. Settlement determinism once a scorecard is final.
-5. Fee-token and reserve correctness.
-
-## Attack Surfaces
-
-- `DefifaGovernor` scorecard state transitions and ratification gating
-- delegation, attestation, and quorum calculations
-- `DefifaHook` cash-out weight and fee-token accounting
-- reserve-related denominators during governance and settlement
-- deployer logic that queues or fulfills lifecycle rulesets
-
-## Accepted Risks Or Behaviors
-
-- Governance and settlement are intentionally phase-heavy, so timestamp and lifecycle transitions are core audit targets rather than edge cases.
-
-## Verification
-
-- `npm install`
-- `forge fmt --check`
-- `forge build --deny notes`
-- `forge build --deny notes --sizes --skip "*/test/**" --skip "*/script/**"`
-- `forge build --deny notes --build-info --skip "*/test/**" --skip "*/script/**"`
-- `forge test --deny notes`
-- `npm pack --dry-run --json`

package/CHANGELOG.md

@@ -1,48 +0,0 @@
-# Changelog
-
-## 0.0.41 — Owner-settable referral target on `DefifaDeployer`
-
-- `DefifaDeployer` now inherits OpenZeppelin `Ownable`. New constructor arg `address initialOwner` is passed straight to `Ownable(initialOwner)`. **This is a breaking constructor signature change** — `script/Deploy.s.sol` and every test that instantiates `DefifaDeployer` directly was updated to pass `initialOwner` (typically `safeAddress()` in the deploy script; `address(this)` in tests).
-- New `referralProjectId()` view returning the packed `(chainId << 48) | projectId` reference credited as the referrer on every fee-payout `sendPayoutsOf` call from `fulfillCommitmentsOf`.
-- New `setReferralProjectId(uint256 projectId, uint256 chainId)` (`onlyOwner`): takes the two fields unpacked, packs and stores them. Bounded so the pack is lossless — `projectId <= type(uint48).max`, `chainId <= type(uint208).max`. Reverts with `DefifaDeployer_ReferralProjectIdTooLarge` / `DefifaDeployer_ReferralChainIdTooLarge` otherwise. Emits `SetReferralProjectId(referralChainId, referralProjectId, caller)`.
-- Default at construction: `(chainId = 1, projectId = DEFIFA_PROJECT_ID)` — fee-volume credit still lands on the Defifa project on Ethereum mainnet regardless of which chain a game runs on. Owner can repoint this or pass `(0, 0)` to disable referral credit entirely.
-- The inline `(uint256(1) << 48) | DEFIFA_PROJECT_ID` pack inside `fulfillCommitmentsOf` is replaced by a read of the new storage slot. No external behavior change for default deployments.
-
-## 0.0.35 — Bump v6 deps to nana-core-v6 0.0.53 cohort
-
-- `@bananapus/core-v6`: `^0.0.48 → ^0.0.53` ([PR #145](https://github.com/Bananapus/nana-core-v6/pull/145)).
-- `@bananapus/721-hook-v6`: `^0.0.46 → ^0.0.50`.
-- `@bananapus/permission-ids-v6`: `^0.0.22 → ^0.0.25`.
-- All `JBRulesetMetadata` literals (src + test) patched to include `pauseCrossProjectFeeFreeInflows: false`.
-
-## Scope
-
-This repo was not part of the deployed v5 ecosystem that the top-level changelog measures, so it is excluded from the ecosystem delta.
-
-This file instead describes the current v6 repo at a high level and the broad migration direction from the older `defifa-v5` codebase.
-
-## Current v6 surface
-
-- `DefifaDeployer`
-- `DefifaHook`
-- `DefifaGovernor`
-- `DefifaProjectOwner`
-- `DefifaTokenUriResolver`
-
-## Summary
-
-- The repo is now built directly on the v6 Juicebox stack, including the v6 core and 721-hook packages.
-- The v6 surface is split across dedicated deployer, hook, governor, project-owner, and token-uri contracts, with dedicated regression and review test coverage around governance, fee accounting, attestations, and lifecycle edge cases.
-- Solidity and tooling were upgraded to the v6 baseline around `0.8.28`.
-
-## Local review remediations
-
-- Reserve-minted NFTs are now excluded from refund calculations during MINT, REFUND, and NO_CONTEST phases. A public `isReserveMint` mapping tracks which tokens were created via tier reserve frequency rather than paid for. `beforeCashOutRecordedWith` subtracts their tier price from `cumulativeMintPrice`, preventing reserve beneficiaries from withdrawing funds they never contributed.
-- Reserve minting now caps `count` by `adjustedPendingReservesFor(tierId)` inside `DefifaHook.mintReservesFor`. Without the cap, a caller could request more reserves than the refund-adjusted pending balance, inflating `totalMintCost` from already-refunded mints and breaking the supply-vs-pending-reserves invariant that fee-token claims rely on.
-- One-tier games now revert at launch with `DefifaDeployer_InvalidGameConfiguration` if `scorecardTimeout == 0`. A one-tier game cannot reach quorum (the BWA multiplier reduces the sole tier's power to zero), so a zero timeout would leave funds permanently locked with no exit path. Enforcement moves this from a launcher-side responsibility (previously documented in `RISKS.md §8.6`) to a contract-level guarantee.
-- `DefifaHook.mintReservesFor` now reverts with `DefifaHook_ReservedTokenMintingBlockedInNoContest` while the game is in `NO_CONTEST`. Reserve mints inflate `totalMintCost` so reserved recipients can claim fee tokens; without the block, a game that failed `minParticipation` could be revived back to SCORING via free notional face value before `triggerNoContestFor` latches the failure.
-
-## Migration notes
-
-- Do not treat this repo as part of the deployed v5-to-v6 ecosystem delta.
-- If you need a Defifa-specific migration, rebuild from the current v6 ABIs and current contract set instead of relying on the ecosystem summary.