@bananapus/721-hook-v6 0.0.76 → 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +5 -0
  2. package/package.json +5 -5
package/README.md CHANGED
@@ -64,6 +64,9 @@ If a bug affects supply, reserve minting, or tier lookup, it usually lives in th
64
64
  - custom token URI resolvers should be treated as part of the trusted surface
65
65
  - adding a 721 hook through a deployer is easy; carrying the right ruleset behavior forward is where mistakes happen
66
66
  - projects should be explicit about whether the hook affects pay, cash out, or only metadata-facing paths
67
+ - reserve beneficiary defaults are mutable hook state, so operators should not rely on later same-batch updates when
68
+ computing who receives reserve NFTs
69
+ - future token-URI resolver slots are metadata authority; treat resolver changes like collection-facing admin actions
67
70
  - per-tier owner-tracked voting units are queryable via `getPastTierVotingUnits(tierId, blockNumber)`: mints, transfers, and burns write ownership history, so the trace follows owned units regardless of delegation
68
71
  - active delegated vote totals are queryable globally via `getPastTotalActiveVotes(blockNumber)` / `getTotalActiveVotes()` and per tier via `getPastTotalTierActiveVotes(tierId, blockNumber)` / `getTotalTierActiveVotes(tierId)`. These totals include only voting units held by accounts with a nonzero delegate, so a token in undelegated custody does not count and returned tokens become active again if the holder's delegation is still set.
69
72
  - per-account active tier voting units are queryable via `getPastAccountTierActiveVotes(account, tierId, blockNumber)`. This follows the account holding the tier units, not the delegate receiving voting power, so reward distributors can cap tier-scoped claims against the holder's active units even when votes are delegated to another address.
@@ -139,6 +142,8 @@ script/
139
142
  - custom token URI resolvers are part of the security surface
140
143
  - projects need to be deliberate about whether the hook participates in pay, cash out, or both paths
141
144
  - tier mutations after launch are powerful and should be permissioned carefully
145
+ - distributors and curated drops that depend on historical 721 ownership should pre-warm checkpoints before relying on
146
+ snapshot-based eligibility
142
147
 
143
148
  When people say "the 721 hook," they often mean three different things: the hook contract, the store, and the metadata resolver plugged into it.
144
149
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bananapus/721-hook-v6",
3
- "version": "0.0.76",
3
+ "version": "1.0.0",
4
4
  "license": "MIT",
5
5
  "repository": {
6
6
  "type": "git",
@@ -25,10 +25,10 @@
25
25
  "artifacts": "source ./.env && npx sphinx artifacts --org-id 'ea165b21-7cdc-4d7b-be59-ecdd4c26bee4' --project-name 'nana-721-hook-v6'"
26
26
  },
27
27
  "dependencies": {
28
- "@bananapus/address-registry-v6": "^0.0.35",
29
- "@bananapus/core-v6": "^0.0.86",
30
- "@bananapus/ownable-v6": "^0.0.39",
31
- "@bananapus/permission-ids-v6": "^0.0.31",
28
+ "@bananapus/address-registry-v6": "^1.0.0",
29
+ "@bananapus/core-v6": "^1.0.0",
30
+ "@bananapus/ownable-v6": "^1.0.0",
31
+ "@bananapus/permission-ids-v6": "^1.0.0",
32
32
  "@openzeppelin/contracts": "5.6.1",
33
33
  "@prb/math": "4.1.2",
34
34
  "solady": "0.1.26"