# Introduction

## RAX Protocol RAX is an AI-powered risk intelligence layer for DeFi. The protocol analyzes on-chain opportunities, simulates possible outcomes and allocates capital through autonomous vault strategies designed to maximize **risk-adjusted yield**. Unlike traditional yield aggregators, RAX focuses on **risk analysis before allocation**, evaluating exposure, liquidity conditions and protocol health. *** ### Core Components #### Risk Intelligence RAX continuously evaluates DeFi opportunities using multiple metrics including liquidity depth, volatility and protocol health to generate a dynamic **risk score**. #### Simulation Engine Before capital is allocated, RAX runs simulations to evaluate potential outcomes such as: * expected yield * downside risk * drawdown scenarios * exposure concentration #### Allocation Engine The allocation engine distributes capital across strategies based on **risk-adjusted return** rather than raw yield. #### AI-Managed Vault Capital is deployed through an ERC-4626 vault architecture that executes allocation decisions and manages deposits and withdrawals on-chain. #### RaxBot RaxBot provides an interpretation layer that helps users understand the system’s decisions and risk exposure. *** ### Learn More Explore the documentation to understand how RAX works: * Risk Score * Exposure vs Allocation * Simulations * Allocation Engine * AI-Managed Vault # Quickstart This quickstart introduces the core workflows of RAX Protocol and helps you get value from the system within minutes. RAX can be used in multiple ways depending on your role and objectives. The paths below outline the most common entry points. *** #### Option 1: Explore in Demo Mode Start here if you want to understand what RAX does before connecting a wallet. 1. Visit the RAX application 2. Select Demo Mode from the landing page — no wallet required 3. Explore the Risk Overview dashboard: global risk metrics, protocol status, AI market signals 4. Navigate to Exposure Analysis to see how capital is distributed across protocols and assets 5. Run a Simulation to see how the autonomous vault would behave over time Demo Mode provides full access to the interface with simulated data. *** #### Option 2: Analyze Risk and Exposure Use this path if you want to understand DeFi risk conditions. 1. Open the Risk Overview dashboard 2. Review the overall Risk Score and its component dimensions 3. Check protocol-level status for Aave, Compound, Uniswap, and Aerodrome 4. Navigate to Exposure Analysis to identify concentration across protocols and asset classes 5. Review alerts for any active risk warnings This workflow is useful for gaining situational awareness before making capital decisions. *** #### Option 3: Allocate Capital Through the Vault Use this path to actively manage capital with AI assistance. 1. Connect your wallet (Base Sepolia testnet) 2. Configure a Mandate — define your risk tolerance, protocol exposure limits, liquidity thresholds, and rebalance rules 3. Deposit USDC into the vault 4. Review AI-generated allocation proposals in the Allocation Engine 5. Approve, reject, or enable auto-execution for proposed rebalances 6. Monitor decisions in the Decision History *** #### Option 4: Enable Autonomous Mode For users ready to let the system operate independently within constraints. 1. Complete Option 3 (mandate configured, capital deposited) 2. Enable Auto-Execute in your mandate settings 3. RaxBot will begin running decision cycles automatically 4. Monitor notifications for rebalances, emergency stops, and pending approvals 5. Adjust the mandate as conditions change — the system adapts on the next cycle Autonomous Mode requires the Power tier ($RAX token holding). *** #### What to Explore Next After completing the quickstart, we recommend: * **Risk Score** to understand how risk is measured and what the dimensions mean * **Exposure vs Allocation** to learn how concentration affects portfolio risk * **Allocation Engine** to see how strategies and constraints interact * **AI-Managed Vault** to understand the on-chain architecture * **Security & Risk Disclosures** to understand system limits and assumptions *** #### Important Notes * RAX provides risk intelligence and decision support, not financial advice * Risk scores and simulations are based on models and assumptions that may not hold under extreme conditions * The current deployment is on Base Sepolia testnet — testnet tokens have no monetary value * All capital decisions remain the responsibility of the user # Glossary This glossary defines key terms used throughout the RAX Protocol documentation. *** **Allocation Engine** — The decision-support system that evaluates opportunities and proposes capital allocations within mandate constraints. Can be invoked manually through the interface or autonomously through RaxBot. **Decision Cycle** — One complete evaluation pass by RaxBot: risk calculation, mandate checking, allocation proposal, and execution or hold. Each cycle produces a logged decision record. **ERC-4626** — A tokenized vault standard on Ethereum. The RAX vault implements this standard, issuing shares proportional to deposits and managing assets across multiple strategies. **Exposure** — The actual distribution of capital across protocols, assets, or chains at any point in time. May differ from the target allocation due to market movements between rebalances. **Intelligence Score** — A proprietary composite metric (0-100) where higher values indicate better risk-adjusted opportunity. Inverts risk dimensions and adds yield quality bonuses. **Keeper** — A dedicated wallet authorized to execute rebalance transactions on the vault contract. The keeper operates within mandate rules and is the only address permitted to call the rebalance function on-chain. **Mandate** — A user-defined set of constraints that governs all autonomous actions: risk tolerance, exposure limits, allowlists, rebalance thresholds, drawdown limits, and approval rules. **RaxBot** — The autonomous execution process that runs decision cycles on a schedule, monitoring conditions and acting within the mandate without requiring user interaction for each cycle. **Risk Score** — A normalized value from 0 to 100 representing relative risk. Derived from five weighted dimensions and used for comparison across assets, protocols, and portfolios. **Strategy Adapter** — A smart contract that connects the vault to a specific DeFi protocol (Aave, Compound, Uniswap V3, Aerodrome), handling deposits, withdrawals, and yield collection through the IStrategyAdapter interface. **Tier** — Access level determined by $RAX token holdings. Four tiers: Free (0 RAX), Holder (1+ RAX), Pro (1,000+ RAX), Power (10,000+ RAX). # Risk Score

