Historical round. This page records the source as it stood on 14 July 2026 and what happened to each finding afterwards. Several of these findings concern the multi-stablecoin registry and the identity-based compliance model, both of which ADR-0029 and ADR-0030 later removed from the launch surface. Where this page and the clean mainnet-v1 round disagree, the later round governs.
Why a second round
Round 1 concentrated, as first rounds do, on the surfaces that look most dangerous: backing valuation and the facility lifecycle. This round deliberately excluded all nine of its findings and re-attacked the modules it had touched least — compliance, the vault, the redemption queue, the points module, the governor, and the stablecoin side of the treasury.
It surfaced nine further findings: two High, three Medium, three Low and one Informational. That a second pass over the same tree, with the first pass's results removed from scope, found as many findings as the first is the useful result here. It is the argument for the multi-round structure the protocol has used since.
The findings in detail
A protocol exemption let a blocked holder move value out through a vault deposit
The compliance check returned true whenever either endpoint of a transfer was protocol-exempt, and it did so before consulting the blocklist. Production marked the vault exempt, and the vault's deposit path validated only the share receiver, not the caller supplying the assets. A jurisdiction-blocked wallet could therefore deposit on behalf of an allowlisted receiver: the inbound leg was exempt because the vault was an endpoint, and the shares minted clean and transferable to a different party — converting a frozen balance into an unfrozen one.
This dissolved rather than being patched. Transfer-level identity gating was removed entirely: the transfer check is now sanctions-only, and the sanctions test precedes the module exemption, so a blocked wallet cannot route value through an exempt module in either direction.
A disabled stablecoin kept counting at face value
Disabling a stablecoin left it in the reserve's historical list, and idle reserve counted every listed token's balance at decimal face value with no haircut, impairment flag or removal path. If a token were disabled because it depegged or was frozen, its full nominal balance would still support supply — while the release path refused to redeem the residual out.
Fixed at the time by a governance write-off primitive plus isolation of the per-token balance read. The whole registry was subsequently removed: mainnet v1 is canonical USDC only.
The queue budget reserves nothing
At epoch close the queue snapshots a share of stable liquidity to cap how many shares become claims, but escrows no stablecoin. Queue claimants are paid in already-redeemed protocol tokens, so the contention sits one hop downstream: when they convert to stablecoin they compete with direct redeemers for the same unreserved pool. The budget is a throughput cap, not the liquidity guarantee the documentation implied.
Accepted as a labelling rather than a solvency issue — claimants hold fully-backed tokens throughout — and the documented semantics were corrected to an honest throughput cap. A hard liquidity reservation remains an economic-review item, deliberately not rushed into an escrow design.
A failing points hook could freeze the vault
The vault called the points hook on every mint, burn and transfer with no isolation, so a bad points-module upgrade or hostile configuration could revert deposits, transfers and — critically — redemption burns, contradicting the comment asserting that points never affect transfer validity. The hooks are now fail-open. Points are a non-financial participation ledger and must never be able to block a redemption.
A broken stablecoin entry could brick backing
Idle reserve called the balance function on every historical stablecoin entry with no isolation and no removal path, so a once-approved token that later reverted would revert the whole backing calculation — cascading into every mint, redeem and yield assertion, the loss burn path and the redemption queue, with no on-chain remediation. Resolved together with the face-value finding, and then made moot by the single-stablecoin scope.
One sub-claim in the original filing did not hold and is recorded as refuted: the list could not grow unboundedly, because re-approval never re-added an entry.
Lower-severity findings
Points rate changes re-priced un-checkpointed history. Rate and multiplier changes re-priced the entire un-checkpointed interval at the new parameters, and wallets were not enumerable to checkpoint first. Materially mitigated by non-retroactive rate epochs — each change appends an epoch and prior intervals keep their old rate. The residual is the per-wallet lazy checkpoint on first touch after a change.
Identity rebinding misattributed points. A compliance identity rebinding did not notify the points module, so credit between rebind and the next synchronization accrued to the old identity. Moot: the points redesign made accrual per-wallet and removed the identity indirection entirely.
The governor initializer accepts zero module addresses. It omits the local zero-address checks its sibling modules all carry. Still open, tracked.
The Informational finding that became Critical
A queued request could become sub-wei dust after a later loss and burn for zero assets. It was filed Informational on the reasoning that the amount was below one wei and therefore not material, and its recommendation — an explicit guard on a zero-asset burn — was never implemented.
A week later the conservative redemption NAV clamp destroyed that premise. The clamp could price a whole position at zero rather than at a sub-wei residual, and the burn still proceeded. The same mechanism was re-filed in the pre-mainnet campaign as a Critical total-loss path, reproduced seven times, and fixed there.
This is the clearest lesson in the audit record: the finding was closed on an argument about magnitude rather than a bound in the code, and a later change falsified the argument while the code stayed as it was. It is why the dispositions on this site record the premise of an acceptance and not only its outcome.
Method
The same five-pass structure as Round 1, re-aimed: storage, initialization and upgrade safety; authorization and the production role and exemption topology rebuilt from the deploy script rather than from the contracts; accounting and precision; lifecycle and liveness; and oracle, token and cross-module adversarial interaction. The offline suite was re-run against unchanged source and static-analysis results re-triaged. No source file was modified during the review.
Limitations
As Round 1: source-level only, no deployed-bytecode, custody, legal-enforceability, attester operations or live infrastructure review, and third-party library internals not re-audited beyond their integration boundaries. An independent external audit remains a required production gate.