The contract is designed so that no outgoing transfer happens inside a state change. This was the reason the protocol fee was moved to a withdrawal ledger, so that a frozen or failing fee recipient could not block settlement. The bad-faith bond burn does not follow this rule. It sends ETH to the burn address during dispute resolution, and the transaction fails entirely if the transfer fails. The burn address contains no code on any major chain today, so the transfer succeeds. This is still an assumption about an address the project does not control, on a young network. It is also the only place where an external call can stop a state change. The call also forwards all remaining gas. If code that rejects incoming value ever existed at that address, the bad-faith decision would become permanently unusable. No funds would be lost, because the honest-failure decision remains available, but one documented outcome would not be available.

Before a dare is claimed, the funding deadline is measured from the creation time. After it is claimed, it is measured from the claim time. A claim that arrives one second before the original deadline therefore restarts the whole window. The campaign can run for almost twice the configured period. With the current setting of fourteen days, this means up to twenty-eight days against an advertised fourteen. The behavior is not described in the scope or specification documents. Contributors who paid early, expecting a limited period, find their money committed for up to twice as long as stated. One factor reduces the severity. A contributor can always withdraw their own contribution while the lock is not yet funded, so nobody is trapped. They only need to notice and act.

Pausing blocks dare creation, both claim paths, contributions, proof submission, settlement, the expiry functions, the dispute timeout, and dispute opening by anyone other than the platform role. It does not block bond withdrawal, payout withdrawal, contribution refunds, cancellation by the creator, voiding by the platform role, or dispute resolution. Value therefore continues to leave the contract during an emergency. There is a good reason for this. A pause that traps user funds is a serious trust problem, and keeping withdrawals open is the safer default. The consequence should still be stated clearly. If the reason for pausing is that funds are being taken, pausing does not stop the withdrawal of amounts that are already queued. There is also an effect in the other direction. A lock in the funded state has no exit during a pause except through the platform role. Cancellation applies only to the two earlier states, and the performance expiry is itself blocked by the pause.

When a lock settles in favor of the receiver, the total contributed is set to zero. The individual contributor entries and the contributor count are left in place. This causes no problem today, and that was verified, because the settled state is excluded from every refund path. It is recorded because it is a risk for future changes. If a later change allowed the settled state in the refund function, an old contributor amount would be subtracted from a total that is already zero. Depending on how it is written, this would either fail or corrupt the accounting.

The stretch tiers are validated, written to storage, and then never read by any code in the contract. The same applies to the description, the proof link, the contributor count, and the receiver subject hash. The lock also stores its own identifier, which repeats the key it is already stored under and is used only to check whether a lock exists. All of this is written on paths that users pay for, and it is read only by systems outside the contract.

Creating a dare requires no deposit and no fee. An attacker can therefore increase the lock counter and write storage for the cost of gas alone. No code in the contract loops over locks, so the contract itself cannot be blocked this way. The cost falls on external indexers and on the interface. There is a second point. The targeted dare function accepts any identity value from any caller, with no attestation. Anyone can therefore create a lock naming any person, without that person being involved.

The contribution function has no check preventing the receiver or the creator from funding their own dare. A receiver can fund their own campaign to reach the target, submit a proof, and settle. They recover their own money minus the protocol fee. This is not directly profitable, because the fee is a real cost. It does allow false activity and reputation. The claim paths do reject a creator claiming their own dare, so the gap applies only to contributions. The team has recorded this as an accepted position, with prevention handled outside the contract.

The protocol fee rounds down. Any remainder therefore goes to the receiver rather than to the protocol. The amount is at most one base unit per settlement. This is documented as intentional, and the split was proven to be exact with no remainder lost across a wide range of amounts. It is recorded only because protocol fees usually round in the other direction. A reader comparing this contract to that convention should know the direction was chosen on purpose.

Open dares are claimed on a first-come basis, with no commit and reveal step. A program watching pending transactions can therefore always claim ahead of a genuine claimant. This follows from the documented design of the open mode. It is recorded separately from the unreachable-target finding, which is the part that turns a normal race into a lasting block.

The setup function is declared public but is never called from inside the contract. It should be external. A public function that is never called internally still uses the more expensive calling convention.

All source files accept a range of compiler versions. The build configuration selects one version, and the deployed metadata confirms which version was used, so the deployed contract is unambiguous. The open range still allows a different compiler on any future build. This includes a new deployment or an upgrade prepared by a different person on a different machine.

