D2 Finance HYPE++

Contract Addresses

Contract	Address	Type
HYPE++ Vault	0x75288264FDFEA8ce68e6D852696aB1cE2f3E5004	VaultV1Whitelisted, ERC-4626-style vault
HYPE++ Trader / OMS	0x8CaBD8b787e8c69C5f24091cFDA197fF570345B3	Verified selector router (non-upgradeable; delegatecalls modules)
D2 Module (D2 facet)	0xc8071aD5560904B3b721e7E5d29742F523a69111	Delegatecall module; implements d2_deposit/d2_withdraw (EXECUTOR_ROLE-gated), hardcoded in Strategy Factory
Vault Owner	0x0E8c0470773c65498F438cac380648B314399A46	EOA onchain (team states institutional MPC/HSM custody); owns BOTH HYPE++ vault and dgnHYPE vault
Trader Admin / Executor / Fee Receiver	0x7ab129978091DEE65A319c5FC728818D73221999	EOA onchain (team states institutional MPC/HSM custody); holds DEFAULT_ADMIN_ROLE and EXECUTOR_ROLE on trader
D2 Vault Multisig	0xB2fEDed045F3fd9FcCCF8E7e95729c4182916CE0	Safe, 4-of-7; also trader admin/executor
dgnHYPE Vault	0x64167cd42859F64cfF2Aa4B63c3175cceF9659dd	Nested D2 VaultV0 held by HYPE++ trader
dgnHYPE Trader / Custody Safe	0x155d0B27B754ebC664aeD565945C1AaEa91966fb	Nested D2 custody Safe, 3-of-5
Hyperliquid Operational EOA 1	0x0C684f333A7e120bce61383DA670bbB0157e82d0	EOA receiving USDC from the dgnHYPE Safe and forwarding it to HyperCore via Bridge2 or Circle CCTP
Hyperliquid Operational EOA 2	0x11A691612BD108e57cC04ea42B006C9CB1ff006A	EOA that received USDC from the dgnHYPE Safe in August 2026; routes through Bridge2 and Circle HyperCore CCTP
Hyperliquid Operational EOA 3	0x4c3d48cbe2186beeafecc6723630ab8eda4117fc	EOA that returned ~2.55M USDC from HyperCore to the dgnHYPE Safe on September 19, 2026
Aave V3 aArbUSDCn	0x724dc807b04555b71ed48a6896b6f41593b8c637	Aave V3 Arbitrum aToken for native USDC (pool 0x794a61358D6845594F94dc1DB02A252b5b4814aD); held by HYPE++ trader
Hyperliquid Bridge2	0x2Df1c51E09aECF9cacB7bc98cB1742757f163dF7	Verified Hyperliquid Arbitrum bridge contract; not an EOA
Circle HyperCore CCTP Extension	0xA95d9c1F655341597C94393fDdc30cf3c08E4fcE	Circle-documented Arbitrum contract for USDC transfers to HyperCore
Circle CCTP V2 MessageTransmitter	0x81D40F21F12A8F0E3252Bccb954D722d4c464B64	Circle-documented CCTP V2 contract; mints USDC on Arbitrum for HyperCore withdrawals
USDC	0xaf88d065e77c8cC2239327C5EDb3A432268e5831	Underlying asset
Vault Factory	0xb5B272EF918835651375f84D463b1Ba7B61eF028	Deployed HYPE++ vault
Strategy Factory	0x2AA01FdE174aB160b4e4F49F152C20d6Ec029d67	Deployed HYPE++ trader

Deployment metadata:

• HYPE++ vault and trader were deployed in transaction 0xf5642a6a...6265e at Arbitrum block 276124793 on November 19, 2024.
• The vault is NOT behind a proxy (EIP-1967 implementation slot is zero; re-checked October 12, 2026); it is a standalone VaultV1Whitelisted contract. Ownership is transferable via the standard Ownable transferOwnership().
• The trader is NOT a standard proxy (EIP-1967 implementation slot is zero); it is a standalone selector router that delegatecalls to pre-configured modules.
• The contract at 0xc8071aD5560904B3b721e7E5d29742F523a69111 is the D2 module (verified source D2_Module): it was deployed earlier (block 218684412, tx 0xe432dabc...8675) by a different EOA (0x00Aa367B7692be05E47B9c461fF35410208158b0), and the Strategy Factory hardcodes it as the D2 facet. The HYPE++ trader wires it as targets[28] — the delegatecall target for the d2_deposit(address,uint256) and d2_withdraw(address,uint256) selectors (both EXECUTOR_ROLE-gated). It is not a proxy implementation, but it is an active delegatecall module in the trading path.

Audits and Due Diligence Disclosures

D2 publicly lists three audit links: Paladin, Cyfrin D2 v2.1, and Cyfrin Hyperliquid CoreWriter. The most directly relevant audit lineage is:

Date	Firm	Scope	Link
Mar 23, 2023	Paladin	D2 staking contracts	Paladin D2
Sep 27, 2023	Paladin	D2 strategy stack including VaultV1, TraderV0, StrategyETH, AccessControl, and DeFi modules	Paladin D2
Feb 24, 2025	Cyfrin	D2 v2.1	PDF
Oct 16, 2025	Cyfrin	D2 HYPE CoreWriter v2.0	PDF

