Only one question per project can be open (AskOpen), a defended challenge restarts challengeCooldown, and the bond of a defended challenge is paid to p.beneficiary. When the beneficiary (or any wallet it controls) is itself the challenger, the bond comes straight back to it, so a self-challenge costs only the 0.5 IMD oracle fee.

By sending its own challenge the moment challengeOpenAt arrives (first in the block, or front-running a pending honest challenge in the mempool), the beneficiary keeps every honest challenger out: their transaction reverts AskOpen while the self-challenge is open, and ChallengeTooSoon for a whole new cooldown once the panel says yes. The panel then only ever sees the beneficiary's chosen [REASON] text, never the honest challenger's pointer to the violation.

No funds are lost, but the challenge mechanism, the only way to delist, can be kept away from the public indefinitely at 0.5 IMD per cooldown (free on Sepolia, where the fee token is open-mint).

A fix that keeps the agreed no-owner design: do not restart the cooldown on a defended challenge (or restart it only when challenger != beneficiary), and/or do not pay a defended bond to the beneficiary when the challenger is the beneficiary (burn it or send it to the Intake's treasury). Which of these is wanted is the author's scope decision.

The registry pulls and approves exactly ORACLE_FEE and asks the constant ACTION with a constructor-fixed oracleSigner, and it has no owner. The live Intake v2 (source read from Sourcify, 0xa43e...de82 on Sepolia) lets its owner call setPrice(action, asset, amount) at any time: a higher price makes requestWithFailure revert PriceNotMet, and setPrice(..., 0) (how a version such as oracle-1 is retired for oracle-2) makes it revert ActionNotSold.

From that moment applyListing and challenge revert forever. Every project listed at that moment stays listed == true with no way to delist it, since the only delisting path is a signed challenge answer; the same happens if the oracle signer key is rotated (every answer fails BadSignature, the fee is spent, and expire only returns bonds). The oracle-consumer reference says the intake, action, asset+price and signer must never be constants.

The launch forbids post-deployment configuration and the brief wants no owner, so the ownerless choice is a design decision to record, but one part can be fixed without any owner: read the live price with intake.priceOf(ACTION, oracleAsset) at ask time and pull/approve that amount, so a price move does not stop the registry. design.md ("Fixed oracle settings") plans a redeploy; the indexer must then treat the old registry's listings as frozen, since nobody can ever delist them there.

applyListing is open to anyone for any contract and one question per project may be open. A griefer who front-runs the real applicant's transaction with the same project but its own beneficiary and rate blocks the real application with AskOpen until the panel says no (minutes) or a day passes (expire), then repeats. Each attempt costs the griefer only the 0.5 IMD oracle fee, which on Sepolia is the open-mint test IMD, so it is free there.

If the panel ever wrongly answers yes, the griefer's wallet becomes the beneficiary that holds the project's points and collects every defended bond, and the team can only undo that through a challenge after the cooldown. design.md lists this under "Known limits"; it is recorded here so the adapter decides whether an application by a non-beneficiary should be refused or rate-limited, with the trade-off that any gate needs some notion of who speaks for a project.

credit is permissionless and accepts any non-zero amount, and trader is any address. TestSIMD stamps lastDepositBlock[to] on every positive mint (_beforeTokenTransfer) and _withdraw reverts SameBlockRedeem while block.number == lastDepositBlock[owner]; maxRedeem/maxWithdraw report 0. On the live vault, previewDeposit(1) = 1e6 shares (decimals offset 6), so a 1-wei credit always mints shares and passes the ZeroShares check.

A griefer who front-runs a trader's redeem/withdraw with Stacker.credit(trader, 1) in the same block makes it revert, for 1 wei of the freely minted TestIMD plus gas. Repeating this in every block blocks the trader's exit for as long as the griefer keeps paying gas.

The vault comments say a third party must not be able to stamp a hold on an account for free; the Stacker gives anyone a cheap, labelled way to do it, and each grief also emits a Stacked event that the site's leaderboards read. Root cause is shared: TestSIMD.deposit(1, victim) does the same directly, so a fix needs both contracts.

Possible fixes: a minimum credit in the Stacker (it raises the cost only), and in the vault, stamping only when the receiver is the caller, or not letting third-party mints extend an existing holder's hold.

Economic impact: no funds are lost, but the cashback trader's sIMD exit is delayed at the griefer's will.

Boundary (constructor argument edge). The constructor stores challengeCooldown = challengeCooldown_; (src/ProjectRegistry.sol:179) without any bound. The only place it is used is the signed-yes branch of onOracleResult, where uint64(block.timestamp) + challengeCooldown is a checked uint64 addition.

For any cooldown >= 2^64 - block.timestamp (about 1.8e19 seconds; block.timestamp is ~1.76e9 today) the addition panics with 0x11. The Intake calls the callback inside a try, so the revert is swallowed: the request is marked completed, the answer is never delivered, and the applicant's 0.5 IMD fee is spent for nothing on every attempt.

Rejections, challenges and failures still work, so the registry looks healthy but can never produce a listing, and with no owner it cannot be repaired. The manifest in launch.json passes 3600, which is safe; the defect is that the contract accepts an input that permanently breaks its one purpose instead of refusing it in the constructor (for example if (challengeCooldown_ > 365 days) revert), where an empty-chain rehearsal would catch it.

Reported at low severity because it needs a wrong deployment input.

Not a substantiated defect; recorded so the judge can route it. The body (lines 521-533) is strict JSON that the paid door refuses whole on an unknown key (status 1, fee spent, onOracleFailure clears the slot). Every key except consumer is in the supplied oracle-consumer reference's body schema (v, question, chainId, window, answerType, evidence, panelSize, quorum, validForSeconds, allowAmbiguous, definitions).

The reference only says a body may 'name its own consumer' without giving its field names, so {"chainId":..., "verifyingContract":...} cannot be checked offline; the Intake contract itself does not parse the body, so the Sepolia fork test's acceptance proves nothing about the door. The key is also redundant here, because the callback target is this contract and the plane defaults the domain to it.

Every text limit was computed and holds: question 1016 bytes (apply) / 1051 bytes (challenge) at maximum inputs against the 2000 limit; definitions 444/228/349/194/163 bytes against 512; keys <= 11 against 64; panel 15/11 within the cap of 100; validForSeconds 86400 within 60..30 days.

Control-flow gap between challenge() and onOracleResult(). challenge() snapshots p.beneficiary into the question text (line 249) and the panel judges that wallet under the 'beneficiary' definition. setBeneficiary() only checks listed and the caller, not p.ask == Ask.None, so the beneficiary can be rewritten while the question is in flight. onOracleResult() then reads p.beneficiary again (line 327) and pays the bond to the new wallet, and the record keeps a beneficiary no panel ever judged, with the challenge consumed.

Every other interleaving on an open question is blocked (applyListing and challenge revert AskOpen); this is the one state write left open mid-operation.

Impact is bounded: the bond is the project's own money and the switch is something the beneficiary could do before or after the challenge, so this is a consistency defect in the operation's atomicity, not a loss of funds. Minimal fix that preserves the design: revert in setBeneficiary while p.ask != Ask.None, or snapshot the beneficiary at challenge time and pay that one.

p.rateBps is written once, in applyListing, and never again while the project is listed (the only other write is the next applyListing, which requires listed == false). challengeQuestion() tells the panel 'It is listed at a cashback rate of <p.rateBps> basis points' and the 'rate' definition requires that ' must be the rate in force now'.

The definitions explicitly allow a project whose rate can change as long as it stays within 25-100 bps, but the registry has no way to restate the rate: no setRate ask, and applyListing reverts AlreadyListed. So a listed project that moves its rate from 50 to 75 bps (both allowed) is bound to fail the rate rule on any challenge, and the only way to re-state the rate is to be delisted first (losing the listing period and paying two more oracle fees).

Design limitation of the control flow rather than a bug the panel can see, but it is a concrete state in which the contract's own rules and its question text contradict each other.

Fix options: let the beneficiary open a rate-restatement ask (an Apply-like question that keeps the listing), or make the challenge question ask only that the rate is within 25-100 bps and name the stated rate as informational.

Area: Trust Gap (access x asymmetry between what proves an answer and what it is applied to). onOracleResult binds an answer to the registry only through the Intake's request id (projectOfIntake[intakeId]) and the signer check in _verifyAttestation.

It never records a.requestId (the inherited consumed mapping and _consume are unused) and never compares a.questionHash with anything, so one signed attestation, obtained legitimately for one question, is also a valid, fully verified answer for every other open question of this registry asked within ISSUED_AT_TOLERANCE (5 minutes) of its issuedAt: a yes to project A's application lists project B, a yes to a challenge of A defends B and pays B's beneficiary the bond.

The only gate between the two is the Intake writer's choice of args in complete, which the registry's own header lists as a trusted party; the oracle-consumer reference asks consumers to consume one of the two ids once, and the registry consumes the intake id, so this is defence in depth rather than a bypass for an outsider.

It still means that a writer bug (an answer paired with the wrong request, which the writer's args can do with no on-chain check) or a replayed delivery turns into a listing, a delisting or a bond payment with no signed statement about that project.

Minimal fix that preserves the design: call _consume(a.requestId) after _verifyAttestation (about 22k gas, within the 200k stipend measured by test/RegistryCallbackGas.t.sol), so each signed answer can act once; optionally also require a.questionHash to differ from the last one settled for the project.

Area: Trust Gap seam 3 (access x asymmetry) with an economic edge. challenge builds the question from p.rateBps and p.beneficiary as they are at execution time (src/ProjectRegistry.sol:248-250) and the bond on a yes is paid to p.beneficiary at settlement time (line 327). setBeneficiary (lines 394-401) is open to the current beneficiary at any moment, including in the same block as a pending challenge and while a challenge is open.

The challenge definitions re-ask the beneficiary rule (the beneficiary must be the owner or a team wallet), so a project whose points were handed to an outsider is challengeable on exactly that ground, yet the outsider can watch the mempool, front-run the challenge with setBeneficiary(project, teamWallet), let the panel judge a question that names the team wallet, collect the 5 IMD bond at the team wallet, and hand the points back to the outsider afterwards.

The challenger paid 0.5 IMD plus the bond (5.5 test IMD on Sepolia) to have a state judged that was never put to the panel, and the Challenged event and the Intake's Requested body carry the rewritten beneficiary, so nothing on chain records what the challenger contested. The defender's cost is gas; the defender's gain is the bond, repeatable per challenge.

Each side of this is intended in isolation (open setBeneficiary; questions built from current state; bond to the beneficiary), which is why it only appears when the three are read together.

Minimal fix preserving the design: let the challenger pin what they contest, e.g. challenge(project, reason, expectedBeneficiary) reverting when p.beneficiary differs (the rate cannot change after listing, so the beneficiary is the only mutable term), and/or snapshot the beneficiary into the open challenge so the bond and the question agree.

Area: Access Control (roles outside the launched contracts that govern their effect). Neither launched contract has an owner, but the Stacker deposits into the live TestSIMD 0xf9e2eec3b610ec6781f7438ac5fb4bc049d81cc1 whose owner() is 0x4b91078b2374c956A65F7Af0999CaE0a935E6821 (read on Sepolia today; paused() is false; asset() is the TestIMD 0x2b69...1e82 the manifest passes, so the Stacker's AssetMismatch check will pass).

That owner holds setPaused(true), which makes every Stacker.credit revert (integrators are told to try/catch and pay plain IMD instead), and rescueERC20(token, to, amount), which can move the whole IMD balance of the vault, i.e. all cashback ever stacked through the Stacker.

The Stacker's own max approval to the vault cannot be spent by the vault's owner (Solady's deposit pulls from msg.sender only, and the Stacker holds no IMD between calls), so the exposure is the traders' staked IMD, not the projects' pending credits.

This is the documented Sepolia-only design (mainnet uses the renounced sIMD) and matches the brief; it is recorded here as the one privileged power that can take value out of the system, with its actor and preconditions, not as a defect.

The Intake side has its own trusted roles: its owner (0x047F...54B7) can change priceOf, callbackGas (1,000,000 on Sepolia today) and the writer; the writer (0x3d3C...25CB) chooses the callback arguments and can withhold answers, which the registry mitigates with expire and the failure path. No action required for this launch; the website should state the vault owner's powers next to the Stacker.

From audit_permissions; reproduced. onOracleResult binds an answer to a request only through the Intake's id (projectOfIntake[intakeId]) and the signature check.

It never calls the inherited _consume(a.requestId) (the consumed mapping is unused) and never compares a.questionHash with anything, so one valid attestation, obtained for one question, is also a fully verified answer for every other open question of this registry asked within ISSUED_AT_TOLERANCE (5 minutes) of its issuedAt and before its expiresAt: a yes to project A's application lists project B; a yes to a challenge of A defends B and pays B's beneficiary the bond.

Only the Intake can reach the callback and the Intake's writer picks the arguments, so this is defence in depth against a writer bug or a replayed delivery, not a bypass for an outsider; the oracle-consumer reference asks consumers to consume one of the two ids once, and the registry consumes only the intake id.

Fix: call _consume(a.requestId) after _verifyAttestation (about 22k gas, within the 200k stipend measured by test/RegistryCallbackGas.t.sol).

Merged from audit_economics (low) and audit_flow (info); one root cause. credit is permissionless, takes any non-zero amount and any trader, and deposits with the trader as share recipient. TestSIMD._beforeTokenTransfer sets lastDepositBlock[to] = block.number on every positive mint, and _withdraw reverts SameBlockRedeem while block.number == lastDepositBlock[owner] (maxRedeem/maxWithdraw read 0).

With the vault's decimals offset of 6, previewDeposit(1) is 1e6 shares, so a 1-wei credit always passes the ZeroShares check. A griefer who front-runs a trader's redeem with Stacker.credit(trader, 1) in the same block makes it revert, for 1 wei of freely minted TestIMD plus gas, repeatable every block; each grief also emits a Stacked event the site's leaderboards read.

The vault is live and reused, and TestSIMD.deposit(1, victim) does the same directly, so the Stacker only adds a cheap labelled path; no funds are lost, the exit is delayed at the griefer's will. A minimum credit in the Stacker raises the cost only; the complete fix is in the vault (stamp only when receiver == caller), which this launch does not redeploy. Also an integration note for the website: a redeem that reverts right after a credit is this.

From audit_math; reproduced with test/scratch/CooldownOverflow.t.sol. The constructor stores challengeCooldown_ (line 179) with no bound; its only use is the checked uint64 addition in the signed-yes branch of onOracleResult. For any cooldown >= 2^64 - block.timestamp the add panics (0x11).

The Intake calls the callback inside a try, so the revert is swallowed: the request is marked completed, no listing happens, and the applicant's 0.5 IMD is spent on every attempt.

Rejections, challenges and failures still work, so the registry looks healthy but can never produce a listing, and with no owner it cannot be repaired. launch.json passes 3600, which is safe, so this needs a wrong deployment input; the defect is that the constructor accepts an input that permanently breaks the contract's one purpose instead of refusing it (e.g. revert when challengeCooldown_ > 365 days), where the empty-chain rehearsal would catch it.

From audit_flow; reproduced by reading every write to rateBps. p.rateBps is written only in applyListing (line 226), which requires !listed; setBeneficiary changes only the beneficiary. challengeQuestion tells the panel 'It is listed at a cashback rate of <p.rateBps> basis points' and the 'rate' definition requires that ' must be the rate in force now', while the same definition explicitly allows a rate that can change inside 25-100 bps.

So a listed project that moves its rate from 50 to 75 bps, which the rules permit, is bound to fail the rate rule on any challenge, and can only restate its rate by being delisted first (losing the listing period and paying two more oracle fees plus a challenger's bond flow). The contract's own rules and its question text contradict each other for a state the rules allow.

Fix options that keep the design: a beneficiary-opened rate-restatement ask that keeps the listing, or a challenge question that only requires the rate to be within 25-100 bps and names the stated rate as informational.

From audit_flow; reproduced. applyListing and challenge are permissionless and a project has one open ask at a time (the same check at line 244). A third party can front-run the team's application with wrong terms (another beneficiary or rate); the panel answers no and the slot reopens only after the answer or after PENDING_EXPIRY (1 day) via expire; the griefer re-applies as the slot opens.

The same slot rule applies to challenges: a beneficiary can keep a soft self-challenge open (bond returns to itself on yes, the earlier fix stops the cooldown from restarting) so a pointed honest challenge is refused AskOpen until the slot briefly reopens. On Sepolia the oracle asset is open-mint, so each cycle costs gas only. ADAPTATION.md records the application half as a retained limit of the approved 'anyone applies' design (imported finding 04f9947f...).

Recorded for coverage; no mechanism change is proposed within the approved ownerless design.

From audit_math; kept as an unverified item because it cannot be reproduced on chain. The body (lines 521-533) is strict JSON that the paid door refuses whole on an unknown key (status 1, fee spent, onOracleFailure clears the slot). Every key except consumer is in the oracle-consumer reference's documented body (v, question, chainId, window, answerType, evidence, panelSize, quorum, validForSeconds, allowAmbiguous, definitions).

The reference says only that a body may 'name its own consumer' without giving the object's field names, so {"chainId":..., "verifyingContract":...} cannot be checked offline; the Intake contract does not parse the body, so the Sepolia fork test proves nothing about the door. If the shape is wrong, every application and challenge fails with body_invalid for the life of the registry, each spending 0.5 IMD, and no owner can change the body.

The key is also redundant: the callback target is this contract on the same chain and the plane defaults the domain to it. Text limits were checked and hold (question <= 1051 bytes of 2000; each definition <= 444 of 512; panel 15/11; validForSeconds 86400).

From audit_permissions; confirmed against test/mocks/TestSIMD.sol (the verbatim copy of the live vault's logic: setPaused, rescueERC20, rescueETH, renounceOwnership guarded while paused).

Neither launched contract has an owner, but every credit lands in the live TestSIMD 0xf9e2eec3b610ec6781f7438ac5fb4bc049d81cc1 whose owner (read by the specialist as 0x4b91078b2374c956A65F7Af0999CaE0a935E6821) can setPaused(true), making every Stacker.credit revert (integrators are told to try/catch), and rescueERC20(token, to, amount), which can move the vault's whole IMD balance, i.e. all cashback ever stacked.

The Stacker's max approval to the vault cannot be spent by the vault owner (Solady deposit pulls from msg.sender only, and the Stacker holds no IMD between calls), so the exposure is traders' staked IMD, not projects' pending credits. This is the documented Sepolia-only design and matches the brief; recorded as the one privileged power that can take value out of the system, not as a defect. The website should state it beside the Stacker.

Settles earlier finding 739a4a9f (low). It still reproduces unchanged: credit is permissionless, any non-zero amount mints shares to trader (decimals offset 6, so previewDeposit(1) = 1e6 shares), and the live vault's _beforeTokenTransfer stamps lastDepositBlock[to] on every mint while _withdraw reverts SameBlockRedeem in that block.

The author's dispute holds on the facts: the root cause is in the reused TestSIMD (test/mocks/TestSIMD.sol lines 109 and 122, the verbatim copy of the live vault), TestSIMD.deposit(1, victim) does the same without the Stacker, this launch does not redeploy the vault, and a Stacker minimum would reject legitimate small cashback (0.25% of a small trade) without closing the direct path. No funds are at risk; the exit is deferred one block per griefing transaction.

The website and README now explain the delay beside staking (VaultTrustRegression covers both paths). Downgraded to info as a documented limitation of a reused dependency; no change to the launched contracts is requested.