The SqueekMatchEscrow contract stage is complete and committed. All checks pass: forge build, 92 tests across 8 suites under the verifier's fuzz seed and a second seed, and forge fmt --check.

What was built

• src/SqueekMatchEscrow.sol: one ownerless, fee-free contract with asks, bids and swaps, each with create, fill and cancel. Asks keep the Squeek in the maker's wallet. Bids escrow SQK for any Squeek at an exact level, with an optional merge-ready filter. Swaps trade Squeek for Squeek, pinned to a token or any Squeek at a level, with an SQK difference payable by either side. Expiry defaults to 7 days with a 30-day cap. The maker may cancel at any time and anyone may cancel after expiry, with refunds always going to the maker. Every action emits an event, every function is reentrancy guarded, and effects precede token moves.
• Level and eligibility are read at fill from SqueekMining through the NFT's mining() pointer. Merge-ready mirrors SqueekMining's own merge precondition: live position, below the maximum level, no pending power change, cooldown reached at SqueekCore's completed block height.
• test/: mocks of the four Squeekchain contracts, three reentrancy attackers, success and failure tests for every path, SQK conservation checks, and five fuzz tests.
• docs/abi/SqueekMatchEscrow.json, README.md, a reviewable deploy script with a tested deploy function, and vendored forge-std 1.17.0 and OpenZeppelin 5.4.0 as plain files.

Deployment parameters for the manifest step

Both come from the Squeekchain Deployments page named in the brief and were verified live on Sepolia through a public RPC. The constructor makes no external call. No $owner argument exists because the brief requires no owner, and there is nothing to set after launch.

Points for the independent review

• Squeekchain documents its contracts as in active development. SqueekMining and SqueekCore are proxies, so a breaking change to position, collectionPolicy or state would make bid and swap fills revert while asks keep working. The README records this.
• The brief's "deposit state" and mergeDeposited refer to a staking feature whose ABI Squeekchain has not published. A deposited Squeek is simply not owned by its holder, so fills involving it revert with a named error.
• A scratch test replicating the protected floor (CREATE2 deploy from a factory on an empty chain plus an opcode scan) passed with a 10,459-byte runtime. Slither was not available on this machine and did not run.

Created launch.json with the accepted constructor addresses.

Manifest structure and ABI checks passed. forge build succeeded; all 92 tests passed with the supplied fuzz seed. No other submission files changed.

Notes flag an address mismatch between the live API and official deployment record, requiring resolution before trading.

I found one medium-severity defect and one informational item, and wrote them to .imd-findings.json with a coverage row for each of the 9 entry points. The existing test suite passes (92 tests). No repository files were changed; the scratch test directory has been deleted.

Findings

1. Medium: old asks and swaps come back to life when the Squeek returns to the maker (src/SqueekMatchEscrow.sol:219, and the same check at :372). At fill time the contract only checks who owns the Squeek now. When the Squeek leaves the maker's wallet, any other order for it stays open for up to 30 days. If the Squeek later comes back, anyone can fill that old order at its old terms.

   • Example: Alice lists Squeek 11 at 1 SQK and again at 100 SQK. Bob fills the 100 SQK ask. Two days later Alice buys 11 back from Bob. Carol then fills Alice's forgotten 1 SQK ask, and Alice loses the Squeek for 1 SQK.
   • Broken promise: the README says "only one fill can succeed" when a Squeek is listed twice.
   • Proof: an attached Foundry test fails on the current code for exactly this reason.
   • Suggested fix: tie each order to the ownership period it was created in, for example with a per-maker, per-token counter that each fill increases.

2. Info: bids and swaps can be created at levels that can never fill (:255, :327). Only level 0 is rejected. On Sepolia the maximum level is 10, so a bid for level 11 or higher can never match. A merge-ready bid or swap at level 10 always reverts at fill. Nobody loses funds, because the maker can cancel at any time, but the SQK sits in an order that looks open.

What I checked and found sound

• Matches the live contracts: I read the verified SqueekMining source on Sepolia. The escrow's merge-ready check matches what merge() actually requires:
  • no scheduled power change;
  • cooldown block reached (blockHeight < nextMergeBlock is the same threshold);
  • below the maximum level.
• No surprises from the other contracts:
  • transferring a Squeek never calls into SqueekMining, so a Squeek that was ready before the fill is still ready after it;
  • token id 0 is never minted, so it is safe as the "any Squeek" value;
  • SQK is a plain capped ERC20 with no transfer fee.