Paladin's public page lists the September 2023 strategy audit as completed with 85 total issues: 18 governance, 3 high, 8 medium, 23 low, and 33 informational. Paladin's page also cautions users to confirm they are interacting with audited contracts. HYPE++ was deployed later, in November 2024, but the verified source identifies the vault as VaultV1Whitelisted and the trader as D2's Strategy router/OMS architecture.

The audits cover smart-contract code. They do not cover the majority of HYPE++ capital at the snapshot: 69.27% sits in dgnHYPE, whose trader is a standard Safe that forwards funds to EOAs and HyperCore accounts, where no D2 contract logic constrains it.

Bug Bounty

No active Immunefi, Sherlock, Cantina, HackerOne, Code4rena, or Safe Harbor program was found in the D2 docs (re-checked October 12, 2026). Targeted manual searches on Immunefi ("D2 Finance") and the Safe Harbor registry (SEAL) returned no listed program. D2 publishes audit links and security process statements, but no public bounty with payout terms was found.

Historical Track Record

HYPE++ was deployed on November 19, 2024, giving the scoped vault roughly 23 months of onchain history at the October 12, 2026 snapshot. Scoped TVL is $8.66M based on totalAssets() in USDC terms. DeFi Llama reports $28.69M for D2 Finance protocol-wide on October 12, 2026 (30-day peak $35.01M on September 19, 2026).

Dated epoch outcomes and TVL changes:

Epoch	Funds custodied	Funds returned	Result
21 (Jul 9 – Sep 18, 2026 scheduled)	11,691,129.81 USDC	11,914,081.42 USDC on September 19, 2026 03:33 UTC (tx)	+1.91% to depositors; 55,737.90 USDC performance fee (tx). Returned ~19.5h after the scheduled end.
22 (Sep 22 – Sep 30, 2026 scheduled)	8,164,463.85 USDC on September 25 (tx)	8,297,153.45 USDC on September 30, 2026 12:36 UTC (tx)	+1.63% to depositors; 33,172.40 USDC fee (tx). The gain was a transfer from the trader-role EOA, not trading by the HYPE++ trader; see Funds Management.
23 (Oct 2, 2026 – Jan 15, 2027 scheduled)	8,662,163.87 USDC on October 12 (tx)	Pending	—

• HYPE++ totalAssets() was 11.69M USDC on August 10, 2026 and 8.66M USDC on October 12, 2026 (-25.9%). The decline came from net withdrawals during the September 19 – October 2, 2026 funding windows: ~7.45M USDC withdrawn versus ~4.06M USDC deposited. The share price rose from ~1.4827 to ~1.5355 USDC over the same period.
• The owner raised maxDeposits from 12M to 15M USDC on September 19, 2026 (tx) and lowered it to 10M USDC on September 22, 2026 (tx).
• The owner added 34 addresses to the whitelist (NewWhitelistStatus(..., true)) on September 20 (tx) and September 30, 2026 (tx). No whitelist removals were emitted since August 1, 2026.

D2 documentation describes a broader multi-year strategy record and states that the team combines DeFi-native and traditional finance derivatives experience. This is useful context, but the report scores the onchain HYPE++ vault rather than offchain performance history.

No public exploit specific to the HYPE++ vault was identified. The main historical concern is not a known loss event; it is the intentionally active-managed design, where funds are transferred out of the vault into a trader contract and onward into nested D2 custody, operational EOAs, and HyperCore trading accounts.

Funds Management

HYPE++ is an ERC-4626-compatible USDC vault. Users deposit USDC during funding windows and receive HYPE++ shares. During the trading phase, the trader contract calls custodyFunds() on the vault and receives the vault's USDC. While custodied = true, totalAssets() returns the last custodiedAmount rather than current vault-held USDC. At epoch end the trader calls returnFunds(); the amount returned becomes the new vault NAV.

Current reserve reconciliation (block 514216436, October 12, 2026):

Component	Value	Share of HYPE++ totalAssets()
HYPE++ totalAssets() / custodiedAmount()	8,662,163.870361 USDC	100%
HYPE++ totalSupply()	5,641,236.892148 shares	—
HYPE++ vault USDC balance	0 USDC	—
HYPE++ trader direct USDC balance	1,000,999.329714 USDC	11.56%
HYPE++ trader Aave V3 aArbUSDCn balance	1,661,212.950725 USDC	19.18%
HYPE++ trader dgnHYPE balance	4,410,567.717197 shares (= 100% of dgnHYPE totalSupply())	—
dgnHYPE totalAssets() / custodiedAmount()	6,000,065.047643 USDC	69.27%
dgnHYPE custody Safe direct USDC balance	3,410,065.048382 USDC	—
dgnHYPE custody type	3-of-5 Safe	—

The top-level HYPE++ arithmetic reconciles: direct USDC + Aave aUSDC + dgnHYPE reported assets = 8,662,277.33 USDC versus 8,662,163.87 USDC totalAssets() (+113 USDC of Aave interest). The trader's Aave position came from five aave_supply calls on October 12, 2026 (e.g., 900,000 USDC), and its 6,000,000 USDC dgnHYPE deposit was made the same day (tx).

