@croptop/core-v6 0.0.19 → 0.0.21

package/ADMINISTRATION.md

@@ -6,25 +6,25 @@ Admin privileges and their scope in croptop-core-v6.
 
 ### 1. Project Owner
 
-**How assigned:** Receives the JBProjects ERC-721 NFT for the project. Initially set by the `owner` parameter in `CTDeployer.deployProjectFor()` (line 325, `CTDeployer.sol`). Can be transferred via standard ERC-721 transfer.
+**How assigned:** Receives the JBProjects ERC-721 NFT for the project. Initially set by the `owner` parameter in `CTDeployer.deployProjectFor()`. Can be transferred via standard ERC-721 transfer.
 
 **Scope:** Per-project. Controls posting rules and hook ownership for a single project.
 
 ### 2. Hook Owner
 
-**How assigned:** Determined by `JBOwnable(hook).owner()`. For CTDeployer-launched projects, the deployer initially owns the hook (via `DEPLOYER.deployHookFor()` at line 264). The project owner can later claim hook ownership via `claimCollectionOwnershipOf()` (line 223).
+**How assigned:** Determined by `JBOwnable(hook).owner()`. For CTDeployer-launched projects, the deployer initially owns the hook (via `DEPLOYER.deployHookFor()`). The project owner can later claim hook ownership via `claimCollectionOwnershipOf()`.
 
 **Scope:** Per-hook. The hook owner (or anyone with `ADJUST_721_TIERS` permission for that hook's project) can configure posting criteria.
 
 ### 3. CTDeployer (Contract)
 
-**How assigned:** Immutable singleton deployed at construction. Acts as the `IJBRulesetDataHook` for all CTDeployer-launched projects (set at line 290 of `CTDeployer.sol`).
+**How assigned:** Immutable singleton deployed at construction. Acts as the `IJBRulesetDataHook` for all CTDeployer-launched projects (set in `deployProjectFor()`).
 
 **Scope:** All Croptop-deployed projects. Proxies pay/cashout data hook calls, grants fee-free cashouts to suckers, and holds broad permissions on behalf of launched projects.
 
 ### 4. CTPublisher (Contract)
 
-**How assigned:** Immutable singleton deployed at construction. Receives `ADJUST_721_TIERS` permission from CTDeployer at construction (line 113-119, `CTDeployer.sol`).
+**How assigned:** Immutable singleton deployed at construction. Receives `ADJUST_721_TIERS` permission from CTDeployer at construction.
 
 **Scope:** All hooks for which it has `ADJUST_721_TIERS` permission. Creates NFT tiers and mints first copies.
 
@@ -34,9 +34,11 @@ Admin privileges and their scope in croptop-core-v6.
 
 **Scope:** Per-project. Grants `CTPublisher` permanent `ADJUST_721_TIERS` permission for the received project. Once the project is transferred here, human ownership is effectively burned.
 
+- **Important:** `onERC721Received()` accepts project NFTs from any transfer, not only mints. If a project owner accidentally transfers their project NFT to `CTProjectOwner`, it is permanently locked -- there is no recovery function. The only check is that `msg.sender` is the `PROJECTS` contract (ensuring it is a JBProjects NFT, not an arbitrary ERC-721).
+
 ### 6. Sucker Registry
 
-**How assigned:** Immutable dependency set at CTDeployer construction (line 98). Receives `MAP_SUCKER_TOKEN` permission at construction (line 101-110, `CTDeployer.sol`).
+**How assigned:** Immutable dependency set at CTDeployer construction. Receives `MAP_SUCKER_TOKEN` permission at construction.
 
 **Scope:** All projects deployed via CTDeployer. Can map tokens for cross-chain bridging. Determines which addresses get fee-free cashouts.
 
@@ -52,42 +54,54 @@ Admin privileges and their scope in croptop-core-v6.
 
 | Function | Required Role | Permission ID | Scope | What It Does |
 |----------|--------------|---------------|-------|-------------|
-| `deployProjectFor()` (line 243) | Anyone | None | Global | Deploys a new Juicebox project with 721 hook, configures posting rules, optionally deploys suckers, transfers ownership to `owner`. No access restriction -- anyone can deploy a project. |
-| `claimCollectionOwnershipOf()` (line 223) | Project owner | None (direct `ownerOf` check) | Per-project | Transfers hook ownership to the project via `JBOwnable.transferOwnershipToProject()`. Caller must be `PROJECTS.ownerOf(projectId)`. |
-| `deploySuckersFor()` (line 346) | Project owner or delegate | `JBPermissionIds.DEPLOY_SUCKERS` | Per-project | Deploys new cross-chain suckers for an existing project. Uses `_requirePermissionFrom()` against the project owner. |
+| `deployProjectFor()` | Anyone | None | Global | Deploys a new Juicebox project with 721 hook, configures posting rules, optionally deploys suckers, transfers ownership to `owner`. No access restriction -- anyone can deploy a project. |
+| `claimCollectionOwnershipOf()` | Project owner | None (direct `ownerOf` check) | Per-project | Transfers hook ownership to the project via `JBOwnable.transferOwnershipToProject()`. Caller must be `PROJECTS.ownerOf(projectId)`. |
+| `deploySuckersFor()` | Project owner or delegate | `JBPermissionIds.DEPLOY_SUCKERS` | Per-project | Deploys new cross-chain suckers for an existing project. Uses `_requirePermissionFrom()` against the project owner. |
 
 ### CTPublisher
 
 | Function | Required Role | Permission ID | Scope | What It Does |
 |----------|--------------|---------------|-------|-------------|
-| `configurePostingCriteriaFor()` (line 230) | Hook owner or delegate | `JBPermissionIds.ADJUST_721_TIERS` | Per-hook, per-category | Sets posting rules: minimum price, min/max supply, max split percent, address allowlist. Uses `_requirePermissionFrom()` against `JBOwnable(hook).owner()`. |
-| `mintFrom()` (line 297) | Anyone (subject to allowlist) | None (enforced by allowlist in `_setupPosts`) | Per-hook | Publishes posts as 721 tiers, mints first copies, routes 5% fee to `FEE_PROJECT_ID`. Validates all posts against configured criteria. |
+| `configurePostingCriteriaFor()` | Hook owner or delegate | `JBPermissionIds.ADJUST_721_TIERS` | Per-hook, per-category | Sets posting rules: minimum price, min/max supply, max split percent, address allowlist. Uses `_requirePermissionFrom()` against `JBOwnable(hook).owner()`. |
+| `mintFrom()` | Anyone (subject to allowlist) | None (enforced by allowlist in `_setupPosts`) | Per-hook | Publishes posts as 721 tiers, mints first copies, routes 5% fee to `FEE_PROJECT_ID`. Validates all posts against configured criteria. |
 
 ### CTProjectOwner
 
 | Function | Required Role | Permission ID | Scope | What It Does |
 |----------|--------------|---------------|-------|-------------|
-| `onERC721Received()` (line 47) | Anyone who transfers a JBProjects NFT | None | Per-project | On receiving a project NFT from `PROJECTS` (mint only, `from == address(0)` is NOT enforced here), grants `CTPublisher` the `ADJUST_721_TIERS` permission for that project. |
+| `onERC721Received()` | Anyone who transfers a JBProjects NFT | None | Per-project | On receiving a project NFT from `PROJECTS` (mint only, `from == address(0)` is NOT enforced here), grants `CTPublisher` the `ADJUST_721_TIERS` permission for that project. |
 
 ### Permissions Granted at CTDeployer Construction
 
 These permissions are set in the CTDeployer constructor and apply to all projects it will ever deploy (wildcard `projectId: 0`):
 
-| Permission | Granted To | Line | Purpose |
-|-----------|-----------|------|---------|
-| `MAP_SUCKER_TOKEN` | `SUCKER_REGISTRY` | 101-110 | Allows the sucker registry to map tokens for cross-chain bridging on any project owned by CTDeployer. |
-| `ADJUST_721_TIERS` | `PUBLISHER` (CTPublisher) | 113-119 | Allows CTPublisher to add tiers to any hook on any project owned by CTDeployer. |
+| Permission | Granted To | Purpose |
+|-----------|-----------|---------|
+| `MAP_SUCKER_TOKEN` | `SUCKER_REGISTRY` | Allows the sucker registry to map tokens for cross-chain bridging on any project owned by CTDeployer. |
+| `ADJUST_721_TIERS` | `PUBLISHER` (CTPublisher) | Allows CTPublisher to add tiers to any hook on any project owned by CTDeployer. |
 
 ### Permissions Granted During `deployProjectFor()`
 
-These permissions are set per-project during deployment (line 328-339, `CTDeployer.sol`):
+These permissions are set per-project during deployment:
+
+| Permission | Granted To | Purpose |
+|-----------|-----------|---------|
+| `ADJUST_721_TIERS` | `owner` | Allows the project owner to adjust 721 tiers. |
+| `SET_721_METADATA` | `owner` | Allows the project owner to update 721 metadata. |
+| `MINT_721` | `owner` | Allows the project owner to mint 721 tokens directly. |
+| `SET_721_DISCOUNT_PERCENT` | `owner` | Allows the project owner to set tier discount percentages. |
+
+## Data Hook Proxy
+
+When deploying a project, `CTDeployer` sets itself as the project's `dataHook` in the ruleset metadata. It then proxies data hook calls to the project's actual 721 tiers hook:
+
+- **`beforePayRecordedWith`**: Calls `IJBRulesetDataHook(hook).beforePayRecordedWith(context)` where `hook = dataHookOf[context.projectId]`, then returns the 721 hook's specifications.
+- **`beforeCashOutRecordedWith`**: Checks if the caller is a registered sucker via `SUCKER_REGISTRY.isSuckerOf()`. If so, returns 0% cash-out tax (fee-free bridging). Otherwise, delegates to the 721 hook.
+- **`hasMintPermissionFor`**: Returns `true` for registered suckers, `false` for all other addresses. Does not delegate to the 721 hook.
+
+This proxy pattern exists so that CTDeployer can intercept cash-out calls to grant fee-free bridging to suckers while still supporting the 721 hook's NFT minting logic.
 
-| Permission | Granted To | Line | Purpose |
-|-----------|-----------|------|---------|
-| `ADJUST_721_TIERS` | `owner` | 329 | Allows the project owner to adjust 721 tiers. |
-| `SET_721_METADATA` | `owner` | 330 | Allows the project owner to update 721 metadata. |
-| `MINT_721` | `owner` | 331 | Allows the project owner to mint 721 tokens directly. |
-| `SET_721_DISCOUNT_PERCENT` | `owner` | 332 | Allows the project owner to set tier discount percentages. |
+The `dataHookOf[projectId]` mapping is write-once (set during `deployProjectFor`, no setter function). The proxy target cannot be changed after deployment.
 
 ## Immutable Configuration
 
@@ -104,9 +118,9 @@ These values are set at deploy time and cannot be changed after deployment:
 | `SUCKER_REGISTRY` | CTDeployer | Constructor (immutable) | Sucker registry for cross-chain bridging. |
 | `PERMISSIONS` | CTDeployer, CTProjectOwner | Constructor (immutable) | JBPermissions contract for access control. |
 | `trustedForwarder` | CTDeployer, CTPublisher | Constructor (immutable via ERC2771Context) | Meta-transaction trusted forwarder address. |
-| `dataHookOf[projectId]` | CTDeployer | `deployProjectFor()` (line 307) | Once set during deployment, the data hook for a project can never be changed. Write-once storage. |
-| Project weight | CTDeployer | `deployProjectFor()` (line 256) | Hardcoded at `1_000_000 * 10^18` with ETH base currency and max cashout tax rate. |
-| Hook deploy salt | CTDeployer | `deployProjectFor()` (line 286) | `keccak256(abi.encode(salt, msg.sender))` -- deterministic but caller-specific. |
+| `dataHookOf[projectId]` | CTDeployer | `deployProjectFor()` | Once set during deployment, the data hook for a project can never be changed. Write-once storage. |
+| Project weight | CTDeployer | `deployProjectFor()` | Hardcoded at `1_000_000 * 10^18` with ETH base currency and max cashout tax rate. |
+| Hook deploy salt | CTDeployer | `deployProjectFor()` | `keccak256(abi.encode(salt, msg.sender))` -- deterministic but caller-specific. |
 
 ## Admin Boundaries
 
@@ -118,11 +132,11 @@ What admins CANNOT do:
 
 3. **Project owners cannot change the data hook.** `dataHookOf[projectId]` is write-once (set during `deployProjectFor`, no setter function). The data hook proxy pattern is permanent.
 
-4. **Project owners cannot disable Croptop posting entirely for a category.** `configurePostingCriteriaFor()` requires `minimumTotalSupply > 0` (line 250-252, `CTPublisher.sol`). The workaround is to set an astronomically high `minimumPrice` with `minimumTotalSupply = maximumTotalSupply = 1`. See finding NM-006.
+4. **Project owners cannot disable Croptop posting entirely for a category.** `configurePostingCriteriaFor()` requires `minimumTotalSupply > 0`. The workaround is to set an astronomically high `minimumPrice` with `minimumTotalSupply = maximumTotalSupply = 1`. See finding NM-006.
 
 5. **Project owners cannot bypass posting criteria to mint directly through CTPublisher.** They must use `mintFrom()` like anyone else, which enforces all configured rules. However, owners can adjust tiers directly on the hook (bypassing CTPublisher) if they have `ADJUST_721_TIERS` permission.
 
-6. **CTPublisher cannot mint without paying.** `mintFrom()` requires `msg.value >= totalPrice + fee` (line 332-334). There is no free-mint path through CTPublisher.
+6. **CTPublisher cannot mint without paying.** `mintFrom()` requires `msg.value >= totalPrice + fee`. There is no free-mint path through CTPublisher.
 
 7. **CTProjectOwner cannot return project ownership.** Once a project NFT is transferred to CTProjectOwner, there is no function to transfer it back. Ownership is effectively burned.
 

package/ARCHITECTURE.md

@@ -13,10 +13,11 @@ src/
 ├── CTProjectOwner.sol   — Proxy owner for Croptop-deployed projects
 ├── interfaces/
 │   ├── ICTDeployer.sol
+│   ├── ICTProjectOwner.sol
 │   └── ICTPublisher.sol
 └── structs/
     ├── CTAllowedPost.sol         — Rules for what can be posted
-    ├── CTDeployerAllowedPost.sol — Deployer-level post rules
+    ├── CTDeployerAllowedPost.sol — Deployer-level post rules (no hook field)
     ├── CTPost.sol                — A post submission
     ├── CTProjectConfig.sol       — Project configuration
     └── CTSuckerDeploymentConfig.sol — Cross-chain config
@@ -25,42 +26,154 @@ src/
 ## Key Data Flows
 
 ### Project Deployment
+
+```
+Creator → CTDeployer.deployProjectFor(owner, projectConfig, suckerConfig, controller)
+  1. Deploy 721 hook via IJB721TiersHookDeployer (empty tiers, ETH currency)
+  2. Launch JB project with:
+     → weight = 1,000,000 * 10^18
+     → cashOutTaxRate = MAX (100%)
+     → dataHook = CTDeployer itself (see "Data Hook Behavior" below)
+     → useDataHookForPay = true, useDataHookForCashOut = true
+  3. Store dataHookOf[projectId] = the 721 hook (for pay forwarding)
+  4. Configure allowed post rules on CTPublisher
+  5. Deploy suckers for cross-chain support (if configured)
+  6. Transfer project NFT to the specified owner
+  7. Grant owner permissions: ADJUST_721_TIERS, SET_721_METADATA, MINT_721, SET_721_DISCOUNT_PERCENT
+```
+
+### Content Publishing (mintFrom)
+
 ```
-Creator → CTDeployer.deployProjectFor()
-  → Launch JB project via JB721TiersHookProjectDeployer
-  → Configure CTDeployer as data hook
-  → Set allowed post rules (price floors, supply limits, categories)
-  → Transfer project ownership to CTProjectOwner proxy
+Publisher → CTPublisher.mintFrom(hook, posts[], nftBeneficiary, feeBeneficiary, ...)
+  → _setupPosts: for each post:
+    1. Reject empty encodedIPFSUri
+    2. Reject duplicate encodedIPFSUri within the batch
+    3. If tier already exists for this encodedIPFSUri:
+       → Use existing tier ID, add tier's price to totalPrice
+       → (Prevents fee evasion by using actual on-chain price, not user-supplied)
+    4. If tier is new:
+       → Load allowance for (hook, category) — see "Allowed Post Rules" below
+       → Validate: category enabled, price >= minimum, supply in range,
+         splitPercent <= maximum, caller in allowlist (if restricted)
+       → Create JB721TierConfig with the post's price, supply, category,
+         splitPercent, and splits array
+       → Record tierIdForEncodedIPFSUriOf mapping
+       → Add post.price to totalPrice
+  → Calculate fee: totalPrice / FEE_DIVISOR (5% fee, FEE_DIVISOR = 20)
+     Fee is skipped when projectId == FEE_PROJECT_ID
+  → adjustTiers on the 721 hook to add new tiers
+  → Pay the project terminal: payValue = msg.value - fee
+     Metadata encodes tier IDs to mint, so the 721 hook mints one NFT per post
+  → Pay fee to FEE_PROJECT_ID terminal with remaining balance
 ```
 
-### Content Publishing
+### Allowed Post Rules
+
+Each category on each 721 hook has an allowance stored as bit-packed values in `_packedAllowanceFor[hook][category]`. The project owner configures these via `configurePostingCriteriaFor`.
+
+| Field | Type | Bits | Purpose |
+|-------|------|------|---------|
+| `minimumPrice` | `uint104` | 0-103 | Floor price per NFT. Posts below this revert. |
+| `minimumTotalSupply` | `uint32` | 104-135 | Minimum editions. Must be >= 1; a zero value means the category is disabled. |
+| `maximumTotalSupply` | `uint32` | 136-167 | Maximum editions. Must be >= minimumTotalSupply. |
+| `maximumSplitPercent` | `uint32` | 168-199 | Cap on the publisher's split (out of `SPLITS_TOTAL_PERCENT = 1,000,000,000`). 0 means no splits allowed. |
+| `allowedAddresses` | `address[]` | separate storage | If non-empty, only these addresses may post in this category. Empty means anyone can post. |
+
+Validation order in `_setupPosts`: category enabled (minimumTotalSupply != 0) -> price check -> supply range check -> split percent cap -> allowlist check.
+
+Categories cannot be fully removed after creation. This is by design -- once a category exists, removing posting would break expectations for existing posters. Projects can set restrictive allowance configurations to effectively disable new posts.
+
+## Data Hook Behavior
+
+CTDeployer registers itself as the ruleset's `dataHook` so it can intercept both payments and cash-outs. It acts as a transparent proxy that adds sucker-awareness:
+
+**`beforePayRecordedWith`**: Passthrough with null check. If `dataHookOf[projectId]` is `address(0)`, returns the context weight and empty hook specifications (defaults). Otherwise, forwards the call to the stored data hook (the project's 721 hook). The 721 hook returns the weight and pay hook specifications that handle NFT minting. CTDeployer does not modify pay behavior.
+
+**`beforeCashOutRecordedWith`**: Checks if the `holder` is a sucker for the project (via `SUCKER_REGISTRY.isSuckerOf`). If yes, returns `cashOutTaxRate = 0` with no hook specifications -- suckers cash out without any tax. If no, forwards to `dataHookOf[projectId]` for standard cash-out behavior.
+
+**`hasMintPermissionFor`**: Returns `true` only for addresses that are suckers for the project. This allows suckers to mint tokens on-demand during cross-chain bridging.
+
 ```
-Publisher → CTPublisher.postFor(projectId, posts[])
-  → For each post:
-    → Validate against allowed post rules
-      → Check category permissions
-      → Check price >= minimum
-      → Check supply within bounds
-      → Check publisher in allowlist (if restricted)
-    → Add NFT tier to project's 721 hook
-    → Configure split for publisher (fee share)
-  → Pay project to mint NFTs
+Payment path:        CTDeployer.beforePayRecordedWith → 721 hook (passthrough)
+Cash-out (sucker):   CTDeployer.beforeCashOutRecordedWith → return 0% tax
+Cash-out (normal):   CTDeployer.beforeCashOutRecordedWith → 721 hook (forward)
+Mint permission:     Only suckers get on-demand mint permission
 ```
 
+## Ownership Model
+
+### Why a Proxy Owner?
+
+When CTDeployer creates a project, it initially owns the project NFT (because `launchProjectFor` mints to `msg.sender`). CTDeployer needs to be the initial owner so it can:
+1. Configure posting criteria on CTPublisher (requires `ADJUST_721_TIERS` permission from the hook's owner, which is CTDeployer).
+2. Deploy suckers (requires project ownership).
+3. Grant the final owner NFT management permissions.
+
+After setup, CTDeployer transfers the project NFT to the specified `owner`. The 721 hook's ownership stays with CTDeployer, which has granted `ADJUST_721_TIERS` permission to CTPublisher with `projectId = 0` (wildcard). This means CTPublisher can add tiers to any Croptop-deployed project without further permission grants.
+
+### CTProjectOwner: The Immutable-Rules Pattern
+
+`CTProjectOwner` is a separate contract that serves as a "lockbox" for projects that want immutable posting rules. When the project owner transfers their project NFT to a CTProjectOwner instance:
+
+1. `onERC721Received` fires and grants CTPublisher the `ADJUST_721_TIERS` permission for that project.
+2. CTProjectOwner exposes no function to reconfigure posting criteria, queue new rulesets, or transfer the project further.
+3. The posting rules become permanently frozen -- content can still be published under the existing rules, but the rules themselves cannot change.
+
+This enables a trust model: creators can prove to publishers that the rules (price floors, supply caps, split percentages) will never change, providing a credible commitment that the economic terms are permanent.
+
+### Claiming Collection Ownership
+
+`CTDeployer.claimCollectionOwnershipOf(hook)` allows the project NFT holder to take direct ownership of the 721 hook by calling `JBOwnable.transferOwnershipToProject(projectId)`. After this, the hook's owner resolves to whoever holds the project NFT. The caller must then independently grant CTPublisher the `ADJUST_721_TIERS` permission, or subsequent posts will revert.
+
+## Publisher Fee and Split Mechanics
+
+### Fee Structure
+
+CTPublisher charges a 5% fee (`FEE_DIVISOR = 20`) on the total price of all posts in a `mintFrom` call. The fee is skipped when the target project is the fee project itself (`FEE_PROJECT_ID`).
+
+```
+msg.value breakdown:
+  totalPrice     → paid to the project's terminal (mints NFTs + project tokens)
+  totalPrice/20  → paid to FEE_PROJECT_ID's terminal (Croptop platform fee)
+  remainder      → reverts if insufficient, excess stays as overpayment
+```
+
+### Publisher Split Mechanism
+
+When a publisher creates a new post, they can set a `splitPercent` and a `splits` array on their `CTPost`. These are stored directly on the 721 tier via `JB721TierConfig.splitPercent` and `JB721TierConfig.splits`.
+
+The split mechanics work at the 721 hook level: whenever someone mints (buys) an NFT from that tier, the 721 hook routes `splitPercent` of the tier's price to the addresses in the `splits` array. The publisher typically sets themselves as a split recipient so they earn a share of every future mint from the tier they created.
+
+The project owner controls the maximum split a publisher can claim via `maximumSplitPercent` in the allowed post rules. If `maximumSplitPercent` is 0, publishers cannot set any splits. This gives project owners control over how much revenue publishers can capture versus how much flows to the project treasury.
+
+## Design Decisions
+
+**Permissioned publishing over open posting.** Posts are validated against per-category allowance rules rather than allowing anyone to post anything. This prevents spam, ensures minimum economic commitment (price floors), and lets project owners curate their collection's quality by restricting who can post and at what terms.
+
+**Publisher gets a split, not a direct payment.** Rather than paying publishers upfront, Croptop uses the 721 hook's split mechanism. The publisher earns a percentage of every future mint from their tier. This aligns incentives: publishers profit when their content is popular enough that others want to mint copies, not just from the act of posting.
+
+**CTDeployer as data hook proxy.** Instead of requiring projects to use a custom data hook, CTDeployer inserts itself as a transparent proxy. This lets it add sucker-awareness (tax-free cross-chain cash-outs) without requiring the underlying 721 hook to know about suckers. The 721 hook handles NFT minting logic; CTDeployer handles cross-chain policy.
+
+**Immutable rules via CTProjectOwner.** Rather than building immutability into CTPublisher (which would add complexity for all projects), immutability is opt-in: transfer the project to CTProjectOwner and the rules freeze. Projects that want governance flexibility simply keep the project NFT in a wallet or multisig.
+
+**Category-based organization.** Posts are organized by `category` (uint24), with each category having independent allowance rules. This lets a single project support multiple content types (e.g., category 1 for images at 0.01 ETH, category 2 for music at 0.1 ETH) with different price floors, supply limits, and access controls.
+
+**Duplicate prevention via encodedIPFSUri mapping.** `tierIdForEncodedIPFSUriOf[hook][encodedIPFSUri]` ensures each piece of content can only create one tier. If a tier already exists, the mint uses the existing tier (at its on-chain price, not the caller-supplied price). This prevents duplicate tiers and fee evasion.
+
 ## Extension Points
 
 | Point | Interface | Purpose |
 |-------|-----------|---------|
-| Data hook | `IJBRulesetDataHook` | CTDeployer acts as data hook |
-| 721 hook | `IJB721TiersHook` | NFT tier management |
-| Publisher | `ICTPublisher` | Content posting workflow |
+| Data hook | `IJBRulesetDataHook` | CTDeployer proxies pay/cash-out hooks, adds sucker-awareness |
+| 721 hook | `IJB721TiersHook` | NFT tier management, split routing on mints |
+| Publisher | `ICTPublisher` | Content posting workflow and allowance configuration |
 
 ## Dependencies
-- `@bananapus/core-v6` — Core protocol
-- `@bananapus/721-hook-v6` — NFT tier system
-- `@bananapus/ownable-v6` — JB-aware ownership
-- `@bananapus/permission-ids-v6` — Permission constants
-- `@bananapus/buyback-hook-v6` — Buyback integration
-- `@bananapus/suckers-v6` — Cross-chain support
-- `@bananapus/router-terminal-v6` — Payment routing
-- `@openzeppelin/contracts` — ERC2771, ERC721Receiver
+
+- `@bananapus/core-v6` -- Core protocol (terminals, rulesets, permissions, directory)
+- `@bananapus/721-hook-v6` -- NFT tier system (tiers, minting, splits)
+- `@bananapus/ownable-v6` -- JB-aware ownership (ownership-to-project transfer)
+- `@bananapus/permission-ids-v6` -- Permission constants
+- `@bananapus/suckers-v6` -- Cross-chain support (sucker registry)
+- `@openzeppelin/contracts` -- ERC2771 (meta-transactions), ERC721Receiver