• Data reads: the escrow's interface structs decode the live Sepolia return values correctly.
• Expiry: fills work strictly before expiresAt and cancelling by anyone is allowed from expiresAt on, with no gap or overlap. A 30-day duration is accepted, and the expiry value cannot overflow.
• Escrowed SQK: each amount enters once at creation and leaves once, through either a fill or a cancel.

Coverage: the five entry points named in the findings (createAsk, createBid, createSwap, fillAsk, fillSwap) are marked as findings. The other four (fillBid, cancelAsk, cancelBid, cancelSwap) hold. None were left unreached.

Static-analysis leads: I rejected all of them.

• Slither's warnings about the strict equality and timestamp comparisons describe intended behaviour.
• Aderyn's reentrancy warning at line 219 points at a read-only ownerOf call inside a reentrancy-guarded function, and the order's status is set before any token moves.

I couldn't read the Squeekchain docs site (it blocks automated requests), so the merge-rule comparison rests on the verified on-chain source instead.

I found two medium-severity defects in SqueekMatchEscrow. Both are written to .imd-findings.json, each with a Foundry proof. Each proof fails on the current code and passes once a minimal fix is applied. I tried that fix in a separate copy under /tmp, so no repository file was changed. Both defects come from the same gap: an ask or swap records only the maker and the token id, and a fill re-checks only that the maker still owns the token and has approved the escrow.

Finding 1 (medium): a merged-up Squeek sells at its old price (src/SqueekMatchEscrow.sol:218, swap version at :371-373)

• What happens: Alice lists her level-1 Squeek A1 for 1 SQK. She then buys a level-1 partner through her own merge-ready bid and merges, keeping A1, which becomes level 2. Bob can still fill the old ask and gets the level-2 Squeek for 1 SQK.
• Swap version: the same happens with a swap. Someone who brings a level-1 Squeek receives Alice's level-2.
• Why it's likely: this is the app's main flow. Merging and cancelling are separate transactions, and Alice's approval for all her Squeeks stays on because every trade needs it.
• Fix: store the Squeek's level when the order is created and require it to be unchanged at fill.

Finding 2 (medium): an old order comes back to life when the Squeek returns (src/SqueekMatchEscrow.sol:219)

• What happens: Alice lists A1 for 1 SQK, sells it into Bob's 5 SQK bid, then buys it back from Bob's 6 SQK ask. Her forgotten 1 SQK ask is fillable again, and Carol takes A1 for 1 SQK.
• README conflict: the README says a superseded listing "reverts with MakerNoLongerOwns until it is cancelled". That only holds while the token is away from the maker.
• Fix: keep a per-token counter that goes up every time the escrow moves the token, and reject orders created under an older value. A transfer outside the escrow still needs the maker to cancel, and the README should say so.

Coverage: the record has a row for all 9 entry points plus 3 invariant and static-analysis rows.

• Findings: createAsk, fillAsk, createSwap and fillSwap.
• Holds:
  • The three cancels: each refunds exactly once, only to the maker, and only the maker can cancel before expiry.
  • createBid and fillBid: checked against the published SqueekMining merge rules. The merge-ready check matches what a merge requires: no pending power change, below the maximum level, and the cooldown block reached. Transfers don't reset a Squeek's position.
• Static-analysis leads, both rejected:
  • Aderyn reentrancy at line 219: it's a read-only ownerOf call, every function has the reentrancy guard, and order status is set before any token moves.
  • Slither strict equality at line 451: it's an intended order-status comparison.
• Checks that held: escrowed SQK always equals the open bid amounts plus the makers' swap payments, and expiry boundaries are consistent between fill and cancel.

Not covered:

• The real behaviour of the Sepolia SqueekMining contract. I checked the docs, not the deployed code.
• Whether a merged Squeek's pending power change shows up the way the docs describe.
• launch.json, which doesn't exist yet at this stage. That isn't a defect.

The scratch tests, the patched copy and the forge build output have all been removed. Only .imd-findings.json is new, and it's untracked.

The review is complete. The findings file is valid, the snippet matches the tree at the cited line, all nine entry points have a coverage row, and the scratch test is removed. The working tree holds no changes beyond the findings file, which is ignored by git.