Several statements in the supplied documents do not match the live deployment or the current code. The scope document names the replaced proxy and implementation addresses. It also states that all four time windows are one hour. The live deployment uses fourteen days, fourteen days, three days, and seven days, with a ten minute pause grace period. The build verification document reports one hundred and four tests, while the suite now contains two hundred and thirteen. Its closing note states that the upgrade validation passes without doing real work. That is no longer true. This review confirmed that the check runs, accepts the safe upgrade fixture, and correctly rejects the deliberately unsafe one.

The creator can cancel throughout the committed state. There is no deadline check and no pause check. A creator can therefore cancel after a receiver has posted a bond and committed to performing. This includes canceling just before the contribution that would have reached the funding target. The receiver's bond is returned, so no funds are lost. The receiver's effort is not protected, and the cancellation can be timed deliberately.

The lock file records a top-level library at version 5.1.0. The import settings do not use it. The version that actually compiles into the bytecode is the 5.6.1 copy inside the upgradeable library. The unused entry serves no purpose. It leads a reviewer to check the wrong dependency for known issues.

The cumulative pause counter uses eight of the thirty-two bytes in its slot. Twenty-four bytes remain free directly before the upgrade reserve. A future upgrade that adds a small variable after it will use that free space rather than a reserve entry. The usual rule of reducing the reserve by the number of slots added would then be wrong. Following that rule would move the reserve and every variable after it.

The upgrade reserve is sized so that the total storage layout uses sixty-seven slots. The common convention would produce fifty. This is not a defect, and the layout is fixed by the stored snapshot. It differs from what a reviewer will expect, and the reason is not recorded anywhere.

Anyone can send the funding token directly to the escrow. The native asset can also be forced into a contract without its agreement. Neither action creates a matching obligation. Any statement that the balance equals the obligations can therefore be made false by a third party at no cost. The escrow can still pay everything it owes. There is also a case a user can cause themselves. A payout owner may name the escrow as the recipient. This sets their ledger entry to zero while the balance stays the same, turning their own claim into unassigned surplus. This was confirmed directly. None of this makes the escrow unable to pay. The tests used in this review already state the property as coverage rather than equality, but the published specification states equality and should be corrected.

The fee is calculated by multiplying the total contributed by the rate, and then dividing by the denominator, in that order. Above roughly one thousandth of the largest representable value, the multiplication overflows and the transaction fails before the division can reduce the result. This cannot be reached with any realistic supply of a six decimal stablecoin. The exactness of the split was proven across a wide but limited range of amounts. This is therefore a robustness note, not a live defect. It is recorded because the earlier description of the fee property as holding without conditions was broader than what was actually proven.

Removing the grace floor from the deadline calculation left the setting itself in place. It is still validated against an upper bound, still written to storage, still emitted in the configuration event, and still a required deployment input. The most recent unpause timestamp is likewise still written and never read. Nothing reads either of them. An operator reading the deployment inputs, the configuration event, or the deployment script will reasonably conclude that a grace period is in effect after a pause, and there is none. The dedicated error for an over-long grace value reinforces that impression.

The lock structure gained a field in the middle, so every field after it moved. The team correctly identified that this makes the remediated build storage-incompatible with the deployed one and set a hard condition that it must go out as a fresh proxy rather than an upgrade. The version accessor still returns the same string as the deployed build. An operator, indexer, or incident responder reading it on chain cannot tell the two apart, which is exactly the distinction the hard deployment condition depends on. The upgrade fixture in the repository does bump its own string, so the mechanism exists and is simply not applied to the production contract.

This was reported before and has grown rather than shrunk. The scope document names a proxy and implementation pair that the freeze document explicitly labels superseded, and lists a deployed configuration that no longer describes anything. It states that the reentrancy guard is used on every value-moving external function, which is not the case for the three functions that receive the bond. The build verification document reports a test count from several revisions ago and still carries the caveat that upgrade validation passes trivially and that storage safety is unverified, which was the specific stale statement the previous report asked to have removed and is now the opposite of the truth. The known-issues document describes pause credit as accumulating from lock creation across every later phase, which the remediation deliberately changed. The invariant specification describes the same superseded behaviour in its pause property and states solvency as an exact balance equality. The remediation documents are accurate and thorough; the older ones around them are not, and the freeze document's blanket statement that the newer documents supersede the older ones where they overlap does not tell a reader which statement to discard.

