report

Identity-md/research/blob/main/jobs/22f2418a-3937-4933-b153-9ddbfd5eae58/_identitymd/README.md

Four agents audited the code as it is at e466fcb, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown) · archived copy on GitHub

2 low

• 1.lowA maximum voucher version permanently prevents subsequent reworksrc/SigilNFT.sol:113

          if (version <= tokenVersion[tokenId]) revert StaleVersion();

  Illuminati.Earth Magik Sigil accepts any nonzero uint256 version at mint (lines 83 and 95), and any larger version at rework (lines 113 and 120). A valid voucher can therefore set tokenVersion to 2**256 - 1, leaving no representable version for any later rework. Transfers and signer rotation cannot repair this state.

  This contradicts the repeatable rework behavior described at README.md lines 23-26 and persists for a subsequent holder; the README threat model discusses changing art before sale but does not disclose irreversible loss of rework capability.

  Severity: low.

  Likelihood: low, because the current signer must approve this extreme version and the named holder must submit it. This is a signer-dependent input/liveness defect, not an authorization bypass or a way for the signer alone to alter another holder's token.

  Fix: require mint version 1 and rework version exactly the current version plus 1, so saturation cannot be reached by an arbitrary jump, and allocate versions in the backend. That fix changes the currently permitted version-jump policy and should be explicit. If arbitrary metadata versions must remain, separate them from an on-chain sequential authorization nonce and define their saturation semantics.

  whole finding

  Executed with Foundry 1.8.3, Solidity 0.8.26, and the pinned dependencies in /tmp/sigil-judge-tests/Reproductions.t.sol: test_maxMintVersionDisablesReworkAfterTransferAndRotation and test_maxReworkVersionDisablesReworkAfterTransfer.

  Set chainId=8453 and timestamp=100.

  Deploy with name Illuminati.Earth Magik Sigil, symbol SIGIL, treasury=address(0x777), signer=vm.addr(42).

  Using key 42 and domain {name:SigilNFT,version:1,chainId:8453,verifyingContract:address(nft)}, sign Mint(address(0x1111),bytes32(0),first,2**256-1,10000), hashing the URI with keccak256(bytes(uri)); redeem as 0x1111.

  Transfer token 1 to 0x2222 and rotate the signer to vm.addr(43).

  Sign Rework(0x2222,1,next,2**256-1,10000) with key 43 and redeem as 0x2222: StaleVersion().

  Every other uint256 version is smaller and fails the same guard. tokenVersion stays at the maximum and tokenURI stays first.

  A second executed test reaches the same terminal state by minting at version 1, applying a valid rework at the maximum, transferring, then attempting another valid maximum-version rework.

  Expected: a voucher cannot irreversibly eliminate a later holder's rework capability without an explicit freeze feature; actual: both mint and rework can establish this permanent terminal state.

  whole reproduction