Outcome. The permission model of SqueekMatchEscrow holds up. There is no owner, initializer, proxy or privileged path, every state-changing entry point is reentrancy guarded, and every token movement is bounded to the parties of the order being filled or cancelled. I report one low-severity asymmetry and no permission bypass.

What I checked across the three guides

• Access Control: every writer of each order's status, the maker-or-expired cancel gate, the self-trade gate, and the confused-deputy question of whether the escrow's Squeek or SQK approvals can be spent through someone else's order. They cannot: fills only move the stored maker's listed token and the caller's own token, and SQK is only ever pulled from the caller.
• Asymmetry: create versus fill versus cancel for all three kinds, the fill settlement order under maker and taker receive hooks, and the view versus fill expiry comparisons. A scratch test confirmed a swap maker that moves its offered Squeek away inside the hook reverts the whole fill.
• Trust Gap: the merge-ready gate against the live Sepolia SqueekMining implementation fetched from Sourcify. Its merge requires exactly what the escrow enforces for the delivered Squeek, SqueekNFT transfers never call Mining, and SQK is a plain capped ERC-20. The live ABI word layouts of position, collectionPolicy and state match the interface.

The finding, low severity. Fills check the taker's Squeek live for level and merge readiness, but never re-read the maker's listed Squeek in an ask or the maker's offered Squeek in a swap. A maker can merge that Squeek up as a survivor after creating the order, which raises its level and sets a pending round and cooldown, and an incoming fill still succeeds. The taker loses no SQK and receives a higher-level token, but not the merge partner the trade was for. The reproduction and a minimal fix that keeps the design are in the file.

Also verified, not findings. The README's two Sepolia constructor addresses respond correctly over a public RPC, the committed ABI export is identical to the compiled ABI, the full suite passes 92 of 92, and all four static-analysis leads are false positives for the reasons given in the coverage rows.

Not reached. The Squeekchain docs site is behind a bot wall, so the merge rules were taken from the verified on-chain source rather than the documentation.

I audited the economics of SqueekMatchEscrow and found 5 defects: 1 high, 2 medium and 2 low. They're all written to .imd-findings.json, with coverage rows for all 9 entry points. No project files changed, and I deleted my scratch tests afterwards.

Proofs: findings 1 and 2 carry proof tests that fail on the current code. They pass against a candidate fix I tried in a throwaway copy, not in your tree. That fix isn't the only option, and its token-level approval requirement has a usability cost that finding 2 describes. Finding 3 has no proof because it needs a fork, which the proof format doesn't allow.

What holds:

• All three cancel functions and fillBid behave as intended, and the 92 existing tests pass.
• Escrowed SQK is fully accounted for by open orders, based on reading the code; no test checked this on a fork.
• The mergeReady check matches the real merge rules, and the contract's struct layouts match the live contracts.
• The Aderyn and Slither leads were false positives; each has a coverage row explaining why.

What I couldn't reach:

• Squeekchain docs: docs.squeekchain.com returned a Cloudflare 403, and I didn't try to get around it. I used the Sourcify-verified NFT, SQK and Mining source plus live chain reads instead.
• SqueekCore source: I only exercised it through live reads and didn't read its code.
• launch.json: it doesn't exist in this tree yet, so there was no manifest to review.

The live figures come from a fork around Sepolia block 12051138, so they will drift over time. All of it is testnet SQK.

I added invariant and edge-case tests for SqueekMatchEscrow, and they pass. I found no critical or high defects; two lesser issues are written up in .imd-findings.json. The full suite is 110 tests passing with the verifier's fuzz seed, and forge build is clean. I only added files under test/, and the earlier contributors' tests are unchanged.

test/SqueekMatchEscrow.invariant.t.sol (the contract holds SQK for bids and swaps)

• A handler makes random calls with four users and twelve Squeeks. It covers create, fill and cancel for asks, bids and swaps, plus outside events: time passing, Squeek levels, cooldowns and pending power changing, Squeeks moving between wallets, approvals being revoked, and SQK sent straight to the contract.
• Before every escrow call, the handler works out on its own whether the call should succeed. Afterwards it checks the actual result and the exact SQK and Squeek movements.
• Five invariants, 256 runs × 60 calls:
  • every call behaved as the handler predicted;
  • the contract's SQK balance equals what open bids and swaps are owed plus any SQK sent to it directly;
  • nothing is paid out beyond what was put in, and no maker is refunded more than they deposited;
  • total SQK and the number of Squeeks never change, and the contract never holds a Squeek;
  • stored orders match what was requested, and filled or cancelled orders never reopen.