The lock file pins two paths. One is the test framework. The other is a top-level OpenZeppelin checkout at version 5.1.0 which the remapping file never points at: the compiled contracts resolve through the nested copy inside the upgradeable package, which is version 5.6.1. Neither the upgradeable package nor the upgrade-tooling package appears in the lock file at all. The previous report asked for the unused pin to be removed; it is still there, and the sharper problem is that the reproducibility guarantee the file is supposed to provide currently applies to none of the code that is actually compiled. In practice the libraries are committed into the repository rather than fetched, so the build does reproduce, but the file states something that is not true and the two sources of truth disagree.

The cumulative paused-seconds counter is an eight-byte value occupying its own slot with twenty-four bytes free, immediately before the upgrade reserve. A future variable of eight bytes or less added directly after it packs into that free space and consumes no new slot. Anyone following the usual convention of reducing the reserve by one for each variable added would shift every reserved slot and corrupt the layout. The reserve size also differs from the common convention without a stated reason. The structure that must never be extended now carries a clear warning comment; these two points do not.

The member-aware snapshot and the proof step are a genuine improvement and both were run and confirmed working during this review, including that a swap of two same-width members inside either structure is detected. The proof itself asserts only that each fixture's extracted layout differs from the committed baseline. The fixtures are hand-maintained copies of the real structures. If a field is later added to a real structure and the fixture is not updated, the fixture still differs from the baseline and the proof still reports success, but it is then demonstrating that the extractor notices a missing field rather than that it notices a swap of two same-width members. That is the one thing this gate exists to prove.

Thirteen items remain in the state the previous report described. None of them was introduced or worsened by the remediation, and the gas items among them were deliberately left out of the frozen slice with that decision recorded. The bad-faith burn still sends the bond out with a direct call inside a state change rather than crediting the burn address in the pull ledger, which is harmless in practice because the destination has no code but is the only remaining outgoing transfer on a path that is not a withdrawal. The funding window still restarts from the claim rather than from the creation, and that is still neither capped nor written down. Which functions keep working during a pause is still not documented anywhere, and value still leaves the contract while paused through the withdrawal and refund paths. There is still no comment at the point where a resolved lock's pledged total is zeroed while the per-contributor entries are left behind. Display-only data is still written to storage and never read. Dare creation is still free, unauthenticated, and able to name any identity. An open dare can still be taken by whoever gets a transaction in first. The setup function is still public rather than external. The compiler version is still a range rather than a fixed version in every source file, which the build settings override but the source itself does not state. The creator can still cancel after a receiver has posted a bond. Solvency is still asserted as an exact balance equality. The fee still multiplies before dividing.

The goal is now chosen at creation for open dares, and the creation event carries only the kind and the creator. The goal and the stretch tiers reach the log only through the claim event, which is emitted when somebody claims. Funders can contribute from creation onward, so between creation and the first claim a consumer working from logs alone cannot tell a funder what they are funding towards and has to read the lock from storage to find out. This is a direct consequence of moving the goal earlier; it did not exist while the claimant set the goal, because then the goal and the claim arrived together.

The document is presented as approved and implemented, and states that the deadline calculation returns the base plus the credit and that the unpause timestamp and the grace value are no longer read by the deadline math. The delivered code reads the unpause timestamp inside that calculation. The document then sets out two options, recommends dropping any post-unpause buffer, and argues against the gated-buffer option on the grounds that it is materially more code and more to red-team. The delivered code implements a gated buffer, and with a weaker gate than the one the document sketched: the document proposed gating on the phase being live when the last pause began, the code gates on the phase being live when it ended, and that difference is the reason a later pause can drop the buffer. The document also still claims the never-shortens property for the old formula, and carries a stale test count. A maintainer reading it would conclude that the deadline calculation touches no mutable state, which is the assumption the current defect breaks.

The buffer is a compile-time hour and the shortest permitted window is also a compile-time hour, chosen independently of each other. The scope document records the deployed configuration with all four windows at that minimum. At those values the buffer is not a cushion on a phase, it is a second copy of the whole phase: a phase with a hundred seconds left when a pause ends comes back with a full hour. The same equality is the only reason the buffer the initializer arms at deployment is inert, since it is exactly as long as the shortest window a freshly created lock can have. Nothing checks the relation, so a later change to either constant, or a shorter window becoming permitted, changes behaviour silently in a part of the code whose stated property is that it never shortens anything.