The Risk Score is a core concept in RAX Protocol. It provides a normalized view of relative risk across assets, protocols, strategies, and portfolios, allowing users to reason about exposure and capital allocation using a consistent reference point. *** #### What the Risk Score Represents The RAX Risk Score is a normalized value ranging from 0 to 100. * Lower values indicate lower relative risk * Higher values indicate higher relative risk The score is designed to be comparative, not absolute. It reflects how risky an asset, protocol, or portfolio is relative to others under current market conditions. A low score does not imply the absence of risk. A high score does not imply inevitable failure. *** #### How the Score Is Calculated RAX uses a five-dimensional scoring model with the following weights: **Smart Contract Risk (30%)** — Evaluates protocol maturity, TVL as a proxy for battle-testing, and protocol category. Established protocols like Aave and Compound receive lower scores. Newer or structured products receive higher scores. **Impermanent Loss Risk (25%)** — Relevant for liquidity pool positions. Evaluated based on pool type, observed IL over 7-day windows, and asset correlation. Stablecoin pools score very low; volatile LP pairs score high. **Liquidity Risk (20%)** — Assesses available liquidity relative to the vault or pool size, trading volume ratios, and capacity utilization. Low-liquidity positions increase exit risk and receive higher scores. **Volatility Risk (15%)** — Measures yield stability over 30-day windows using APY percentage change. Stablecoin positions receive minimal scores. The system also incorporates predicted stability classification where available. **Protocol Risk (10%)** — A tiered assessment based on protocol reputation. Tier 1 protocols (Aave, Uniswap, Curve, Lido, Compound, Maker) receive the lowest scores. Tier 2 (Balancer, Convex, Yearn) and Tier 3 (Velodrome, Aerodrome, Pendle) receive progressively higher scores. #### Risk Categories Composite scores map to categories: * 0–20: Very Low * 21–40: Low * 41–60: Moderate * 61–80: High * 81–100: Very High *** #### How the Risk Score Is Used The Risk Score appears throughout the RAX system: * Global Risk Score to describe overall conditions * Portfolio Risk Score to summarize aggregate portfolio risk * Protocol and vault risk scores to compare relative safety * Allocation Engine inputs to constrain and guide capital allocation * Alert thresholds to detect rising or abnormal risk * Emergency triggers — if the score exceeds 150% of the mandate maximum, an automatic emergency stop activates In all cases, the score is intended to be interpreted alongside supporting metrics, not in isolation. *** #### Interpreting Risk Score Changes Risk Scores are dynamic and may change over time. Common reasons include increases in volatility, liquidity inflows or outflows, shifts in market correlation, detection of anomalous behavior, and changes in exposure composition. A rising Risk Score indicates increasing relative risk. A falling Risk Score indicates improving relative conditions. Trends across multiple readings are more informative than single-point values. *** #### What the Risk Score Does Not Do The Risk Score does not predict future prices, guarantee safety or returns, replace detailed analysis, or eliminate the need for human judgment. It is a decision-support signal, not an autonomous decision-maker. *** #### Using the Risk Score Effectively To use the Risk Score effectively: * Compare scores across similar assets or strategies * Monitor changes over time rather than focusing on single values * Combine the score with exposure analysis and simulations * Apply explicit constraints when allocating capital * Treat scores with caution during unprecedented market events — models have assumptions that may not hold under extreme conditions # Exposure vs Allocation

Exposure and allocation are related but distinct concepts in RAX. *** #### Defining the Difference **Allocation** is the intended distribution of capital — the target percentages assigned to each protocol or strategy by the allocation engine or user. **Exposure** is the actual distribution of capital at any given moment. It may differ from the allocation due to market movements, yield changes, deposits or withdrawals in underlying protocols, or timing between rebalances. The gap between allocation and exposure is what triggers rebalancing. When the deviation exceeds the mandate's rebalance threshold, the system proposes bringing exposure back in line with the target allocation. *** #### Why the Distinction Matters In traditional finance, allocation and exposure are often treated as the same thing. In DeFi, they can diverge significantly between rebalances because underlying positions shift in value continuously. A portfolio allocated 30% to Aave may drift to 35% exposure if Aave positions appreciate faster than others. This drift changes the risk profile even though no deliberate action was taken. RAX monitors this drift continuously and uses the deviation as a key input to the rebalancing decision. *** #### Exposure Dimensions RAX tracks exposure across three dimensions: * **Protocol exposure** — percentage of capital in each protocol (Aave, Compound, Uniswap, Aerodrome, etc.) * **Asset class exposure** — distribution across stablecoins, volatile assets, and liquidity pool positions * **Chain exposure** — distribution across networks (currently Base; multi-chain is planned) Concentration risk is measured using the Herfindahl-Hirschman Index (HHI). A higher HHI indicates a more concentrated portfolio, which increases the concentration risk component of the overall Risk Score. *** #### How Exposure Informs Decisions High concentration in a single protocol or asset class creates dependency risk. If that protocol experiences a vulnerability or liquidity event, a concentrated portfolio suffers disproportionately. The allocation engine uses exposure data to avoid proposing allocations that would increase concentration beyond mandate limits. The mandate's `maxProtocolExposure` parameter directly caps how much any single protocol can represent in the portfolio. # Risk-Adjusted Yield