dgnHYPE is a nested active D2 strategy with custodied funds. Its trader() is a 3-of-5 Safe, and dgnHYPE uses the same custodied accounting pattern: while custodied, totalAssets() returns the stored custodiedAmount rather than live balances. dgnHYPE epoch 23 has funding start October 11, 2026 01:10 UTC, trading start October 12, 2026 01:10 UTC, and a scheduled end of October 13, 2026 01:10 UTC; the Safe took custody of 6,000,065.05 USDC on October 12, 2026 01:24 UTC (tx). dgnHYPE withdrawals stay blocked until the Safe calls returnFunds(). That call does not depend on the scheduled end, so the HYPE++ exposure is governed by the HYPE++ epoch (ending January 15, 2027) and by when the Safe returns funds.

Hyperliquid custody path

Arbitrum transfers show the route for dgnHYPE capital:

• Outbound, July–August 2026: On July 27, 2026, the dgnHYPE vault transferred 7,500,500.905511 USDC to its custody Safe (transaction). The Safe transferred 5.0M USDC to operational EOA 1 (0x0C684f333A7e120bce61383DA670bbB0157e82d0), which deposited it into Hyperliquid Bridge2 (e.g., 900,000 USDC Safe transfer, 900,000 USDC bridge deposit). On August 1, 2026 the Safe sent 400,000 USDC to operational EOA 2 (0x11A691612BD108e57cC04ea42B006C9CB1ff006A), which used both Bridge2 (example) and Circle's HyperCore CCTP extension (example).
• Other Safe counterparties, August 2026: On August 20, 2026 the Safe sent 170,000 USDC to another unidentified EOA, 0x9a62fee8aa39ef2623ba54293282726da31e3259 (e.g., 85,000 USDC). That EOA also receives USDC from operational EOA 2 and forwards it to 0x2ca22119cea729ac4ee86efe2188f9aa98045d49 (e.g., 200,000 USDC). On August 27, 2026 the trader-role EOA sent 200,000 USDC to the Safe in several transfers (e.g., 60,000 USDC). The Safe, the trader-role EOA, and these EOAs exchange funds outside the vault accounting path.
• Return, September 19, 2026: Withdrawals from Hyperliquid arrived on Arbitrum as USDC minted through Circle's CCTP V2 MessageTransmitterV2; the decoded messages carry source domain 19 (HyperEVM) and destination domain 3 (Arbitrum) per Circle's domain list. Operational EOA 1 received ~3.10M USDC (e.g., mint), and a third EOA, 0x4c3d48cbe2186beeafecc6723630ab8eda4117fc, received ~2.55M USDC (e.g., mint). Both forwarded the USDC to the Safe within minutes, and the Safe returned 7,778,689.51 USDC to dgnHYPE (tx), +3.71% on the custodied amount.
• Outbound, October 12, 2026: After taking custody of 6.00M USDC, the Safe sent 2.60M USDC to operational EOA 1 (e.g., 800,000 USDC). The EOA forwarded 2,599,000 USDC to the Circle HyperCore CCTP extension (e.g., 800,000 USDC). The remaining 3.41M USDC was still in the Safe at the snapshot.
• Off-vault settlement into HYPE++ (September 30, 2026): During HYPE++ epoch 22, the trader made no calls between custodyFunds() and returnFunds() (trader transaction list). The epoch's entire gain came from transfers into the trader of 165,862 USDC by the trader-role EOA 0x7ab129978091DEE65A319c5FC728818D73221999 (e.g., 40,000 USDC). That gain was 132,689.60 USDC to depositors plus 33,172.40 USDC fee, and it arrived after dgnHYPE had already settled and while HYPE++ held no dgnHYPE. Earlier that day the dgnHYPE Safe had received 269,990 USDC from an unidentified EOA, 0x2ca22119cea729ac4ee86efe2188f9aa98045d49 (tx). That EOA had itself received 270,004.40 USDC minutes earlier (tx) from 0xee7ae85f2fe2239e27d9c1e23fffe168d63b4055. This is an ERC-1967 proxy over a verified SingleOwnerMSCA smart-account implementation (0xd206ac7fef53d83ed4563e770b28dba90d0d9ec8). Since July 2026 it has received ~27M USDC from a high-activity EOA, 0x968d48e3f318d4eb0f6b5b1d51d1f8c8c780561f (e.g., 9.0M USDC), and it distributes USDC to many other addresses. TODO: owner identity of 0xee7ae85f2fe2239e27d9c1e23fffe168d63b4055, 0x968d48e3f318d4eb0f6b5b1d51d1f8c8c780561f, 0x2ca22119cea729ac4ee86efe2188f9aa98045d49, and 0x9a62fee8aa39ef2623ba54293282726da31e3259; no explorer label, D2 documentation, or D2 frontend data identifies them. The Safe then sent 260,000 USDC to the trader-role EOA (e.g., 160,000 USDC). HYPE++ PnL can therefore be credited by discretionary EOA transfers from outside the vault/trader accounting path.
• HyperCore state (Hyperliquid info API, October 12, 2026): Operational EOA 1 holds short BTC and HYPE perpetuals (20x and 10x leverage settings; ~$1.33M notional) plus spot USDC (~1.89M), HYPE, and UBTC. Operational EOA 3 holds a long HYPE perpetual (~$1.81M notional, 10x), short BTC and long ETH perpetuals, plus spot USDC (~1.21M) and ~75,971 HYPE. The Safe has no HyperCore balance. These accounts may serve more than one D2 strategy, and nothing onchain attributes their holdings to dgnHYPE or HYPE++. TODO: per-vault attribution of these HyperCore accounts and balances to dgnHYPE. D2 does not publish it in its docs or in the d2.finance frontend bundle, and it must come from D2 reporting.
• All operational addresses are EOAs (no bytecode). The Hyperliquid Bridge2 and Circle CCTP destinations are verified contracts. The material trust issue is the Safe -> EOA -> HyperCore path: once the Safe releases funds, its 3-of-5 approval no longer governs them; control follows the EOA and HyperCore account keys.
• D2's disclaimer page states that the V0 sub-vault architecture is managed through an Anchorage Digital Porto wallet operated by a licensed Approved Investment Manager, and that V0 trader permissions are enforced by the Porto wallet's policy engine rather than by smart contract. This is a team representation; it is not observable onchain.
• The dgnHYPE Safe and the trader-role EOA are frequent targets of address poisoning. Lookalike addresses send zero-value and fake-"USDC" transfers that mimic operational EOA 1, EOA 2, and the trader-role EOA (e.g., a fake-token transfer from lookalike 0x0c68973c41ba3b60f463433d54036182f22582d0). No real USDC transfer to a lookalike address was found in the reviewed history. The Safe's unrestricted transfers to EOAs are therefore also exposed to signer address-verification errors.

