EXECUTIVE SUMMARY

In Brief

AUREUS is a tokenized fund. Members deposit USDC and receive AUR tokens that represent proportional ownership of a treasury. That treasury is deployed across systematic trading strategies on Hyperliquid, with a permanent reserve held in STRCx, a yield-bearing tokenized preferred stock. Profits are distributed to Members weekly.

AUREUS is built on Arbitrum One. It is operated by Soomario Strategies, a team with extensive experience in systematic trading and DeFi protocol operations. The protocol's distinguishing feature is a comprehensive on-chain transparency layer — a non-upgradable proof-of-reserves oracle, an append-only trade ledger, and rate-limited admin functions — that allows Members to verify the protocol's state independently and continuously.

A portion of protocol profits — 10% of every profitable epoch — routes to a Recovery Fund that supports the prior token community of the team's previous protocol. This is described in Section II.

The full Roman-treasury vocabulary used throughout this document — Aerarium, Forge, Members, Team, epoch, Recovery Fund — is explained in the Glossary.

SECTION · I

The Problem AUREUS Solves

Two practical problems exist for retail crypto investors who want access to systematic trading strategies:

Copy-trading is structurally limited. Most copy-trading platforms can only follow one wallet on one chain trading one asset class. If a strategy is multi-asset — combining crypto perpetuals with tokenized US equities, for example — copy-trading cannot express it. The signal is lost in translation.

Self-directed trading requires expertise most investors don't have. Following a trader on Twitter is not a strategy. Running a disciplined system across dozens of assets, with risk controls and position sizing rules, requires both technical skill and emotional discipline that few investors maintain over time.

AUREUS addresses both by pooling capital into a single treasury that the operator deploys across systematic strategies on the Member's behalf. The Member's position is tokenized — represented by AUR — so they hold a transferable, liquid asset rather than being locked into a long-term commitment. They earn the strategy returns through that token's appreciation and through periodic profit distributions, without making any trading decisions themselves.

The model is not novel. Tokenized funds exist. What AUREUS does differently — and what the architecture is specifically built to demonstrate — is make the fund's state visible on-chain in real time, so that the failure modes of opaque pooled vehicles become visible before they become catastrophic.

SECTION · II

The Recovery Fund

AUREUS includes a mechanism called the Recovery Fund. Ten percent of every profitable epoch routes to a labeled wallet — 0x9eC5279bf6148a0f027B7329f694B0bd00302678 — until $350,000 is reached. At that point, a snapshot is taken of NGET token balances as of a specific Arbitrum block, and the Recovery Fund is airdropped pro-rata to those addresses. After the airdrop completes, the 10% allocation redirects to the Team.

The Recovery Fund does not start at zero. It carries a seeded starting balance of approximately $3,000 — residual capital from the prior Nugget Fund's October 2025 liquidation — currently active in Soomario Elite and Aphelion strategies. The exact starting balance at AUREUS launch will reflect those strategies' performance up to that point. The wallet address above can be queried at any time to verify current balance.

The labeled wallet is currently a single-key EOA, not a multi-signature wallet. The team may migrate the Recovery Fund to a multi-signature wallet once balance crosses a meaningful threshold; if so, the migration will be publicly announced and the new address communicated before the change takes effect.

NGET is the token of a prior protocol operated by the AUREUS team. The Recovery Fund honors that prior community as AUREUS grows. The Recovery Fund participates in AUREUS strategies alongside other Member capital — it is not parked as idle USDC — which accelerates the recovery and reflects the operator's confidence in the new protocol's design.

NGET and AUREUS are otherwise entirely separate protocols. AUR is a freshly deployed ERC-20 token with a new contract address, with no shared state or storage with the existing NGET token. There is no migration between them. New AUREUS Members do not need to understand or interact with NGET in any way; the Recovery Fund operates entirely in the background from a new Member's perspective. Holders of NGET retain their NGET balances unchanged.

Why this is built into the protocol

Putting the Recovery Fund into the smart contract rather than handling it as a separate program is a deliberate design choice. It means:

  • The mechanism is auditable on-chain by anyone
  • The 10% allocation cannot be redirected without a visible protocol change
  • Progress toward $350K is publicly observable in real time
  • The recovery happens automatically once the threshold is reached, not at the operator's discretion

