The timelocked USDC withdrawal is bounded only by the treasury minimum float, which defaults to zero. With the float at zero the admin can schedule a withdrawal of the entire treasury balance and execute it after the timelock elapses. The 24 hour delay plus the guardian cancel path are the intended mitigations, but on the reviewed deployment there were no guardians registered, so the delay was the sole protection. This is the expected treasury-management power of the admin and is time-delayed, so it is low severity, but operators should set a meaningful float so the floor is real.

The mint side carries a deliberate two-part defence against being front-run ahead of a premium increase: proposing a mint-premium change sets a pause timestamp equal to the execution time, and the mint handler refuses while either that timestamp is in the future or a mint-premium proposal is armed. The source explains correctly why both halves are needed, because between the delay elapsing and the admin executing or cancelling, the timestamp alone would resume minting at the old premium. The redeem side has the mirror-image exposure and no mirror-image defence. Proposing a redeem-premium change records the pending proposal slot and nothing else, and the redeem handler reads neither that slot nor any equivalent. During the announced delay window before a redeem premium increase, holders redeem at the old cheaper rate, consuming the rolling redemption budget and the treasury at precisely the moment the protocol had decided that outflow should cost more. This was latent while redemptions shipped closed and it is live now that initialize opens them.

The queued-action account records the scheduling time and the execution time but no deadline, and every execute handler checks only that the current time is at or past the execution time. A proposal that matures and is never executed therefore remains a standing authorisation for the life of the program. This is the same hazard the guardian removal path names explicitly and closes with a bounded execution window, described there as a stored coupon that can be pre-armed while things are quiet and spent later with no reaction time, and the reasoning transfers directly and with more value at stake to the treasury withdrawal, the inventory-wallet redirect, the redeem-limit loosening and the public-mint opening. Two mitigations are already present and are the reason this is low rather than medium: only one proposal per action kind can be active, so a stale proposal blocks new ones of its kind and is therefore visible in the configuration rather than hidden, and a guardian can cancel it at any point before execution. Both depend on somebody noticing that an old slot is still armed months later. Replay and post-cancellation execution are separately and correctly blocked, verified across all twelve execute handlers, by two independent mechanisms: each handler requires the configuration slot to still point at its own nonce, and each closes the queued-action account on execution.

The large-redemption threshold, the queue delay and the redemption request nonce lost their only readers when the queued redemption flow was removed. The struct marks the first two as dead and keeps them declared so that field offsets do not move, which is the right call. The problem is that both write paths still accept them. The effective-change gate explicitly discards them, yet the instant tighten instruction and the timelocked execute handler both assign them, and the emitted event reports the new values. An operator responding to an incident can therefore tighten a large-redemption threshold, see a confirmed transaction and a matching event, and have changed nothing. This is the same silent-no-op-on-an-emergency-lever class the team already found and fixed once for the redemption switch, where the source records the right principle, that a silent no-op on an emergency lever is worse than a revert. One further property of this same payload is worth recording, because it bears on whether the guardian veto can be exercised competently. The action is named for the redeem throttles, but its payload also carries the switch that re-opens redemptions, which is the only route by which USDC leaves the treasury to holders. A guardian deciding within the delay window whether to cancel a proposal named for limits must therefore decode the payload to discover whether it also re-opens the exit, and the three inert fields sit in that same payload. Making the payload say what it does would serve the veto as well as the operator.

Three artefacts that a reader is invited to treat as assurance no longer describe the code that ships, and all three failed the same way, by not being attached to anything that would notice. First, the remediation checklist carries a short list of properties that must continue to hold after any change, and one states that the premium ceilings remain at three hundred and five hundred basis points with the combined premium logic unchanged. Neither half holds: the mint ceiling was widened from three hundred to five hundred, and the combined floor is set to zero with both comparisons commented in the source as no-ops. The re-audit brief discloses the ceiling move in a single line under changed policy without connecting it to the gate it breaks, and does not mention the combined logic at all. Second, and more substantially, the formal proof harness is a hand-maintained copy of the pricing core whose own header records the obligation to track the original. The original changed structurally: the fee model moved from a premium baked into an effective price to a fee taken off the top at pure spot, which the source marks by labelling both effective-price helpers as quoting only. A call-site search confirms neither is invoked anywhere outside the unit tests in its own module, while the priced instructions call the fee helper and value the net amount at the raw oracle price. Of the three proofs, the one asserting that the redeem price never exceeds the oracle now constrains a function with no caller, and that is precisely the property the published statement cites as evidence. The mint proof keeps partial value because the payout helper it exercises is live and the domain it explores contains the live domain, but it reaches that helper through the dead one, and it still assumes a premium bound of three hundred basis points while naming the ceiling constant that is now five hundred. The round-trip proof is the most representative and also the narrowest, fixed to one price and bounded to a hundred dollars. Third, an attempt to run the harness in this pass did not terminate: the solver was stopped after roughly seventeen hours still inside the first of the three proofs with no verdict emitted, on a harness whose header records that its bounds were already narrowed for tractability. That is recorded as not verified rather than as a failure, and it is the clearest evidence for the process point, since a proof nobody runs can report neither that it has stopped matching the code nor that it has stopped finishing. The practical risk in all three is low and should be stated as such. The launch premiums moved down rather than up, every premium change passes the delay, and a user on the mint side is independently protected by the minimum-output check, so nobody can be priced worse than they agreed. Nothing indicates the live math is wrong; it is simple, unit-tested and independently fuzzed. What is affected is the accuracy of claims made to readers who cannot check them, which is the reason an audit statement exists. The other declared gates were re-checked and do hold: overflow checks enabled in the release profile, the extension allowlist unchanged and still rejecting transfer hooks and fees, a thirty second staleness ceiling, a tighten-only supply cap, instant re-opening of redemptions still refused, and the development and harness features non-default. The publisher floor deserves mention on the other side of the ledger, being enforced at the point of use by taking the maximum of the configured value and the hard floor rather than only at the setter, which is the stronger placement.

