Skip to main content

Mamo

Mamo — 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).

Mamo — an AI/Agents non‑custodial “personal finance agent” on Base (a DeFi product): the user deposits USDC/cbBTC, and the system automatically allocates liquidity between Moonwell and Morpho for the best rates; token (symbol: MAMO) on the Base network (ERC‑20).

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: a non‑custodial “piggy bank with interest” on Base: you deposit USDC or cbBTC, the service itself chooses where to place it (Moonwell / Morpho) and auto‑compounds.
  • Who it’s for: ordinary users who want “their money to work”, but without constant management of DeFi positions.
  • Why onchain/token: onchain is needed for self‑custody (personal smart‑contract vaults and withdrawal at any time, even if the service is offline); the MAMO token exists, but per public Tier‑1 materials it is not required for basic use (USDC/cbBTC deposits).

How it works (very briefly)

  1. The user does: connects a wallet (Base) and deposits USDC or cbBTC into their own Mamo contract.
  2. The system does: allocates the deposit to the Moonwell Core Market or a Morpho vault (Moonwell Flagship/Frontier) and switches the position when rates change.
  3. The user gets: interest from borrowers + bonus tokens (WELL/MORPHO), which Mamo periodically converts into the base asset and reinvests (auto‑compounding).
  4. Where the blockchain is: the user’s personal strategy contracts, registry/strategy factories, onchain deposit/withdrawal/rebalancing operations; swaps via CowSwap with price checks against Chainlink oracles.
  5. Token role (if any): the MAMO token is issued on Base; its utility for the operation of the product is not described in the Tier‑1 documentation.

Quick links: AI thesis fit

Project passport

Field Value
Project name Mamo
Also known as (aliases) Mamo Agent; @Mamo_agent; MamoAIbot; $MAMO
Logo (logo) ../assets/126_mamo_logo.svg
Token symbol (ticker) MAMO
Category AI/Agents
Primary chain (chain) Base
Type EVM
Network status mainnet
Consensus (consensus) L2 (Optimistic Rollup, Base on Ethereum)
Launch date (launch_date) May 20, 13:39 UTC (genesis event; the year is not specified in the source)
Project status (status) active
Token (standard) ERC-20
Token contract 0x7300B37DfdfAb110d83290A29DfB31B1740219fE
Token model (token_type) —
Max supply 1,000,000,000 MAMO (fixed)
Issuance fixed
Tokenomics (tokenomics, brief) 10% airdrop; 25% treasury (24m vesting); 25% platform dev (24m vesting); 15% team (6m cliff + 24m); 15% Virtuals LP locked; 10% cbBTC LP locked
Governance company (Lunar Labs Inc.)
Admins/keys multisig + timelock (registry admin); guardian: multisig; backend address
Audit yes (Certora; Halborn)
Bug bounty yes (Code4rena)
Team (team) Lunar Labs Inc.
Funding (investors/funding) no VC allocations (as claimed)
AI component (ai_component) autonomous AI agent
Use‑case (use_case) auto-allocation yield for USDC/cbBTC
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 0 / 3
Last verified 2026-02-11

General project overview

Mamo is positioned as a “personal finance companion / autonomous agent” that helps the user earn yield on USDC and cbBTC deposits on the Base network without managing DeFi positions on their own. The product flow is simplified as much as possible: create an account, make a deposit, watch the balance grow.

On the technical side (Tier‑1), Mamo is built around personal smart contracts: separate contracts are deployed for the user (a USDC account and, if needed, a cbBTC account), tied to their wallet. This provides self‑custody: the user can withdraw funds at any time, even if the Mamo service is unavailable.

Features/modules

  • Personal smart‑contract vaults for USDC/cbBTC, tied to the user’s wallet.
  • Auto‑allocation of yield between the Moonwell Core Market and Morpho vaults (Moonwell Flagship/Frontier).
  • Reward collection and auto‑compounding: bonus tokens (WELL/MORPHO) are periodically converted into the base asset.
  • Conversion protection: swaps via CowSwap, price checks against Chainlink oracles and slippage limits (per the tech docs/repo).
  • Permissioned upgrades: strategy upgrades only with the user’s explicit consent.

Typical scenarios

  • Scenario 1 (USDC “piggy bank”): the user deposits USDC → Mamo places it in Moonwell or a Morpho vault and switches when rates change → yield accrues and compounds.
  • Scenario 2 (cbBTC “bitcoin account”): the user holds cbBTC on Base → Mamo places it in Moonwell/Morpho lending strategies → rewards are converted and reinvested.
  • Scenario 3 (withdrawal without trusting the service): the user withdraws funds directly from the contracts to their wallet (including when Mamo is offline).

Getting started (wallet/network)

  • What you need: an EVM wallet (for example, via WalletConnect) and USDC/cbBTC assets on the Base network; optionally — interaction via the Telegram bot.
  • Network/chain: Base.
  • Fees: Base gas fees for deposits/withdrawals/strategy moves; possible fees of third‑party protocols (Moonwell/Morpho) and/or swap executors (CowSwap) — depend on the operations.