• To check the harness isn't vacuous, I planted a double-refund bug in a scratch copy. Four of the five invariants caught it. The totals check can't see that kind of bug by design, since a double refund moves SQK between users without changing the total.

test/SqueekMatchEscrow.edges.t.sol (17 tests)

• Order ids that are unknown, zero, or belong to a different order type.
• The exact expiry second for fills and for cancels by someone other than the maker, and the "expired" flag in cancel events.
• Someone approved to manage another holder's Squeeks still can't sell them.
• Approval for a single Squeek works and is used up by the sale; revoking it blocks a swap fill but the maker can still get their SQK back.
• A swap that names a specific Squeek, a Squeek that doesn't exist yet, and Squeek id 0.
• A Squeek's level and live status are read at fill time, not when the order was made.
• An old ask can't take a Squeek from its new owner.
• A fuzz test (1,000 runs) that orders can't touch each other's escrowed SQK.

Findings in .imd-findings.json:

• Low: old orders stay open and can come back to life. An ask or swap stays open after the maker moves the Squeek away, and isOpen() still returns true. If the Squeek comes back to the maker while their approval for the contract is still set, the old order fills at its old price. Example: createAsk(A1, 1 ether), the maker sends A1 to carol, carol sends it back, then bob buys it with fillAsk for 1 ether. I confirmed this in a scratch test. The website's "floor ask" and match board would also show these listings even though they can't be filled.
• Info: impossible levels are accepted. createBid and createSwap only reject level 0, although the code comments say 1 up to the maximum level. createBid(255, …) succeeds and creates an order nothing can ever fill. No SQK is lost because cancelling refunds it in full.

I didn't write tests that assert either behaviour is correct. The one test touching the second finding passes whether the contract rejects those levels or accepts them, as long as the maker gets a full refund.

The review is complete. The findings file .imd-findings.json holds five merged findings and twelve coverage rows, and no repository file was changed (the scratch tests I used are removed).

What I reproduced and kept

1. Medium: listed Squeek's level is not pinned. Asks and swaps store only the token id. The verified SqueekMining merge raises the survivor's level in place with no transfer, so an open order sells the merged, higher-level Squeek plus its accrued credit at the old price. Three specialists reported this (rated high, medium and low); merged into one finding at medium, since it needs an order left open on the Squeek being merged. Both specialist proofs failed on this tree as stated. One is attached.
2. Medium: orders revive when the Squeek returns. Nothing closes an ask or swap when its Squeek leaves the maker. Under a standing operator approval, the forgotten order fills again once the token comes back. Four specialists reported this; merged into one finding. Both attached proofs failed as stated. One is attached. The README's "until it is cancelled" guarantee is false in this state.
3. Low: unfillable levels accepted at creation. Bids and swaps for level 11 or merge-ready at level 10 are created and escrow SQK although no Squeek can fill them. Three reports merged. I wrote and attached a self-contained proof that fails on this code.
4. Low: accrued SQK is not bindable. A swap maker contract can claim the listed Squeek's accrued SQK inside the receive callback between the two NFT transfers. Reproduced with a mock claim. Recalibrated from medium to low because no contract guarantee is broken and the brief already treats this as a website warning.
5. Low: isOpen reports unfillable orders. Revoking approval leaves an order open with no event. Reproduced.

Dropped leads

• The aderyn reentrancy line is a view read before a state write under nonReentrant.
• The slither strict-equality and timestamp lines are an enum comparison and the designed expiry.

Verified clean

• The manifest has only the schema keys, two string constructor arguments in declaration order, and a 1,037-character note. Live Sepolia reads confirm the NFT's mining contract names the same SQK token and NFT, so the accepted constants are internally consistent. I could not reach the Squeekchain API or docs (Cloudflare challenge), so the deployment-identity note in the manifest stays unverified.
• The ABI export equals the compiled ABI, runtime is about 10.5 KB with no forbidden opcodes, and all 110 project tests pass.

Coverage: six of nine entry points carry a finding, three hold, plus three invariant rows. Nothing was marked unreached.

All five findings reproduced and are fixed. Both reviewer proofs now pass, and the full suite passes with and without the verifier's fuzz seed.

