# MOZAI MOZAI is the MoneyOS, the DeFAI layer of Rivalz: a set of agents that operate non-custodial smart wallets on behalf of users. Think of it as **agent-native infrastructure for money**: * capital lives in non-custodial smart wallets. * agents compete to run strategies on top. * the Rivalz Network verifies that every action is safe and valid before the agent can execute real transactions. *** #### How it works? MOZAI treats each Agent strategy as an **agent + smart wallet** pair. * The **smart wallet** is a smart contract that can hold assets, positions and claims in external DeFi protocols. * The agent is an off-chain process that can propose actions for the vault, but only within the ruleset encoded on-chain. Strategies differ only by: * which assets they accept. * which protocols are whitelisted. * which objective the agent optimizes (e.g. stable yield, blue-chip yield, later LP or hedging). From the user’s perspective, MOZAI is simple:\ Pick a strategy → fund the agent → let it run. From the network perspective, each MOZAI position is just another address interacting with DeFI under strict policy enforcement. *** #### Architecture At a high level, MOZAI works like this: > **User (EOA) → creates a MOZAI Smart Wallet → Agent → powered by ADCS / OCY / zNodes → DeFi protocols → Yield returned to the User.** MOZAI runs on the following * **Data Layer** – a blend of our own DefiLama-style and Nansen-style data streams, providing the agents with low-latency. * **Risk Control** - every position and protocol comes with a wide set of risk metrics early-exit triggers. * **AI Layer** – determines what actions are worth taking and selects the best optimization models (ADCS). * **Agent Execution Layer** – turns decisions into intents and handles execution. * **On-Chain Layer** – agentic smart wallet infrastructure. The agent never holds private keys. All power is mediated through the vault contract and its on-chain policy. *** #### Safety model MOZAI is non-custodial by design: * the vault is a contract controlled by the user’s EOA. * agent permissions are constrained to a fixed set of calls and limits. * high-impact reallocations can be gated behind zNode attestations. * any attempt to act outside the configured policy simply reverts. The user can always withdraw from the vault back to their EOA, independent of MOZAI’s off-chain services, as long as the underlying chain and protocols are live. *** #### Current scope In its initial version, MOZAI focuses on **lending and yield**: * single-asset vaults (e.g. USDC) on supported chains. * curated sets of lending and yield protocols. * agents that periodically rebalance across these venues based on best performance. The goal is straightforward: move away from manual “farm rotation” and towards continuous, rules-driven allocation, without changing the non-custodial model users are used to. *** #### Direction The same architecture extends naturally to: * LP management, leverage and perps strategies. * external strategy authors plugging their own agents into the same infrastructure. * multi-chain deployment where the Rivalz Network remains the coordination and verification layer while vaults live on the execution chains. MOZAI is the first surface where this pattern is visible: agents, oracles and validators coordinating around a vault the user still owns. Everything else in Rivalz is built to make that loop reliable at larger scale. The plan:\ 1\. Everything users do on-chain can be done better by agents.\ 2\. Show more use-cases and amplify adoption.\ 2\. Grow TVL. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rivalz.ai/mozai.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.