Architecture/tech (non‑AI)

  • Components: Mamo Strategy Registry, strategy factories, strategies for Moonwell/Morpho, user contracts (USDC/cbBTC accounts), slippage/price checker, CowSwap integration via EIP‑1271 (isValidSignature), onchain pause guardian/multisig.
  • Participant roles: the user (owner of the contracts and the only one who can withdraw/upgrade upon approval); Mamo backend (can initiate updatePosition/rebalancing within the granted permissions); external bots/executors (can execute swaps at a valid price).
  • Where logic runs: the core custody/deposit/withdrawal/swap‑check logic and the limits — onchain (Base); computing “where the rate is better” and orchestrating actions — the offchain backend.
  • Dependencies: Moonwell, Morpho, CowSwap, Chainlink (oracles), Base L2.

Token/economics (expanded, no forecasts)

  • What the “product economy” actually is: the user’s yield comes in USDC/cbBTC (interest) + reward tokens (WELL/MORPHO), which the system converts back into the base asset and reinvests.
  • MAMO token utility: the Tier‑1 token page describes the supply and distribution, but does not describe the necessity of the token for the operation of the product (no explicit “payments in the token”/“governance via the token”/“collateral”).
  • Who pays fees: the user pays Base gas for onchain operations; third‑party protocol fees depend on the selected markets/operations.
  • Issuance/burn: total supply is fixed at 1B MAMO; burn/inflation mechanics are not claimed in Tier‑1.
  • Distribution and token issuance schedule: see the Tokenomics block in the passport (airdrops/vesting/LP locks).
  • Treasury: there is a treasury allocation (25% per the token page); the control and onchain mechanism of the treasury are not disclosed in this card.

Governance

  • Who makes decisions: Lunar Labs Inc. (legal documents); onchain admin roles for the registry/guardian — multisig addresses.
  • How protocol parameters/strategies change: the backend can initiate rebalancing; strategy upgrades require the user’s consent and are limited to a whitelist of implementations.
  • Keys/multisig (addresses): Mamo Multisig, Mamo Pause Guardian, Mamo Backend are published in Contract Addresses.

Security and incidents

  • Audits: Certora (March 2025; the report is attached on the Audits page) and Halborn Security (May 2025; link to the report).
  • Bug bounty: yes (Code4rena; claimed up to $250k).
  • Incidents: no public postmortems were found in the Tier‑1 sources in this card.
  • Threat model (notes): smart‑contract risk, risk of the Moonwell/Morpho protocols, oracle/DEX risk; at the same time, the design claims self‑custody and the absence of custody risk on Mamo’s side.

Project status and timeline

  • Current status: an active product on Base (USDC/cbBTC deposits via personal contracts).
  • Key milestones: audits in 2025 (Certora, Halborn); token genesis event — May 20 (time 13:39 UTC).
  • Roadmap: no public roadmap (Tier‑1) was found in this card.

Ecosystem/integrations

  • Integrations: Base, Moonwell, Morpho, CowSwap, Chainlink; liquidity pools are mentioned on the token page (Aerodrome).
  • Where it’s actually used: the onchain contracts and strategy logic are described in the GitHub repository and tech docs; the product page mamo.bot.

