Skip to main content

Mozaic

Mozaic — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Mozaic — an AI/Other | DeFi project on Arbitrum One, token (symbol: MOZ).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: vault products for automated yield farming.
  • Who it’s for: users who want to delegate the choice of farms/strategy rebalancing.
  • Why onchain/token: strategies are executed via DeFi contracts; participation/governance in the Mozaic DAO is tied to MOZ/xMOZ.
  • What you can actually touch (Tier‑1): https://app.mozaic.finance/

How it works (very briefly)

  1. The user does: connects a wallet and interacts with the vault products via the dApp.
  2. The system does: (per the documentation) the offchain component Archimedes evaluates APY/prices/fees and proposes a rebalance; the results are implemented in onchain execution.
  3. The user gets: automation of rebalancing/compounding within the chosen vault.
  4. Where the blockchain is: onchain — vault contracts and interactions with integrations (for example, GMX/Stargate); offchain — Archimedes computations/evaluation.
  5. Token role (if any): MOZ/xMOZ are used for membership/voting in the Mozaic DAO (xMOZ).

Quick links: AI thesis fit

Project passport

Field Value
Project name Mozaic
Also known as (aliases) MOZ, Mozaic Finance
Logo (logo) —
Token symbol (ticker) MOZ
Category AI/Other | DeFi | Infra
Primary chain (chain) Arbitrum One
Type EVM
Network status mainnet
Consensus (consensus) L2 (Optimistic Rollup, Arbitrum One on Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x20547341E58fB558637FA15379C92e11F7b7F710
Token model (token_type) utility (payments + staking + governance)
Max supply 1,000,000,000 MOZ
Issuance fixed
Tokenomics (tokenomics, brief) 1B minted at genesis (finite supply); xMOZ is converted from MOZ 1:1
Governance DAO (Mozaic DAO; voting via xMOZ)
Admins/keys —
Audit yes
Bug bounty yes
Team (team) —
Funding (investors/funding) —
AI component (ai_component) Archimedes (yield farming optimization, off-chain)
Use‑case (use_case) yield farming automation via vault strategies
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 2 / 1 / 3
Last verified 2026-02-11

General project overview

Mozaic describes itself as a set of vault products for yield farming, where the offchain component Archimedes makes decisions about rebalancing and compounding, and the onchain part implements these decisions via DeFi integrations.

Features/modules

  • Vault products (for example, Theseus/Hercules) with integrations into DeFi protocols (for example, GMX and Stargate).
  • Archimedes (the AI component): considers APY/predictive APY metrics, token prices, fees, slippage, TVL, volumes and other factors when choosing a strategy.

Typical scenarios

  • Scenario 1: a user deposits assets into a vault → the strategy manages the position and rebalances according to the product rules.
  • Scenario 2: a user tracks the state of the vault/position and the risks of the integrations → makes the entry/exit decision independently (without trading advice).
  • Scenario 3: a DAO member (holding xMOZ) votes on proposals → influences the parameters/directions of protocol development.

Getting started (wallet/network)

  • What you need: an EVM wallet.
  • Network/chain: Arbitrum One (the documentation also lists a MOZ contract on Base; xMOZ is described as available on Arbitrum).
  • Fees: network fees on deposits/withdrawals and on the protocol’s interactions with integrations.

Architecture/tech (non‑AI)

  • Components: vault contracts + integrations (for example, GMX/Stargate) + the offchain component Archimedes.
  • Participant roles: users of the vault products; DAO members (MOZ/xMOZ).
  • Where logic runs: Archimedes computations are claimed to be offchain; strategy execution — onchain.
  • Dependencies: integrated DeFi protocols; infrastructure of EVM networks.

Token/economics (expanded, no forecasts)

  • Token utility: the governance mechanics and DAO membership are tied to MOZ/xMOZ (voting rights are limited to xMOZ).
  • Protocol necessity drivers: participation in governance and the membership rules (xMOZ as the “voting key”).
  • Who pays fees: network users on onchain operations; the protocol/contracts — on interactions with integrations.
  • Where fees go: — (not found per Tier‑1 sources).
  • Issuance/burn: MOZ is described as finite supply (1B minted at genesis).
  • Security/incentive mechanisms: — (for the MOZ/xMOZ token, slashing/penalty mechanics were not found per Tier‑1 sources).
  • Distribution and token issuance schedule: — (not found per Tier‑1 sources).
  • Treasury: — (not found per Tier‑1 sources).

Governance

  • Who makes decisions: the Mozaic DAO (proposal process).
  • How protocol parameters change: via proposals/voting under the DAO rules; voting rights belong to xMOZ holders.
  • Where decisions are discussed/made: snapshot (link in the dApp) + documentation.
  • Keys/multisig: — (not found per Tier‑1 sources).

Security and incidents

Project status and timeline

  • Current status: mainnet (the product and the token are on EVM networks; per the passport — Arbitrum One).
  • Key releases/milestones: — (not found per Tier‑1 sources).
  • Roadmap: there is a token roadmap section in the documentation.

Ecosystem/integrations

  • Integrations: the documentation lists the vaults’ integrations (for example, GMX Market (GM) Pools; Stargate Finance).
  • Partners: — (not found per Tier‑1 sources).
  • Where it’s actually used: by users of the vault products via the dApp (the official interface).

AI component of the project

  • What is real AI here? The documentation describes the AI component Archimedes: it analyzes APY/price/fee data and makes decisions about rebalancing/compounding (the computations are claimed to be offchain).
  • What is truly onchain? Vault operations and integrations are executed onchain; the address of the MOZ token is published in the official documentation.
  • Why is a token needed? Under the Mozaic DAO rules, participation and voting are tied to MOZ/xMOZ (voting is limited to xMOZ holders).
  • Red flags (based on the information found): the absence of independent checks of the model/quality; risks of smart contracts and integrations; the gap between offchain decisions and onchain execution.

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity medium 2
Token necessity low 1
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): AI intent is present, but there are also stronger Tier‑1 descriptions of the AI feature (AI_1..AI_4).
  • Evidence: Tier‑1 — https://docs.mozaic.finance/
  • Why sufficient / why not (one line): AI_0 applies when there is only intent without a description of the AI mechanics; here the descriptions exist.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): Archimedes rebalances/compounds strategies, choosing more efficient yield pools based on a set of factors.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/archimedes/ai-fi
  • Why sufficient / why not (one line): The docs explicitly describe the AI feature and “how it works” at the process level.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a public dApp for interacting with the product (wallet connection, Claim/DAO/Docs sections).
  • Evidence: Tier‑1 — https://app.mozaic.finance/
  • Why sufficient / why not (one line): This is a reproducible official interface (“what you can touch”).
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 1
  • Metrics: comparative results of a simulation/test of the strategy (example: expected yield vs baseline).
  • Context (version/date/how measured): a 14‑day simulation (April 7th–14th, 2022) and live tests on Stargate (as described in the docs).
  • Evidence: Tier‑1 — https://docs.mozaic.finance/archimedes/machine-learning
  • Why sufficient / why not (one line): There are numbers and context; this is not an independent benchmark, but a sufficient minimum per the operational definition of AI_3.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): The input data/modeling process and the decision‑making logic are described, including the claim of offchain computations.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/archimedes/ai-fi , https://docs.mozaic.finance/archimedes/machine-learning
  • Why sufficient / why not (one line): There is a Tier‑1 description of the inputs/logic (without the full code/replication of the training).
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Arbitrum One
  • Addresses/identifiers: MOZ token (ARB): 0x20547341E58fB558637FA15379C92e11F7b7F710
  • Evidence: Tier‑1 — https://docs.mozaic.finance/token/moz
  • Why sufficient / why not (one line): The token contract address is published in the official documentation.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: vault contracts that interact with DeFi integrations (for example, GMX/Stargate) and implement the strategies.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/vaults/overview
  • Why sufficient / why not (one line): The docs describe the vault products and integrations, as well as onchain risks (smart‑contract exploit), which points to onchain logic.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: per Tier‑1 sources, no formalized Tier‑1 justification “without the blockchain the product breaks down” was found.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/
  • Why sufficient / why not (one line): The documentation records onchain execution, but does not prove criticality per the SSOT test.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has the MOZ and xMOZ tokens.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/token/moz , https://docs.mozaic.finance/token/xmoz
  • Why sufficient / why not (one line): The Tier‑1 documentation lists the tokens and the contract addresses.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): No direct description of mandatory payment for the service with the MOZ token was found in Tier‑1 sources.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/token/moz
  • Why sufficient / why not (one line): The token page describes the supply/addresses, but does not record payment as a requirement.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): Per Tier‑1 sources, no Tier‑1 description of collateral/penalties/slashing tied to MOZ/xMOZ was found.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/
  • Why sufficient / why not (one line): The docs have the MOZ↔xMOZ conversion and membership, but without slashing/penalty mechanics.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): Voting on proposals is limited to xMOZ holders; membership includes MOZ/xMOZ.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/governance/framework/membership
  • Why sufficient / why not (one line): The membership rules explicitly state the xMOZ requirement for voting.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The governance mechanics and DAO membership are described specifically through MOZ/xMOZ.
  • Evidence: Tier‑1 — https://docs.mozaic.finance/governance/framework/membership
  • Why sufficient / why not (one line): Under the published protocol rules, the tokens play the role of a “participation/voting key”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.mozaic.finance/archimedes/ai-fi Tier‑1: Archimedes (AI) is described as the rebalancing/compounding mechanism; the computations are claimed to be offchain.
Tier‑1 https://docs.mozaic.finance/archimedes/machine-learning Tier‑1: model design, input data and examples/results of simulations and live tests.
Tier‑1 https://docs.mozaic.finance/vaults/overview Tier‑1: the existence of vault products and integrations (the onchain logic is not limited to the token).
Tier‑1 https://docs.mozaic.finance/token/moz Tier‑1: max supply and the contract addresses of the MOZ token (ARB/Base).
Tier‑1 https://docs.mozaic.finance/governance/framework/membership Tier‑1: voting on proposals is limited to xMOZ holders.
Tier‑1 https://app.mozaic.finance/ Tier‑1: a public dApp (what you can touch) for interacting with the product.
Tier‑1 https://docs.mozaic.finance/security/vault-audits Tier‑1: links to audit reports (PDF) are published.
Tier‑2 https://www.coingecko.com/en/coins/mozaic Tier‑2 token profile/metadata and links (context).
Tier‑2 https://coinmarketcap.com/currencies/mozaic/ Tier‑2 token profile/metadata and links (context).

No comments to display

Back to top