Control concentration: The dgnHYPE vault's owner() is the same EOA (0x0E8c0470773c65498F438cac380648B314399A46) that owns the HYPE++ vault, so a single onchain EOA controls both vaults (D2 states this is an institutional MPC/HSM custody wallet; not verifiable onchain). dgnHYPE is a different contract: its verified source is VaultV0 (codehash differs from the HYPE++ VaultV1Whitelisted vault), and whitelistBalance()/whitelistAsset() do not exist on it (they revert). Its withdraw/redeem are still gated by onlyWhitelisted, but VaultV0's modifier is a pure require(whitelisted[msg.sender]) with no holder-balance branch. So the blacklist path applies to dgnHYPE: the owner can remove its sole holder, the HYPE++ trader. The setWhitelistBalance(uint256.max) balance-gate path does not exist there. Because the HYPE++ trader holds 100% of dgnHYPE supply, blocking dgnHYPE redemptions would trap ~69.27% of HYPE++ assets (~$6.00M) inside the nested strategy.

Accessibility

• Deposit and mint are available only during the funding phase, only while not custodied, and only for whitelisted users or users holding more than whitelistBalance of whitelistAsset.
• Current whitelistAsset is USDC and whitelistBalance is 1,000,000 base units (1 USDC), meaning users with more than 1 USDC can satisfy the holder branch of onlyWhitelisted().
• Withdraw and redeem are also gated by onlyWhitelisted() — verified against the verified source. All four functions (deposit, mint, withdraw, redeem) share the same modifier, which is require(whitelisted[msg.sender] || IERC20(whitelistAsset).balanceOf(msg.sender) > whitelistBalance). Because of the holder branch, setWhitelistStatus(user, false) alone does not block a user who still holds more than whitelistBalance (currently >1 USDC) of whitelistAsset — they continue to satisfy the modifier and can withdraw. The reliable block is setWhitelistBalance(type(uint256).max), which disables the holder branch for everyone. See § Critical Risks.
• Withdrawals are also blocked while custodied or during an active epoch.
• Current maxDeposits is 10,000,000 USDC, and current totalDeposits is 8,662,163.870361 USDC. dgnHYPE maxDeposits is 8,000,000 USDC.
• HYPE++ MAX_EPOCH_DURATION() is 315,360,000 seconds (10 years), so the contract does not meaningfully bound the epoch length the owner can schedule.

Token Mint Authority

Mint mechanism: ERC-4626 deposit/mint. HYPE++ shares are minted by deposit() or mint() only when USDC is transferred into the vault. There is no privileged MINTER_ROLE on the HYPE++ vault.

Mint requires backing: Yes at the HYPE++ vault level. deposit() and mint() route through OpenZeppelin ERC-4626 mechanics and require underlying asset transfer in the same transaction. This does not remove trading-loss risk after funds are custodied, and the share price after each epoch equals whatever the trader returns.

Per-address mint authority (verified onchain on October 12, 2026, from token contract 0x75288264FDFEA8ce68e6D852696aB1cE2f3E5004):

Address	Can Mint	Can Burn	Role / Mechanism	Notes
Any user satisfying onlyWhitelisted() during funding	Yes	Yes, via redeem/withdraw after epoch	ERC-4626 deposit/redeem	Requires USDC transfer for mint; redeem is blocked while custodied or during epoch
0x0E8c0470773c65498F438cac380648B314399A46	No direct unbacked mint	No	Vault owner	EOA can set whitelist parameters, deposit caps, and epoch schedule
0x8CaBD8b787e8c69C5f24091cFDA197fF570345B3	No direct unbacked mint	No	Trader	Can custody and return funds; the returned amount sets NAV, and trading losses are borne by vault users

