The NIGHTSHIFT (SHIFT) token is implemented, tested, documented and committed. A clean export of the commit builds, passes all tests with the verifier's fuzz seed, and passes the format check, all offline.

What was built

• src/ShiftToken.sol: an OpenZeppelin v5 ERC-20 named NIGHTSHIFT, symbol SHIFT, 18 decimals. The constructor mints the full 1,000,000,000 supply once to the deployer and makes no external calls.
• Every ordinary transfer burns 1% of the amount, rounded down. The sender pays the gross amount, the recipient receives the net, and the supply shrinks. The rate is a constant, so there is no owner and no setter.
• Transfers touching the factory, the Uniswap v4 PoolManager, or the launch's MerkleDistributor pass through whole. The distributor is read from the factory at transfer time, and a failing lookup just means the transfer is taxed normally.
• No mint, pause, blocklist, burnFrom, delegatecall or selfdestruct exists, so the supply can only fall and no privileged hand can move a holder's balance.

Checks

Check	Result
forge build (solc 0.8.26, bytecode_hash none)	pass
forge test with the verifier's fuzz seed	31 passed, 0 failed
forge fmt --check	pass

The tests cover the burn on both transfer paths, rounding and zero amounts, each launch flow with the distributor unset and set, factory-as-EOA and reverting-lookup robustness, the revert paths, the absence of admin entry points, and an opcode scan of the runtime.

One thing to know

The sandbox pinned a read-only .gitmodules inside the raw OpenZeppelin clone, so that directory is git-ignored and the project builds against a clean copy under lib/openzeppelin/. Dependencies are committed as ordinary files, and the commit contains no gitlinks.

The README documents the burn rule, the three constructor arguments the manifest fills, the fee-on-transfer caveat for integrators, and that nothing needs configuring after launch.

Created launch.json matching ShiftToken, its constructor arguments, exact supply, and required pool and economics.

Manifest checks and forge build passed. All 31 tests passed with the specified fuzz seed. Only launch.json is included in the deliverable.

The math audit of src/ShiftToken.sol found two minor issues and nothing critical, high or medium. Both reproduced in a scratch Foundry test, which I then deleted. The existing suite passes (31 tests), and .imd-findings.json holds both findings plus a coverage record.

Findings

1. Low: the 1% burn rounds down, to zero on small transfers (src/ShiftToken.sol:81, return (value * BURN_BPS) / BPS_DENOMINATOR;).
   • An ordinary transfer of 99 wei burns nothing, which breaks "1% burn on every transaction".
   • A transfer of 199 wei burns 1 wei, an effective rate of 0.5%.
   • 100 transfers of 99 wei burn 0, where one transfer of 9,900 wei burns 99.
   • Splitting is not a practical way to avoid the fee: moving 1 SHIFT fee-free would take about 10¹⁶ transfers.
   • Fix: round the fee up (ceil division or Math.mulDiv with Rounding.Ceil).
2. Info: very large amounts fail with the wrong error (src/ShiftToken.sol:91).
   • burnFor(value) multiplies before it divides, so any value above type(uint256).max / 100 overflows and reverts with a generic arithmetic error.
   • That happens before the balance check, whose comment says it exists so the revert reports value. So transfer(B, type(uint256).max) fails with the arithmetic error instead of the usual "insufficient balance" error.
   • It also hits the exempt launch addresses (factory, pool manager, distributor), and the public burnFor(type(uint256).max) view reverts too.
   • No transfer that should succeed fails, since no balance can get near that size (supply is 10²⁷).

Coverage rows

• transfer and transferFrom: both have findings (they share the same internal path).
  • These hold: the sender is debited exactly value and the recipient gets value - burned, and the balances always add up to the total supply, including self-transfers and zero-value transfers.
  • transferFrom spends allowance for the full value before transferring, as documented.
• approve: holds; it is unmodified OpenZeppelin code with no arithmetic.
• Invariants: the supply can never grow after the constructor, and transfers touching the factory, pool manager or distributor move exactly the stated amount.

Outside my area

• Not run: I could not test anything against Uniswap v4, because lib/ contains only forge-std and OpenZeppelin.
• Unproven lead, not reported: because every transfer to or from the pool manager is exempt, a holder could probably send tokens through it to another wallet without the burn. The launch rules require that exemption, so I treated it as a design consequence.

No repository files were changed.

I found one low-severity defect in ShiftToken: anyone can skip the 1% burn on a wallet-to-wallet transfer by routing it through the Uniswap v4 PoolManager. Nothing else in my area failed. The findings are in .imd-findings.json and no other file was changed. My scratch test was deleted and git status is clean.

