The code implements the brief's rule exactly (REST requires the caller to hold no Founding Charter), so this is not a deviation from the specification; it is a note on what that rule means against the real dependency, which the project's tests only model with a mock whose holders can freely transfer and burn.

Read from Robinhood Chain (chain 4663, rpc.mainnet.chain.robinhood.com) on 2026-10-13: CHARTER 0x69101f92427376FA80476A997d024cf9dC3EaE39 is an OpenZeppelin-v5-style ERC-721 named 'Founding Charter' with nextId() == 1033; transfersEnabled() returns false and transferFrom by the holder reverts TransfersDisabled; burn(uint256) reverts NotCentralBank for the holder, for owner() (0x5c19F925E1e0D54E34681A6CB70d55c90b12A68c) and for a stranger.

A holder therefore has no transaction of their own that lowers their Charter balance to zero. Under the current Charter state the 720,000,000 BIC REST pool (1032 x REST) is released only to claimants the CentralBank revokes, or to everyone if the Charter owner later calls enableTransfers() (after which a holder can move the Charter to a second wallet and claim REST immediately; the id cannot be claimed again, so no double payment arises).

The same parties can also block a revoked claimant's REST by minting them a new Charter (any id, including above 1032). CharterClaim has no admin, so none of this can be adjusted after launch. If this is the intended design (REST as compensation for revoked Charters) no change is needed; the README should state the live transfer/burn restrictions rather than only 'the collection must report a zero balance'.

Area: Trust Gap (access x economics). CharterClaim's permission model is correct, but every payout is an unreserved transfer from whatever balance the contract happens to hold.

The contract has no owner, no funding hook and no way to be topped up except a plain ERC-20 transfer, and the brief's 10/10/80 split conflicts with the generic launch policy quoted in the assignment (which routes the requester's share to the pool and the requester's wallet, and says no application contract receives supply at launch). README.md lines 28-36 already flag this conflict.

If the factory funds CharterClaim with less than ALLOCATION, nothing in the contract detects it: entitled claimants are paid in call order until the balance runs out and the remainder revert with ERC20InsufficientBalance, with no way for anyone to correct it other than sending more BIC. This is a launch-integration dependency, not a code bug; it is reported so the judge and the manifest step confirm the funding recipient and amount.

Live-chain note: 62 of IDs 1-1032 are already burned on the real Charter (0x69101f92...) and burned IDs cannot be reminted (mint(address) auto-increments nextId, currently 1033), so about 62 * SHARE = 48,062,015 BIC of the 800,000,000 is locked forever by design.

Area: Access Control / Asymmetry (gate on a value a third party can write). The REST gate reads the claimant's collection-wide balanceOf, which any current Charter holder can increase by calling transferFrom/safeTransferFrom on the Charter.

I verified on Robinhood Chain (chain id 4663) that the Founding Charter at 0x69101f92427376FA80476A997d024cf9dC3EaE39 is a standard, freely transferable OpenZeppelin ERC-721 (transferFrom, safeTransferFrom, approve, setApprovalForAll present; no ERC-5192 lock; supportsInterface(0x80ac58cd)=true, (0xb45a3c0e)=false), with ~901 distinct holders and ids 2-1033 existing.

So the gate is satisfiable by moving a Charter to a second wallet (REST does not require giving up economic control), and griefable by gifting a Charter to a claimant. The grief is self-limiting: the victim keeps the NFT and can transfer it back out in one transaction (as the scratch test shows), and the griefer permanently gives up a Charter, so there is no loss of funds.

This matches the brief's literal requirement ('holds no Founding Charter at all') and README.md line 73 documents it; it is recorded as a trust assumption, not a defect, with an asymmetry note: claimable(account) also reports rest = 0 while the gifted Charter is held, which is consistent with claimRest.

The claimant is bound permanently to the first wallet that claims an id (line 56) and REST is gated only by the caller's current Charter balance (line 68). Nothing ties REST to actually relinquishing the Charter.

If the Charter owner calls enableTransfers() (an owner-only function present in the live runtime), a holder can claim INSTANT, move the Charter to a second wallet they control, claim REST from the first wallet, and move the Charter back, keeping full membership while having collected 100% of SHARE.

The same mechanism means a secondary-market buyer of a Charter whose id was already claimed gets no claim at all: claim([id]) reverts AlreadyClaimed and claimRest requires claimant[id]==msg.sender, so the seller keeps both halves. This follows the brief's wording ('the wallet holds no Founding Charter'), so it is a design note rather than a code defect; it matters because the 10%/90% split reads as an incentive to give up the Charter, which the contract cannot enforce.

The README already states the reacquisition limitation but not the buyer-gets-nothing consequence. If the requester wants REST to require giving up the Charter, the brief must change (e.g. require that ownerOf(id) reverts, i.e. the id was burned, instead of balanceOf==0).

claimRest checks the collection-wide balanceOf(msg.sender), including ids above MAX_ID that have no claim of their own (id 1033 is already minted on the live contract: ownerOf(1033) = 0x681D22c5E615C7a876026ceba3dC36c6dDE5b97d, while ownerOf(1034) reverts ERC721NonexistentToken).

Once the Charter owner enables transfers, any holder can transfer a Charter into a claimant's wallet and that claimant's claimRest reverts StillHoldsCharter until they move it out again; claimable(victim) also reports rest = 0. Today, with transfers disabled, only the central bank can create this state (mint(address) to the claimant), which is a privileged action.

