The review is complete. The findings file is written and all four snippets match the source lines exactly. No contract or configuration file was changed.

Outcome. PinkyVaultV2 holds up well. I found no loss-of-funds, wrong-party payout, accounting, reentrancy or access-control defect, and nothing the launch forbids. Four entries are in .imd-findings.json, one low and three informational:

• Low, collapsed window in close. When fewer than 32 chain blocks have passed since make, close records a one-block window at the make block instead of refusing. The whole term is then invisible to the oracle. Reproduced in a scratch test. It needs a chain that mints fewer than 32 blocks in 12 minutes, which Robinhood Chain does not do today, so it is bounded. The fix is a revert until 32 blocks exist behind the head.
• Info, untested recipe kinds. Only the log-sum recipe has live attestation evidence in the tree. Hold uses call-compare and Moves uses log-count. If the oracle refuses either, each such promise burns up to 1.5 IMD in fees and refunds with no verdict. This cannot be checked offline and is the one live pre-launch check the adapter should make.
• Info, owner trust assumption. A signer or protocol proposal enacted after seven days applies to promises already open for up to 30 days. Documented in the README. Recorded with a concrete sequence, as the brief asks for this owner role.
• Info, coverage statement. Which files were read, what was executed and what was verified on chain.

Verified by execution. The build passes with an 18 KB runtime and no forbidden opcodes. The project's 41 V2 tests and 4 conformance tests pass. Every kind's result callback completes under a cold 200k gas stipend using 68k to 85k gas, and the failure callback uses 44k.

Verified on Robinhood Chain, reads only. The IMD, PinkyStaking, Intake version 2, PINKY and first-vault addresses in launch.json all resolve to code. The staking contract points at PINKY and IMD and has 5 million PINKY staked. Intake version 2 quotes 0.5 IMD for the action. The manifest is schema-valid with ten string arguments in constructor order and notes under the limit.

Not reached. The floor's OwnerChecks source that the protected owners test inherits is not in the tree. The live Intake version 2 source and any published oracle recipe grammar were not reachable. The first vault, LaunchToken, site and tools were not read beyond what the body-building lines needed, since they are not part of this launch.

Sources from the web search returned nothing relevant to IdentityMD: glama.ai, patents.google.com, PromptLedger, nhimg.org, docs.typo3.org 0.14, docs.typo3.org 0.15, Kevros, Arcaeon Ledger, fablepool.com.

The work is complete and verified. PinkyVaultV2 was already shaped for the factory, so the launch needed one contract change, from the audit, plus notes.

What I checked and left alone

• The constructor takes ten static arguments, stores them, calls no contract, and takes the owner as its first argument filled by $owner. The floor rehearsal in scratch deploys it with the launch.json arguments on an empty chain 4663. The runtime is 18,107 bytes with no forbidden opcodes.
• No token, pool or distributor was added. launch.json is the requester's and matches the constructor's argument order, so it was not touched.

Audit finding fixed

• The low finding reproduced. With fewer than 32 chain blocks since make, close recorded a one-block window at the start block while settle refused. In src/PinkyVaultV2.sol the _close function now reverts with TooEarly until 32 blocks exist behind the head, as the audit proposed. The new test is test_CloseRefusesUntilThirtyTwoBlocksExistBehindTheHead in the vault's test file, and no existing test changed.

Audit findings not changed, with reasons in ADAPTATION.md

• Hold and Moves recipes have no live attestation. This needs a funded wallet, which the task must not use. The README now records it as the pre-launch check: buy one request of each kind before anyone bonds behind them.
• Proposals applying to open promises is the owner role the brief asks for. The README states the trust assumption and names the owner wallet from the launch.
• The coverage statement is not a defect.

Verification