Finding 1 (low): the burn can be bypassed through the PoolManager (src/ShiftToken.sol:92, together with the exemption at line 74)

• Cause: a transfer is untaxed if either side is the PoolManager. Inside one v4 unlock, Alice can call sync, transfer to the PoolManager, call settle, then call take to send to Bob. Both legs are exempt and no pool or swap is needed.
• Reproduction: Alice moves 1,000,000e18 this way. Bob receives the full 1,000,000e18 and total supply is unchanged. A direct transfer would deliver 990,000e18 and burn 10,000e18.
• Check: a scratch Foundry test passed, but against a simple stand-in for the PoolManager's sync/settle/take. The project doesn't vendor v4-core, so I couldn't run it against the real PoolManager.
• Fix: removing the exemption isn't an option, because the launch rules require buys and sells through the PoolManager to arrive whole. The minimal fix is to document that all v4 trades and settle/take round trips burn nothing. Taxing more would need a design decision from the requester.

Coverage: I covered all three entry points through the Execution Trace, Periphery and First Principles guides, plus two invariants:

• approve: holds; it is OpenZeppelin's version, unchanged.
• transfer and transferFrom: finding 1. Otherwise both behave as intended:
  • the fee rounds down;
  • a short balance reverts with the full amount before anything is burned;
  • transferFrom spends allowance for the full amount;
  • a factory with no code, or a distributorOf lookup that fails, just means the transfer is taxed rather than blocked.
• Supply never grows after construction: holds. There is no mint path, no owner, and no delegatecall or selfdestruct.
• Launch flows arrive whole: holds for factory → distributor, distributor → claimant, the pool seed, and buys and sells.

Limits:

• I didn't run the separate launch tests the network applies before admission, because they need its environment.
• I couldn't confirm the real factory's distributorOf signature (the token calls it with a uint64; a uint256 version would not match). The test probe uses uint64.
• The existing 31 tests all pass.

Both reproductions hold. The review is complete and .imd-findings.json is written; the tree is otherwise untouched (scratch tests live under the gitignored test/scratch/).

Outcome. The NIGHTSHIFT token's burn arithmetic, conservation invariant, supply monotonicity and launch-flow exemptions all check out under the Economic Security, Invariant and Flow Gap guides. One medium finding and one info-level trust note are recorded.

Finding 1, medium. The 1% burn can be avoided by anyone. Because the PoolManager is exempt as both sender and recipient, a holder can call the v4 PoolManager's permissionless unlock, sync, transfer in, settle, then take to any address, with no swap. Both hops are exempt, so the recipient gets the full amount and nothing burns. ERC-6909 claim tokens inside the manager give the same effect permanently. The repro in test/scratch/BurnBypassViaPoolManager.t.sol shows 495e18 SHIFT arriving whole where the rule says 4.95e18 should burn. This cannot be closed without failing the launch floor's sell test, so the fix is a scope decision: document it, or move the burn to the buy side with the requester's agreement.

Finding 2, info. The distributor exemption is read live from the factory on every taxed transfer. A factory answer whose upper bytes are dirty makes abi.decode revert, which blocks every ordinary transfer while launch flows keep working. Verified in test/scratch/DirtyDistributorWord.t.sol. Precondition is factory misbehaviour, so it is a trust assumption, not a defect.

Coverage. All three listed entry points have rows: approve holds, transfer and transferFrom reference finding 1. Five extra rows record the invariants and leads I checked, including the aderyn literal lead, which is style only. The existing 31 project tests pass.

The review is complete. The findings file is written and validated against the tree, and nothing outside .imd-findings.json and test/scratch/ was touched.

Outcome. Three findings, none critical or high, so no proof file is attached. All 31 existing tests pass, and both of my scratch reproductions behave as described.

• Medium: the 1% burn is bypassable by anyone through the PoolManager. The exemption at src/ShiftToken.sol:92 is by address on either side of a transfer. Any caller can unlock the Uniswap v4 PoolManager, transfer SHIFT into it whole, settle, then take to any recipient whole, ending with zero delta and no burn. ERC-6909 claim balances inside the PoolManager also move without ever reaching the token's burn logic. The burn therefore applies at most once per holder, when tokens first enter a contract they control. The recipient-side exemption is forced by the protected floor's exact-settle sell test, so this is a design consequence that needs a scope decision, not a missing check. I said so in the finding and listed the tradeoff.
• Low: the documented lookup fallback is not total. When the factory's distributorOf returns 32 or more bytes whose first word has high bits set, abi.decode at line 69 reverts, and every ordinary transfer reverts with it, contrary to the NatSpec promise that a failed lookup just taxes the transfer. Launch flows still work. Fix is a bounded decode.
• Info: trust assumption. The factory's live distributorOf answer is the only mutable input to the permission model. Whoever can change it can name a tax-free hub or make contributor claims arrive short. Recorded for the README, not as a defect.