Raw yield (APY) is insufficient for evaluating DeFi opportunities without risk context. A 50% APY pool with extreme volatility and low liquidity may deliver worse risk-adjusted outcomes than a 5% APY position in a stable, liquid protocol. Headline yield attracts capital, but risk-adjusted yield determines whether that capital is preserved. *** #### How RAX Calculates Risk-Adjusted Yield RAX computes risk-adjusted yield as: Risk-Adjusted Yield = APY / (1 + Risk Score / 100) A pool with 12% APY and a risk score of 30 has a risk-adjusted yield of approximately 9.2. The same 12% APY with a risk score of 70 drops to approximately 7.1. This metric feeds into the Intelligence Score and directly influences the allocation engine. Under defensive and balanced strategy profiles, the engine favors positions with higher risk-adjusted yield over raw APY. *** #### Role in Allocation Strategies that deliver more return per unit of risk are favored, especially under defensive or balanced profiles. Higher-yield strategies with weaker risk-adjusted performance may be deprioritized even if headline returns appear attractive. This ensures the system does not chase yield at the expense of portfolio stability — a core design principle of RAX. *** #### Limitations Risk-adjusted yield is backward-looking — it uses current APY and current risk scores. It does not account for future changes in either metric. It should be used alongside simulations and stress testing, not as a standalone decision signal. # Risk Overview The Risk Overview is the primary dashboard for monitoring market and portfolio conditions. It provides a consolidated view of system health, risk metrics, and recent activity. *** #### What It Displays * **Portfolio metrics** — total value, current allocation summary, number of active strategies * **Platform metrics** — protocols monitored, strategies deployed, average APY across positions * **Risk metrics** — overall risk score with breakdown by protocol risk, concentration risk, liquidity risk, and volatility exposure * **AI Market Signals** — real-time observations about current market conditions and detected patterns * **Protocol Status** — live operational status of integrated protocols (Aave, Compound, Uniswap, Aerodrome) * **Activity Feed** — recent system events including rebalances, deposits, withdrawals, and decision outcomes *** #### Navigating from Risk Overview The Risk Overview serves as a hub. Users can navigate directly to Exposure Analysis for deeper breakdowns, to the Allocation Engine to act on insights, or to Simulations to test hypothetical scenarios. Risk Overview is available at the Free tier. No wallet connection is required in Demo Mode # Exposure Analysis The Exposure Analysis section provides a detailed breakdown of where capital is deployed and where concentration risks exist. *** #### What It Displays * **Protocol Exposure** — percentage allocated to each protocol, with warnings when any single protocol exceeds safe thresholds * **Asset Class Exposure** — distribution across stablecoins, volatile assets, and liquidity pool positions * **Chain Exposure** — distribution across networks * **Concentration Risk Score** — derived from the HHI calculation, flagging insufficient diversification * **Liquidity Risk Assessment** — ratio of liquid assets to total portfolio value Each metric includes a visual indicator: green (within safe bounds), yellow (approaching limits), red (exceeding limits). *** #### Using Exposure Analysis Exposure Analysis is most useful when combined with the Risk Score. A low overall risk score with high concentration in a single protocol may mask dependency risk. Exposure Analysis surfaces these hidden risks. Before enabling autonomous mode, review exposure analysis to ensure the mandate's protocol exposure limits are appropriate for your current positions. Exposure Analysis is available from the Holder tier. # Alerts & Monitoring The alert system generates warnings when risk metrics cross defined thresholds. *** #### Alert Severity Levels **HIGH** — Protocol risk exceeds acceptable levels, severe portfolio concentration detected, or liquidity constraints identified. These require immediate attention. **MEDIUM** — Moderate concentration risk detected, or volatility exposure approaching the mandate's risk tolerance limit. **LOW** — Informational alerts about metrics approaching thresholds. No immediate action required. *** #### How Alerts Are Generated Alerts are produced by the Risk Calculator during each evaluation cycle. Alert thresholds adapt based on the active mandate's risk tolerance setting — a defensive mandate triggers alerts at lower thresholds than an aggressive one. *** #### Monitoring Best Practices * Review alerts regularly rather than waiting for critical severity * Treat persistent MEDIUM alerts as signals to adjust the mandate before conditions escalate * Use alert patterns over time to inform strategy changes * Combine alerts with Exposure Analysis for full context Alerts & Monitoring is available from the Holder tier. # Simulations Simulations allow users to test how the autonomous vault would behave over a specified time period before committing to autonomous operation. *** #### How Simulations Work The simulation engine runs the full allocation engine decision loop — risk calculation, mandate checking, opportunity evaluation, allocation proposal — repeatedly over a simulated time window. Each iteration may produce a different outcome depending on simulated market conditions, including random volatility events. *** #### Running a Simulation Users configure the duration (how many hours to simulate) and the vault to test against. The simulation produces a timeline of events showing every decision the system would have made. *** #### Interpreting Results The simulation summary shows: total evaluations performed, number of rebalances triggered, number of emergency stops, number of holds, and number of pending approvals. A healthy simulation typically shows mostly holds with occasional rebalances. Frequent emergency stops suggest the mandate's risk limits may be too close to current market conditions. Frequent rejections suggest overly restrictive constraints. This helps users calibrate their mandate before enabling autonomous mode. *** #### Limitations Simulations use simplified market models with random volatility events. They do not replicate actual market conditions and should not be interpreted as predictions. They are tools for understanding system behavior under mandate constraints. Simulations are available from the Pro tier.
They support more deliberate and resilient decision-making in complex DeFi environments. # Allocation Engine The Allocation Engine is the decision-support core of RAX Protocol. It is designed to help users allocate capital in a disciplined manner by applying explicit risk constraints, strategy profiles, and real-time risk intelligence. Rather than optimizing for maximum yield, the Allocation Engine prioritizes control, resilience, and capital efficiency. *** #### How It Works Each evaluation follows a structured sequence: 1. Load the vault's current state and active mandate 2. Check whether the vault is paused 3. Calculate risk metrics across all current positions 4. Check for emergency triggers (critical risk, drawdown breach, liquidity crisis) 5. Detect current market and portfolio conditions 6. Verify the minimum rebalance interval has elapsed 7. Evaluate available opportunities against the mandate's constraints 8. Propose an allocation based on strategy profile and risk-adjusted yield 9. Run a full compliance check against all mandate constraints 10. Generate an explanation of the reasoning 11. Determine whether the deviation warrants rebalancing 12. Execute, request approval, or hold based on compliance results *** #### Strategy Profiles The engine operates using strategy profiles that define the user's risk posture: * **Defensive** — focused on capital preservation and stability, favoring low-risk positions * **Balanced** — targeting risk-adjusted efficiency across the portfolio * **Aggressive** — tolerating higher volatility for potential upside Profiles define boundaries and priorities. They do not execute trades automatically unless autonomous mode is enabled. *** #### Risk Constraints Risk constraints are explicit limits applied to every allocation decision: * Maximum acceptable Risk Score * Maximum protocol exposure per position * Maximum chain exposure * Minimum liquidity threshold * Maximum capital moved per rebalance * Drawdown tolerance * Protocol and asset allowlists Constraints act as guardrails that prevent allocations outside acceptable risk boundaries. If any constraint would be violated, the proposal is rejected. *** #### Allocation Suggestions Based on the active profile and constraints, the engine generates allocation suggestions that may include increasing or decreasing exposure to specific strategies, rebalancing across protocols, reducing concentration in high-risk areas, or maintaining defensive positioning. All suggestions are advisory by default and require user approval unless autonomous mode is enabled. *** #### Human Oversight and Control The Allocation Engine is designed with human oversight in mind. It does not execute trades autonomously unless the user explicitly enables auto-execution in the mandate. Users remain in control of strategy selection, constraint configuration, approval decisions, and the ability to pause at any time. This design ensures accountability and transparency at every step. The Allocation Engine is available from the Pro tier. Autonomous execution requires the Power tier. # Settings & Access Control Settings and Access Control define how RAX is configured, secured, and governed at the user level. *** #### Mandate Configuration The mandate defines all rules governing vault operation. Configurable parameters include: * Risk tolerance profile (defensive, balanced, aggressive) * Maximum risk score (default: 50) * Maximum protocol exposure per position (default: 40%) * Maximum chain exposure (default: 100%) * Minimum liquidity threshold (default: 10%) * Maximum capital per rebalance (default: 25%) * Rebalance threshold — deviation percentage (default: 5%) * Minimum rebalance interval (default: 1 hour) * Maximum drawdown before emergency stop * Protocol allowlist * Asset allowlist * Auto-execute toggle (off by default) * Approval threshold for large capital movements Changes take effect on the next decision cycle. All changes are versioned — each decision record references the mandate version that was active, providing a clear audit trail. *** #### Access Tiers RAX uses two complementary access systems: **Wallet-based progression:** * Free — no wallet required, basic analytics * Wallet Connected — personalized exposure and alerts * Capital Deposited — allocation engine and mandate configuration * Autonomous Mode — keeper-driven auto-execution **Token-based tiers (determined by $RAX balance on Base):** | Tier | Minimum $RAX | Key Features | | ------ | ------------ | ------------------------------------------------------- | | Free | 0 | Risk Overview, basic exposure | | Holder | 1 | Full vault rankings, advanced filters, alerts | | Pro | 1,000 | Simulations, allocation presets, full exposure analysis | | Power | 10,000 | Decision export, full settings, RaxBot access | Founder wallets receive full Power tier access regardless of token balance. *** #### Security Practices The vault contract uses Ownable2Step (two-step ownership transfer preventing accidental transfers), ReentrancyGuard, and Pausable patterns from OpenZeppelin. Only the authorized keeper address can execute rebalances. Emergency pause can be triggered by the owner at any time. Settings should be reviewed periodically, especially after changes in market conditions or strategy. # AI-Managed Vault The AI-Managed Vault is a fully functional, on-chain capital management system deployed on Base. It combines the ERC-4626 tokenized vault standard with multi-strategy allocation, autonomous keeper-based rebalancing, and a comprehensive fee and safety system. *** #### Architecture The vault implements ERC-4626. Users deposit USDC and receive vault shares proportional to their deposit. The vault manages assets across multiple DeFi strategies through dedicated adapter contracts. **Vault Contract:** `0x3E6bf646b379C75d47Cf91d5569621FD0df53d78` (Base Sepolia) **Underlying Asset:** USDC (`0x25b56942824E65B5d83BD57f54e3518CccFcd088` — MockUSDC on testnet) The total assets under management equals idle USDC in the vault plus the sum of assets deployed across all registered strategy adapters. *** #### Strategy Adapters The vault allocates capital through four dedicated adapter contracts: * **Aave Adapter** — deposits into Aave lending pools * **Compound Adapter** — deposits into Compound lending markets * **Uniswap V3 Adapter** — concentrated liquidity positions * **Aerodrome Adapter** — liquidity provision and gauge staking Each adapter implements the `IStrategyAdapter` interface, providing standardized `deposit()`, `withdraw()`, and `totalAssets()` functions. New strategies can be added through the `addStrategy()` function with a configurable maximum exposure limit. *** #### Keeper System The keeper is a dedicated wallet authorized to execute rebalances on the vault contract. The `onlyKeeper` modifier restricts the `rebalance()` function to this address or the contract owner. Rebalancing accepts an array of strategy addresses and target weights in basis points (summing to 10,000). The vault redistributes capital across strategies accordingly. The keeper can also trigger `harvestAll()` to collect rewards from all active strategies. *** #### Fee Structure The vault collects fees through four mechanisms: * **Management Fee** — annual fee in basis points, accrued over time (maximum 5%) * **Performance Fee** — charged on profits above the high watermark (maximum 30%) * **Deposit Fee** — entry fee deducted from deposits * **Withdrawal Fee** — exit fee deducted from withdrawals Fees are collected to a designated treasury address. The high watermark ensures performance fees only apply to new profits — during recovery periods after a drawdown, no performance fees are charged. *** #### Safety Mechanisms The vault includes multiple layers of protection: * **Pausable** — emergency pause halts all deposits, withdrawals, and rebalances instantly * **ReentrancyGuard** — prevents reentrancy attacks on deposit and withdrawal functions * **Ownable2Step** — two-step ownership transfer prevents accidental or malicious ownership changes * **Max Drawdown Halt** — if vault value drops below the drawdown threshold (configurable, default 15%) relative to the initial share price, operations halt automatically * **High Watermark** — tracks peak share price, preventing performance fee extraction during recovery *** #### Mandate Enforcement The off-chain allocation engine enforces all mandate constraints before submitting any rebalance transaction to the keeper. The keeper will not submit a transaction that violates the mandate. The on-chain contract provides an additional safety layer through the pause mechanism and drawdown check, creating defense in depth. *** #### Current Deployment The vault is live on Base Sepolia testnet. All strategy adapters are deployed and registered. The keeper wallet is funded and operational. Mainnet deployment is planned following further testing and audit. # Overview RaxBot is the autonomous execution component of RAX Protocol. It operates as a background process that continuously monitors vault conditions, evaluates risk, and executes allocation decisions within the boundaries defined by the user's mandate. *** #### What RaxBot Does RaxBot performs a repeating decision cycle: * Calculates current risk metrics across the vault's positions * Checks for emergency conditions that require immediate action * Evaluates whether the current allocation still satisfies the mandate * Proposes rebalancing if conditions have changed beyond the configured threshold * Executes approved changes on-chain via the dedicated keeper wallet * Logs every decision with full rationale for transparency Each cycle produces a decision record that is stored and auditable. *** #### How It Relates to the Allocation Engine The Allocation Engine described in the Product Guides section is the logic core that RaxBot executes. When a user interacts with the Allocation Engine through the interface, they are running the same evaluation that RaxBot runs autonomously. The difference is timing and trigger: through the interface, the evaluation runs on demand. Through RaxBot, it runs automatically at regular intervals. The mandate, risk constraints, and compliance checks are identical in both paths. *** #### What RaxBot Is Not RaxBot is not a general-purpose AI assistant or chatbot. Users do not have conversations with it. RaxBot is not a prediction engine. It does not forecast prices or guarantee returns. RaxBot is not unconstrained. Every action it takes must satisfy the active mandate. It cannot exceed the maximum risk score, allocate to protocols outside the allowlist, or move more capital than the per-rebalance limit allows. RaxBot is a constrained autonomous process that operates within explicit rules defined by the user. *** #### Transparency Every decision cycle produces a log entry containing the type of decision, current and proposed allocations, risk scores before and after, compliance check results, the rationale behind the decision, and execution details including transaction hash when applicable. Users can review the complete decision history at any time through the interface. # Decision Cycles A decision cycle is one complete evaluation-and-action pass performed by RaxBot. Each cycle follows a fixed sequence of steps and produces one of several possible outcomes. *** #### Possible Outcomes **Hold** — The current allocation is within acceptable parameters. No action needed. This is the most common outcome in stable conditions. **Rebalance** — Conditions have changed enough to warrant adjusting allocations. If the mandate allows auto-execution and compliance checks pass, the rebalance is executed on-chain immediately. **Pending Approval** — The proposed change is compliant but exceeds the approval threshold defined in the mandate, or auto-execution is disabled. The user is notified and must approve or reject. **Rejected** — The proposed allocation violates one or more mandate constraints. No action is taken. The violation details are logged. **Emergency Stop** — A critical condition has been detected. The vault is paused automatically. No human approval is required — this is a safety mechanism. **Paused** — The vault was already paused. The cycle logs this state and takes no further action. *** #### What Triggers a Rebalance A rebalance is triggered when any of the following conditions are met: * The vault has no current allocations (initial allocation required) * The current risk score exceeds the mandate's maximum allowed risk score * The deviation between current and proposed allocations exceeds the rebalance threshold *** #### Emergency Triggers Emergency stops are automatic and non-discretionary. They activate when: * Maximum drawdown is breached (current value has fallen too far from peak) * Risk score exceeds 150% of the mandate's maximum * Liquidity risk exceeds 85/100 When an emergency stop fires, the vault is paused on-chain. No deposits, withdrawals, or rebalances can occur until the pause is lifted. *** #### Cycle Frequency The minimum interval between cycles is configured in the mandate. Even if a cycle determines that rebalancing is needed, it will not execute if the minimum interval has not elapsed since the last rebalance. # Interpreting Results Every decision cycle produces a structured record. Understanding these records is essential for monitoring RaxBot's behavior and verifying that it operates within your mandate. *** #### Decision Record Fields **Type** — The category of decision: hold, rebalance, emergency\_stop, or pending\_approval. **Status** — Whether the decision was executed, is awaiting approval, was rejected, or completed as a hold. **Current Allocation** — The vault's allocation at the time of the decision. **Proposed Allocation** — The allocation RaxBot recommends, if a change is warranted. **Current Risk Score** — The overall risk score at evaluation time, on a 0-100 scale. **Expected Risk Change** — How much the risk score would change if the proposal were executed. Negative values mean risk would decrease. **Compliance Check** — The result of validating the proposal against all mandate constraints. Lists any violations or warnings. **Rationale** — A human-readable explanation of why the decision was made. **Execution Details** — For on-chain executions: transaction hash, block number, gas used, and explorer link. For simulated executions: marked as simulated. *** #### Reading Compliance Results **Violations** are hard failures that block execution. Common violations: risk score exceeds mandate maximum, single protocol exceeds exposure limit, liquid assets below threshold, protocol not on allowlist, capital movement exceeds per-rebalance limit. **Warnings** indicate approaching limits without blocking execution. *** #### When to Intervene Manual intervention is appropriate when: repeated rejected proposals suggest the mandate is too restrictive, emergency stops require review before unpausing, pending approvals accumulate, or the rationale describes conditions you want to respond to differently. The correct response is always adjusting the mandate — not overriding individual decisions. # Access & Limits #### Access Requirements Full RaxBot access requires the Power tier (10,000+ $RAX) and explicit activation of auto-execute in the mandate settings. Autonomous mode is never enabled by default. At the Capital Deposited tier, users can run the Allocation Engine on demand and review decision history, but all proposals require manual approval. *** #### Mandate-Defined Limits All limits are per-vault and configured through the mandate: * **Maximum Risk Score** — default 50 * **Maximum Protocol Exposure** — default 40% * **Maximum Chain Exposure** — default 100% * **Minimum Liquidity Threshold** — default 10% * **Maximum Capital Per Rebalance** — default 25% * **Rebalance Threshold** — default 5% * **Minimum Rebalance Interval** — default 1 hour * **Maximum Drawdown** — triggers emergency stop * **Protocol Allowlist** — empty = all supported protocols allowed * **Asset Allowlist** — empty = all supported assets allowed * **Approval Threshold** — capital above which manual approval is required even in autonomous mode *** #### System Limits * The keeper wallet must maintain a minimum ETH balance for gas. Insufficient balance results in simulated (non-on-chain) execution. * The vault contract enforces the keeper role. Only the authorized address can call the rebalance function. * The Pausable mechanism halts all operations when triggered. * The drawdown check runs after every on-chain action. *** #### Adjusting Limits All mandate parameters can be modified through the Settings interface. Changes take effect on the next decision cycle. Mandate changes are versioned — each decision record references the active version, ensuring a clear audit trail. # API Overview RAX exposes internal API endpoints through Next.js API routes that power the dashboard and can be used for integration. *** #### Current State The API supports vault operations (create, deposit, withdraw, query state), allocation engine operations (evaluate, approve, reject, simulate), mandate management (create, update, read), and decision log retrieval. The API is currently internal and authenticated through wallet connection. Endpoints follow the pattern: /api/vault/\[action] /api/engine/\[action] /api/mandate/\[action] All endpoints accept and return JSON. *** #### Planned A public API with formal authentication (API keys), rate limiting, versioning, and comprehensive endpoint documentation is planned. This will enable external integrations, third-party dashboards, and programmatic access to risk intelligence. # Data Schemas #### Risk Metrics ```json { "overallScore": 35.2, "protocolRisk": 25.0, "concentrationRisk": 40.0, "liquidityRisk": 20.0, "volatilityExposure": 32.0, "alerts": ["MEDIUM: Moderate concentration risk"], "timestamp": "2026-03-14T12:00:00Z" } ``` #### Detailed Risk Breakdown (per vault/pool) ```json { "impermanent_loss_risk": 15.0, "smart_contract_risk": 25.0, "liquidity_risk": 30.0, "volatility_risk": 20.0, "protocol_risk": 10.0, "total_score": 21.5, "category": "LOW" } ``` #### Decision Record ```json { "type": "rebalance", "status": "executed", "vaultId": "...", "currentAllocation": [ { "protocol": "Aave", "percentage": 40, "amount": 4000 } ], "proposedAllocation": [ { "protocol": "Aave", "percentage": 30, "amount": 3000 }, { "protocol": "Compound", "percentage": 35, "amount": 3500 } ], "currentRiskScore": 42.5, "expectedRiskChange": -7.3, "expectedYieldChange": 1.2, "complianceCheck": { "isCompliant": true, "violations": [], "warnings": ["Risk score approaching maximum"] }, "aiRationale": "Portfolio rebalancing recommended to reduce concentration risk...", "mandateId": "...", "mandateVersion": 3, "execution": { "success": true, "txHash": "0x...", "blockNumber": 12345, "gasUsed": "142000", "simulated": false, "keeperAddress": "0x...", "explorerUrl": "https://sepolia.basescan.org/tx/0x..." } } ``` #### Mandate ```json { "riskTolerance": "balanced", "maxRiskScore": 50, "maxProtocolExposure": 40, "maxChainExposure": 100, "minLiquidityThreshold": 10, "maxCapitalPerRebalance": 25, "rebalanceThreshold": 5, "minRebalanceInterval": 3600, "maxDrawdown": 15, "protocolAllowlist": ["Aave", "Compound", "Uniswap", "Aerodrome"], "assetAllowlist": ["USDC"], "autoExecute": false, "requireApprovalAbove": 10000, "emergencyPaused": false, "version": 3 } ``` # Risk Disclosures RAX Protocol involves multiple categories of risk that users should understand before interacting with the system or depositing capital. *** #### Smart Contract Risk The vault and strategy adapter contracts may contain bugs or vulnerabilities. While the contracts use audited OpenZeppelin libraries (Ownable2Step, ReentrancyGuard, Pausable, ERC4626, SafeERC20), the RAX-specific logic has not undergone a formal third-party audit at this stage. A formal audit is planned before mainnet deployment. #### Strategy Risk Capital deployed to external protocols (Aave, Compound, Uniswap V3, Aerodrome) inherits the risks of those protocols, including smart contract vulnerabilities, governance attacks, oracle failures, and liquidity events. RAX monitors these protocols but cannot prevent their failure. #### Keeper Risk The keeper wallet is a single point of execution. If the keeper private key is compromised, unauthorized rebalances could occur within the onlyKeeper constraint. If the keeper process stops, the vault cannot rebalance until it is restored, though deposits and withdrawals remain functional. #### Model Risk Risk scores are derived from models with assumptions that may not hold under extreme or unprecedented market conditions. Scores may underestimate risk during black swan events or novel attack vectors. Models are comparative, not predictive. #### Liquidity Risk Exiting positions in low-liquidity protocols may result in slippage or delayed withdrawal. The mandate's minimum liquidity threshold mitigates but does not eliminate this risk. #### Testnet Status The current deployment is on Base Sepolia testnet. Testnet tokens have no monetary value. System behavior on testnet may differ from mainnet conditions. #### General Warning Users should not deposit more capital than they can afford to lose entirely. RAX provides risk intelligence and decision support, not guarantees. # Known Failure Modes RAX is designed to degrade safely under adverse conditions. Understanding known failure modes helps users configure mandates appropriately and respond to incidents. *** #### Keeper Process Interruption If the keeper process stops, the vault continues holding its current allocations but cannot rebalance or respond to changing conditions. The vault contract remains functional for deposits and withdrawals. The system does not auto-pause on keeper failure. #### Gas Exhaustion If the keeper wallet runs out of ETH for gas, rebalances are logged as simulated but not executed on-chain. The system falls back gracefully and will resume on-chain execution when the wallet is refunded. #### Mandate Too Restrictive Overly tight constraints can cause every proposal to be rejected, resulting in continuous hold decisions. The system will not take action that violates the mandate, even if conditions deteriorate. Users should monitor for this pattern and widen constraints when appropriate. #### Strategy Adapter Failure If an external protocol's adapter encounters an error — contract upgrade, paused protocol, or state change — the vault's totalAssets calculation may be affected. The vault will continue functioning with its idle balance. #### Emergency Stop Loop Under extreme volatility, emergency stops may trigger repeatedly. The vault will remain paused until conditions stabilize and an authorized address performs a manual unpause. #### Data Degradation In the presence of stale, incomplete, or unreliable data, risk scores may become less accurate. The system does not automatically increase conservatism when data quality declines — this is a known limitation. # Incident Response RAX Protocol includes monitoring and alerting mechanisms designed to surface abnormal conditions and potential incidents. *** #### What Constitutes an Incident An incident may include severe liquidity stress, rapid increases in Risk Scores, persistent high-severity alerts, widespread anomalies, or infrastructure disruptions. #### Detection RAX detects incidents through real-time monitoring, risk threshold breaches, anomaly detection in the decision cycle, and emergency trigger activation. When an incident is detected, alerts are generated according to configured severity levels. #### System Response Upon detecting an incident, RAX may increase alert frequency, highlight affected positions, apply more conservative behavior through mandate enforcement, restrict allocation suggestions to lower-risk positions, and — in critical cases — trigger an automatic emergency stop that pauses the vault on-chain. #### User Responsibilities During an Incident During elevated risk conditions, users should review alerts and supporting metrics, avoid increasing exposure without thorough analysis, reassess risk constraints and strategy profiles, use simulations to evaluate downside scenarios, and apply independent judgment. #### Communication Significant incidents affecting system-wide behavior may be communicated through in-app notifications, documentation updates, and public communication channels. Transparency is prioritized. #### Limitations Incident detection does not guarantee prevention of losses. RAX may not detect all incidents in advance, particularly those involving novel or unprecedented conditions. # Responsible Disclosure RAX Protocol is committed to the responsible disclosure and remediation of security vulnerabilities. *** #### Scope Responsible disclosure applies to vulnerabilities in RAX Protocol smart contracts, the vault and strategy adapter system, API and data handling, allocation and risk engine logic, and user-facing applications. Issues affecting external protocols (Aave, Compound, etc.) should be reported to their respective maintainers. #### How to Report If you believe you have identified a security vulnerability, please report it privately. Reports should include a clear description, steps to reproduce, potential impact assessment, and any relevant proof of concept. Do not publicly disclose vulnerabilities before remediation or coordination. #### Process Upon receiving a report, RAX will acknowledge receipt, assess severity and impact, work to validate and remediate, and coordinate disclosure timing. All reports are handled promptly. #### Bug Bounty A formal bug bounty program may be introduced in the future. Until then, responsible disclosure is encouraged and recognition may be provided on a case-by-case basis. # Overview The $RAX token is deployed on Base at address `0x3051a5e7AB247eBF2baa7Af9e3B574b344B175E3`. It serves as the access and coordination mechanism for the RAX Protocol ecosystem. Its primary purpose is to align usage and participation with long-term protocol health, rather than to serve as a speculative asset. *** #### Primary Functions **Feature Access** — $RAX holdings determine the user's access tier. Holding tokens unlocks progressively advanced platform features, from basic analytics to autonomous vault management. **Protocol Alignment** — Token-gated access ensures that users with meaningful participation in the ecosystem have access to the most powerful tools. *** #### Access Tiers | Tier | Minimum $RAX | Features Unlocked | | ------ | ------------ | ----------------------------------------------------------------------- | | Free | 0 | Risk Overview, basic exposure data | | Holder | 1 | Full vault rankings, advanced filters, alerts & monitoring | | Pro | 1,000 | Advanced simulations, allocation engine presets, full exposure analysis | | Power | 10,000 | Decision log export, full settings, governance preview, RaxBot access | *** #### What the Token Is Not $RAX does not represent equity, dividends, or guaranteed returns. Its value is derived from functional utility and participation within the protocol, not from financial guarantees. # Token Utility #### Tier-Gated Access The primary utility of $RAX is gating access to protocol features. The tier system reads the user's on-chain token balance to determine access level. Features unlock progressively as described in the Token Overview. #### Vault Fee Alignment (Planned) The vault charges management and performance fees denominated in USDC. Future governance may direct a portion of vault revenue to token holders through buyback, burn, or redistribution mechanisms. The specific mechanism will be determined through governance. #### Governance Participation (Planned) $RAX tokens will grant participation rights in governance decisions. Token holders may propose changes, vote on protocol parameters, and participate in strategic decisions. Governance rights may require staking or lock commitments. #### Non-Speculative Positioning The $RAX token is designed as a utility and coordination mechanism embedded in the protocol. It aligns access, usage, and incentives without positioning the token as a financial instrument. # Staking A staking mechanism for $RAX is planned to reward long-term participation and further align holder incentives with protocol health. *** #### Design Principles Staking is being designed around the following principles: * Rewards should be sustainable and tied to protocol usage, not inflationary emissions alone * Longer lock durations should receive proportionally higher rewards * Staking should create meaningful participation without creating exit barriers during emergencies #### Planned Features * Multiple lock duration options with corresponding reward tiers * Potential integration with governance weight — staked tokens may carry more voting power * Auto-compound option for staking rewards #### Current Status Staking is not yet live. Parameters including reward rates, lock durations, and mechanics will be defined through governance before launch. The staking UI exists in the application as a preview of the planned interface. # Governance Governance will enable $RAX token holders to participate in decisions that shape the protocol's parameters, strategies, and evolution. *** #### Scope of Governance Governance decisions may include: protocol parameter changes (fee structures, default mandate limits), approval of new strategy adapters, modifications to the tier system and access requirements, allocation of protocol revenue, and strategic direction. #### Design Principles * Proposals require sufficient support before reaching a vote * Voting power may be weighted by staking duration and amount * Critical changes require higher thresholds than routine adjustments * A timelock or delay period may apply before approved changes take effect #### Current Status Governance is under development. The governance UI in the application shows preview proposals to illustrate the planned experience. No binding governance votes are active at this time. # Guardrails Guardrails define the boundaries within which governance and autonomous systems operate, preventing unilateral changes that could harm users or destabilize the protocol. *** #### Mandate Guardrails The mandate system includes hard limits that governance cannot override: * Fee caps are enforced at the smart contract level (management fee max 5%, performance fee max 30%) * The keeper role is restricted to a single authorized address per vault * Emergency pause is always available to the owner, regardless of governance state * Drawdown protection activates automatically and cannot be disabled through governance #### Governance Guardrails When governance is active, it will include protections against governance capture: * Minimum quorum requirements for votes to be valid * Timelock periods between vote approval and execution * Emergency veto capability for critical security issues * Gradual rollout of parameter changes rather than instant application #### System Guardrails The protocol maintains several invariants: * The vault cannot allocate to strategies not registered through `addStrategy()` * Rebalance weights must sum to 10,000 basis points (100%) * The keeper cannot bypass the Pausable state * All decision records are immutable once logged These guardrails exist to ensure that no single actor — human or automated — can compromise the system's integrity. # App Roadmap #### Delivered * Five-dimensional risk scoring engine with Intelligence Score * ERC-4626 vault deployed on Base Sepolia with full deposit/withdraw lifecycle * Four strategy adapters: Aave, Compound, Uniswap V3, Aerodrome * Keeper-based autonomous rebalancing with on-chain execution * Mandate enforcement system with compliance checking and versioning * Decision logging with full rationale and execution details * Progressive access tiers — wallet-based and token-based ($RAX on Base) * Simulation engine for testing vault behavior under various conditions * Dashboard with risk analytics, exposure analysis, protocol status, and activity feed * Emergency stop mechanism with automatic pause on critical conditions #### In Progress * RaxBot as standalone autonomous process with scheduled decision cycles * LLM-powered explanation provider replacing template-based rationale * Notification layer for decision alerts (Telegram, webhooks) * Formal smart contract audit * Mainnet deployment preparation #### Planned * Public API with authentication, rate limiting, and versioning * Multi-chain support beginning with Ethereum mainnet and Arbitrum * Staking mechanism for $RAX with multiple lock durations * Governance framework and DAO structure * Additional strategy adapters for new protocols * Risk oracle for external protocol and DAO integration * Cross-chain allocation and monitoring * Bug bounty program