Rate limits / supply caps: Current maxDeposits is 10,000,000 USDC.

Backing check at mint time: Atomic at the HYPE++ vault level. Collateral must transfer into the vault on mint/deposit.

Collateralization

HYPE++ is not overcollateralized. It is a share token over an actively managed USDC strategy. The top-level HYPE++ accounting reconciles to direct USDC, Aave aUSDC, and dgnHYPE shares, but the system is not equivalent to a passive collateral vault:

• While custodied, the vault's totalAssets() is the stored custodiedAmount, not a live mark-to-market of all current trader positions.
• The verified source comments on returnFunds() state that losses may be sustained during trading and investors suffer the loss.
• HYPE++ depends on dgnHYPE for 69.27% of reported assets, creating recursive D2 strategy exposure. The remaining 30.73% is USDC held directly or in Aave V3 by the contract-constrained HYPE++ trader.
• The trader's allowed token list contains 32 tokens (including volatile assets: WETH 0x82aF49447D8a07e3bd95BD0d56f35241523fBab1, WBTC 0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f, ARB, GMX, GRAIL, PENDLE, LINK, wstETH, and old bridged USDC.e 0xFF970A61A04b1cA14834A43f5dE4533eDBBD5CC8) and the allowed spender list contains 30 addresses, including major Arbitrum DeFi venues and D2 strategy vaults. Both counts are unchanged at the snapshot.
• dgnHYPE's trader() is a 3-of-5 Safe holding 3.41M USDC directly against 6.00M reported totalAssets(); 2.60M USDC was forwarded on October 12, 2026 to operational EOA 1 and on to HyperCore. The Safe is a standard Safe with no onchain guardrails: 3-of-5 signers can call execTransaction to send assets to any address. Unlike the HYPE++ trader OMS, which is constrained to 32 pre-approved tokens and 30 venues, the dgnHYPE Safe has unrestricted custody over 69.27% of HYPE++ assets.
• HyperCore holdings in the operational accounts include leveraged perpetual positions on HYPE, BTC, and ETH. Nothing onchain attributes them to dgnHYPE.

Provability

Top-level HYPE++ accounting is partially provable:

• totalAssets(), custodiedAmount(), direct USDC balances, Aave aToken balances, dgnHYPE balances, and dgnHYPE totalAssets() are onchain.
• HYPE++ does not need an offchain price oracle for the top-level USDC + aUSDC + dgnHYPE share accounting.
• End-to-end position risk is not transparent from a single call because nested dgnHYPE is custodied by a Safe and reports stored custodied accounting while active.
• Arbitrum transfers expose the path from dgnHYPE to its Safe, through operational EOAs, and into HyperCore via Bridge2 or Circle CCTP, plus the CCTP return path. HyperCore account balances are visible through Hyperliquid's API, but those accounts are not attributed to a specific vault, so no complete cross-venue NAV can be built.
• Epoch NAV is whatever amount the trader returns. In HYPE++ epoch 22 the gain was credited by transfers from the trader-role EOA (sourced via the dgnHYPE Safe from an unidentified EOA) rather than generated by recorded trader activity. Depositors therefore rely on D2's offchain books for PnL attribution.
• D2 docs state positions are generally onchain-verifiable but disclose exceptions for Flowdesk OTC trades and partial verifiability of Flowdesk collateral. No Flowdesk exposure was proven for HYPE++, but the disclosure is relevant to D2's strategy model.

Liquidity Risk

Exit liquidity is restricted by epoch state rather than by a normal liquid secondary market. HYPE++ withdrawals/redeems are unavailable because custodied() = true and epoch 23 is scheduled to end on January 15, 2027, about 95 days after funds were custodied and 105 days after trading started. Users can only redeem after the trader returns funds and the vault is out of epoch. The next exit window is therefore more than three months away and depends on the trader returning funds.

Epoch lengths vary: epoch 21 ran ~72 days of trading, epoch 22 ~8 days, and epoch 23 is scheduled for ~105 days. The owner EOA sets each schedule, and the 10-year MAX_EPOCH_DURATION gives no practical contract bound. Historical funding windows did process large exits: ~7.45M USDC was withdrawn between September 19 and October 2, 2026.

No meaningful onchain DEX liquidity for HYPE++ was identified. The primary exit path is vault redemption after epoch completion, subject to returned assets and any trading PnL.

Centralization & Control Risks

Governance

The largest risk is centralization:

Custody-wallet representation (team): D2 states that the two operational addresses — the vault owner 0x0E8c0470773c65498F438cac380648B314399A46 and the trader admin/executor/fee-receiver 0x7ab129978091DEE65A319c5FC728818D73221999 — are institutional MPC/HSM custody wallets, not single-key EOAs. The described controls are biometric authentication, quorum signing, distributed shards/HSM, and policy engines that gate operational and administrative calls with defined thresholds and allowed initiators. None of this is observable onchain (both addresses hold no bytecode); D2 discloses it to institutional/fund LPs under NDA, so it is recorded here as a team representation rather than an independently verifiable fact. It does not change the onchain control surface: those addresses hold unilateral owner/admin/executor/fee-receiver powers with no onchain timelock.