Coverage. All three entry points have rows: approve holds, transfer and transferFrom carry finding 1. Four invariant rows cover fixed supply with no privileged surface, balance conservation, the launch flows, and the absent manifest. Access Control was covered fully, since the contract has no roles or setters. Asymmetry was covered for transfer versus transferFrom, burn versus exempt branches, and self-transfer. Trust Gap was covered for the factory lookup and the PoolManager custody path. Nothing in my area was left unreached.

I added two test files and reported one real defect in the token. forge build succeeds and forge test passes 54 of 54 with the verifier's fuzz seed: the 31 existing tests plus 23 new ones.

What I added (only under test/; the existing test/ShiftToken.t.sol is unchanged):

• test/ShiftToken.invariant.t.sol: invariant tests that make random sequences of calls from 7 accounts, including the factory, PoolManager and distributor. The calls are transfers, approve + transferFrom (exact and unlimited allowances), transfers over the balance or allowance that must revert, re-pointing the distributor, and tries at admin calls like mint, pause or blacklist. Every call checks its own result: the sender loses the full amount, the recipient gets the amount minus the burn, and the supply falls by exactly the burn. The invariants are:

  • balances always add up to the total supply;
  • total supply plus everything burned equals the initial 1,000,000,000;
  • the supply never grows;
  • nothing ever sits at the zero address;
  • the fixed settings and the 1% rate never change.

  These run 256 sequences of 64 calls each and fail on any revert, so a broken check can't be silently skipped. That setting caught a bug in my own test code, which I fixed; it was not a token bug.

• test/ShiftToken.edge.t.sol (22 tests):

  • the factory's distributor lookup returning short, empty or over-long replies;
  • a distributor that is re-pointed and loses its exemption;
  • unlimited allowances not being spent down;
  • a failed transfer leaving the allowance untouched;
  • transfers to the zero address and approving the zero address both rejected;
  • exempt accounts trying to send more than they hold;
  • the whole supply moving between ordinary holders;
  • the burn event firing only when something is burned;
  • the edges of the 1% calculation.

  It also has fuzz tests: the burn is always exactly 1% rounded down, exempt flows arrive in full, splitting a transfer saves at most 1 wei of burn, and a failed transfer changes nothing.

Reported in .imd-findings.json instead of written as passing tests:

• Medium: anyone can skip the 1% burn. Any transfer touching the PoolManager is burn-free in either direction (src/ShiftToken.sol:74, :92). Anyone can use Uniswap v4's settle-and-take flow to move tokens between two ordinary holders with no burn. Every buy from the launch pool is also burn-free. Example: Alice sends 1000 to the PoolManager, which pays 1000 to Bob. Bob gets 1000 and the supply is unchanged; under "1% burn every transaction" he should get 990. The launch only needs transfers into the PoolManager to be exempt, so payouts from it could be taxed without breaking the launch checks. The finding includes a test that fails on the current code. If the token is fixed, the existing test test_poolManagerFlowsAreNotTaxedEitherWay will need updating, because it asserts that a buy arrives in full.
• Info: if the factory's distributorOf returned a malformed address, every ordinary transfer would revert (confirmed). The real factory can't return one.
• Info: transfers under 100 wei burn nothing because of rounding down. Splitting saves at most 1 wei per extra transfer, which isn't worth the gas.

I couldn't run the two provided launch-check files here, because the Uniswap v4 code they import isn't in this repository.

The review is complete. The findings file is at .imd-findings.json, the working tree is otherwise clean, and the scratch tests are gone.

Outcome. The specialists' eleven reports collapse into five findings, each reproduced on this tree. Nothing new surfaced in my own pass with the auditor checklists.

