@bannynet/core-v6 0.0.24 → 0.0.25

package/README.md

@@ -80,8 +80,8 @@ The contract stack relies on `via_ir = true` in `foundry.toml`.
 
 ```bash
 npm install
-forge build
-forge test
+forge build --deny notes
+forge test --deny notes
 ```
 
 Useful scripts:

package/foundry.toml

@@ -15,7 +15,8 @@ depth = 100
 fail_on_revert = false
 
 [lint]
-exclude_lints = ["pascal-case-struct", "mixed-case-variable"]
+exclude_lints = ["mixed-case-variable", "pascal-case-struct"]
+
 [fmt]
 number_underscore = "thousands"
 multiline_func_header = "all"

package/package.json

@@ -1,11 +1,23 @@
 {
   "name": "@bannynet/core-v6",
-  "version": "0.0.24",
+  "version": "0.0.25",
   "license": "MIT",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/mejango/banny-retail-v6"
   },
+  "files": [
+    "CHANGELOG.md",
+    "foundry.toml",
+    "references/",
+    "remappings.txt",
+    "script/Add.Denver.s.sol",
+    "script/Deploy.s.sol",
+    "script/Drop1.s.sol",
+    "script/helpers/",
+    "script/outfit_drop/",
+    "src/"
+  ],
   "engines": {
     "node": ">=20.0.0"
   },
@@ -20,18 +32,16 @@
     "artifacts": "source ./.env && npx sphinx artifacts --org-id 'ea165b21-7cdc-4d7b-be59-ecdd4c26bee4' --project-name 'banny-core-v6'"
   },
   "dependencies": {
-    "@bananapus/721-hook-v6": "^0.0.38",
-    "@bananapus/core-v6": "^0.0.36",
-    "@bananapus/permission-ids-v6": "^0.0.19",
-    "@bananapus/router-terminal-v6": "^0.0.30",
-    "@bananapus/suckers-v6": "^0.0.28",
-    "@croptop/core-v6": "^0.0.36",
-    "@openzeppelin/contracts": "^5.6.1",
-    "@rev-net/core-v6": "^0.0.35",
-    "keccak": "^3.0.4"
+    "@bananapus/721-hook-v6": "0.0.43",
+    "@bananapus/core-v6": "0.0.39",
+    "@bananapus/router-terminal-v6": "0.0.36",
+    "@bananapus/suckers-v6": "0.0.33",
+    "@openzeppelin/contracts": "5.6.1",
+    "@rev-net/core-v6": "0.0.39",
+    "keccak": "3.0.4"
   },
   "devDependencies": {
-    "@bananapus/address-registry-v6": "^0.0.17",
-    "@sphinx-labs/plugins": "^0.33.3"
+    "@bananapus/address-registry-v6": "0.0.25",
+    "@sphinx-labs/plugins": "0.33.3"
   }
 }

package/src/Banny721TokenUriResolver.sol

@@ -291,6 +291,8 @@ contract Banny721TokenUriResolver is
 
             // If the token has an owner, check if the owner has locked the token.
             uint256 lockedUntil = outfitLockedUntil[hook][tokenId];