This is consistent with AUREUS's broader design philosophy: structural commitments encoded in code are more durable than commitments held in goodwill.

SECTION · III

How AUREUS Works

In the simplest description: Members deposit USDC, receive AUR, and earn returns through that AUR's value over time and through profit distributions paid weekly.

Minting AUR

A Member sends USDC to the Forge — the contract that mints AUR. The Forge calculates how many AUR to mint based on the current NAV per AUR:

AUR minted = USDC deposited / current NAV

The newly minted AUR enters a pending state for one epoch. This prevents Members from depositing immediately before a profit distribution to capture rewards they did not actually fund. Their AUR becomes fully active at the next epoch close.

Holding and earning

Once active, the Member's AUR earns returns in two ways:

Through epoch profit distributions. Each week, profitable strategy returns are distributed to staked AUR holders pro-rata. Members can claim distributed USDC to their wallet, or leave it in the contract to compound automatically.

Through NAV appreciation. Some portion of profits remains in the treasury, raising the NAV per AUR over time. When a Member eventually redeems their AUR, they receive USDC at the current NAV, which should be higher than when they deposited (assuming the strategies have been net-profitable).

Exiting

Three paths to exit exist, covered in detail in Section VI:

  • OTC — sell AUR to another Member through a built-in marketplace, 0.5% fee
  • End-of-epoch redemption — burn AUR for USDC at the next NAV close, 2% fee, processed within 24 hours
  • ASAP redemption — burn AUR for USDC immediately at the on-chain verified NAV, 5% fee, processed within 48 hours, subject to rate limits

Where the value comes from

The treasury holds two components, described in Section IV. The first deploys capital into systematic strategies on Hyperliquid. The second holds a permanent reserve in STRCx, which itself earns yield (currently ~11.5% APY). Both contribute to NAV growth. Strategy returns are the larger contributor in profitable conditions; STRCx is the steady floor that earns regardless of strategy performance.

SECTION · IV

The Treasury — Aerarium

The treasury — called the Aerarium, from the Roman public reserve — is split into two components in fixed proportions:

ComponentAllocationPurpose
Soomario Strategies on Hyperliquid80%Active capital, generates trading returns
STRCx Reserve20%Permanent reserve, never sold, earns ~11.5% APY

Soomario Strategies