• Medium, merged from four areas: the PoolManager is burn-exempt as sender as well as recipient. Anyone can route a holder-to-holder transfer through v4 unlock, sync, settle and take, and both legs skip the burn, so the token's single feature is optional for any contract account. Every buy from the launch pool is also untaxed. The specialist's proof fails on this code with Bob receiving 1000e18 instead of 990e18, so I kept it on the finding. The fix the proof encodes taxes payouts from the PoolManager while keeping seed and sells exact, which the protected floor allows. The accepted test asserting a buy arrives whole would need updating, or the requester can instead document the bypass.
• Low, merged from three areas: a 32-byte distributorOf reply with dirty upper bits makes the decode revert, which blocks every ordinary transfer and contradicts the NatSpec promise that a factory problem only means the transfer is taxed. Verified with a shaped factory. Launch flows survive because they short-circuit before the lookup.
• Info, merged from two areas: rounding down below 100 wei. Documented in NatSpec and README, not exploitable at 18 decimals, so I lowered audit_math's low to info.
• Info: the fee multiplication panics before the balance check for amounts above roughly 1.15e75, giving the wrong revert reason. Unreachable by any balance.
• Info, merged from two areas: the factory's live distributorOf answer is the token's one trust boundary and can name an arbitrary burn-free hub. Recorded as a trust assumption, not a defect.

Coverage. All three entry points are answered: approve holds, transfer and transferFrom point to finding 1. Four extra rows record that supply is minted once and cannot grow, the launch flows arrive whole, the CREATE2 deployment model needs nothing the manifest does not give, and launch.json is schema-valid with the correct supply and argument order.

Dropped. The aderyn large-literal note is cosmetic and was left out.

Revision complete. All three findings that reproduced are fixed, two advisory ones are answered as documented behaviour, and the reviewer's proof now passes.

What reproduced and what changed

• PoolManager bypass (medium). The proof failed on the starting tree exactly as reported. src/ShiftToken.sol now exempts the PoolManager only as a recipient through a new isExemptRecipient view. Seeds and sells still arrive whole, so settle sees an exact delta. Buys and takes are taxed 1% like any other transfer, which closes the sync/settle/take hop. Payouts from the PoolManager to the factory or distributor stay whole since those recipients are exempt in both directions.
• Dirty distributor reply (low). A factory returning a 32-byte word with high bits set bricked ordinary transfers. The lookup now decodes the word as an integer and treats anything above 160 bits as "no distributor".
• Overflow panic (info). The fee is now computed with OpenZeppelin's internal Math.mulDiv, so huge transfers revert with the documented insufficient-balance error instead of an arithmetic panic. The verifier's fuzz seed still passes, so results for reachable amounts are unchanged.
• Rounding down (info). Reproduces but is intended and documented. Answered as disputed with the reasoning. No code change.
• Factory trust boundary (info). Added to the README's Assumptions as the token's one external trust dependency. No code change.

Tests. The suite grew from 30 to 36 tests in test/ShiftToken.t.sol. The old "not taxed either way" PoolManager test was replaced with one asserting the buy arrives at 99% and the sell of the full bought balance arrives whole. New tests cover the proof's scenario, PoolManager payouts to launch addresses, dirty and short factory replies, and the overflow revert reason.

Check	Result
forge build	passes, one pre-existing lint note about an event after a staticcall
forge test with verifier seed	39 passed, 0 failed, including the proof
forge fmt --check	passes

Files changed. src/ShiftToken.sol, test/ShiftToken.t.sol, README.md, and the new .imd-responses.json answering all five finding ids. Nothing is committed, since the harness owns the submission commit. The scratch copies under test/scratch/ are disposable.

The revision is complete. Only launch.json changed.

What I checked

• The accepted token is src/ShiftToken.sol: constructor takes factory, poolManager and launchNumber in that order, and mints 1,000,000,000 SHIFT with 18 decimals once to msg.sender. The manifest's token block, constructorArgs order and totalSupply of 1000000000000000000000000000 match it exactly.
• No application contracts exist in the tree, so contracts stays empty.
• The pool block and the economics object are verbatim from the brief, with lowercase addresses and only schema keys present.

What I changed

• The notes previously said transfers to or from the pool manager are exempt from the burn. The source exempts the PoolManager only as a recipient, so buys paid out by it are taxed. I rewrote that sentence to describe the accepted behavior, and added that a failed distributorOf lookup exempts no distributor. Notes are now 940 characters.

Verification

• A JSON check confirmed kind, totalSupply, decimals, economics, pool, contract-name shape and notes length.
• forge build succeeded with lint warnings only.
• forge test with the verifier's fuzz seed passed all 36 tests.

I've updated my two test files to match the revised implementation, and all 68 tests now pass with forge build and forge test under the verifier's fuzz seed. I found no defects, so I didn't write .imd-findings.json.

What broke. Another contributor changed src/ShiftToken.sol after my last round in two ways:

• The PoolManager is now exempt from the burn only when it receives tokens. When it pays tokens out (a buy, or a take), the 1% burn applies.
• burnFor now uses Math.mulDiv, so it gives an answer for every value instead of reverting on very large ones.

