Non-Custodial Vault Management Schematic

---

DG** Vault – Non-Custodial Ops & Fund Safety

TL;DR

• No EOAs ever hold user funds on Arbitrum.

• Hyperliquid withdrawals are cryptographically bound to on-chain intents.

• Admins can’t move tokens; they can only call allow-listed functions.

• On-chain math caps every payout by actual L2 arrivals. The worst credible incident is delay, not loss.

---

Core Components

• DG** Vault (Arbitrum): ERC-4626-style vault; enforces solvency & batch redemptions.

• Escrow-Forwarder (Arbitrum): immutable contract that auto-forwards 100% USDC to the vault on receipt.

• Intent Registry (Arbitrum): emits BatchWithdrawalIntent(batchKey, amount, forwarder, expiry).

• Manager/Admin/NAV Safes: Gnosis Safe accounts with Guards (function allowlists), no token transfers.

• Deterministic Withdrawal Signer (off-chain): 2-of-3 MPC service; refuses to sign unless the on-chain intent matches (dest, amount, unexpired).

• Hyperliquid (HL) L1: SMA wallet (trading + vault); bridge to Arbitrum.

• Agents: Deposit Processor, Withdrawal Listener (WL), L2 Watcher (computes ΔL2).

---

2) How Funds Flow (Safe by Construction)

Deposits (high level)

1. User calls deposit on DG** Vault.

2. Processor batches and funds strategy on HL; no L2 hot-wallet custody at any point.

Withdrawals (batch MTM redemptions)

1. User calls initiateWithdrawal.

2. WL groups requests; Manager Safe emits on-chain intent with (batchKey, amount, forwarder, expiry).

3. Deterministic Signer (MPC) reads the intent and signs an HL withdraw only if:

   • destination == forwarder (immutable address),

   • amount == intent.amount,

   • intent is unexpired and unused.

4. HL bridge sends USDC to the Escrow-Forwarder on Arbitrum.

5. Escrow-Forwarder immediately sends 100% to DG** Vault (no retention, no owner).

6. Manager Safe calls confirmBatchUsdcReceived with USDC_ready = min(intent.amount, ΔL2) (ΔL2 = watcher-observed arrival).

7. Users are settled at the same batch price via confirmWithdrawalWithPnL.

---

3) Why Funds Are Safe (Security Guarantees)

A. No L2 Hot-Wallet Risk

• The “platform wallet” EOA is replaced by Escrow-Forwarder (immutable, keyless).

• Forwarder behavior: auto-forward 100% to DG** Vault.

• Anyone can call forward() if a nudge is ever needed.

B. HL Withdrawals Bound to On-Chain Intent

• The only destination is the forwarder; only the on-chain amount is signable.

• The signer has no override API. It’s MPC (2-of-3) and refuse-by-default.

C. On-Chain Spend Caps

• USDC_ready ≤ ΔL2 (actual L2 arrival) at T6A—cannot reserve more than received.

• (Optional) Enforce USDC_ready ≤ intent.amount for symmetry.

D. Admins Can’t Move Tokens

• All admin roles are Safes with Guards: they can only call:

  • Admin: confirmDeposit

  • Manager: emitWithdrawalIntent, confirmBatchUsdcReceived, confirmWithdrawalWithPnL

  • NAV: updateVaultExchangeBalance

• No ERC-20 transfers permitted from any Safe; Guards block non-allowlisted calls.

E. Replay & Idempotence

• batchKey and per-user nonces prevent double-spend and replays.

• The signer refuses repeated signatures for an already-used intent.

---

4) Roles & Responsibilities (Separation of Duties)

Plane	Tooling	Who	Powers
Trading	HL trading keys	Ops	Place/cancel orders only (no withdraw)
Settlement	MPC signer + Manager Safe	Ops + Gov/Risk + Tech (2/3)	Emit intent; sign HL withdraw only if it matches intent; confirm batch reserve + per-user settlements
Measurement	NAV Feeder Safe	Risk/Data + Tech (2/2)	Update totalAssets() (staleness bounds enforced)
Control/Audit	Safes + Guards + Logs	Governance/Audit	Policies on-chain; publish signer log roots; monitor ΔL2 vs USDC_ready

---

5) Proof Users Can Verify

• Vault wiring: on-chain event VaultWiring(vault, hlSmaPubKey, hlVaultId, forwarder).

• Intent ledger: BatchWithdrawalIntent events (batchKey, amount, forwarder, expiry).

• Signer trail: daily hash root over {batchKey, amount, dest, intentTx} (published to chain or public page).

• Forwarder receipts: Forwarded(amount) events; totals match HL withdrawal amounts.

• Reserve cap: T6A logs proving USDC_ready ≤ min(intent.amount, ΔL2).

---

6) Threat Model (Before → After)

Scenario	Before	After (DG** Vault architecture)
L2 EOA compromised	Hot funds stolen	No EOA exists; forwarder only (keyless)
HL withdrawal key phished	Withdraw anywhere/any amount	Impossible (signer only signs to forwarder for intent amount)
Over-reserve vs arrivals	Possible with operator error	Blocked (USDC_ready ≤ ΔL2)
Admin fat-finger	Token loss / wrong calls	Guarded: only allow-listed functions; no token transfers
Rogue insider	Reroute or resize funds	Cannot; at worst, induce delay, not loss

---

8) FAQs

Q: Does DG** Vault hold user funds in an operator wallet on L2? A: No. Funds land at the Escrow-Forwarder, which immediately forwards 100% to DG** Vault. No L2 EOAs.

Q: Can someone change the HL withdrawal destination? A: No. The signer will only sign to the forwarder; any other destination is rejected by code (no override API).

Q: What happens if part of the system goes down? A: Withdrawals may pause (liveness), but funds can’t be misrouted or lost. Deposits and accounting remain intact.

---