• HYPE++ vault owner is an EOA. D2's Security docs state that "the vault owner default is a 4/7 multi-sig"; HYPE++ does not follow that default.
• The owner EOA can call startEpoch(), setMaxDeposits(), setWhitelistAsset(), setWhitelistBalance(), transferOwnership(), setWhitelistStatus(), setWhitelistStatuses(), and renounceOwnership().
• Critical: The owner can block all withdrawals via two one-transaction paths:
  1. setWhitelistStatus(user, false) / setWhitelistStatuses([...], [false,...]) — removes specific users from the whitelist mapping for withdraw/redeem (not just deposit/mint). On HYPE++ this only bites users who do not independently satisfy the holder branch, so to block a target it must be paired with a raised whitelistBalance; on dgnHYPE (VaultV0, no holder branch) it is fully effective on its own.
  2. setWhitelistBalance(type(uint256).max) — no user can hold more than uint256.max tokens, so the holder branch can never pass and every non-whitelisted withdraw()/redeem() reverts. One transaction, zero enumeration, blocks every shareholder indiscriminately. (This selector exists on the HYPE++ VaultV1Whitelisted vault, not on the dgnHYPE VaultV0.) The onlyWhitelisted() modifier gates all four functions (deposit, mint, withdraw, redeem) on both vaults — verified against verified source. On HYPE++ (VaultV1Whitelisted) the modifier includes the balanceOf > whitelistBalance holder branch; on dgnHYPE (VaultV0) it is a pure whitelisted[msg.sender] mapping check.
• The HYPE++ vault is NOT behind a proxy. This means the vault logic cannot be upgraded, but ownership can be transferred at any time via transferOwnership(). No OwnershipTransferred event was emitted on either vault since August 1, 2026.
• HYPE++ trader DEFAULT_ADMIN_ROLE holders are the D2 Vault MS and the trader-role EOA. EXECUTOR_ROLE holders are the same two addresses. The full RoleGranted/RoleRevoked history contains only the November 19, 2024 deployment events (factory roles granted and then revoked).
• The trader-role EOA also receives trader fees via feeReceiver(). performanceFeeRate() is 20% and managementFeeRate() is 0.
• The D2 Vault MS is a 4-of-7 Safe, but there is no onchain timelock on trader role changes or vault owner actions.
• dgnHYPE vault has the same EOA owner as HYPE++, further concentrating control. dgnHYPE is a VaultV0 (distinct bytecode) whose withdraw/redeem are also onlyWhitelisted, but with no holder-balance branch. Blacklisting its sole holder (the HYPE++ trader) via setWhitelistStatus therefore blocks redemptions; the setWhitelistBalance(uint256.max) path does not exist on VaultV0. A dgnHYPE-level block would trap ~69.27% of HYPE++ assets (~$6.00M).
• The dgnHYPE Safe is a 3-of-5 Safe (threshold and owner count unchanged at the snapshot).