The guardian is the designated independent check on the admin, and on this deployment it is not independent, by two separate mechanisms that compound. The first is in the program. The removal side was hardened correctly and thoroughly, but the appointment side was loosened in the same period: the appointee co-signature was removed, so growing the set is a single admin signature with no external consent and no delay. With the active-guardian floor at one, three slots by default and five configured for mainnet, a compromised admin appoints a key it controls, schedules removal of the honest guardian, absorbs that guardian's single self-cancellation, re-schedules and finalises, needing no consent from outside itself and completing in roughly two delay windows, after which every counter still reads healthy because the count counts registrations rather than independence. The recorded reasoning for dropping the co-signature is sound on its own terms, that a compromised operator could generate and sign for the key so it proved participation rather than independence, and that it made appointment unexecutable through the documented ceremony; what it does not address is that the co-signature was the only step that made dilution visible before it landed. The second mechanism is in the deployment and was disclosed by the operator: the vault holding the guardian and the vault holding the admin are both three-of-five over the same five members, so three keys reach both at the same instant and the capture sequence above is not even required. Critically, every independence check the program performs compares addresses, and the two vaults are different addresses, so the appointment check, the authorisation predicate and the unpause precondition all pass while the property they exist to establish is false. That is not a coding error, since signer-set membership behind a multisig address is not visible to the program, but it means the checks cannot be read as evidence of independence and an integrator or auditor reading them alone would conclude the opposite of the truth. Two smaller related weaknesses ride on the same mechanism: the unpause instruction takes the guardian record as a plain account rather than a signer, so it establishes that a guardian exists and not that one consented, and the authorisation predicate carries a documented residual in which an admin transfer onto a guardian key leaves that guardian counted but inert. SEVERITY. Graded Low rather than Medium, on the convention the original register already applies to the guardian layer: a finding whose precondition is itself carried as a separate higher-severity item is scored on what it adds beyond that precondition, not on the combined outcome. What this adds is the failure of a mitigating control rather than a new capability. Every path it opens presupposes either an already-compromised administrator or a quorum that, on the disclosed assignment, simultaneously holds the upgrade authority, and an attacker holding the upgrade authority can replace the program and remove the guardian check outright, so the veto's non-independence grants that attacker nothing it did not already have. The concentration itself remains open at Medium and is where this exposure is scored. It would return to Medium if the authority split were completed without also making the guardian independent, because the veto would then be the layer actually being relied upon.

The pre-mint instruction is instant, admin-only, requires no USDC, reads no oracle, and is bounded only by the lifetime supply cap of 150000 ounces. Since the launch-posture change, initialize ships with redemptions enabled, so pre-minted supply that is not backed by treasury USDC can be burned for treasury USDC. That route has none of the three protections the governed withdrawal has: no delay, no guardian cancellation window, and no minimum treasury float, because the float deliberately gates the administrative path only so a user redemption never fails on an admin-facing threshold. Two mitigations must be credited before the residual is stated. The destination is no longer redirectable, being bound at initialize with the instant setter deleted, so the admin key alone cannot mint into an address it controls. And the pre-mint is gated on the pause, so the exposure begins at go-live rather than at initialization. What remains is a custody problem that the operator identified independently and recorded as a numbered decision, and their analysis matches this one including the correct rolling-window bound. The inventory wallet is an on-curve single-signer hot wallet, deliberately so, and it is intended to hold the pre-minted supply. Its holder signs the redemption directly, with no admin instruction and no delay, so the weakest key in the system controls the unbacked supply that can draw on the backing. Blocking that address in the redemption path would close nothing, because the token is fungible and can be moved first. The only code bound is the rolling window, whose honest limit is close to twice the configured budget across an adversarially aligned span, roughly forty thousand USDC in the first day and twenty thousand per day thereafter while nobody pauses. The accepted mitigation is entirely operational and has two parts, pre-minting only an operational tranche and holding the reserve in a vault, and it rests on two conditions the operator's own register records as not existing as of the date of this review: the tranche size is an input that is not yet fixed, and neither the automated alerting nor the exercised guardian response exists. A bound that depends on an unfixed number and on detection that has not been built is not yet a bound, which is why this stays open and why the recommendation is to place it in the program. SEVERITY. Graded Low rather than Medium, on the convention the original register already applies to the guardian layer: a finding whose precondition is itself carried as a separate higher-severity item is scored on what it adds beyond that precondition, not on the combined outcome. What holds the exposure down is a combination of four bounds that are real and verifiable in source or in the operator's register: the destination cannot be redirected without a delay and a cancellation window, the pre-mint is gated on the pause so nothing is exposed before go-live, the conversion route requires the private key of a wallet held outside the program's control so this is a custody compromise rather than an administrator action, and the rolling window caps the rate at close to twice the configured budget per span regardless of how much unbacked supply exists. The loss is therefore rate-limited and capped by the tranche actually issued rather than by the supply cap. It would return to Medium if the reserve were issued to the hot wallet rather than held in a vault, and it should be treated as Medium in operational terms until the two conditions the operator sets for itself are met, namely a fixed tranche size and working detection, because until then the bound is a policy rather than a control.