What was wrong. An ask or swap stored only maker, token, price and expiry. The fill re-checked ownership and approval, but a merge raises the survivor's level without any transfer, so a stale listing could sell the upgraded Squeek at the old price. And an order stayed Open after the Squeek left, so it revived at the old terms when the Squeek came back under a standing approval.

Changes in src/SqueekMatchEscrow.sol:

• Asks and swaps now record the maker Squeek's level at creation. The fill reverts with LevelMismatch if the live level differs.
• A per-token tradeCount is bumped by every fill that moves a Squeek. Asks and swaps record it at creation and the fill reverts with StaleOrder once it has changed. The ownership check still runs first, so the documented MakerNoLongerOwns is unchanged while the Squeek is away.
• Bid and swap creation now reject levels no Squeek can satisfy. That means a level above the collection maximum, or merge-ready at the maximum.
• Swap settlement delivers the maker's Squeek to the taker before the taker's Squeek reaches the maker, closing the in-hook claim window.
• A new isFillable view applies the maker-side checks so the website can filter phantom floors. The isOpen view is unchanged and its docs now say what it ignores.
• The created events carry the recorded level for indexers.

Tests and docs. The test suite grew from 92 to 107 tests, with new cases for the merge scenario, revival via bid-and-ask and via two swaps, the outside-transfer limit, creation-time level bounds, the claiming maker contract, and the new view. Mocks gained a settable maximum level and a claim stub that enforces the owner rule. The ABI export was regenerated and the README documents the pin, the counter, the fact that accrued SQK is not part of the trade, and that transfers made outside the escrow still need a cancel.

Verification. The build, the tests under the verifier's fuzz seed, and the format check all pass. Lint output is the same three categories as the starting tree. Runtime is about 12 KB. Each finding is answered as fixed in .imd-responses.json.

One design note for the reviewer: a transfer made outside the escrow does not bump the counter, so a Squeek that leaves and returns by another route keeps its old listing live. That is documented as a maker responsibility rather than enforced, since the escrow sees no such transfers.

The manifest is done and verified. Only launch.json changed.

What I found. This revision came with no listed findings, so I checked the accepted manifest against the accepted source instead of guessing. The single contract SqueekMatchEscrow has a nonpayable constructor taking two addresses, SqueekNFT and SqueekToken, and the manifest fills exactly those in declaration order. The contract has no owner, so no $owner argument is needed, which matches the brief's "no owner, no fee, no proxy" requirement. The addresses match the deploy script constants, the README deployment table and the deployment test.

On-chain confirmation. Both published Squeekchain sources sit behind a Cloudflare challenge and could not be fetched from this machine. I verified the inputs against Sepolia directly through a public RPC instead. The NFT argument reports name Squeek and symbol SQUEEK and points to a SqueekMining contract whose configuration names the same SQK token and the same NFT. The token argument reports symbol SQK with 18 decimals. The alternative token from the earlier review finding also exists and also reports symbol SQK, so only an address comparison can distinguish them.

What I changed. The contract list and constructor arguments are unchanged from the accepted manifest. I extended the notes with today's on-chain confirmation and with the observation that the two SQK tokens share a symbol, and kept the prior deployment-identity finding and its instruction to refuse trading on mismatch. Notes remain well under the limit.

Checks run:

• Scratch schema check: exact keys, string arguments, identifier length, dependency order and notes length all pass.
• forge build succeeds.
• forge test with the verifier's fuzz seed: 107 passed, 0 failed.

The deployment-identity conflict between the documented deployment and the API remains a review item for the services stage, not a manifest defect.

My test suites compiled again and now pass. With the verifier's seed, forge build succeeds and forge test runs 131 tests in 11 suites with 0 failures. I found no defects in the revised contract, so I wrote no .imd-findings.json. Only test/SqueekMatchEscrow.invariant.t.sol and test/SqueekMatchEscrow.edges.t.sol changed.

Why work was needed: the implementation changed after my last round. Asks and swaps now record the Squeek's level and a per-Squeek trade count when created, and the maximum level is read from the live mining policy. My invariant file read the old order layouts and no longer compiled.

Invariant suite

• Updated model: the handler now predicts:
  • NoLivePosition and InvalidLevel (against the current maximum level) at creation.
  • On fills: the maker's Squeek is still theirs, still approved, untraded here since the order was made (StaleOrder), and at the same level (LevelMismatch).
  • Trade counts going up on every fill, on both sides of a swap.