Four of my tests still expected the old behaviour and failed. I changed only what the new rules required.

test/ShiftToken.invariant.t.sol

• The handler now works out the expected burn from the rules themselves rather than calling the token's own exemption checks. Transfers to or from the factory or the named distributor are free, transfers to the PoolManager are free, and everything else burns 1% rounded down.
• New handler action roundTripThroughPoolManager: a sell into the PoolManager arrives in full, and buying the same amount back burns 1%.
• All 5 invariants pass with failing on any revert turned on.

test/ShiftToken.edge.t.sol

• Fixed tests:
  • The zero-distributor check now asserts the PoolManager is exempt only as a recipient.
  • The "overspend from an exempt sender" test now uses the distributor instead of the PoolManager.
  • The overflow test became test_burnForIsTotalUpToTheMaximum, and the fuzzed fee check now runs over the full number range.
  • The fuzzed exempt-counterparty test no longer treats the PoolManager as an exempt sender.
• New tests:
  • PoolManager payouts: a payout to an ordinary holder is taxed (99% arrives, one FeeBurned event); a payout to the factory or distributor arrives in full; a PoolManager self-transfer burns nothing.
  • Exemption follows the address, not the caller: a transferFrom between two holders is still taxed when the PoolManager is the spender.
  • No cheaper route through the pool (fuzzed): sending tokens into the PoolManager and back out to someone else costs exactly the same as a direct transfer.
  • Corrupted distributor reply (fuzzed): if the factory's answer has extra high bits set, no distributor is exempt.
• New failure-path tests: the PoolManager paying out more than it holds, a holder selling more than they hold, and a transfer of type(uint256).max all revert with the full requested amount.

I also checked the new design against the launch test in the protected files: the seed and sells arrive in full, and a buy still delivers more than zero tokens, so that test's requirements still hold.

The changes are in the working tree and not committed. forge build prints only lint notes, no errors.

I'm reporting no new findings this round: three of my four earlier findings are fixed, and I've dropped the rounding note. .imd-findings.json holds {"findings":[]} and a coverage record that marks all three entry points holds.

The full suite passes (69 tests, including the invariant runs). I also ran the attached proof and my own scratch tests against the new code, then deleted the scratch files; no other file changed.

My earlier findings:

• [medium] Moving SHIFT through the PoolManager avoided the burn — fixed. The PoolManager is now exempt only when it receives SHIFT (isExemptRecipient, src/ShiftToken.sol:93-95). What it pays out to an ordinary account is taxed 1%. The proof Proof_0f2688bd2dc9.t.sol now passes: Bob gets 990e18 and the supply drops by 10e18. I checked this against the launch floor in Token.protected.t.sol:
  • Seed: comes from the factory, so it arrives whole.
  • Sell: goes to the PoolManager, so it arrives whole and settles the exact amount.
  • Buy: arrives 1% short. The floor only requires bought > 0 and then sells the trader's whole balance, so it still passes.
  • Payouts to launch addresses: the PoolManager paying the factory or the distributor is still whole.
  • PoolManager accounting: it is debited the full amount on payout, so its balance bookkeeping is unchanged.
  • What's left: passing SHIFT claims between holders inside the PoolManager still burns nothing, but taking them out is taxed, and the README now says so.
• [low] A malformed distributor reply froze ordinary transfers — fixed. launchDistributor() (lines 75-76) now returns the zero address when the reply's first word exceeds type(uint160).max. With a dirty word, a dirty word plus extra data, or a 1-byte reply, the transfer goes through and is taxed. Nothing reverts.
• [info] Huge amounts reverted with an overflow panic — fixed. burnFor now uses Math.mulDiv, so burnFor(max) returns max / 100. A transfer of max now reverts with ERC20InsufficientBalance(A, 1000e18, max). The opcode scan is still clean (no DELEGATECALL, CALLCODE or SELFDESTRUCT), and the deployed code is under 24,576 bytes.
• [info] The burn rounds down — dropped. The author is right. It reproduces exactly as described, but it's intended, documented in NatSpec and the README, and pinned by a test. Splitting a transfer saves at most 1 wei of burn each time, so there's nothing to exploit.
• [info] Trust in the factory's distributorOf — settled. This is a trust assumption, not a code defect. The README's Assumptions section now records it.

The specialists' findings all have one of these root causes, so nothing new comes from them. Slither reported nothing. Aderyn's large-number note is about the supply constants, which are correct. launch.json has the right constructor arguments and supply, and its notes describe the PoolManager change accurately.