AUREUS

New in v1.5. All operator actions are now performed through a dedicated, audited admin dashboard that runs as a Safe App inside the protocol multisig. Operations that previously required hand-encoding raw contract calldata — closing an epoch, depositing rewards, processing redemptions, pausing — are now gated, previewed against live chain state, and dispatched through the Safe transaction queue for 2-of-3 signing. The reward split, NAV rate limit, and redemption fees described below were all re-verified directly against the deployed mainnet contracts during this work (see §13).

§1Live contract addresses (Arbitrum One)

Implementation contracts (behind UUPS proxies above)

§2Live wallet addresses (Arbitrum One)

All wallets below are publicly trackable on Arbiscan. Their roles and authorities are defined contractually and operationally.

Governance

The third signer is an external trusted community member; their address is held off-chain to preserve their privacy. A fourth cold-storage signer will be added in the first 30 days, taking the configuration to 2-of-4.

The protocol multisig has been verified on-chain as the owner() of both the Forge and the AureusRedemption contract, so every owner-gated operation routes through the 2-of-3 Safe.

Capital flow wallets (ReservesOracle tracked addresses)

These four addresses feed ReservesOracle.getHardReservesUsd(). Members can query that view at any time to see the protocol's verified on-chain reserves.

Reward destination wallets (V2 epoch split)

All three reward destination wallets are confirmed set on-chain. The split is enforced in contract storage as mloShare = 500, operationsShare = 500, recoveryShare = 1000 basis points, with stakers receiving the 10000 − 500 − 500 − 1000 = 8000 bps residual — i.e. exactly 80 / 5 / 5 / 10.

Infrastructure wallets

§3How AUREUS works

The basics

• AUR is an ERC-20 token on Arbitrum One. Buy it by depositing USDC into the Forge contract.
• Initial NAV: $1.00 USDC per AUR. NAV is recalculated and published every two weeks at epoch close.
• Staked AUR earns USDC distributions at each epoch close, paid out of strategy profits.
• Three exit paths: end-of-epoch (2% fee), ASAP (5% premium fee), peer-to-peer OTC sale (0.5% fee).

Minting AUR

A member sends USDC to the Forge. The Forge calculates AUR to mint at the current NAV:

AUR minted = USDC deposited / current NAV

Newly minted AUR is auto-staked into the Forge contract by default (recommended path; the dashboard handles this). It enters a pending state for one epoch — this prevents members from depositing immediately before a profit distribution to capture rewards they didn't fund. At the next epoch close, the pending AUR becomes fully active and starts earning.

Power users can opt out of auto-stake at the contract level and receive AUR directly to their wallet (transferable immediately, but not earning epoch rewards until manually staked).

Earning yield

Strategy returns are deposited into the Forge via depositRewards() between epochs. At each closeEpoch() call, the accumulated reward pool is computed and split per the standard schedule. The reward pool for an epoch is derived on-chain as:

owedToStakers = (totalInvestedAmount × accUsdPerShare / 1e18) − totalClaimedRewards
rewardPool    = ForgeUSDCBalance − owedToStakers

owedToStakers is the float already credited to stakers but not yet claimed; subtracting it ensures the new pool never re-distributes money that already belongs to members. The pool is then split:

• 80% to staked AUR holders — credited via the internal accUsdPerShare accumulator. Members can claim their accumulated USDC at any time without affecting their stake. Rounding dust accrues to stakers, not operators — stakers take the residual.
• 5% to Team (MLO Payments wallet)
• 5% to Operations (infrastructure costs, keeper hosting, audit funds)
• 10% to Recovery Fund — until cumulative Recovery distributions reach $350K, after which the 10% redirects to the Team wallet (taking Team's effective share to 15%).

Redemption fees flow into the Forge contract and pool with strategy profits at the next epoch close — they follow the same 80/5/5/10 split.

Exiting positions

End-of-Epoch (EOE) redemption — submit a redemption request, processed at the next epoch close at that epoch's settled NAV. Fee: 2%. Operator settles via the multisig.

ASAP redemption — request immediate processing at the current hard NAV. Fee: 5%. Use when you can't wait for the next epoch.

OTC sale — list AUR for sale at any price you choose; another member buys it directly. Fee: 0.5% (collected by the protocol as OTCv2 trading fee). Settles trustlessly without operator involvement.

A user may set a minUsdcOut floor on a redemption request; if NAV moves against them between request and processing, the request is rejected rather than filled at a worse price. All three paths preserve mass at the contract level: USDC and AUR move atomically per the redemption tier's terms.

Reserve transparency

The protocol's NAV per AUR is computed on-chain from the ReservesOracle:

hardReserves = sum of USDC balances at the four tracked addresses
             + pending Hyperliquid bridge withdrawals (per tracked address)

hardNav = hardReserves / totalSupply(AUR)

This is the "hard floor" — verifiable from on-chain reads alone, no operator trust required.

A separate soft layer reports live Hyperliquid trading account state. The keeper posts this at minimum every 24 hours. The soft layer is capped at 10× the hard reserves to prevent runaway misreports. The dashboard surfaces both hard and soft views.

§4Controlled growth phase (first 90 days)

To match the soft launch posture and protect early members, deposits are capped during the first 90 days:

• Total deposits capped at $250,000 USDC in aggregate
• Per-member positions capped at $50,000 USDC

These caps are enforced operationally, not contractually. The Forge accepts deposits permissionlessly; the multisig monitors aggregate exposure and per-member positions and will use its pause authority to gate access before either threshold is breached.

After 90 days (Friday September 4, 2026 — three months from public launch), the caps will be reviewed against operational performance, audit progress, and community input. They may be raised, lowered, or removed by multisig action. The intent is to scale deposits in line with the protocol's demonstrated reliability, not to maintain caps indefinitely.

§5Epoch schedule

Bi-weekly cadence is enforced contractually: epochInterval = 14 days. The first epoch is intentionally short (~5–6 days) to align the public schedule with Friday 09:00 KST closes from the start.

The launch is sequenced so the operator unpauses, mints with personal capital, and validates a real first epoch close before any public announcement — the protocol's first live distribution happens with operator funds, not member funds.

§6Operator authority — what the multisig can and cannot do

The multisig CAN

• Unpause and pause the Forge
• Set the Forge's allowed deposit tokens
• Call closeEpoch() with a new NAV (subject to a 15% maximum change per close)
• Process EOE and ASAP redemption requests (individually or in batches)
• Set tracked addresses on ReservesOracle (subject to 24-hour timelock)
• Configure reward destination wallets if any need to change
• Sweep balances between the multisig and HL Strategies wallets for trading operations
• Use Aureus.setMinter to re-point AUR's minter — intended to be renounced via Ownable.renounceOwnership() once operational confidence is established (operator-discretionary timing, will be publicly announced)

The multisig CANNOT

• Modify member-held AUR balances (no transfer hooks, no blacklist, no force-burn)
• Change the reward distribution percentages (80/5/5/10 is set in contract storage; verified on-chain)
• Change NAV by more than 15% in a single closeEpoch call (rate limit in ForgeV2)
• Make ReservesOracle changes that take effect before 24 hours pass
• Take more than the 5% (or post-Recovery 15%) Team allocation from any single epoch
• Withdraw or modify the Recovery Fund allocation before the $350K threshold
• Mint AUR without depositing corresponding USDC into the protocol (while the minter remains the Forge contract)

All multisig actions are public on Arbiscan in real time, and every operator action is now dispatched through the admin dashboard's Safe queue (see §12), where the encoded calldata is reviewable before signatures are collected.

§7Reserves architecture

Capital flows across three layers, all tracked or accounted for in NAV:

Layer 1 — Operational (Arbitrum, immediately liquid)

• Forge proxy — reward accumulator, claimable staker balance
• AureusRedemption — redemption float in flight

Layer 2 — Cold Arbitrum (governance custody)

• Multisig Safe — forge mint USDC and OTC spread destination; capital staged before sweep to trading
• HL Strategies wallet — capital sitting between multisig sweep and Hyperliquid bridging

Layer 3 — Trading (Hyperliquid)

• HL Strategies sub-accounts — active trading capital across strategies (Aphelion HL, Soomario Strategies, etc.)
• Hyperliquid bridge — pending bridge withdrawals (counted per Layer 2 address via the bridge contract)

The ReservesOracle queries all four tracked addresses on Layer 1+2 directly, and the Hyperliquid bridge for any pending withdrawals associated with those addresses. Layer 3 active trading state is reported by the keeper bot as the soft layer.

§8Strategy performance (pre-launch reference)

The strategies AUREUS deploys are not new — they have been running on operator capital before launch and have published live track records at the product level. AUREUS deploys capital across Soomario Strategies including Elite (HYPE/AVAX directional), Aphelion (multi-signal long-bias accumulator), and provisionally Rotation (tokenized equity rotation, live on Solana) as its live track record builds.

Each underlying strategy has its own product page, dashboard, and individual track record published at soomariostrategies.com/products. The aggregate AUREUS NAV is reported on-chain at each bi-weekly epoch close; backtest or attribution figures for individual strategies are documented on those product pages and in the strategy whitepapers, not in this protocol whitepaper.

Past performance does not guarantee future results. Epochs can close at flat or negative NAV.

§9Audit posture

AUREUS launched with internal RED_TEAM review (three passes, all findings dispositioned with regression tests; 81 tests passing in test/AureusV2.t.sol). The Sepolia retest cycle validated the architecture end-to-end before mainnet broadcast, including catching one deploy-script gap that would have bricked the first epoch close — exactly the catch the retest exists for.

Formal external audit (Sherlock, Trail of Bits, OpenZeppelin, or equivalent firm) is planned for Months 2–6 post-launch. The controlled-growth phase ($250K aggregate cap) is structured so that aggregate Member exposure during the audit-pending window is structurally bounded.

This sequence — internal red team → live deploy → external audit during operations — is a deliberate choice. It avoids the trap of paying for an audit on code that subsequently changes during real-world stress testing, and lets the audit be informed by actual operational data rather than only theory.

§10Risks and caveats

This section is not exhaustive; deposit only what you can afford to lose.

• Smart contract risk. RED_TEAM passed three times but is not a substitute for external audit. The 90-day caps mitigate aggregate exposure.
• Operator key risk. The multisig holds significant authority. 2-of-3 reduces single-key compromise risk; the upgrade to 2-of-4 in the first 30 days reduces it further.
• Trading strategy risk. Profits are not guaranteed; epochs can close at flat or negative NAV. The 15% per-close rate limit bounds single-epoch reporting risk but not actual loss.
• Hyperliquid platform risk. Trading happens on Hyperliquid; HL platform outages, bugs, or insolvency would affect AUREUS reserves.
• Bridge risk. Capital in transit between Arbitrum and Hyperliquid is exposed to bridge-contract risk.
• Strategy concentration risk. The underlying strategies share venue (Hyperliquid) and broadly correlated asset universes. Diversification across strategies reduces single-strategy risk but does not eliminate correlated drawdowns in adverse market regimes.

§11How to participate

When the multisig signs unpause() (publicly observable on Arbiscan) and the protocol is publicly announced:

1. Deposit USDC. Visit the dashboard, connect a wallet (Rainbow / WalletConnect / Coinbase Wallet supported), approve USDC for the Forge proxy, deposit any amount up to the per-member cap.
2. Hold AUR. Your staked AUR earns the staker share of each epoch.
3. Claim epoch rewards. After each Friday 09:00 KST close, your claimable USDC balance updates. Claim at your convenience.
4. Exit via EOE / ASAP / OTC when you want to redeem AUR for USDC.

All four actions are transactions you sign with your own wallet on Arbitrum One. The protocol never has custody of your AUR or your claimed USDC.

§12Operations & the admin dashboard

Every recurring operator action is performed through a purpose-built admin dashboard that runs as a Safe App inside the protocol multisig (app.safe.global). The dashboard does not hold keys and cannot move funds on its own — it constructs transactions, previews their on-chain effect, and submits them to the Safe transaction queue, where they still require the full 2-of-3 signature threshold to execute. Nothing is ever sent via a single externally-owned account.

What the dashboard surfaces (read-only console)

• Current NAV (hard layer) and the Forge's reward-pool balance
• Multisig and HL Strategies USDC balances
• Pending redemption queue (EOE / ASAP requests)
• Pause state and next-epoch countdown
• A live Authorization check confirming the Safe is the on-chain owner of the Forge and Redemption contracts — surfaced so any future ownership change (including a renounce) is visible before any action is attempted

What the dashboard can dispatch (each gated and previewed)

• Pause / Unpause — a two-click confirm; unpause is recognized as the public go-live action and is gated accordingly.
• Deposit rewards — bundles approve + depositRewards into a single Safe MultiSend so the allowance and the deposit are signed together. Enforces the contract's 1-USDC minimum and a "cannot exceed multisig balance" cap before the transaction can be armed.
• Close epoch — the highest-stakes action. The dashboard mirrors the contract's exact integer math to preview the new NAV against the ±15% rate limit, the reward pool (ForgeUSDC − owedToStakers), and the full 80/5/5/10 distribution — including the Recovery-Fund redirect logic — before a signature is collected. The confirm panel displays the concrete distribution amounts so the operator signs against numbers, not an abstraction.
• Process redemptions — batches approve + processBatch into one MultiSend, previews each pending request's gross / fee / net payout (2% EOE, 5% ASAP, verified on-chain), checks per-request slippage floors, and auto-excludes any request that would revert. Partial-batch semantics are preserved: a request that fails leaves the others to process and remains retriable.

Every capital-moving action computes its preview in exact integer arithmetic (matching the contract's own math, with no floating-point rounding in any threshold), shows a confirmation panel with the concrete figures, and dispatches only through the Safe queue. The design principle throughout: the operator should always be signing against numbers they can see and verify, and no UI affordance should be able to queue a transaction the contract would reject.

§13On-chain verification (performed June 2026)

During the admin-dashboard build, the following protocol parameters were read directly from the deployed mainnet contracts and confirmed against this document. Members can reproduce every one of these reads against the addresses in §1.

The reward shares and redemption fees being verified directly from chain — rather than assumed from documentation — closed out the single largest correctness question before launch.

§14Changelog

v1.5 (June 2026) — Operations version

Added §12 documenting the admin dashboard (Safe App, read-only console, four gated write actions: pause/unpause, depositRewards, closeEpoch, processRedemptions). Added §13 with the on-chain verification table confirming the 80/5/5/10 split, 2%/5% redemption fees, 15% NAV rate limit, $350K recovery target, $1.00 launch NAV, and both contracts owned by the multisig. Corrected the §3 exit-paths line to state fees explicitly (2% EOE / 5% ASAP / 0.5% OTC) and added the minUsdcOut slippage-floor note. Added the reward-pool derivation formula (ForgeUSDC − owedToStakers) and the staker-residual rounding note. Clarified the launch sequence: operator unpauses and validates a real first epoch close with personal capital before public announcement.

v1.4 (June 2026) — Post-mainnet-deploy version

Live contract and wallet addresses populated. First epoch schedule confirmed (Fri Jun 5, 2026). Initial NAV set to $1.00 USDC per AUR. All four ReservesOracle tracked addresses live: Forge, AureusRedemption, multisig, HL Strategies wallet. The setMinter renouncement section confirms intent; timing remains operator-discretionary. Sepolia retest summary added to §9. Strategy backtest reference moved to §8 as inherited claim from AUREUS_BACKTEST.md.

v1.3 (May 2026) — Pre-deploy version

STRCx reserve removed from launch architecture; bi-weekly epochs (14-day) confirmed; multisig composition disclosed (2-of-3 at launch, 2-of-4 planned); controlled-growth-phase added ($250K / $50K caps for 90 days); restructured §10 around RED_TEAM-gated launch and formal audit deferred to Months 2–6; tracked-address set expanded to four pools post-routing of forge mint revenue to multisig; fee-economics paragraph corrected to reflect the standard 80/5/5/10 split at next close; minter authority qualified with renouncement-intent commitment.

v1.2 and earlier — Internal development versions; not published.