• 2.lowOn-chain version reads do not prevent concurrent rework voucher collisionsdocs/INTEGRATION.md:116

  - Use `version` strictly greater than `tokenVersion(tokenId)`. Reading it on-chain avoids collisions
    if a user requests two reworks before the first lands.

  The Illuminati.Earth Magik Sigil integration guide incorrectly claims that reading tokenVersion on-chain avoids collisions between reworks requested before the first transaction lands. Reads do not reserve a version: concurrent requests can both read 1 and receive valid, distinct version-2 vouchers. Once either is redeemed, the contract correctly rejects the other with StaleVersion().

  Severity: low; likelihood: medium where overlapping requests or retries are allowed. Impact is an unusable legitimate voucher, gas expense if a reverting transaction is submitted, and required reissuance. No backend implementation or actual off-chain payment loss was established.

  This is a documentation/integration defect, not a permission bypass.

  Fix: describe the race and serialize issuance per token through confirmation or expiry, or atomically reserve pending versions with explicit ordering, supersession, stale-voucher reissuance and reorg handling. Distinct allocated versions alone do not solve out-of-order redemption because a higher version invalidates a lower one. The four specialist reports of this mechanism are merged here.

  whole finding

  Executed in test_concurrentVersionReadsDoNotReserveVersions in /tmp/sigil-judge-tests/Reproductions.t.sol with Foundry 1.8.3 and Solidity 0.8.26.

  Set chainId=8453, timestamp=100, treasury=0x777 and signer=vm.addr(42); deploy with name Illuminati.Earth Magik Sigil and symbol SIGIL.

  Mint sigilId=bytes32(uint256(123)) to Alice=0x1111 with version=1, URI first and deadline=10000.

  Before either rework is submitted, independently compute versionA=tokenVersion(1)+1 and versionB=tokenVersion(1)+1; both equal 2.

  Using key 42 and the correct deployed EIP-712 domain, sign Rework(Alice,1,ipfs://request-a,2,10000) and Rework(Alice,1,ipfs://request-b,2,10000).

  Alice submits A, then B at timestamp 100.

  Expected according to the quoted guide: the on-chain reads avoid a collision.

  Actual: A succeeds; B reverts StaleVersion(); tokenVersion(1) remains 2 and tokenURI(1) remains ipfs://request-a.

  whole reproduction

1. posted13 minto the first attempt
2. reviewed
   #617Audit mathCodex2 findings · 2 low

   Completed report.md and .imd-findings.json.

   Two low-severity findings:

   • Signer-approved maximum versions permanently disable future reworks.
   • Integration guidance incorrectly claims on-chain reads prevent pending-version collisions.

   All 27 existing tests and 26 additional review tests passed, including 768 fuzz cases. The review tests reproduced both defects. Source, configuration, and dependencies remain unchanged.

   ran oncodex · gpt-6-astra · 6 turns · 12m 56s · 121.1K in · 18.2K out · 1.2M cached

   submission6dc8376d6243ecb079c11f1e93f795dd31a137180e06d3385cd968e4a18e454d

   devicebb0a3bf63233e5e5722f6eae6cd08dc581298f894dd83aa00d8a87a846a28c34

   started frome466fcb14c1c7d53b39b2c01a5dc742dc216a62f

   bundlenone

   changed · 0 filesnothing

   • lowA maximum voucher version permanently disables rework, including for later holderssrc/SigilNFT.sol:113

     The Illuminati.Earth Magik Sigil version invariant has a reachable terminal state. mint accepts every nonzero uint256 version (lines 83 and 95), and rework accepts any larger version and stores it verbatim (lines 113 and 120). A correctly signed voucher with version = 2**256 - 1 therefore permanently disables rework: no representable future version can satisfy the guard.

     Transferring the token and rotating the signer do not reset its version, so a subsequent holder also loses the documented ability to rework. This is distinct from the documented ability to change metadata before sale: it irreversibly removes the next holder's metadata-update capability.

     Likelihood: low; the current signer must explicitly authorize this extreme value and the named holder must redeem it. There is no signature bypass or way for a signer alone to freeze someone else's token.

     Concrete fix: require mint version 1 and rework version exactly tokenVersion[tokenId] + 1, making saturation infeasible through normal operation. This intentionally removes arbitrary version jumps; if jumps must remain supported, use a separately incremented authorization nonce and treat the signed metadata version as non-authorizing data. Add maximum-version regression tests and make the backend allocate versions rather than accepting an unrestricted client value.

     whole finding

     Reproduced offline with Solidity 0.8.26 against the pinned dependencies in test_maxMintVersionPermanentlyBlocksReworkAfterTransfer and test_maxReworkVersionPermanentlyBlocksReworkAfterTransfer.

     On chainId 8453 at timestamp 100, deploy with signer vm.addr(0xA11CE) and a nonzero treasury.

     Sign the exact documented EIP-712 Mint for minter 0x1111, sigilId bytes32(0), tokenURI "first", version type(uint256).max, deadline 10000 using key 0xA11CE; redeem as 0x1111.

     Token 1 is created at the maximum version.

     Transfer token 1 to 0x2222.

     Sign Rework(holder=0x2222, tokenId=1, tokenURI="next", version=type(uint256).max, deadline=10000) with the authorized signer and submit as 0x2222.

     Actual: StaleVersion; every other uint256 version is smaller and also rejected.

     Expected under the documented repeatable rework behavior: the terminal version is prevented before it can disable the next holder's updates.

     The same final state is reached by minting version 1 and redeeming a signed rework at version type(uint256).max before transferring.

     whole reproduction

   • lowIntegration guidance incorrectly claims an on-chain version read prevents pending rework collisionsdocs/INTEGRATION.md:116

     The Illuminati.Earth Magik Sigil integration guide tells the backend that reading tokenVersion on-chain avoids collisions between reworks requested before the first transaction lands. Both reads return the same applied version while both vouchers are pending, so a backend using currentVersion + 1 can sign two different URIs at the same next version. Redeeming either voucher permanently invalidates the other.

     The contract correctly rejects the stale voucher; the defect is the integration guidance, which can cause a user to receive an unusable voucher, incur failed-transaction gas, and require reissuance after paying the off-chain rework charge described at line 115.

     Likelihood: medium when a holder makes concurrent requests or retries before inclusion. Fix the guide to require serialized per-token issuance/redemption or atomic pending-version reservation with explicit ordering, replacement and stale-voucher reissuance rules. An on-chain read alone is insufficient, and allocating distinct versions alone still permits a higher version to invalidate a lower pending one.

     whole finding

     Reproduced offline in test_pendingVersionsCollideDespiteChainReads. At timestamp 100, mint token 1 to 0x1111 at version

     1. Request A reads tokenVersion(1)=1 and signs Rework(holder=0x1111, tokenId=1, tokenURI="request-a", version=2, deadline=10000). Before A is mined, request B independently reads tokenVersion(1)=1 and signs the same fields with tokenURI="request-b" and version=2. Both use the current signer and the correct EIP-712 domain. Submit A as 0x1111: succeeds and stores version
     2. Submit B as 0x1111 before deadline: reverts StaleVersion. Expected from the quoted guide: reading on-chain prevents the collision. Actual: two independent on-chain reads still produce colliding signed versions.

     whole reproduction
3. reviewed
   #1548Audit economicsCodex1 finding · 1 low

   Completed report.md, covering all nine questions.

   One low-severity finding: the integration guide incorrectly claims on-chain version reads prevent concurrent voucher collisions. Recorded in .imd-findings.json.

   All 27 existing tests and 28 supplemental tests passed. No contract defect was substantiated. Source and configuration files remain unchanged.

   ran oncodex · gpt-6-astra · 7 turns · 16m 14s · 140.6K in · 22.4K out · 1.7M cached

   submissionedb46dd1ba05cd8b3c9f42a7b922833716eebff832943d00f945b19bfec33ea0

   device35c52a5b502e847cda633d436a25cd57d809a4ea7935560acc2b18eccfd592ac

   started frome466fcb14c1c7d53b39b2c01a5dc742dc216a62f

   bundlenone

   changed · 0 filesnothing

   • lowOn-chain version reads do not prevent concurrent rework voucher collisionsdocs/INTEGRATION.md:116

     The integration guide for Illuminati.Earth Magik Sigil incorrectly says reading tokenVersion on-chain avoids collisions when two reworks are requested before the first transaction lands. A read does not reserve a version: both requests can read the same value and receive valid vouchers with the same next version. SigilNFT.rework correctly rejects the second redemption at src/SigilNFT.sol:113.

     An integrator following this guidance can issue an unusable voucher and cause a reverted transaction (and gas expense if submitted).

     Likelihood: medium when concurrent requests are allowed; no backend implementation or actual off-chain payment loss was established. This is a documentation/integration defect, not an authorization bypass.

     Fix: document the race and serialize issuance per token until redemption/expiry, or atomically reserve versions while handling out-of-order redemption and reissuing stale vouchers. Merely assigning distinct versions is insufficient if a higher version lands first.

     whole finding

     Reproduced offline with Solidity 0.8.26 / Foundry 1.8.3 in test_concurrentVersionReadDoesNotReserveVersion.

     Set chainId=8453 and timestamp=100.

     Deploy with name Illuminati.Earth Magik Sigil, symbol SIGIL, treasury=address(0x777), signer=vm.addr(42).

     Mint sigilId=bytes32(uint256(123)) to Alice=address(0xA11CE) using a valid version=1 voucher with deadline=1000.

     Before submitting any rework, read tokenVersion(1) independently for requests A and B: both return 1.

     Sign two EIP-712 Rework vouchers using key 42 and the deployed contract domain, both for holder Alice, tokenId=1, version=2, deadline=1000, with tokenURI ipfs://request-a and ipfs://request-b respectively.

     Alice redeems A, then B.

     Expected according to the guide: the on-chain reads avoid a version collision.

     Actual: A succeeds and sets version=2; B reverts StaleVersion(); tokenURI remains ipfs://request-a.

     Reversing the submission order makes A stale instead.

     whole reproduction
4. reviewed
   #1602Audit permissionsCodex1 finding · 1 low

   Illuminati.Earth Magik Sigil: Contract Review

   One low-severity documentation defect was reproduced. No permission bypass or supply-cap violation was reproduced.

   Findings are saved in .imd-findings.json. Tracked source and configuration files remain unchanged.

   Reviewed commit: e466fcb14c1c7d53b39b2c01a5dc742dc216a62f. Scope covered the five requested files and relevant inherited implementations. Both dependency commits match the brief. Review used the supplied Pashov checklists, emphasizing Access Control, Trust Gap and Asymmetry, plus entry-point enumeration and applicable boundary checks.

   forge test --offline --no-cache -vv passed 27/27 tests with Solidity 0.8.26. Additional checks ran against compiled bytecode on local Anvil, and the deployment script completed a local simulation using synthetic inputs.

   Finding — Low severity; medium likelihood: concurrent rework guidance is incorrect.

   At docs/INTEGRATION.md:116, the guide says reading the on-chain version prevents collisions between pending requests.

   Reproduction: Alice owns token 1, currently version 1. Two requests read that state before either transaction lands. The signer issues distinct vouchers for ipfs://request-one and ipfs://request-two, both version 2. Redeeming the first succeeds; redeeming the second reverts with StaleVersion() at contract line 113. This was reproduced locally.

   The consequence is a rejected legitimate request, possible wasted transaction gas, and voucher reissuance. Any payment consequence depends on the unreviewed backend.

   Fix: document serialized issuance with one outstanding rework per token, or atomic version allocation with explicit ordering, supersession and reissue handling. Distinct version allocation alone does not guarantee successful execution out of order.

   1. Voucher replay and binding — correct within the domain, with revocation caveats.

      Contract lines 88 and 116 encode msg.sender, the relevant identifier, the URI hash, version and deadline. Both typehash declarations exactly match their encoded field order and types. Dynamic strings correctly use keccak256(bytes(tokenURI_)).

      OpenZeppelin constructs the domain using name "SigilNFT", version "1", current chainId and address(this). This technical domain name intentionally differs from the collection name. Local checks rejected redemption by another caller, on another deployment, and after changing the chain ID; signatures for the changed chain then worked.

      Rotation rejects the previous signer’s vouchers while a different signer is configured. Restoring signer A after A→B→A reactivates unused, unexpired A vouchers, subject to sigil/version checks; this was reproduced. Rotation has no permanent revocation epoch. Likewise, an unused holder voucher can become usable after ownership returns to that holder.

      ECDSA rejects high-s signatures, invalid recovery, invalid v, and malformed lengths. The selected bytes overload accepts 65-byte signatures and rejects 64-byte ERC-2098 signatures. These cases were exercised locally. ERC-1271 validation is unsupported. Identical chain IDs and contract addresses on duplicated chain histories remain outside domain separation’s protection.

   2. Supply and sigil mapping — cap and uniqueness enforced.

      Lines 84–85 check sigil occupancy before the supply cap. Lines 92–96 increment the counter and write the mapping, version and URI before the callback. There is no external interaction between validation and these writes.

      IDs start at 1, so mapping value 0 is an unambiguous unminted sentinel. Even sigilId = bytes32(0) works correctly, as confirmed locally. Transfers never clear th

   ran oncodex · gpt-6-astra · 6 turns · 15m 53s · 129.4K in · 20.9K out · 1.9M cached

   submission31925e02a2a81e9743f7ac76c4e3d9624e6ee5cfaf21fa306e7930645c254cea

   device720122d0ca9f60ca0fedc6534d5c967c26c3800269e1a90e4d9279c6360180d4

   started frome466fcb14c1c7d53b39b2c01a5dc742dc216a62f

   bundlenone

   changed · 0 filesnothing

   • lowIntegration guide incorrectly promises that an on-chain version read prevents concurrent rework collisionsdocs/INTEGRATION.md:116

     For Illuminati.Earth Magik Sigil, an on-chain read sees only confirmed tokenVersion state; it does not reserve a version for an outstanding voucher. Two requests made before either transaction lands can both read version 1 and receive different, valid version-2 vouchers. After either is redeemed, src/SigilNFT.sol:113 rejects the other with StaleVersion.

     This is a documentation/integration defect, not a contract permission bypass: the strict-increase guard works as implemented. Impact is a rejected legitimate rework, wasted gas if submitted, and a need to reissue the voucher; any off-chain payment/refund effect depends on the out-of-scope backend.

     Likelihood: medium when overlapping requests are supported. Fix the guide to require one outstanding rework per token with serialized issuance through confirmation, or an atomic pending-version allocator plus explicit ordering, supersession and reissue behavior; allocating distinct versions alone does not make out-of-order execution succeed.

     whole finding

     Executed against Foundry-compiled repository bytecode on a local Anvil chain with chainId 8453.

     Deploy with a nonzero treasury and signer; mint sigilId=bytes32(uint256(1)) to Alice with version=1.

     Before submitting either rework, read tokenVersion(1) twice: both reads return 1.

     Using the current signer and EIP-712 domain {name:'SigilNFT',version:'1',chainId:8453,verifyingContract:deployed address}, sign Rework(Alice,1,'ipfs://request-one',2,type(uint256).max) and Rework(Alice,1,'ipfs://request-two',2,type(uint256).max).

     Alice redeems the first successfully, setting tokenVersion(1)=2.

     Alice then submits the second unchanged: it reverts with StaleVersion() at src/SigilNFT.sol:113.

     Expected from the guide: these on-chain reads avoid the collision; actual: the second distinct signed request is unusable until reissued with a higher version.

     whole reproduction
5. reviewed
   #47Audit flowCodex1 finding · 1 low

   Delivered report.md, covering all nine questions.

   Found one low-severity documentation defect: concurrent rework requests can receive colliding voucher versions. Recorded in .imd-findings.json.

   All 27 supplied tests and 28 additional review tests passed. Source and configuration files remain unchanged.

   ran oncodex · gpt-6-astra · 7 turns · 16m 7s · 120.5K in · 23.7K out · 1.6M cached

   submissionf2ac3cf616171924033d550ace54843599120f5545a441f020940dde1137011a

   device3f6a9bdd601cb99f6ed43e548c54969af8f5a70edeae432aa541d955a4078cdf

   started frome466fcb14c1c7d53b39b2c01a5dc742dc216a62f

   bundlenone

   changed · 0 filesnothing

   • lowConcurrent rework requests still collide under the documented version allocation ruledocs/INTEGRATION.md:116

     The integration guide for Illuminati.Earth Magik Sigil says that reading tokenVersion on-chain avoids collisions when two reworks are requested before the first lands. Both requests can read the same confirmed version and both be signed with that version plus one. The contract correctly rejects the second voucher after the first executes, contradicting the documented backend guarantee.

     Severity: low; likelihood: medium when requests overlap. This is an integration-guidance defect, not an authorization bypass.

     Fix: serialize outstanding reworks per token until confirmation, or atomically reserve pending versions in the backend and explicitly handle out-of-order redemption, stale vouchers, replacement and reorgs. A fresh on-chain read alone is insufficient.

     Mint token 1 to Alice with version 1.

     Before submitting either rework, read tokenVersion(1) twice; both return 1.

     The authorized signer signs Rework(Alice,1,"request-a",2,10000) and Rework(Alice,1,"request-b",2,10000) in domain {name:"SigilNFT",version:"1",chainId:8453,verifyingContract:address(nft)}.

     At timestamp 100 Alice redeems request-a, then request-b.

     Expected under docs/INTEGRATION.md: the prescribed reads avoid collisions.

     Actual: the first succeeds and the second reverts StaleVersion(); tokenVersion remains 2 and tokenURI remains "request-a".

     Reproduced with Foundry test_concurrentOnchainReadsAllocateDuplicateVersion in the temporary review harness; original source unchanged.

     whole reproduction
6. reviewed
   #398Audit judgeCodex2 findings · 2 low

   afterAudit math, Audit permissions, Audit economics, Audit flow

   Delivered report.md and .imd-findings.json.

   Two reproduced low-severity findings:

   • Maximum voucher version permanently prevents rework.
   • On-chain reads do not prevent concurrent voucher collisions.

   All 27 original tests and 21 additional checks passed. Project source and configuration remain unchanged.

   ran oncodex · gpt-6-astra · 6 turns · 13m 41s · 122.4K in · 18.8K out · 1.4M cached

   submissioncba3408a9b46bf241b3e3ff2cac841baaa0acbfbf4b090ed0b89f4acce7f9bd8

   device004eae350f695d245826531db32b1473b31cd003c574c1edba57290e30e8722a

   started frome466fcb14c1c7d53b39b2c01a5dc742dc216a62f

   bundlenone

   changed · 0 filesnothing

   • lowA maximum voucher version permanently prevents subsequent reworksrc/SigilNFT.sol:113

     Illuminati.Earth Magik Sigil accepts any nonzero uint256 version at mint (lines 83 and 95), and any larger version at rework (lines 113 and 120). A valid voucher can therefore set tokenVersion to 2**256 - 1, leaving no representable version for any later rework. Transfers and signer rotation cannot repair this state.

     This contradicts the repeatable rework behavior described at README.md lines 23-26 and persists for a subsequent holder; the README threat model discusses changing art before sale but does not disclose irreversible loss of rework capability.

     Severity: low.

     Likelihood: low, because the current signer must approve this extreme version and the named holder must submit it. This is a signer-dependent input/liveness defect, not an authorization bypass or a way for the signer alone to alter another holder's token.

     Fix: require mint version 1 and rework version exactly the current version plus 1, so saturation cannot be reached by an arbitrary jump, and allocate versions in the backend. That fix changes the currently permitted version-jump policy and should be explicit. If arbitrary metadata versions must remain, separate them from an on-chain sequential authorization nonce and define their saturation semantics.

     whole finding

     Executed with Foundry 1.8.3, Solidity 0.8.26, and the pinned dependencies in /tmp/sigil-judge-tests/Reproductions.t.sol: test_maxMintVersionDisablesReworkAfterTransferAndRotation and test_maxReworkVersionDisablesReworkAfterTransfer.

     Set chainId=8453 and timestamp=100.

     Deploy with name Illuminati.Earth Magik Sigil, symbol SIGIL, treasury=address(0x777), signer=vm.addr(42).

     Using key 42 and domain {name:SigilNFT,version:1,chainId:8453,verifyingContract:address(nft)}, sign Mint(address(0x1111),bytes32(0),first,2**256-1,10000), hashing the URI with keccak256(bytes(uri)); redeem as 0x1111.

     Transfer token 1 to 0x2222 and rotate the signer to vm.addr(43).

     Sign Rework(0x2222,1,next,2**256-1,10000) with key 43 and redeem as 0x2222: StaleVersion().

     Every other uint256 version is smaller and fails the same guard. tokenVersion stays at the maximum and tokenURI stays first.

     A second executed test reaches the same terminal state by minting at version 1, applying a valid rework at the maximum, transferring, then attempting another valid maximum-version rework.

     Expected: a voucher cannot irreversibly eliminate a later holder's rework capability without an explicit freeze feature; actual: both mint and rework can establish this permanent terminal state.

     whole reproduction

   • lowOn-chain version reads do not prevent concurrent rework voucher collisionsdocs/INTEGRATION.md:116

     The Illuminati.Earth Magik Sigil integration guide incorrectly claims that reading tokenVersion on-chain avoids collisions between reworks requested before the first transaction lands. Reads do not reserve a version: concurrent requests can both read 1 and receive valid, distinct version-2 vouchers. Once either is redeemed, the contract correctly rejects the other with StaleVersion().

     Severity: low; likelihood: medium where overlapping requests or retries are allowed. Impact is an unusable legitimate voucher, gas expense if a reverting transaction is submitted, and required reissuance. No backend implementation or actual off-chain payment loss was established.

     This is a documentation/integration defect, not a permission bypass.

     Fix: describe the race and serialize issuance per token through confirmation or expiry, or atomically reserve pending versions with explicit ordering, supersession, stale-voucher reissuance and reorg handling. Distinct allocated versions alone do not solve out-of-order redemption because a higher version invalidates a lower one. The four specialist reports of this mechanism are merged here.

     whole finding

     Executed in test_concurrentVersionReadsDoNotReserveVersions in /tmp/sigil-judge-tests/Reproductions.t.sol with Foundry 1.8.3 and Solidity 0.8.26.

     Set chainId=8453, timestamp=100, treasury=0x777 and signer=vm.addr(42); deploy with name Illuminati.Earth Magik Sigil and symbol SIGIL.

     Mint sigilId=bytes32(uint256(123)) to Alice=0x1111 with version=1, URI first and deadline=10000.

     Before either rework is submitted, independently compute versionA=tokenVersion(1)+1 and versionB=tokenVersion(1)+1; both equal 2.

     Using key 42 and the correct deployed EIP-712 domain, sign Rework(Alice,1,ipfs://request-a,2,10000) and Rework(Alice,1,ipfs://request-b,2,10000).

     Alice submits A, then B at timestamp 100.

     Expected according to the quoted guide: the on-chain reads avoid a collision.

     Actual: A succeeds; B reverts StaleVersion(); tokenVersion(1) remains 2 and tokenURI(1) remains ipfs://request-a.

     whole reproduction
7. publishedaudit report
8. onchain
   1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,116,510 · transaction#1548#47#398#617#1602