forge build: ok
forge test (FOUNDRY_FUZZ_SEED as the verifier's): 181 passed, 0 failed

Changed files: src/PinkyVaultV2.sol, test/PinkyVaultV2.t.sol, README.md, ADAPTATION.md. The adaptation notes list each change with its rule or finding, and keep the first launch's notes below for the record. Nothing was committed, since the task did not ask for a commit.

The manifest already in the tree matches the accepted contract exactly, and every check passes. No edit to launch.json was needed.

What I verified

• The constructor of PinkyVaultV2 takes ten parameters in the order owner, IMD, staking, intake, action, signer, minBond, panelSize, quorum, validForSeconds. The manifest's ten entries follow that order and type.
• The addresses are the live ones: IMD on Robinhood Chain and the Intake version 2 and oracle signer from the oracle-consumer reference, and the live PinkyStaking from launch #1166 as recorded in the README, site config and the kept 1166 manifest. The owner argument is $owner, so neither the factory nor IMD controls the vault.
• Panel 7 of 5 and a one-day validity pass the contract's own bounds. The constructor calls no other contract, so it deploys on the empty rehearsal chain.
• The file has exactly the keys kind, contracts and notes. The notes are under the 4000-character limit and describe only PinkyVaultV2 and its live dependencies.

Checks run

• A scratch test in test/scratch deployed PinkyVaultV2 from a factory address on chain id 4663 with the manifest's exact arguments and confirmed every stored setting, the fee sink defaulting to PinkyStaking, and the runtime size under the EIP-170 limit.
• The full suite with the verifier's fuzz seed: 180 tests passed, 0 failed, including the oracle conformance test and both invariant suites.

The working tree is clean apart from the scratch test, which is discarded before submission.

The review is complete and the findings file is written. No files in the tree were changed beyond the required findings file, and the scratch test I used was removed.

Outcome: no reproducible math, boundary or numerical-gap defect in PinkyVaultV2. The findings file holds an empty list and a coverage row for all 33 listed entry points plus two invariants.

What I checked in the assigned area:

• Fee and split arithmetic in payout. The 1% fee rounds down by at most 1 wei. Bounty, staker half and burn sum to the bond exactly. A staker share below PinkyStaking's 0.01 IMD floor, or with nobody staked, is caught and burned instead of reverting.
• Bond accounting across ask, payout, refund and sendFees. Price is refused when zero or above the remaining bond, so the subtraction never underflows. Each path zeroes the bond before transferring, and the fee pot is sent with an exact-delta check that cannot touch bonds.
• Window boundaries. Close needs 32 blocks past the make block and two minutes past the deadline, so the head-minus-32 subtraction cannot underflow and the window always covers the term. I read Robinhood Chain live: about ten blocks per second, so the 32 excluded blocks span roughly three seconds inside the 120-second grace. The quiet-chain concern is therefore not reachable today and is already documented by the author.
• Casts and packing. The uint64 timestamp and block casts are safe. The panel proposal packs and unpacks bit-exactly, verified at the maximum values.
• Attestation decoding. The 32-byte answer length is pinned before decoding, and the verdict comparisons are correct for all four kinds.
• PinkyStaking numerics. The shortened-period branch never divides by zero and never lowers the rate. Truncation strands only dust per notify, which the author already recorded.

Not reached: nothing in the assigned area. The oracle's acceptance of the Hold and Moves recipe shapes cannot be checked offline and is already recorded as a pre-launch check in the README.

The findings file is written and validated: both snippets match their source lines exactly, and all 31 listed entry points plus three invariant rows have coverage entries. The proof test under test/scratch/ fails on the current code as required.

Recap

Scope covered: PinkyVaultV2 in full against the Execution Trace, Periphery and First Principles guides, with OracleAttestation, PinkyStaking and the IIntakeV2 interface traced as its periphery, and launch.json's constructor arguments checked against the manifest schema, the oracle skill's address table and the first launch's manifest. PinkyVault (V1) and LaunchToken were read for their coverage rows only. The baseline suite passes (179 tests).

Findings written to .imd-findings.json:

• Medium, with proof. _close fixes the window end at the head block minus 32, and nothing ties that to the deadline. On Robinhood Chain, which mints blocks only with transactions, fewer than 32 blocks can follow the maker's last in-term transfer, so the window ends before the deadline and a broken promise is answered as kept. The maker is allowed to call close/settle, so it is a free option for them. V1 did not have this since it recorded the closing block and waited 32 blocks to ask. The scratch test fails on this code with the window ending at block 1009 while the breaking transfer sits in block 1010.
• Low. The "no bounty when the asker is the maker" rule in payout is bypassed by settling from any second wallet, returning 10% of a forfeited public bond to the maker. Inherited from V1 and reported as an unenforceable guarantee rather than a regression.

What held: make, ask, both Intake callbacks, payout accounting, refund, sendFees, and the seven-day proposal flow all traced cleanly, including the sender-keyed request mapping across an Intake swap and the exact-pull checks around every external call. The slither reentrancy and PinkyStaking leads did not reproduce as defects.

What I could not reach: live confirmation that the four Robinhood Chain addresses in launch.json carry code. My RPC guess did not resolve and Blockscout sits behind a Cloudflare challenge, so that row is marked as checked against documents only. Hold and Moves recipes remain untested against the live oracle, as the README already states.

Findings file is written and validated: all four snippets match the tree at their cited lines, the proof test fails on the current code for the stated reason, and all 33 listed entry points have coverage rows (plus three invariant/manifest rows). The existing V2 suite still passes (42 tests), so my proof isolates a case the suite never exercises.

What I found (written to .imd-findings.json):

1. Medium, with Foundry proof. settle fixes the oracle window as [startBlock, head − 32]. On Robinhood Chain (Arbitrum, blocks only when there are transactions) fewer than 32 blocks can pass in the two-minute grace, so the window ends before the deadline and a maker who broke a Keep, Pay or Moves promise late in the term is judged Kept and gets 99% of the bond back. The first vault's two-step close-then-ask never had this gap. Proof test in test/scratch/WindowGap.t.sol fails with 1000 < 1009.
2. Low, trust assumption. The seven-day delay is shorter than a promise's lifetime (up to 30 days) and makers cannot exit early. Terms pin price, Intake and action per promise but not the signer, so an enacted signer plus protocol proposal lets the owner sign verdicts for every open promise and collect the 10% bounty as asker. The notes' claim that the owner "can move no funds" is not enforced by the code.
3. Low. enact(Signer) is callable by anyone once the eta passes and applies to requests already bought. An answer signed by the previous key is refused, the Intake does not retry, and the maker loses the 0.5 IMD fee and waits a day.
4. Low. proposeProtocol lacks the code.length check proposeFeeSink has. An enacted no-code Intake address stops make, settle and ask for at least another seven days.

Coverage. Access control, callback authorisation, payout and refund symmetry, fee accounting, proposal packing and the manifest's constructor arguments all hold. I could not verify offline that the live PinkyStaking and PINKY addresses in the manifest are what launch #1166 deployed. The window issue is outside the three assigned guides but severe enough to report.

The review is complete and the findings file is written and validated.

Outcome: The economics of PinkyVaultV2 hold up. Bond and fee accounting is conserved on every exit path, the payout split matches the brief, and the oracle callbacks fit the Intake's gas stipend from cold storage. I found two reproducible low-severity economic asymmetries, both already acknowledged as design in the README, and no fund-loss defect.

What I verified

• Bond conservation under a handler-based invariant fuzz of my own (make, close, settle, ask, answer, fail, payout, refund, sendFees, stake, unstake): vault balance always equals the sum of open bonds plus accrued fees, and every bonded IMD is accounted for across intake payments, payouts, refunds and fees sent.
• Callback gas from cold storage is under 90k for every promise kind, and the failure hook is under 50k, both under the 200k stipend.
• Oracle bodies for all four kinds fit the door's limits even with a maximal amount. The largest question is 340 characters and the largest recipe 347.
• Live reads on Robinhood Chain confirm the manifest's dependencies. PinkyStaking at 0x17fb… has IMD as reward token and PINKY as staking token with 5M PINKY staked. Intake v2 quotes 0.5 IMD for the action, and its bytecode carries the requestWithFailure selector while v1 does not. The chain mints about 10 blocks per second, so the 32-block gap is roughly 3 seconds.
• The manifest has only the schema keys, one contract, ten string arguments in constructor order, and notes under 4,000 characters.

Findings reported (both low, each with a scratch test that reproduces it)

1. Open-ended judged window. The window ends 32 blocks behind the head at whatever time close is called, with no bound tied to the deadline. A beneficiary who waits can collect a bond for a transfer the maker made after the term ended.
2. Refund griefing. ask has no wait on a Closed promise and reopens at the same instant refund does. When the oracle is not answering, any wallet can front-run the refund three times, costing the maker 1.5 IMD and three days for gas alone.

Coverage: all 33 listed entry points have a row, plus rows for the two invariants and the manifest. No entry point is marked unreached. The scratch tests under test/scratch/ are mine and are not part of the submission.

Done. The work is committed as 3070498 and the whole suite passes with the verifier's seed.

What I delivered (all under test/):

• test/PinkyVaultV2Invariant.t.sol. A handler drives PinkyVaultV2 through random sequences at 256 runs and depth 64: all four promise kinds with and without a beneficiary, settle, close, ask and re-ask by watchers and makers, answers on any live request (not only the latest), failure reports, payout, refund, sendFees, stakers joining and leaving, the Intake's price moving to zero and back, and the owner's protocol, panel and sink proposals enacted after seven days or cancelled. Seven invariants hold: the vault holds exactly the open bonds plus unsent fees, every wei deposited is accounted for across the oracle, makers, beneficiaries, askers, stakers, burn and sink, settled promises are empty with no allowances left, bonds equal deposit less fees paid with one request per attempt, verdicts and refunds are final with forward-only transitions, every stored promise is well formed, and settings stay within constructor bounds.
• test/PinkyVaultV2Edges.t.sol. Fifty-five tests on the failure paths: constructor zero and panel bounds, bond and duration edges, fee-on-transfer IMD, callbacks from anyone but the asked Intake, replay and reuse of a verdict, expired and pre-signed attestations, wrong chain or blocks, inconsistent or short panels, malformed answers and signatures, every kind delivered under the real 200,000 gas stipend from cold storage, Intakes that revert, cannot quote, pull the wrong amount, reuse an id or only speak version 1, the refund and payout state machine, sinks that take less, refuse or lack notify, settings that only move after the delay, and two fuzz properties over verdicts and the 1% fee.
• test/PinkyVaultV2Conformance.t.sol. The protocol's vector at the vector address: digest, callback selector, the failure hook's selector, and acceptance of the protocol's signature.
• test/mocks/MocksV2.sol. Version 2 Intake and sink stand-ins the suites need.

Results

Check	Outcome
forge build	clean
forge test with seed 0x9df7…a2c8	240 passed, 0 failed, about 29 s

Findings. Nothing I could not test around. The contract held up under adversarial reading. The .imd-findings.json in the root records three informational notes with no proofs: the owner can, after one seven-day delay, control both the Intake and the signer and so decide open verdicts, though never take a bond; IMD sent straight to the vault is stuck; and a sink that returns without pulling exactly the fees makes sendFees revert rather than silently keep the fees. That file is gitignored here, so it sits in the working tree only.

Still owed. No fork run against Robinhood Chain's live Intake or PinkyStaking, since this machine and the verifier have no network. The mocks reproduce the documented Intake behaviour, including the stipend and the unsigned failure report.

The working tree shows no tracked changes, and the findings file is valid with 8 findings and 34 coverage rows. The review is complete.

Outcome. The audit holds up: every specialist finding except one informational note reproduced against the code. I merged the two duplicate reports and recalibrated severities. Nothing I found in my own pass rose above what the specialists reported, and there is no deployment blocker. PinkyVaultV2's runtime is 18,107 bytes and its creation code 20,174 bytes, both within the factory's limits, the constructor calls no contract, and the manifest's ten arguments match the constructor and the oracle reference's Robinhood Chain addresses.

Findings written to .imd-findings.json, ranked:

1. Medium, with proof. The closing call fixes the oracle window at head minus 32 blocks instead of at the deadline. On a quiet stretch of an Arbitrum-style chain that mints blocks only for transactions, a breach inside the term falls outside the window and a broken promise is judged kept, with the bond going home. The first vault avoided this by recording the closing block and asking 32 blocks later. Both specialist proofs fail on this tree for exactly this reason, and I attached one. This merges the permissions and flow reports.
2. Low. The window has no upper bound tied to the deadline, so a beneficiary who withholds close gets post-term conduct judged. Same code, opposite direction, different fix, so kept separate.
3. Low, trust assumption. After one seven-day delay the owner can point the vault at its own Intake and signer and decide verdicts for promises already open, since terms up to 30 days outlive the delay and the signer is not pinned per promise. The notes' claim that the owner can move no funds overstates. Merges the permissions and test-writer reports.
4. Low. Anyone enacting a due Signer proposal invalidates requests already bought: the old key's answer reverts, the fee is spent, and a day's wait follows.
5. Low. Anyone can re-ask a stranded promise at the refund instant, taking 0.5 IMD and a day from the maker three times. I reproduced this in a probe test: the maker got back 8.5 of 10 IMD at day 10 instead of 10 at day 7.
6. Low. The Intake proposal accepts an address without code, unlike the fee-sink proposal. Reproduced: make and settle revert for seven days after enact.
7. Low. The no-bounty-for-the-maker rule is bypassed from a second wallet. Inherited from the first vault.
8. Info. A sink that pulls less than the fees makes sendFees revert until replaced. Unreachable with PinkyStaking.

Dropped. The note that IMD sent straight to the vault is stuck describes intended behaviour, not a defect.

Checks run. All 102 V2 unit, edge and conformance tests pass. The whole suite could not be compiled at once because solc was killed for memory, so I ran the V2 files individually and did not run the invariant file. The body the vault sends stays under the oracle's limits, and the toleranceBps key the static analysis might question appears in the recorded live request bodies, so it is accepted.

The responses file is excluded by the harness's own git exclude rule, alongside .imd/ and test/scratch/, so that is the expected place for it and the harness collects it from there. Nothing more is needed.

The work is complete. Here is the recap.

Outcome. The reopening finding reproduced and is fixed. The reviewer's proof failed on the starting tree and passes now. The full suite passes with the verifier's fuzz seed.

Check	Result
Project tests with the verifier's seed	185 passed, 0 failed
Reviewer's proof Proof_92eac51fecc7.t.sol	failed before, passes now
Vault runtime size	18,533 bytes, under the 24,576 limit
Floor opcode walk	no DELEGATECALL, CALLCODE or SELFDESTRUCT

The main fix, in src/PinkyVaultV2.sol. The window now ends at the block that closes it, as in the first vault, so no block of the term can fall outside it on a quiet chain. The ask keeps its existing wait of 32 blocks after the closing block, which the oracle needs confirmed. A one-call settle cannot survive that, so settle now does whichever step is next: it closes an Active promise and returns zero, and asks for a Closed one. The guard added last round against a collapsed window is gone because there is no longer a window to collapse.

Advisory findings I judged real and changed, each with a test:

• The maker may close from the deadline itself, anyone else two minutes later, so a maker who closes on time is judged on the term alone.
• The signer a request is bought under is recorded at ask, and its answer stays acceptable after a rotation, so an enact no longer costs an in-flight promise its fee and a day.
• Once the refund is due, only the maker or beneficiary may ask again, so a stranger cannot push the refund back a day at a time.
• A protocol proposal now refuses an Intake address without code.
• The natspec on fee sending describes the short-pulling sink case.

Not changed, answered as disputed. The owner's power to decide open verdicts after seven days is the owner role the brief asks for, and pinning the signer at make would strand promises on a legitimate rotation. The maker's second-wallet bounty cannot be told apart on chain. Both are stated in the README's second-vault section.

For the manifest step. The notes in launch.json still describe the one-call settle, say the owner "can move no funds", and say "the first non-maker asker". I did not edit that file, since it belongs to the manifest step. ADAPTATION.md spells out the wording each sentence needs.

All twelve findings, the eight from the review and the four from the audit, are answered in the responses file at the repository root.

The revision is done. Only launch.json changed, and the build, the full suite and a constructor rehearsal all pass.

What the review required. The constructor arguments were already correct and are untouched. The notes were stale in three places the review flagged for the manifest step, and I rewrote only those parts:

• Settlement now describes the accepted two-step design: the maker may close from the deadline and anyone else two minutes later, the window ends at the closing block itself, and the ask is a second settle or ask call 32 blocks later that pays the Intake through requestWithFailure. The old "one call ends the window 32 blocks behind the head" sentence is gone.
• Owner now says it moves no funds directly, that the Intake it proposes must have code, and that a signer and Intake it enacts after seven days' public notice decide the verdicts of promises still open.
• Bounty now reads "the first asker, unless that is the maker's own address" instead of "the first non-maker asker".

I also added the other accepted revision behaviors the notes omitted: the recorded signer surviving a rotation, and only the maker or beneficiary being able to ask again once the refund is due.

Checks run.

Check	Result
Manifest shape (keys, string args, name length, notes 3600 chars)	valid
forge build	ok, lint warnings only
forge test with the verifier's fuzz seed	184 passed, 0 failed
Scratch constructor rehearsal on empty chain 4663 with the manifest's arguments	passed, runtime under the EIP-170 limit

The scratch test lives in test/scratch and is not part of the submission.

I've updated my PinkyVaultV2 tests to match the contract's latest changes, and forge test passes with the verifier's fuzz seed: 249 tests across 13 suites, none failing. Only test/PinkyVaultV2Edges.t.sol and test/PinkyVaultV2Invariant.t.sol changed.

What broke them. The contract's last revision changed how a promise ends, and my suite no longer compiled:

• Settling takes two calls. The first settle only closes the promise. Asking the oracle needs a second call at least 32 blocks later.
• Who can close changed. The maker can close at the deadline; anyone else must wait two more minutes.
• Asking narrows after a week. Seven days after closing, only the maker or the beneficiary can ask again (others get NotAParty).
• Signer rotation. The vault now remembers which oracle key each promise was asked under. It accepts answers signed by that key or by the current one.
• Intake proposals. Proposing a new Intake address with no contract code is refused.

Edge tests. The shared settle helper now makes the two calls, and 12 tests that settled directly were adjusted the same way. Four tests that ask again after a seven-day settings change now ask as the maker. They also check that a stranger gets NotAParty. The old signer test expected the old key to be refused as soon as the rotation took effect. I replaced it with two tests of the new rule: the old and new keys are accepted and a third key is refused. New tests cover:

• settle and close refusing every state they shouldn't act on, and the 31-versus-32-block limit before asking.
• A fuzz test of close timing for the maker, the beneficiary and a stranger, which also checks where the window ends.
• A fuzz test of the seven-day cutoff for who may ask again, confirming a refused ask spends nothing and the refund still works.

Invariant test. The random-sequence driver now follows the two-call settle. It checks every refusal (too early, not deep enough, out of attempts, not a party, can't pay) and that a refusal moves no money. It also rotates the signer and answers with either accepted key, after checking that a third key is refused. Before this change, random runs almost never reached a payout. I added a step that carries one promise from close through to payout, and confirmed in a throwaway run that payouts, beneficiary payments, asker bounties, staker shares, fees sent and refunds all happen. All seven invariants hold.

Problems reported, not tested around, in .imd-findings.json (no proof file needed at these severities):

• Low: the vault remembers one key per promise, not per request. If the signer rotates and the promise is asked again, a pending answer to the earlier request is refused, even though it's signed by the key it was asked under. The code's own comment says it should be accepted, and that request's fee is lost. test_AReaskAfterARotationMovesThePromiseToTheNewKey pins the current behaviour.
• Info: the window for a Pay promise ends whenever someone closes it. A maker can therefore pay up to two minutes late with nobody able to close first, or later still if no one closes. A beneficiary must close at deadline + 2 minutes to hold the maker to the term.

The review is complete and the findings file is written. The working tree is clean apart from the findings file, and the scratch copies of the proofs are removed.

Outcome: the blocking finding is fixed and nothing new blocks the launch.

Settlement of my earlier findings against the revised code:

• Window ends 32 blocks behind the head (medium, 92eac51f): fixed. The close now records the closing block itself and the ask waits 32 blocks after it, mirroring the first vault. All three attached proofs pass on this tree, and the author's quiet-chain test asserts the body window reaches the closing block.
• No upper bound tied to the deadline (low, eb478df0): fixed as suggested. The maker may close from the deadline, others two minutes later. The residual for Pay promises is recorded as an info note.
• Owner rotation applies to open promises (low, 551cc33f): settled as accepted design. The author kept the delayed-proposal model the brief asks for, and the launch notes now state the power plainly instead of "can move no funds". Recorded as an info trust assumption.
• enact(Signer) strands in-flight requests (low, cff8a019): fixed. The signer is recorded at ask and either that key or the current one is accepted, with the same expiry checks.
• Re-ask griefing at the refund block (low, 38736a70): fixed. Once the refund is due only the maker or beneficiary may ask again.
• proposeProtocol accepts an Intake without code (low, d7034693): fixed. It now requires code, as proposeFeeSink does.
• Bounty bypass from a second wallet (low, e8410fa0): settled. Not enforceable on chain; the README and the manifest notes now describe the rule as address-only. Dropped.
• Short-pulling fee sink (info, e8f2e1ef): settled. Behaviour kept on purpose and the natspec now describes it.

Checks run on this tree:

Check	Result
Three attached proofs under test/scratch	all pass
Full Foundry suite	252 passed, 0 failed
launch.json	schema keys only, 10 arguments in declaration order, notes under 4,000 characters, addresses match the pinned Intake, IMD and signer

New entries, both informational and from the independent tester, reproduced against the tree:

1. The bought-under signer is stored per promise, so a re-ask after a rotation refuses the earlier request's answer from its own key, contrary to the natspec. Reachable only after a day's silence plus a rotation; no bond is at stake.
2. For Pay promises, the maker's exclusive two minutes after the deadline let a payment up to two minutes late count as kept. The target is still paid, so no funds go astray.

Coverage answers all 31 entry points. The slither and aderyn leads were checked and none reproduced as a defect: the reentrancy sites are guarded and write state before the external call, and the staking division loses only dust.