Bitwise Premium RWA AUSD

Market.

Market risk reads low, set by its worst component (worst fall suffered, shared exposure) over the record we hold.

Liquidity.

Liquidity risk reads moderate, set by its worst component (could you get out) over the record we hold.

Depositor concentration.

Depositor concentration risk reads low, set by its worst component (largest depositor) over the record we hold.

Operating.

Operating risk reads low, set by its worst component (stopped operating) over the record we hold.

Controller.

Observed: the owner needs an unread number of signatures; adding a new destination for the funds (an adapter) waits 168 hours in the vault's timelock; a party at another address can revoke that change.

Evidence.

5 of the 5 risk components that apply to this vault carried a reading (liquidation does not apply to this kind of vault).

Low observed risk is not zero risk. Market here is two observed readings: the worst fall in the vault's past share price and how much of its lending shares a market with other vaults we track. It does not assess the collateral, the borrowers' ability to repay, a concentration in one market (read under where the capital rests), or whether withdrawals hold under stress. The overall band weighs every component together instead, so it can read better than this and is not in conflict with it: a dimension says how bad its worst reading is, the band says what the whole weighs.

Input: 18.2% of it could be withdrawn at the last reading, on the vault's own accounting, 18.2%, which is lower than the 23.3% we derive from declared withdrawable $2,462,715 over capital $10,564,296; the lower of the two is used. The reading 0.27 is one less that share over 25%: a quarter or more free reads 0, nothing free reads 1. The overall band weighs every component together instead, so it can read better than this and is not in conflict with it: a dimension says how bad its worst reading is, the band says what the whole weighs.

Low observed risk is not zero risk. It measures how much of the vault its largest depositor holds, not how much the vault lends into one market; that is the allocation table. Input: largest wallet holds at least 18% (the depositor list and the vault's own size disagree, and this is over the larger of the two), by the address's position; addresses are not merged by who owns them, and whether the largest is a person, another vault or a custodian is not established. The reading 0.00 is that share less 25%, over 75%: a quarter or less reads 0, the whole vault 1. The overall band weighs every component together instead, so it can read better than this and is not in conflict with it: a dimension says how bad its worst reading is, the band says what the whole weighs.

Low observed risk is not zero risk. The overall band weighs every component together instead, so it can read better than this and is not in conflict with it: a dimension says how bad its worst reading is, the band says what the whole weighs.

Coverage of the curator's timelocked functions is complete, which is not a review of everything that controls the vault. Each of the curator's 15 timelocked functions was read from the contract at block 26,335,803: its delay, and whether it has been abdicated. The 3 gates that can lock depositors out (setSendSharesGate, setReceiveAssetsGate, setReceiveSharesGate) are abdicated: the contract records each as given up, and it has no function that reverses an abdication. That holds while this code is the vault's: the address carries the contract itself (21,808 bytes) with no proxy implementation, beacon or admin slot set, so we found no way to replace it. Pointing funds somewhere new, or raising a cap, waits its delay, during which a sentinel can revoke it. Fees can change at once, within the contract's ceilings: setPerformanceFee, setManagementFee, setForceDeallocatePenalty. Allocators move funds between destinations already added, within the caps, at once, as the contract intends; who they are was not checked. The owner names the curator and the sentinels, at once; this contract gives it no function that moves funds or sets a gate, a cap or a fee itself, and a new curator's changes wait the same delays. ASPERN rule, since 2026-10-31: a delay of a day or more on that change and a veto at another address read moderate rather than high. The level would read high if any of these could be used without its delay: setSendSharesGate, setReceiveAssetsGate, setReceiveSharesGate, addAdapter, increaseAbsoluteCap, increaseRelativeCap, setAdapterRegistry, the gates that can lock depositors out and the ways to add a destination or raise a cap. Powers that act at once here do not move it: fees (setPerformanceFee, setManagementFee, setForceDeallocatePenalty), because the contract caps them; naming allocators (setIsAllocator), because an allocator moves funds only among destinations already added and within the caps. The ways out of an allocation, as read from this vault, are set out under how you get out; whether they work for each adapter was not verified. It is a rule of ours, not a change in the vault. Not known: whether different addresses are controlled by different people, who the allocators are, and what each adapter's own code allows. This is not part of the overall band.

By weight, 82.5 of the 82.5 points that apply were read, which is 100% of the component weight the band could draw on (a different denominator: components are not equally weighted); the rest of the 100 is the weight of what does not apply. This is a statement about our coverage and carries no level of its own, because how much we could read is not a risk the vault runs.