• New checks: isFillable and tradeCount must match the model, and the new layouts are compared field by field. A new handler action changes the policy's maximum level.
• It was barely testing fills. A probe showed only 2 ask fills, 4 bid fills and 0 swap fills in about 8,000 random calls. I steered fills toward live orders, made cancels choose orders at random, and toned down level changes, long time jumps and maximum-level changes. I also added an action that creates a swap and fills it straight away. Swap fills went from 0–3 to about 11 per 4,000 calls, and ask and bid fills went up too.
• One overflow found along the way was a bug in my handler, not the contract, and is fixed.
• Proof it catches defects: with the StaleOrder check removed from the contract locally, the invariant failed with "fillAsk: succeeded but must have reverted". I then restored the source with git.
• All five invariants pass on the verifier seed and on two other seeds.

Edge tests (22 now)

• A bid above the maximum level now pins the exact InvalidLevel revert, with nothing escrowed and no id used.
• Lowering the policy's maximum level makes creation reject levels above it.
• A merge-ready bid whose level becomes the new maximum can't be filled (AtMaximumLevel), and the maker still gets a full refund.
• A swap holding the maker's SQK becomes unfillable when the maker sells the offered Squeek (MakerNoLongerOwns). It stays dead (StaleOrder) when the Squeek is bought back here, and expiry cancel refunds the SQK.
• Selling a Squeek as the taker of a bid also counts as a trade, so the seller's own earlier swap offering it goes stale.
• A fuzz test checks an ask fills only at its exact listed level, and that any other level, including 0, reverts and moves nothing.

One known gap the main suite already documents and I did not change: a transfer made outside the escrow doesn't count as a trade. If a Squeek leaves its maker that way and comes back, their old ask fills again until they cancel it.

All five findings from my earlier round are fixed in the revised code, and nothing new reproduces. The report is written to .imd-findings.json with an empty findings list, a settled record for each earlier finding, and a coverage row for all nine entry points plus three invariants. The working tree is clean apart from that file.

Settled findings, each verified against the code and by running the attached proofs:

• Level pin (medium). Asks and swaps now record the maker Squeek's live level at creation and the fill reverts with LevelMismatch when it differs. All six tests from the three proofs on this root cause pass on the revised tree after failing on the old one.
• Order revival (medium). A per-token trade counter is bumped by every fill that moves a Squeek and checked at fill as StaleOrder, after the ownership check so the documented error is unchanged. My proof and audit_flow's proof pass. Audit_math's proof reverts only because its NFT mock has no mining contract, which the fixed createAsk now reads. That is a mock incompatibility, not a defect.
• Unfillable levels (low). Bid and swap creation now bound the level by the live maximum, strictly below it when merge-ready.
• Mid-fill claim (low). fillSwap delivers the maker's Squeek first, so a contract maker's receive hook no longer owns the token when it tries to claim. The author's test with a claiming maker mock shows the claim refused and the credit still on the token.
• Phantom floors (low). isFillable applies the full maker-side checks, handles burned tokens without reverting, and the README tells the website to filter on it.

Other checks. The full project suite passes with 130 tests. The exported ABI matches the compiled one. The three static-analysis leads are false positives: an enum equality, the documented timestamp expiry, and a struct field sharing a name with a mapping.

One open item, not a defect. The manifest's constructor addresses match the documented Sepolia deployment record and the live NFT's own mining pointer. The Squeekchain API reports a different, newer installation whose mining contract does not track the Squeeks collection. The manifest notes already record this, and the brief assigns the mismatch refusal to the frontend, so I left it as a coverage row rather than a finding.

Frontend source, static export and validation evidence are ready. Build/typecheck, 41 tests and 16 design checks pass.

Trading remains paused because API identities conflict with deployment records. Deposited merging is explicitly unavailable.

Local staging/commit failed because .git is read-only.

Recorded three reproducible findings in .imd-findings.json:

• Accessibility: “Skip to content” navigates to My singles and discards the current form.
• Bug: Failed order-book reads appear as an empty market.
• Bug: Editing an offered NFT during a pending preview can prepare a different NFT from the one inspected.

Build/typecheck passed, the rebuilt export matched exactly, all 41 supplied Chromium tests passed, and eight targeted WebKit checks passed. Asset hashes and the pinned ABI matched. No transaction was signed.

The visual idea is clear: a warm-paper Squeekchain tool carried by paired hamster illustrations.

The checklist below combines duplicated workflow requirements. Component names refer to web/src/.