Cost to a griefer is one Charter per attempt (the victim can forward it elsewhere), so the impact is a recoverable delay, not a loss, and the behaviour follows the brief's requirement. Reported so the requester knows the wallet-balance rule, not CharterClaim, decides this, and so the README's 'receiving an unwanted Charter can temporarily block REST' is understood to include ids outside 1..1032.

The brief lists the views as claimant(id), instantClaimed(id), restClaimed(id) and claimable(id, account), the last 'returning the instant and rest amounts that account could claim now' for one id. The code exposes claimable(address) only, which scans all 1032 ids (each an external ownerOf STATICCALL when the account holds a Charter) and returns aggregate totals. The compiled ABI (forge inspect) has claimable(address) and no claimable(uint256,address).

README line 79 says the builder 'interpreted' a 'truncated views line'; the brief as supplied to this review is not truncated.

Impact: integrators and the launch frontend calling the specified selector revert, there is no per-id eligibility query, and the aggregate scan costs roughly 1032 external calls per eth_call. No funds are affected; claim and claimRest are unchanged.

Fix: add claimable(uint256 id, address account) returning (instant, rest) for that id (instant = INSTANT when id in range, claimant[id]==0 and ownerOf(id)==account, else 0; rest = REST when claimant[id]==account, !restClaimed[id] and balanceOf(account)==0, else 0). The aggregate view may stay as an extra.

Merged from audit_flow (info), audit_economics #1 (medium) and the gifting notes of audit_permissions #2 and audit_economics #3; one root cause, the collection-wide balance gate the brief requires.

The code implements the brief exactly ('Require CHARTER.balanceOf(msg.sender) == 0'; 'This still works if the Charter was later revoked or burned'), so this is a trust assumption on the Charter issuer, not a code deviation, and it is calibrated low rather than the specialist's medium.

Verified on Robinhood Chain (chain id 4663, rpc.mainnet.chain.robinhood.com, 2026-10-13): CHARTER 0x69101f92427376FA80476A997d024cf9dC3EaE39 is 'Founding Charter', nextId()==1033, transfersEnabled()==false, owner()==0x5c19F925E1e0D54E34681A6CB70d55c90b12A68c, centralBank()==0x5977B25419f9c0dDcB2F89fE204955622f4F57ea; ownerOf(1) reverts ERC721NonexistentToken(1) (burned), ownerOf(2)==0x6d5d4fb55c61019c5eb9236c3da58c774B8232D1, ownerOf(1033) exists.

Consequences: (a) after claiming INSTANT no holder can reach balanceOf==0 by their own transaction, so each id's REST is paid only after the central bank burns that holder's Charter(s) or the owner calls enableTransfers(); if neither happens, 1032*REST stays locked in a contract with no admin or recovery, by design.

(b) The central bank can today, and any holder once transfers are enabled, block a revoked claimant's REST by minting/transferring a Charter to them; ids above MAX_ID count too (1033 exists).

While transfers are disabled a claimant who is minted a new Charter cannot dispose of it, so the block lasts as long as the issuer wants. audit_permissions #2's statement that the live Charter is freely transferable is wrong (a holder's transferFrom reverts TransfersDisabled) and was not kept.

README line 73 ('provided the collection reports a zero balance') and line 106 ('Receiving an unwanted Charter can temporarily block REST') do not state that on the live Charter the holder has no path of their own and that only the issuer's burn (or enabling transfers) releases REST.

Fix within the agreed design: state these live-Charter facts in the README so the requester confirms with the issuer that revocation is the intended release path; changing the gate (e.g. to ownerOf(id) reverting, i.e. the id burned) is a brief change and is noted as a tradeoff only.

Merged from audit_economics #2 (low), recalibrated to info: the brief states both behaviours ('Each id pays out once in total: INSTANT to whoever claims it while holding it, then REST to that same claimant once they hold no Charter'; the gate is the wallet's balanceOf).

The claimant is bound permanently at line 56 and never re-read from ownerOf, so (a) if the Charter owner calls enableTransfers() (owner-only function present in the live runtime; today transfersEnabled()==false), a claimant can move the Charter to a second wallet, call claimRest, and move it back, keeping membership plus 100% of SHARE; (b) a secondary buyer of an already-claimed id can never claim (AlreadyClaimed) and claimRest requires claimant[id]==msg.sender.

No funds are lost or double-paid; each id still pays exactly SHARE once. README line 73 notes reacquisition but not that a transferred Charter carries no claim value after its first claim; adding that sentence is the only change suggested. Making REST require giving up the Charter would be a change to the brief.

Merged from audit_permissions #1 (info), kept at info. The brief gives no funding check and the constructor may not call the token (the launch floor runs constructors on an empty chain), so the code is correct against the brief; this is a launch-integration dependency.

The generic launch text routes the requester's 90% to the pool and the requester's wallet and says no application contract receives supply at launch, while the brief and README lines 28-36 require 80% sent to the contract named CharterClaim. If the factory does not perform that transfer, every claim reverts with ERC20InsufficientBalance; if it sends less than ALLOCATION, entitled claimants are paid in call order until the balance runs out.

Also noted for the requester: 62 of ids 1..1032 are already burned on the live Charter (e.g. ownerOf(1) reverts) and OZ-style mint(address) auto-increments nextId (now 1033), so those ids can never be reminted and about 62*SHARE (about 48M BIC) is locked by design.

Needed evidence: the manifest/deployment step confirms the recipient and amount of the 80% transfer to the deployed CharterClaim address.