The active 80% is deployed across Soomario Strategies — a suite of systematic trading bots operated by the AUREUS team on Hyperliquid. These include strategies covering crypto perpetuals and tokenized US equities (via Hyperliquid's HIP-3 stocks). The specific composition is dynamic and managed by the operator.

The strategies themselves are not novel inventions. They are systematic implementations of trading approaches — DCA at liquidation zones, momentum following, mean reversion, signal-based execution. What's different in AUREUS is not the strategies' design, but the fact that their state is observable on-chain through PositionLogger and verifiable through the keeper-reported reserves.

Members do not need to understand the strategies to participate. They need to understand that capital is being deployed into them, that returns and losses both flow through, and that the on-chain transparency layer makes the operator's claims about performance verifiable.

STRCx Reserve

STRCx is a yield-bearing asset issued by Backed Finance that tokenizes Strategy Inc.'s perpetual preferred stock (STRC). Strategy Inc. is the public company formerly known as MicroStrategy. The preferred stock earns variable dividends — currently ~11.5% APY at the time of writing — and its issuer's solvency is directly tied to the value and management of a large Bitcoin treasury.

AUREUS holds a permanent 20% of treasury in STRCx with a never-sell rule.

The reserve serves three purposes:

  • Floor return. Even during strategy drawdowns, STRCx continues earning dividends. This dampens portfolio volatility.
  • Redemption backstop. STRCx is liquid and verifiable through a Chainlink price feed. It backs the protocol's ability to honor redemptions even during strategy stress.
  • Long-term compounding. Because the reserve is permanent and never sold, its yield compounds indefinitely. Over multi-year horizons this contributes meaningfully to NAV.

The treasury split is operationally enforced for v1. A future protocol version may move the split into the smart contract itself; that change would require additional audit and is not part of the v1 launch.

SECTION · V

Profit Distribution and Economics

Each epoch — one week — the operator calculates the realized profit or loss from the strategies. If the epoch is profitable, the profit splits four ways:

RecipientPre-RecoveryPost-Recovery
Members (staked AUR holders)80%80%
Team5%15%
Operations5%5%
Recovery Fund10%0%

If the epoch is unprofitable, no rewards are distributed to anyone. Stakers, Team, Operations, and Recovery Fund all wait for the next profitable epoch. The operator does not earn on losses.

The Team allocation

The Team allocation funds operator compensation. Pre-Recovery, this is 5% — deliberately lower than industry norm to fund the Recovery Fund. After the Recovery Fund reaches its threshold and is distributed, the Team allocation increases to 15%, which is closer to typical fund operator economics.

The Team allocation is paid in USDC at epoch close. It is not deferred, vested, or tokenized — it is the operator's salary and operational margin.

The Operations allocation

The 5% Operations allocation covers ongoing protocol costs: keeper hosting, monitoring infrastructure, audit costs, contract deployment gas, frontend hosting, legal and accounting work. Anything left after costs goes to the Team budget as discretionary reserve.

The Recovery Fund allocation

The 10% Recovery Fund allocation goes to the labeled wallet 0x9eC5279bf6148a0f027B7329f694B0bd00302678 that participates in AUREUS strategies alongside other Member capital. When the $350,000 threshold is reached, the snapshot-and-airdrop sequence described in Section II executes. The threshold is reached when the Recovery Fund's value — its accrued allocations plus its strategy participation gains — first crosses $350,000. The exact mainnet block at which this happens will be publicly announced before the airdrop executes.

Fee economics

Redemption fees (Section VI) route to staked AUR holders as additional yield, not to the Team or Operations. Specifically, redemption fees flow back into the Forge contract's reward accumulator, so they show up in Member claim amounts at the next epoch close. This creates an aligned incentive: the more Members who exit at premium tiers (ASAP at 5%), the more yield accrues to Members who remain.

SECTION · VI

Withdrawal Mechanics

Three exit paths exist. Each has different cost, NAV basis, and timing.

PathFeeNAV usedProcessing timeCapacity limits
OTC marketplace0.5%Counterparty priceWheneverMarket-driven
End-of-epoch (EOE)2%Next epoch close<24 hours after closeNone
ASAP redemption5%Hard-verified NAV<48 hours1% / Member / 24h; 5% / protocol / 7d

OTC marketplace

The cheapest exit path. Members can list AUR for sale at any price; other Members or external buyers can fill those orders. The protocol takes a 0.5% fee on each fill, which routes to the staked AUR reward pool.

The OTC marketplace is fully on-chain and trustless. It does not require the operator's involvement to clear. Limitations: order matching depends on counterparty availability, so during periods of one-sided sentiment, exits via OTC may be slow or require accepting a discount to NAV.

End-of-epoch redemption

The Member submits a redemption request mid-epoch. At the next epoch close, the operator processes the request: burns the Member's AUR, calculates the payout at that epoch's NAV minus the 2% fee, and sends USDC to the Member's wallet. Used when the Member wants a guaranteed exit but doesn't need the funds immediately. Processed manually by the operator's multisig, typically within 24 hours after the epoch closes. The 2% fee routes to remaining stakers.

ASAP redemption

The Member submits a redemption request that the operator processes as soon as possible. The NAV used is the hard-verified value from the ReservesOracle (the on-chain proof-of-reserves) at processing time, not the operator's last published NAV. The 5% fee compensates for liquidity provision urgency. ASAP is rate-limited to prevent stress on the treasury — per-Member 1% per 24h, protocol-wide 5% per 7d. If a request would exceed either cap, it must wait for the rolling window to expire or be split across multiple smaller requests over time.

Why three tiers

The tiered structure is intentional. It compensates the protocol for the different liquidity demands each exit path imposes. OTC requires nothing from the treasury — the redemption is satisfied by another buyer's deposit. EOE gives the operator one week to manage treasury composition before processing. ASAP requires immediate liquidity, which is more expensive to provide. For most Members in most circumstances, EOE is the right path. ASAP exists for cases where time matters more than cost. OTC exists for Members who can accept a market-clearing price and want zero protocol fees.

Manual processing

All three withdrawal types are processed manually by the operator's multisig. There is no automated process that pulls funds out of strategies and into a redemption queue. This is a deliberate choice — automated redemption logic was considered and rejected because it expands attack surface and concentrates failure modes. Manual processing keeps human judgment in the loop for every exit.

SECTION · VII

Transparency Infrastructure

A central design principle of AUREUS is that the protocol's state should be independently verifiable by Members at any time, without requiring trust in the operator's reporting. This is implemented through three pieces of on-chain infrastructure that operate continuously.

The opacity problem in pooled funds

In a typical tokenized fund — both in DeFi and in traditional finance — the operator's claimed Net Asset Value is the only published number. There is no continuous on-chain reference for what the protocol actually holds at any given moment. Members and observers must trust that the operator's numbers reflect reality. This isn't a hypothetical concern. Opacity in pooled investment vehicles is the precondition for most large-scale fund failures, whether through fraud, accounting errors, or undisclosed drawdowns. The structural answer is to make state visible enough that errors become detectable in real time rather than after the fact.

How AUREUS solves it

Three contracts work together to keep the protocol's state continuously observable:

ReservesOracle — A non-upgradable smart contract that holds the protocol's verified reserve calculation, composed of two layers. The hard layer reads USDC balances held by the protocol, plus the STRCx reserve value (read from a Chainlink price feed), plus the Hyperliquid bridge floor. These are values that can be verified on-chain at any time by anyone with an RPC connection, without trusting the operator. The soft layer carries Hyperliquid position state reported by a keeper bot — the operator's claim about open positions, updated at least daily and on significant movement. Members and observers can compute the divergence between hard and soft layers at any time. A growing gap — particularly during stress — is a public signal visible in real time. The contract is non-upgradable; configuration changes require a 24-hour timelock before taking effect.

PositionLogger — An append-only ledger of every trade executed by the protocol. Each entry includes a reference hash linking back to the corresponding Hyperliquid trade ID. Past entries cannot be modified, only new ones added. This creates a complete public audit trail. After-the-fact rewriting of trade history is not possible.

NAV rate limit on the Forge — The operator publishes a new NAV at each epoch close. The Forge contract enforces a maximum movement of 15% per epoch in either direction. Larger movements cannot be applied in a single transaction; they would need to be spaced across multiple epochs, with every epoch visible. The 15% threshold accommodates legitimate strategy P&L on a one-week timeframe while preventing the operator from publishing accounting changes that would require explanation but bypass it.

What this accomplishes

These three layers prove what assets the protocol holds. They do not prove that those assets are being managed optimally — that remains the operator's responsibility. What the transparency layer accomplishes is bounding the worst failure modes: an operator cannot quietly drift from disclosed strategy without it being visible, and Members have the information they need to exit when they observe something concerning.

This is risk reduction, not risk elimination. Members still take on operator risk. The infrastructure makes that risk smaller and earlier to detect than in conventional pooled fund designs.
SECTION · VIII

Strategy Performance and Track Record

The Soomario Strategies that AUREUS deploys capital into have a backtest history across multiple market regimes. A summary:

  • Backtest window: 2020–2026, across multiple market cycles
  • Asset coverage: Crypto perpetuals (multiple base assets) plus tokenized US equities
  • Backtest aggregate: Positive net returns in the high double digits annualized, with maximum drawdown bounded in the single digits

The detailed backtest memo, including individual strategy results, parameter sets, and methodology, is published separately. It includes per-strategy performance tables, aggregate portfolio simulation, maximum drawdown analysis, sensitivity testing across different parameter regimes, and disclosure of assumptions, slippage models, and known limitations.

A caveat in plain language

Past performance does not predict future results.

This is not legal boilerplate. It is the central truth of strategy investing: a backtest is what happened in historical conditions with known outcomes. Live performance will differ. Sometimes the difference is favorable (strategies discovered structural alpha that persists). Sometimes the difference is unfavorable (market structure shifted, the strategy's premise no longer holds). Investors who expect future returns to match backtested returns are misreading the data.

Live performance figures will be published continuously through the dashboard once mainnet launches. The dashboard shows actual epoch-by-epoch returns, not retrospective backtests. Members should weight live data more heavily than the backtest, particularly as the live track record extends.

SECTION · IX

Governance and Operator Authority

AUREUS is operated by Soomario Strategies, run by the AUREUS team. The protocol is not a DAO. There is no token-weighted voting on protocol parameters. Operational decisions — strategy selection, parameter tuning, treasury composition — rest with the operator.

This is intentional. Pooled fund vehicles benefit from clear operator authority and accountability. Distributing trading decisions across token-weighted votes generally degrades performance and slows reaction time to market conditions.

Operator can

  • Execute trades through the Soomario Strategies on Hyperliquid
  • Set the NAV at each epoch close (within the 15% rate limit)
  • Process redemption requests at the operator's multisig
  • Update the strategy composition over time
  • Deploy contract upgrades (UUPS pattern)
  • Configure the ReservesOracle's tracked addresses (subject to 24-hour timelock)

Operator cannot

  • Move the NAV more than 15% in a single epoch
  • Modify past entries in the PositionLogger
  • Bypass the redemption rate limits without modifying the contract
  • Make changes to the ReservesOracle 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

Multi-signature requirements

All operator actions on protocol contracts require multi-signature approval. The operator does not act unilaterally; multiple signers must approve each transaction. The specific multisig configuration (signer count, threshold) will be disclosed in the technical documentation prior to mainnet launch.

Future governance

The operator retains the option to evolve toward distributed governance over time. This is not a v1 commitment. If Member-driven governance is introduced in a future protocol version, the details will be communicated clearly and Members will have the option to exit before changes take effect.

SECTION · X

Risks and Limitations

This section is deliberately explicit. AUREUS Members are taking on real, identifiable risks. The protocol does not eliminate them; it bounds them.

Operator risk

The strategies are executed by a human operator using systematic rules. Disciplined operation under stress is a real human responsibility, and even careful operators make mistakes. The transparency infrastructure makes the consequences of poor operation visible faster than in conventional pooled funds, but it does not eliminate the risk. Members should assume operator judgment is a factor in returns and that adverse outcomes from operator decisions are possible.

Mitigation: The ReservesOracle, PositionLogger, and rate limits collectively make operator drift visible before it becomes catastrophic. Members can exit through any of three paths at any time.

Smart contract risk

The AUREUS smart contracts (Forge, AureusRedemption, ReservesOracle, PositionLogger, OTCv2) have not been audited by an external security firm at the time of v1 launch.

Before mainnet deployment, the protocol undergoes a structured pre-launch security testing protocol that includes:

  • Static analysis with Slither, Mythril, and Echidna invariant fuzzing
  • AI-driven adversarial code review against the full contract suite
  • Working proof-of-concept exploit attempts on every identified attack surface
  • Multi-model cross-verification using different AI families to surface findings each missed
  • Fix-and-retest cycles until all critical and high-severity findings are addressed

This testing protocol is documented in the public RED_TEAM_RUNBOOK.md document and its findings will be published as RED_TEAM_FINDINGS.md before launch. Empirically, this approach catches a meaningful fraction of issues that a formal third-party audit would find — but it is not equivalent to a formal audit, and Members should understand that gap.

A formal external audit by a firm such as Sherlock is planned for after mainnet launch, once the protocol has accumulated operating history and any post-launch parameter changes are stable. The audit will produce a public report. Findings that require contract changes will be addressed through the Forge's upgrade mechanism (UUPS) and re-tested against the existing test suite.

Until the formal audit completes, smart contract risk in AUREUS is non-zero in ways that an audit would have reduced. The risks the pre-launch testing reduces are mechanical bugs, well-known attack patterns, and economic exploits with prior precedent. The risks the pre-launch testing does not eliminate are novel attack vectors with no training-data precedent and subtle business-logic flaws unique to AUREUS that no general security tool is trained on.

Additional mitigations: rate-limited admin actions, 24-hour timelocks on oracle configuration changes, emergency pause functionality, capped total Member deposits during the unaudited window.

Strategy risk

The Soomario Strategies have a positive backtest history but may underperform in live conditions. Crypto markets are highly volatile. Tokenized stocks are a new asset class with different liquidity profiles than spot equities. Drawdowns of 20% or more on the strategy component of the treasury are within historical range.

Mitigation: 20% STRCx reserve acts as a floor regardless of strategy performance. The Aerarium split provides structural diversification. The keeper bot reports position state continuously, so strategy drawdowns become visible in real time.

Counterparty risk

Several counterparties exist in the AUREUS stack:

  • Hyperliquid — The decentralized exchange where trading strategies execute. If Hyperliquid experienced a critical failure, position values could be impaired.
  • Strategy Inc. and Backed Finance (STRCx) — STRCx is a Backed Finance tokenization of Strategy Inc.'s perpetual preferred stock (STRC). Strategy Inc. is the public company that holds a large Bitcoin treasury and pays variable preferred dividends out of operating cash flow and treasury management activities. STRCx therefore inherits two layers of risk: (a) Strategy Inc.'s solvency and dividend-paying capacity, which is directly tied to Bitcoin's price and the company's ability to service obligations during BTC drawdowns, and (b) Backed Finance's operational integrity in maintaining the tokenization. A deep, sustained Bitcoin bear market could reduce the STRC dividend rate or, in an extreme scenario, impair the underlying preferred stock's value.
  • Chainlink — Provides the STRCx/USD price feed. A failure or manipulation would corrupt the ReservesOracle's hard layer calculation.
  • USDC issuer (Circle) — All deposits are in USDC. A USDC depeg or issuer failure would impair all dollar-denominated positions.

Mitigation: These are systemic crypto risks that no protocol can eliminate. AUREUS chooses widely-trusted counterparties and diversifies across them where possible. The decision to use STRCx over a Treasury-backed alternative like USDY is a deliberate trade for higher yield in exchange for the additional BTC-correlated counterparty risk described above.

Liquidity risk

The ASAP redemption tier has rate limits (1% per Member per 24 hours, 5% protocol-wide per 7 days). During a stress scenario where many Members want to exit simultaneously, the limits would extend exit times beyond 48 hours.

Mitigation: Three exit paths exist with different urgency-cost tradeoffs. OTC has no rate limits but requires counterparty matching. EOE has no rate limits but requires waiting for the next epoch close.

Tax and regulatory risk

AUREUS is a tokenized fund. Token mints, profit claims, redemptions, and OTC sales likely trigger tax events in most jurisdictions. The specific treatment varies by country and individual circumstance. AUREUS is not a regulated investment vehicle and does not provide tax documentation. Members are responsible for their own tax reporting. The protocol may be unavailable or restricted in some jurisdictions. Members are responsible for confirming legal eligibility to participate in their own jurisdiction.

Custody risk

While AUR tokens are held in Members' own wallets, USDC deposits and staked AUR are held by the protocol contracts. Loss of access to a Member's wallet (lost keys, compromised seed phrase) results in loss of access to their AUR. The protocol cannot recover lost Member wallets.

SECTION · XI

Roadmap

Now (Q2 2026)

Contracts are written and have been deployed end-to-end on Arbitrum Sepolia in a structured trial that validated the full lifecycle (mint → stake → epoch close → claim → redeem → burn). The trial summary is published as SEPOLIA_TRIAL_SUMMARY.md.

Mainnet contract code requires modifications identified during the trial — including a profit-split refactor to match the economics in Section V of this document, a fresh-deployment script for AUR (replacing the prior plan that would have upgraded a different contract), and several operational fixes documented in MAINNET_PREREQUISITES.md.

Next 30–60 days

  • Implement the mainnet contract changes documented in MAINNET_PREREQUISITES.md
  • Execute the full pre-launch security testing protocol per RED_TEAM_RUNBOOK.md and publish findings as RED_TEAM_FINDINGS.md
  • Address all critical and high-severity findings; document accepted risk for medium and below
  • Deploy contracts to Arbitrum mainnet with initial deposit caps in place
  • Open Member onboarding
  • Begin first epochs of live operation

Months 2–6

  • Continuous operation through first quarter of live performance
  • Track record building
  • Recovery Fund accumulation toward $350K threshold
  • Commission formal external audit (Sherlock or peer firm) once initial operating history is established
  • Publish audit findings and remediation as AUDIT_REPORT_v1.md
  • Frontend integration of dashboard widgets showing real-time NAV, ReservesOracle data, withdrawal queue

Beyond

  • Possible STRCx allocation enforcement on-chain (currently operational)
  • Possible governance evolution (currently centralized operator)
  • Possible expansion of strategy universe as new asset classes become available on Hyperliquid
  • Possible additional reserve assets if STRCx alternatives emerge

None of the "Beyond" items are committed timeline; they are future considerations contingent on first proving out v1.

SECTION · XII

Technical Appendix

This is a brief technical summary for general audiences. The detailed architecture document (AUREUS_ARCHITECTURE.md) is the canonical source for developers and auditors.

Chain and contracts

AUREUS runs on Arbitrum One. The protocol consists of five smart contracts:

ContractPurposeUpgradable?
Forge (V2)Mints/burns AUR, distributes rewardsYes, UUPS pattern
AureusRedemptionManages three-tier withdrawal flowNo
ReservesOracleOn-chain proof-of-reservesNo
PositionLoggerAppend-only trade ledgerNo
OTCv2Decentralized AUR marketplaceLimited

All five contracts are freshly deployed for AUREUS. AUR is a freshly deployed ERC-20 with no shared state with any prior protocol's token.

Upgrade mechanism

The Forge uses OpenZeppelin's UUPS upgrade pattern. The proxy contract delegates calls to an implementation contract that can be replaced. Upgrades require multi-sig approval. Storage layout compatibility is verified before each upgrade — past upgrades that broke layout would corrupt existing Member balances, so this check is strictly enforced. ReservesOracle, PositionLogger, and AureusRedemption are deployed without upgrade hooks. Their code is immutable post-deployment. Configuration parameters are adjustable through admin functions subject to 24-hour timelocks.

Oracle architecture

The ReservesOracle reads multiple sources: direct on-chain queries for USDC balances at tracked addresses, the Chainlink STRCx/USD price feed for reserve valuation, the Hyperliquid bridge contract for the cross-chain position floor, and keeper-reported state for Hyperliquid open positions. The keeper bot, operated by the AUREUS team, posts position updates to the contract at least every 24 hours and on 5% portfolio movement. Keeper authority is limited to posting position data — it cannot modify hard-layer values or affect Member balances.

Pre-launch security testing and audit materials

The following documents are or will be made publicly available:

  • This whitepaper (AUREUS_WHITEPAPER.md) — published
  • Sepolia trial summary (SEPOLIA_TRIAL_SUMMARY.md) — published
  • Mainnet prerequisites and pre-launch scope (MAINNET_PREREQUISITES.md) — published
  • Architecture documentation (AUREUS_ARCHITECTURE.md) — pre-launch
  • Pre-launch security testing protocol (RED_TEAM_RUNBOOK.md) — published
  • Pre-launch security testing findings (RED_TEAM_FINDINGS.md) — at launch
  • Formal audit report — post-launch, after the audit completes

Source code is published in the GitHub repository at github.com/Makuroi508/aureus, accessible from mainnet launch.

SECTION · XIII

Glossary

Aerarium
The treasury. From the Latin term for the Roman public reserve held in the Temple of Saturn. In AUREUS, the Aerarium refers to the combined Soomario Strategies allocation and STRCx Reserve that backs all AUR tokens.
ASAP redemption
The fastest exit tier. The Member redeems AUR for USDC immediately at the on-chain verified hard NAV, paying a 5% fee. Subject to rate limits (1% per Member per 24h, 5% protocol-wide per 7d).
AUR
The token Members hold. Represents proportional ownership of the Aerarium. Minted when USDC is deposited; burned when redeemed. A freshly deployed ERC-20 with no shared state with any prior protocol's token.
AUREUS
The protocol as a whole. From the Latin for "golden," referencing both the historical Roman gold standard and the protocol's reserve-asset character.
closeEpoch
The contract function that finalizes an epoch's accounting: new NAV is set, profits are distributed, the next epoch begins. Called by the operator's multisig.
End-of-epoch (EOE) redemption
The middle exit tier. Member submits a redemption request; processed at the next epoch close at that close's NAV, paying a 2% fee. Processed within 24 hours of epoch close.
Epoch
One full cycle of accounting. AUREUS uses one-week epochs. Each epoch ends with closeEpoch setting a new NAV and distributing profits.
Forge
The contract that mints and burns AUR. Freshly deployed for AUREUS. Uses the UUPS upgrade pattern. Holds Member stakes and the reward accumulator.
Hard NAV
The component of total NAV that is verifiable on-chain without trusting the operator. Computed by ReservesOracle from USDC balances, STRCx value (via Chainlink), and the Hyperliquid bridge floor.
Hyperliquid
The decentralized exchange where Soomario Strategies execute trades. Provides perpetuals on crypto and tokenized equities.
Keeper
An off-chain bot operated by the AUREUS team that posts Hyperliquid position state to the ReservesOracle. Reports at least every 24 hours and on 5% portfolio movement.
Member
A holder of AUR. Anyone with AUR in their wallet is a Member.
NAV (Net Asset Value)
The value of one AUR in USDC. Calculated by dividing total treasury value by total AUR supply. Used as the price for minting and redemption.
NGET
The legacy token of a prior protocol operated by the AUREUS team. Separate from AUR — different contract, different address, no shared state. Holders of NGET at a designated snapshot block will be eligible for the Recovery Fund airdrop.
OTC marketplace
A built-in on-chain marketplace where Members can buy and sell AUR. Takes a 0.5% fee per fill, which routes to staked AUR holders.
PositionLogger
A non-upgradable contract that records every trade executed by the protocol. Append-only — past entries cannot be modified.
Pre-launch security testing
The structured testing protocol AUREUS uses before mainnet launch in place of a formal third-party audit at launch. Includes static analysis (Slither, Mythril), invariant fuzzing (Echidna), AI-driven adversarial code review, and proof-of-concept exploit attempts. Documented in RED_TEAM_RUNBOOK.md. Findings published as RED_TEAM_FINDINGS.md. A formal external audit is planned for after launch.
Recovery Fund
A labeled wallet at 0x9eC5279bf6148a0f027B7329f694B0bd00302678 that receives 10% of each profitable epoch until $350,000 is reached. Starts with approximately $3,000 seeded from prior Nugget Fund liquidation residual, currently active in Soomario Elite and Aphelion strategies. At threshold, the Recovery Fund is airdropped pro-rata to NGET holders as of a designated snapshot block. Currently a single-key EOA; may be migrated to a multisig once balance grows meaningfully.
ReservesOracle
A non-upgradable contract that publishes the protocol's verified reserve composition on-chain. Composed of a hard layer (verifiable) and soft layer (keeper-reported).
Soft NAV
The component of total NAV reported by the keeper bot from Hyperliquid position state. Trusted but verifiable against the hard NAV.
Soomario Strategies
The suite of systematic trading bots operated by the AUREUS team on Hyperliquid. Receives 80% of treasury allocation.
STRCx
A yield-bearing asset issued by Backed Finance that tokenizes Strategy Inc.'s perpetual preferred stock (STRC). Strategy Inc. is the public company (formerly known as MicroStrategy) that holds a large Bitcoin treasury. STRCx pays variable dividends (currently ~11.5% APY) and carries Strategy Inc. / Bitcoin counterparty risk. Held as 20% permanent reserve in AUREUS, never sold.
Team
The AUREUS operator. Receives 5% of each profitable epoch (15% post-Recovery). Plain-language replacement for "operator" or specific personal references in client-facing materials.
UUPS
Universal Upgradeable Proxy Standard. The OpenZeppelin pattern used for the Forge contract's upgrade mechanism. Allows the implementation to be replaced while preserving the proxy address and Member balances.

Final note

This whitepaper describes the AUREUS protocol as designed for v1 launch. Specific numbers — the 80/5/5/10 profit split, the 15% NAV rate limit, the 1%/24h and 5%/7d ASAP caps, the $350K Recovery Fund target — are launch parameters. They may be adjusted in future protocol versions through transparent, timelocked governance actions. Material changes will be communicated to Members in advance with the option to exit before changes take effect.

For questions, technical details, the published pre-launch testing materials, or to participate in AUREUS, see the resources at the soomariostrategies.com website and the GitHub repository.

AUREUS is built on a single principle: the protocol's state should be verifiable by Members in real time, not relied upon as the operator's word. Every architectural choice — the proof-of-reserves oracle, the append-only trade ledger, the rate-limited admin actions, the three-tier withdrawal flow — exists to serve that principle. Returns are generated by disciplined systematic trading. Trust is generated by structural visibility into what that trading actually does.

Both matter. The protocol provides the second so the first can be evaluated honestly.