AI component of the project

  • What is real AI here? In its legal documents, Mamo is directly described as an “autonomous AI agent” that automates and optimizes DeFi yield strategies. At the same time, the Tier‑1 materials contain no technical description of models/LLMs/algorithms — so “AI reality” is confirmed only at the level of a declaration, without engineering details.
  • What is truly onchain? The user’s personal smart‑contract vaults/strategies on Base, registry/strategies/factories, onchain deposit/withdrawal/swap checks (CowSwap + Chainlink), published contract addresses.
  • Why is a token needed? The MAMO token exists (Base) and has a publicly described distribution, but its utility for the operation of the product (payment/collateral/governance) is not described in Tier‑1.
  • Red flags (based on the information found):
    • AI‑washing risk: an “AI agent” is claimed, but without technical details (what exactly the AI does and how it is measured).
    • token‑washing risk: the token exists, but without a proven necessity in the protocol.
    • operational risks: the backend address and admin roles (multisig/guardian) have influence over rebalancing/pausing/the strategy whitelist.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): Mamo is described as an “autonomous AI agent” for automating/optimizing DeFi yield strategies (without technical details).
  • Evidence: Tier‑1 — https://mamo.bot/docs/mamo-privacy-policy.pdf
  • Why sufficient / why not (one line): this is a Tier‑1 declaration of “AI intent/positioning”, but without a description of a specific AI module → AI_0 = 1.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): no Tier‑1 description was found of what exact AI function the agent performs (LLM/classification/optimization/planning) and where it is implemented.
  • Evidence: Tier‑1 — https://mamo.bot/docs/mamo-privacy-policy.pdf
  • Why sufficient / why not (one line): there is an “AI agent” wording, but without an operational description → AI_1 = 0.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): there is a public product, but it demonstrates DeFi automation; no separate Tier‑1 demo showing specifically the AI part was found.
  • Evidence: Tier‑1 — https://mamo.bot; https://t.me/MamoAIbot
  • Why sufficient / why not (one line): the existence of a product ≠ proof of an AI component → AI_2 = 0.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo
  • Why sufficient / why not (one line): there are no AI quality metrics/benchmarks in Tier‑1.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): no technical description of AI modules/models/versions was found (there is only the onchain architecture of the strategies).
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo/mamo/how-mamo-works; https://github.com/moonwell-fi/mamo-contracts
  • Why sufficient / why not (one line): the tech docs describe the smart contracts and orchestration in detail, but not an AI architecture → AI_4 = 0.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base
  • Addresses/identifiers: a list of contracts is published (registry/strategies/factories/backend/multisig/guardian) + the MAMO token address.
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo/technical/contract-addresses
  • Why sufficient / why not (one line): there are public addresses of the contracts and the network.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: the user’s personal strategy contracts, registry, strategy upgrades, EIP‑1271 validation of CowSwap orders, price/slippage checks, deposits/withdrawals — all of this is onchain mechanics that does not reduce to the token.
  • Evidence: Tier‑1 — https://github.com/moonwell-fi/mamo-contracts; https://mamo.gitbook.io/mamo/mamo/how-mamo-works
  • Why sufficient / why not (one line): Tier‑1 describes the specific onchain logic of the product.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, it is impossible to provide self‑custody/direct withdrawal from the personal vault (including when the service is offline) and transparent execution of the strategy rules.
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo/mamo/how-mamo-keeps-you-safe; https://mamo.gitbook.io/mamo/mamo/how-mamo-works
  • Why sufficient / why not (one line): the key promise “only you can move funds / withdraw even if Mamo is offline” relies on smart contracts.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, MAMO, on the Base network.
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo/mamo/the-mamo-token
  • Why sufficient / why not (one line): the token exists → TK_0 = 0.
  • 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 indication was found in the Tier‑1 documentation that the service is paid for with the MAMO token.
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo; https://mamo.gitbook.io/mamo/mamo/the-mamo-token
  • Why sufficient / why not (one line): there is no confirmation of payment utility → TK_1 = 0.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): there is no description in Tier‑1 of staking/collateral/penalties tied to MAMO.
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo/mamo/the-mamo-token
  • Why sufficient / why not (one line): there are no incentives/collateral/penalties via the token → TK_2 = 0.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): no indication was found in the Tier‑1 documentation that MAMO is used for governance.
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo/mamo/the-mamo-token
  • Why sufficient / why not (one line): there is no governance utility → TK_3 = 0.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the basic product runs on USDC/cbBTC deposits; the necessity of MAMO for the service is not proven → the token is replaceable/optional.
  • Evidence: Tier‑1 — https://mamo.gitbook.io/mamo/mamo/how-mamo-works; https://mamo.gitbook.io/mamo/mamo/the-mamo-token
  • Why sufficient / why not (one line): Tier‑1 does not describe the token as necessary for key actions, so its role is optional.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://mamo.gitbook.io/mamo/mamo/how-mamo-works Tier‑1 description of the flows: personal contracts for USDC/cbBTC, allocation to Moonwell/Morpho, auto‑compounding, upgrades with the user’s consent.
Tier‑1 https://github.com/moonwell-fi/mamo-contracts Tier‑1 technical description (README): registry/strategies/the backend role, EIP‑1271 + CowSwap + Chainlink price checks, upgrade rules.
Tier‑1 https://mamo.gitbook.io/mamo/technical/contract-addresses Tier‑1 list of contract addresses (registry/strategies/factories/backend/multisig/guardian) and the MAMO token address.
Tier‑1 https://mamo.gitbook.io/mamo/mamo/how-mamo-keeps-you-safe Tier‑1 security model: self‑custody, withdrawal even if the service is offline, permissioned upgrades, risks.
Tier‑1 https://mamo.gitbook.io/mamo/mamo/audits Tier‑1 confirmation of independent audits and the bug bounty (Certora + Halborn + Code4rena).
Tier‑1 https://www.halborn.com/audits/moonwell/mamo-contracts-369efe Public Halborn report on the Mamo contracts (May 2025).
Tier‑1 https://mamo.gitbook.io/mamo/mamo/the-mamo-token Tier‑1 facts about the token: address, fixed supply of 1B, distribution/vesting/LP locks, the “no VC allocations” statement.
Tier‑1 https://mamo.bot/docs/mamo-privacy-policy.pdf Legal Tier‑1: the wording “autonomous AI agent built on the Base network… automate/optimize yield strategies”.
Tier‑1 https://mamo.bot/docs/mamo-tos.pdf Legal Tier‑1: describes the service as an “autonomous agent… optimize DeFi yields”, mentions user inputs/prompts (User Content).

No comments to display

Back to top