+            // Outfit locks are user-selected display locks; timestamp tolerance is acceptable here.
+            // forge-lint: disable-next-line(block-timestamp)
             if (lockedUntil > block.timestamp) {
                 extraMetadata = string.concat(extraMetadata, '"changesLockedUntil": ', lockedUntil.toString(), ",");
                 attributes = string.concat(
@@ -945,6 +947,8 @@ contract Banny721TokenUriResolver is
     /// @param bannyBodyId The body currently using the asset.
     /// @param exemptBodyId The destination body currently being decorated.
     function _revertIfBodyLocked(address hook, uint256 bannyBodyId, uint256 exemptBodyId) internal view {
+        // Outfit locks are user-selected display locks; timestamp tolerance is acceptable here.
+        // forge-lint: disable-next-line(block-timestamp)
         if (bannyBodyId != 0 && bannyBodyId != exemptBodyId && outfitLockedUntil[hook][bannyBodyId] > block.timestamp) {
             revert Banny721TokenUriResolver_OutfitChangesLocked();
         }
@@ -1118,6 +1122,8 @@ contract Banny721TokenUriResolver is
         }
 
         // Can't decorate a banny that's locked.
+        // Outfit locks are user-selected display locks; timestamp tolerance is acceptable here.
+        // forge-lint: disable-next-line(block-timestamp)
         if (outfitLockedUntil[hook][bannyBodyId] > block.timestamp) {
             revert Banny721TokenUriResolver_OutfitChangesLocked();
         }

package/ADMINISTRATION.md

@@ -1,87 +0,0 @@
-# Administration
-
-## At A Glance
-
-| Item | Details |
-| --- | --- |
-| Scope | `Banny721TokenUriResolver` metadata, SVG commitments, and outfit-state control |
-| Control posture | Global `Ownable` metadata control plus per-body owner control |
-| Highest-risk actions | Wrong SVG hash commitments, incorrect metadata updates, and long outfit locks |
-| Recovery posture | Metadata is editable, but committed hashes, uploaded SVGs, and active locks are not reversible |
-
-## Purpose
-
-`banny-retail-v6` has a small but real control plane. The resolver owner controls collection-wide metadata and SVG commitments. Body owners control decoration and outfit locks. No admin can rescue equipped NFTs if resolver logic fails.
-
-## Control Model
-
-- `Banny721TokenUriResolver` is `Ownable`.
-- Global admin power is limited to metadata, product naming, and SVG hash commitments.
-- Actual SVG upload is permissionless once the hash is committed.
-- Body owners control decoration and locking for their own bodies.
-- Equipped accessories are held by the resolver while attached.
-
-## Roles
-
-| Role | How Assigned | Scope | Notes |
-| --- | --- | --- | --- |
-| Resolver owner | `Ownable(owner)` at construction | Global | Can transfer ownership with `transferOwnership()` |
-| Body owner | `IERC721(hook).ownerOf(bannyBodyId)` | Per body | Can decorate and lock that body |
-| Anyone | No assignment | Global | Can upload SVG bytes only if they match a committed hash |
-
-## Privileged Surfaces
-
-| Contract | Function | Who Can Call | Effect |
-| --- | --- | --- | --- |
-| `Banny721TokenUriResolver` | `setMetadata(...)` | Resolver owner | Changes global description, URL, and base URI |
-| `Banny721TokenUriResolver` | `setProductNames(...)` | Resolver owner | Changes display names for products |
-| `Banny721TokenUriResolver` | `setSvgHashesOf(...)` | Resolver owner | Commits write-once SVG hashes for UPCs |
-| `Banny721TokenUriResolver` | `setSvgContentsOf(...)` | Anyone with matching bytes | Uploads write-once SVG payloads for committed hashes |
-| `Banny721TokenUriResolver` | `decorateBannyWith(...)` | Current body owner | Equips or unequips accessories and updates custody |
-| `Banny721TokenUriResolver` | `lockOutfitChangesFor(...)` | Current body owner | Extends the outfit lock window for that body |
-
-## Immutable And One-Way
-
-- SVG hash commitments are write-once.
-- SVG contents are write-once once uploaded.
-- `lockOutfitChangesFor(...)` only extends the active lock.
-- The lock duration is fixed by `_LOCK_DURATION`.
-- Default art fragments, category semantics, and the trusted forwarder are constructor or code immutables.
-
-## Operational Notes
-
-- Treat `setSvgHashesOf(...)` like a release gate. A wrong hash usually means a new resolver or new UPC strategy, not a small edit.
-- Treat `setMetadata(...)` and `setProductNames(...)` as collection-wide display changes.
-- Remind users that equipped assets are in resolver custody while attached.
-- Only lock outfits when temporary non-editability is the intended experience.
-- Use safe ERC-721 transfer flows when assets enter the resolver path. Plain `transferFrom` can strand NFTs without a recovery path.
-
-## Machine Notes
-
-- Do not assume there is a rescue path for equipped assets. There is none.
-- Treat `src/Banny721TokenUriResolver.sol` as the source of truth for lock extension and write-once SVG behavior.
-- If a committed hash and intended asset bytes differ, stop. The contract does not support overwrite repair.
-- If an asset arrived through non-safe ERC-721 transfer semantics, do not assume the resolver can detect or recover it.
-
-## Recovery
-
-- Bad metadata can be changed by the owner.
-- Bad SVG commitments or uploaded content cannot be corrected in place.
-- If equipped assets become stuck because of resolver logic, there is no owner rescue path.
-- If NFTs are stranded through non-safe transfer semantics, this contract does not provide recovery.
-
-## Admin Boundaries
-
-- The owner cannot arbitrarily withdraw equipped user NFTs.
-- The owner cannot overwrite committed hashes or uploaded SVG contents.
-- The owner cannot bypass body-owner checks on decoration or locking.
-- Nobody can shorten an active outfit lock.
-- There is no pause, upgrade, or rescue mechanism.
-
-## Source Map
-
-- `src/Banny721TokenUriResolver.sol`
-- `src/interfaces/IBanny721TokenUriResolver.sol`
-- `script/Deploy.s.sol`
-- `test/TestAuditGaps.sol`
-- `test/TestQALastMile.t.sol`

package/ARCHITECTURE.md

@@ -1,101 +0,0 @@
-# Architecture
-
-## Purpose
-
-`banny-retail-v6` is the Banny-specific metadata and attachment layer for Juicebox 721 collections. It does not mint NFTs or own treasury logic. It owns attachment custody, outfit-lock rules, and final token rendering.
-
-## System Overview
-
-The repo centers on `Banny721TokenUriResolver`. A 721 hook from `nana-721-hook-v6` points to this resolver for `tokenURI(...)`. Bodies, outfits, and backgrounds remain separate NFTs at the collection layer. The resolver escrows equipped accessories, records which assets are attached to each body, and composes the final SVG and JSON metadata on demand.
-
-## Core Invariants
-
-- A body can only reference accessories that are currently escrowed by the resolver.
-- Replacing an equipped item must atomically return the old item and escrow the new item.
-- Outfit locks must block both explicit removal and implicit replacement until the lock expires.
-- Equipped assets move with the body NFT on transfer until the new owner unequips them.
-- Registered SVG payloads must match their committed content hash before they can render.
-- Rendering must stay deterministic for the same stored body state.
-
-## Modules
-
-| Module | Responsibility | Notes |
-| --- | --- | --- |
-| `Banny721TokenUriResolver` | Escrow, attachment state, lock windows, and metadata rendering | Main contract |
-| `IBanny721TokenUriResolver` | External integration surface | Used by hooks and offchain tooling |
-
-## Trust Boundaries
-
-- Minting, ownership transfer, and collection-level ERC-721 semantics live in `nana-721-hook-v6`.
-- This repo is trusted for rendering correctness and custody of equipped assets.
-- Asset-content upload is controlled by the registered content owner, but the contract verifies uploaded bytes against the stored hash.
-
-## Critical Flows
-
-### Decorate
-
-```text
-body owner
-  -> calls decorateBannyWith(...)
-  -> resolver verifies body ownership and lock status
-  -> resolver pulls new accessories into escrow
-  -> resolver updates equipped slots
-  -> resolver returns replaced accessories to the owner
-```
-
-### Render
-
-```text
-tokenURI(bodyId)
-  -> resolver loads body, background, and equipped slot state
-  -> fetches registered SVG fragments
-  -> composes layered SVG in Banny-specific order
-  -> returns base64 JSON metadata
-```
-
-### Lock Outfit
-
-```text
-body owner
-  -> calls lockOutfitChangesFor(...)
-  -> resolver stores a no-change window
-  -> later decoration and removal paths must respect it
-```
-
-## Accounting Model
-
-This repo does not own treasury accounting. Its critical state is custody accounting: which NFTs are escrowed, which body they belong to, and when a body is locked against changes.
-
-That custody model uses lazy reconciliation for some stale attachment records. Read paths filter against current ownership and attachment state instead of rewriting storage on every outside transfer.
-
-## Security Model
-
-- The main failure mode is custody drift between slot state and actual escrowed NFTs.
-- Rendering order is part of app semantics, not cosmetic output.
-- Lazy reconciliation is intentional. Changes that assume storage is always perfectly clean can strand assets or mis-render bodies.
-- Any new asset category adds both a rendering concern and a custody concern.
-
-## Safe Change Guide
-
-- Keep generic ERC-721 behavior in `nana-721-hook-v6`, not here.
-- Review escrow writes and transfer behavior together whenever changing attachment logic.
-- If transfer or cleanup behavior changes, re-check lazy reconciliation alongside body-transfer inheritance.
-- If `tokenURI(...)` changes, test stable output for unchanged state and replacement behavior for changed state.
-- If adding slots or asset classes, update rendering order, slot replacement, and lock enforcement in one change.
-
-## Canonical Checks
-
-- accessory escrow, replacement, and decoration flow:
-  `test/DecorateFlow.t.sol`
-- burned-body custody edge cases:
-  `test/audit/BurnedBodyStrandsAssets.t.sol`
-- transfer-path protection against stranded attachments:
-  `test/audit/TryTransferFromStrandsAssets.t.sol`
-
-## Source Map
-
-- `src/Banny721TokenUriResolver.sol`
-- `test/DecorateFlow.t.sol`
-- `test/audit/BurnedBodyStrandsAssets.t.sol`
-- `test/audit/TryTransferFromStrandsAssets.t.sol`
-- `script/Deploy.s.sol`

package/AUDIT_INSTRUCTIONS.md

@@ -1,78 +0,0 @@
-# Audit Instructions
-
-This repo is the Banny avatar composition layer. It does not mint the base NFTs, but it does hold equipped accessories and define the metadata users see.
-
-## Audit Objective
-
-Find issues that:
-
-- strand outfits or backgrounds in resolver custody
-- let the wrong actor equip, unequip, overwrite, or recover accessories
-- break outfit-lock timing or freeze a body longer than intended
-- return metadata that does not match stored attachment state
-- bypass category or layering constraints
-
-## Scope
-
-In scope:
-
-- `src/Banny721TokenUriResolver.sol`
-- `src/interfaces/IBanny721TokenUriResolver.sol`
-- deployment helpers in `script/`
-
-## Start Here
-
-1. `src/Banny721TokenUriResolver.sol`
-2. accessory receipt and release paths
-3. deployment wiring in `script/`
-
-## Security Model
-
-The resolver is an attachment and rendering layer around a `JB721TiersHook` collection.
-
-- the underlying 721 hook remains the token contract and source of body ownership
-- the resolver temporarily holds accessory NFTs while they are equipped
-- body ownership should be the only authority that changes equipped state
-- accessory contracts may be hostile or malformed, so receipt and release ordering matters
-
-## Roles And Privileges
-
-| Role | Powers | How constrained |
-|------|--------|-----------------|
-| Body owner | Equip, unequip, and lock accessories | Must be derived from the current hook-reported owner |
-| Resolver owner | Update metadata and SVG-related admin state | Must not control equipped-state authorization |
-| Accessory NFT contract | Execute callbacks during custody changes | Must not corrupt bookkeeping or steal custody |
-
-## Integration Assumptions
-
-| Dependency | Assumption | What breaks if wrong |
-|------------|------------|----------------------|
-| `JB721TiersHook` | Reports authentic body ownership and tier metadata | Unauthorized decoration or incorrect rendering |
-| Accessory ERC-721s | Behave like standard transferable NFTs | Custody or release flows fail unexpectedly |
-
-## Critical Invariants
-
-1. Every accessory transferred into the resolver remains attributable to one body or is recoverable by the rightful owner.
-2. Only the current body owner or an intended delegate can change that body's equipped state.
-3. Conflicting categories cannot be equipped together, including through replacement or invalidation edge paths.
-4. Outfit-lock state only affects the intended body for the intended duration.
-5. Metadata and SVG generation reflect current state and do not show impossible combinations.
-
-## Attack Surfaces
-
-- decoration entrypoints that replace one accessory with another
-- ERC-721 receipt hooks and any path that accepts custody
-- release paths after redecorating, burning, or invalid token state
-- category validation and conflict checks
-- metadata assembly that assumes onchain assets or tier data remain available
-
-## Accepted Risks Or Behaviors
-
-- Equipped accessories intentionally follow the body unless they are unequipped first.
-- Preserving attribution on failed transfer-out is safer than dropping custody state.
-
-## Verification
-
-- `npm install`
-- `forge build`
-- `forge test`

package/RISKS.md

@@ -1,80 +0,0 @@
-# Banny Retail Risk Register
-
-This file focuses on the failure modes that can break NFT custody, bypass hook assumptions, or leave a rendered Banny in a state that does not match the assets users think they own.
-
-## How to use this file
-
-- Read `Priority risks` first.
-- Use `Accepted Behaviors` to separate intentional tradeoffs from bugs.
-- Treat `Invariants to Verify` as required test and audit targets.
-
-## Priority risks
-
-| Priority | Risk | Why it matters | Primary controls |
-|----------|------|----------------|------------------|
-| P0 | Untrusted `hook` or store integration | The resolver trusts the supplied hook for ownership checks, tier metadata, and transfers. A bad hook can fake authority or trap assets. | Restrict supported hooks, scrutinize the hook boundary, and test hostile hook behavior. |
-| P1 | Silent transfer-failure retention | Failed returns intentionally keep attachment records to avoid stranding NFTs, but this can leave phantom render state if the asset is gone forever. | Explicit accepted-behavior rules, retained-item handling, and custody/state invariants. |
-| P1 | Sale-time outfit-lock griefing | A seller can transfer a locked body and force the buyer to wait up to 7 days before changing outfits. | Fixed-duration lock, marketplace disclosure, and user education. |
-
-## 1. Trust Assumptions
-
-- **Trusted forwarder.** ERC-2771 `_msgSender()` is trusted for ownership checks and admin functions.
-- **Hook contract.** The `hook` parameter is caller-supplied and not validated against a registry.
-- **Owner.** The contract owner controls SVG hashes, product names, and metadata URIs.
-- **721 hook store.** `_storeOf(hook)` trusts the hook to return a legitimate store.
-
-## 2. Economic And Manipulation Risks
-
-- **Outfit theft via body transfer.** Equipped outfits and backgrounds move with the body NFT. If a body is sold while wearing valuable items, the buyer gains control of them.
-- **Try-catch silent failures with retention.** Failed transfer-outs preserve attachment records instead of clearing state. This avoids stranding but can create phantom render entries for burned or removed assets.
-- **Lock griefing.** `lockOutfitChangesFor` extends the lock to `block.timestamp + 7 days`. Locking just before a sale can block the buyer from changing the look for up to 7 days.
-
-## 3. Access Control
-
-- **No hook validation.** Any address can be passed as `hook`. A malicious hook can fake `ownerOf`, execute arbitrary code during transfers, or return manipulated tier data.
-- **SVG content upload is permissionless once the hash is committed.** This is safe only if the committed hash is correct.
-- **`onERC721Received` restriction.** The contract only accepts NFTs when `operator == address(this)`. Plain `transferFrom` bypasses that and can permanently lock NFTs.
-
-## 4. DoS Vectors
-
-- **External call iteration scales with outfit count.** `decorateBannyWith` iterates both old and new outfit arrays, so gas cost scales with the number of outfits changed in one call.
-- **External hook calls in view functions.** `tokenUriOf` and `svgOf` call into the hook's store multiple times. A malicious or gas-heavy hook can make metadata unreadable.
-
-## 5. Integration Risks
-
-- **Cross-contract NFT custody.** Outfits are held by the resolver via `safeTransferFrom`. If approval is revoked on the hook contract, equipping fails.
-- **Tier removal desync.** If a tier is removed while an outfit from that tier is equipped, the outfit may remain attached but render empty.
-- **Non-safe transfer loss.** Outfits sent directly via `transferFrom` can be permanently stuck because there is no rescue function.
-- **Reentrancy assumptions.** `decorateBannyWith` uses `nonReentrant`, but other functions rely on ordering and limited state impact instead.
-
-## 6. Invariants to Verify
-
-- Every outfit held by the contract has a corresponding wearer mapping to a valid body.
-- Every background held by the contract has a corresponding user mapping to a valid body.
-- `outfitLockedUntil` is monotonically non-decreasing per body.
-- After `decorateBannyWith`, old outfits not in the new set are either returned or explicitly retained because transfer-out failed.
-- Category exclusivity holds on the merged set of retained and newly supplied outfits.
-- SVG content integrity holds for all populated entries.
-- The number of held outfit NFTs should match the number of outfits still tracked as equipped for that hook.
-
-## 7. Accepted Behaviors
-
-### 7.1 Failed transfers retain attachment records
-
-If returning a previously equipped item fails, the resolver keeps the attachment record instead of dropping it. This avoids stranding NFTs held by the resolver, but it can leave cosmetic phantom state for permanently unrecoverable assets.
-
-### 7.2 Lock griefing is bounded at 7 days
-
-`lockOutfitChangesFor` can force a buyer to wait, but the window is fixed and cannot be extended arbitrarily beyond the current maximum.
-
-### 7.3 Onchain SVG rendering gas is acceptable
-
-Full `tokenUriOf` rendering is expensive but still within practical RPC limits for the supported outfit counts.
-
-### 7.4 Outfits burn alongside the body
-
-If a body NFT is burned while outfits are equipped, those outfits are intentionally unrecoverable. Users who want to keep them must unequip first.
-
-### 7.5 Reentrancy in non-guarded functions is treated as harmless under the current model
-
-`lockOutfitChangesFor` only extends a timestamp, and view functions do not write storage. That keeps the remaining reentrancy surface narrow.

package/SKILLS.md

@@ -1,42 +0,0 @@
-# Banny Retail
-
-## Use This File For
-
-- Use this file when the task involves Banny outfit attachment, layered SVG rendering, token URI composition, or asset custody and lock behavior.
-- Start here, then decide whether the issue is custody state, lock timing, stored SVG content, or final token-URI composition.
-
-## Read This Next
-
-| If you need... | Open this next |
-|---|---|
-| Repo overview and user-facing behavior | [`README.md`](./README.md), [`ARCHITECTURE.md`](./ARCHITECTURE.md) |
-| Resolver implementation | [`src/Banny721TokenUriResolver.sol`](./src/Banny721TokenUriResolver.sol) |
-| Runtime and content-management invariants | [`references/runtime.md`](./references/runtime.md), [`references/operations.md`](./references/operations.md) |
-| Deployment or scripted drops | [`script/Deploy.s.sol`](./script/Deploy.s.sol), [`script/Drop1.s.sol`](./script/Drop1.s.sol), [`script/Add.Denver.s.sol`](./script/Add.Denver.s.sol) |
-| Decoration lifecycle and custody invariants | [`test/DecorateFlow.t.sol`](./test/DecorateFlow.t.sol), [`test/OutfitTransferLifecycle.t.sol`](./test/OutfitTransferLifecycle.t.sol) |
-| Adversarial, fork, or final QA coverage | [`test/BannyAttacks.t.sol`](./test/BannyAttacks.t.sol), [`test/Fork.t.sol`](./test/Fork.t.sol), [`test/TestAuditGaps.sol`](./test/TestAuditGaps.sol), [`test/TestQALastMile.t.sol`](./test/TestQALastMile.t.sol) |
-
-## Repo Map
-
-| Area | Where to look |
-|---|---|
-| Main contract | [`src/Banny721TokenUriResolver.sol`](./src/Banny721TokenUriResolver.sol) |
-| Scripts | [`script/`](./script/) |
-| Tests | [`test/`](./test/) |
-
-## Purpose
-
-App-layer token URI resolver for Juicebox 721 collections. It lets Banny body NFTs equip outfit and background NFTs, holds them while equipped, and renders fully onchain layered SVG metadata.
-
-## Reference Files
-
-- Open [`references/runtime.md`](./references/runtime.md) for attachment and custody behavior, rendering order, and the main invariants that protect equipped assets.
-- Open [`references/operations.md`](./references/operations.md) for upload and metadata-management behavior, deployment breadcrumbs, and common stale-data traps around SVG content.
-
-## Working Rules
-
-- Start in [`src/Banny721TokenUriResolver.sol`](./src/Banny721TokenUriResolver.sol) for both rendering and attachment behavior.
-- Treat custody, stale attachment cleanup, and lock timing as high-risk. Rendering bugs are visible, but custody bugs are worse.
-- Equipped outfits and backgrounds travel with the body NFT. Treat that inheritance as intentional before calling it a bug.
-- When a task mentions minting, pricing, or terminal accounting, verify that the problem is not actually in the upstream 721 hook repo.
-- If you touch SVG or metadata behavior, check whether the issue is in stored content, rendering composition, or the hook-to-resolver integration point before patching.