The trader contract is a standalone selector router (code size ~4.2KB; EIP-1967 implementation slot zero) that delegatecalls modules based on msg.sig. The constructor wires selectors to module targets. The trader uses solidstate AccessControl (which, like OpenZeppelin's, is not enumerable — getRoleMemberCount and getRoleMember are unavailable), so role-holder enumeration requires scanning RoleGranted/RoleRevoked events. Operationally, this gives the executor a broad DeFi action surface, bounded by the strategy's allowed tokens/spenders/modules, but still much more discretionary than a passive vault.

Programmability

The strategy is manual and custodial for most of its capital:

• Vault deposit/withdraw rules are programmatic.
• Trading execution is manual or offchain-directed. In the HYPE++ trader it runs through executor role calls into the OMS. In dgnHYPE (69.27% of assets) it runs through Safe transactions, operational EOAs, and HyperCore accounts with no contract-level constraints.
• Epoch start/end scheduling is owner-controlled, with no practical maximum duration.
• NAV crystallizes at whatever amount the trader returns. Epoch 22 showed that PnL can be credited by discretionary EOA transfers rather than recorded trading.

The design suits an active derivatives/managed strategy product, but it scores poorly under a Yearn-style risk framework because users rely on D2 operators to trade safely, report PnL honestly, and return funds.

External Dependencies

Dependencies include:

• Arbitrum One as the execution chain. L2BEAT lists Arbitrum One as a Stage 1 optimistic rollup and notes upgrade/security-council and sequencer-related trust assumptions.
• Circle/Arbitrum USDC as the base asset.
• D2's nested dgnHYPE strategy (69.27% of assets).
• Hyperliquid/HyperCore for spot and derivatives execution, reached from the dgnHYPE Safe through operational EOAs and then Hyperliquid Bridge2 or Circle CCTP.
• Circle CCTP (HyperCore extension outbound; CCTP V2 mints on return) as the main USDC transport between Arbitrum and HyperCore.
• Aave V3 Arbitrum (19.18% of HYPE++ assets via aArbUSDCn at the snapshot).
• Anchorage Digital Porto policy engine for V0 sub-vault operations (team-disclosed; not observable onchain).
• Broad Arbitrum DeFi venues approved in the trader's allowed spender list, including Aave, 1inch, GMX/Camelot-style modules, and D2 strategy contracts.
• Offchain operator process for strategy decisions.

Operational Risk

D2 documentation covers architecture, epochs, security process, strategy philosophy, vault-owner policy, and audit links. D2 also discloses BVI approved asset manager language and a Marshall Islands DAO for frontend hosting. D2 states that a BVI Financial Services Commission-approved investment manager carries out discretionary management of the HYPE++ strategy, including the dgnHYPE allocation sleeve, and is subject to fiduciary duties under that regime. Where the strategy takes OTC exposure, D2 says that regulated entity is the ISDA counterparty facing the desks. This is recorded as a team representation; it does not change the onchain custody mechanics described above.

Operational gaps remain:

• The HYPE++ vault owner is an EOA, contradicting D2's own documented 4/7-multisig default. No D2 documentation reviewed explains this vault-specific ownership choice or states whether ownership will be transferred (D2 states this address is an institutional MPC/HSM custody wallet — see Governance).
• The public docs reviewed do not identify the EOA holding trader admin/executor/fee-receiver roles (D2 states it is an institutional MPC/HSM custody wallet — see Governance).
• D2's GitBook no longer publishes the strategy contract list or the multisig list, reducing public mapping of strategy addresses and signer sets.
• No public bug bounty with payout terms was found.
• Nested dgnHYPE backing is only partially transparent: the Safe held 3.41M USDC against 6.00M reported totalAssets(), with the balance forwarded to HyperCore accounts that are not publicly attributed.
• At least three operational EOAs sit between the dgnHYPE Safe and HyperCore. No public documentation reviewed identifies those EOAs, their key-management policy, or their recovery process. D2 represents the V0 path as operated through an Anchorage Digital Porto wallet by its regulated investment manager; this is a legal/policy layer, not an onchain control.
• HYPE++ epoch 22 PnL was credited via transfers from the trader-role EOA that originated outside the vault and trader accounting path.
• The Safe and trader-role EOA receive persistent address-poisoning traffic; the Safe's unrestricted transfer model relies on signers verifying destination addresses manually.

Monitoring

Recommended monitoring frequency: hourly during active epochs, daily outside active epochs.

Monitor these contracts and values:

• HYPE++ vault 0x75288264FDFEA8ce68e6D852696aB1cE2f3E5004
  • custodied(), custodiedAmount(), totalAssets(), totalSupply(), totalDeposits(), maxDeposits(), getCurrentEpochInfo(), getCurrentEpoch(), whitelistBalance(), whitelistAsset()
  • Events: EpochStarted, FundsCustodied, FundsReturned, NewMaxDeposits, NewWhitelistStatus, OwnershipTransferred
• HYPE++ trader 0x8CaBD8b787e8c69C5f24091cFDA197fF570345B3
  • hasRole(DEFAULT_ADMIN_ROLE, account) and hasRole(EXECUTOR_ROLE, account) for known holders
  • The trader uses solidstate AccessControl (not enumerable); getRoleMemberCount and getRoleMember are unavailable. Monitor RoleGranted/RoleRevoked events for role-holder enumeration.
  • Events: RoleGranted(bytes32,address,address), RoleRevoked(bytes32,address,address)
  • getAllowedTokens(), getAllowedSpenders(), feeReceiver(), performanceFeeRate(), managementFeeRate()
  • Direct USDC balance and Aave aArbUSDCn balance.
  • Inbound USDC transfers from non-vault addresses (especially the trader-role EOA) before returnFunds().
  • Note: setFeeReceiver() and fee-rate changes go through setFeeRates(uint256,uint256) (both gated by DEFAULT_ADMIN_ROLE, verified onchain).
• Vault owner EOA 0x0E8c0470773c65498F438cac380648B314399A46
  • All outbound transactions to HYPE++ vault, dgnHYPE vault, and any vault factory.
  • Note: This EOA owns both HYPE++ and dgnHYPE vaults.
• Trader role EOA 0x7ab129978091DEE65A319c5FC728818D73221999
  • All role/admin/trading transactions and USDC flows to/from the HYPE++ trader and the dgnHYPE Safe.
• D2 Vault MS 0xB2fEDed045F3fd9FcCCF8E7e95729c4182916CE0
  • Safe: getThreshold(), getOwners(); monitor AddedOwner, RemovedOwner, ChangedThreshold events.
  • Trader role changes via this Safe.
• dgnHYPE vault 0x64167cd42859F64cfF2Aa4B63c3175cceF9659dd
  • totalAssets(), totalSupply(), custodied(), custodiedAmount(), trader(), owner(), getCurrentEpochInfo()
• dgnHYPE Safe 0x155d0B27B754ebC664aeD565945C1AaEa91966fb
  • getThreshold(), getOwners(); monitor threshold/owner changes and direct USDC balance against reported custodiedAmount.
  • All outbound USDC transfers; compare each destination against the known operational EOAs (exact 40-character match, given address-poisoning lookalikes).
• Hyperliquid operational EOAs 0x0C684f333A7e120bce61383DA670bbB0157e82d0, 0x11A691612BD108e57cC04ea42B006C9CB1ff006A, and 0x4c3d48cbe2186beeafecc6723630ab8eda4117fc
  • Monitor every inbound transfer from the dgnHYPE Safe, subsequent Bridge2/CCTP deposits, unexpected destinations, and whether funds return before epoch settlement.
  • HyperCore clearinghouseState / spotClearinghouseState via the Hyperliquid info API: account value, open perpetual notional, and leverage.
• Hyperliquid Bridge2, Circle HyperCore CCTP extension, and Circle MessageTransmitterV2
  • Monitor deposits/mints attributable to the operational EOAs and bridge/validator/CCTP incidents.

Suggested alert thresholds:

• Any vault OwnershipTransferred event.
• Any NewWhitelistStatus event with status false targeting a non-zero shareholder (blacklisting of existing depositors blocks withdrawal), and any whitelistBalance() change.
• Any trader RoleGranted or RoleRevoked event.
• Any setMaxDeposits() change greater than 10%.
• Any new epoch with a scheduled trading period materially longer than 30 days (epoch 23 is ~105 days).
• Any mismatch where HYPE++ trader direct USDC + Aave aUSDC + dgnHYPE-derived assets fail to reconcile to HYPE++ totalAssets() by more than 1%.
• Any dgnHYPE totalAssets() drop greater than 2% between checks.
• Any dgnHYPE Safe transfer to an address other than the dgnHYPE vault or a known operational EOA, or any operational-EOA transfer to a destination other than the identified Hyperliquid/CCTP routes.
• Any inbound transfer to the HYPE++ trader from the trader-role EOA or another non-vault address in the 24 hours before returnFunds().
• Funds not returned within 72 hours after the scheduled epoch end (January 15, 2027 08:00 UTC for epoch 23).

Appendix: Contract Architecture

User USDC
   |
   v
[HYPE++ Vault / VaultV1Whitelisted]  (non-upgradeable, no proxy)
   - ERC-4626 share token
   - owner: EOA 0x0E8c... (Ownable, transferOwnership available)
   - deposits only during funding window
   - withdrawals only after epoch and when not custodied
   - trader is immutable (set at construction, no setTrader function)
   |
   | custodyFunds() during epoch (only trader can call)
   v
[HYPE++ Trader / Strategy OMS]  (selector router, not a proxy, ~4.2KB)
   - delegatecalls modules by msg.sig; AccessControl (not Enumerable)
   - DEFAULT_ADMIN_ROLE: Vault MS + EOA 0x7ab1...
   - EXECUTOR_ROLE: Vault MS + EOA 0x7ab1...
   - fee receiver: EOA 0x7ab1... (performanceFeeRate = 20%)
   - allowed tokens/spenders define trading surface
   |
   +--> Direct USDC balance (~1.00M, 11.56%)
   |
   +--> [Aave V3 aArbUSDCn] (~1.66M, 19.18%)
   |
   +--> [dgnHYPE Vault shares] (~4.41M shares = 100% of supply; ~6.00M USDC, 69.27%)
          |
          v
        [dgnHYPE Vault / VaultV0]  (non-upgradeable, no proxy)
          - owner: EOA 0x0E8c... (same EOA as HYPE++ vault owner)
          - trader: 3-of-5 Safe 0x155d...
          |
          v
        [dgnHYPE Trader / 3-of-5 Safe]
          - reports ~6.00M USDC totalAssets (custodiedAmount)
          - unrestricted Safe execution (team: Anchorage Porto policy engine)
          - ~3.41M real USDC directly observed; 2.60M forwarded Oct 12, 2026
          |
          +--> [Operational EOA 1 0x0C68...] --USDC--> [Bridge2 / Circle CCTP HyperCore ext.]
          |
          +--> [Operational EOA 2 0x11A6...] --USDC--> [Bridge2 / Circle CCTP HyperCore ext.]
          |
          +<-- [Operational EOA 1 / EOA 3 0x4c3d...] <--CCTP V2 mint-- [HyperCore withdrawals]
                                                     |
                                                     v
                                               [HyperCore trading accounts]

Governance / control:

[EOA 0x0E8c...] --owns--> [HYPE++ Vault]
[EOA 0x0E8c...] --owns--> [dgnHYPE Vault]
[Vault MS 4/7]  --DEFAULT_ADMIN+EXECUTOR--> [HYPE++ Trader]
[EOA 0x7ab1...] --DEFAULT_ADMIN+EXECUTOR--> [HYPE++ Trader]
[EOA 0x7ab1...] <--feeReceiver-- [HYPE++ Trader]

---

Reassessment Triggers

• Governance-based: Reassess immediately if vault ownership transfers, trader roles change, Safe threshold/signers change, or a timelock is added.
• Epoch-based: Reassess if funds are not returned within 72 hours after the scheduled epoch end (January 15, 2027 08:00 UTC for epoch 23), if the next epoch's trading period exceeds 30 days, and after epoch 23 settles.
• Funds-based: Reassess if HYPE++ totalAssets() falls by more than 2% outside expected fee/PnL reporting, or if reconciliation between HYPE++ direct assets, Aave aUSDC, and dgnHYPE-derived assets fails by more than 1%.
• Dependency-based: Reassess if dgnHYPE strategy composition changes, if dgnHYPE experiences losses, if a new operational EOA appears, if funds route to a new bridge/custodian, or if Flowdesk/OTC exposure is introduced.
• Incident-based: Reassess after any D2, Arbitrum, Hyperliquid, Circle USDC/CCTP, Aave, GMX, 1inch, Camelot, or nested D2 strategy incident.