Skip to main content

Unibase

Unibase (UB) — 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).

Unibase — an infrastructure project that, in Tier‑1 sources, describes a “decentralized AI memory layer” for autonomous AI agents: long‑term memory (Membase), an agent interoperability protocol (AIP; MCP + gRPC compatibility), and a storage/DA layer (Unibase DA). The UB token is issued as an ERC‑20 on Ethereum.

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: “memory + interoperability” for AI agents (storage of/access to memory, identity, interaction between agents).
  • Who it’s for: developers of agent systems and protocols; teams building multi‑agent applications.
  • Why onchain/token: onchain is used for attestable identity/accounting/verifiability; UB is described as the token for fees/governance/staking in the ecosystem (Tier‑1 whitepaper).
  • What you can actually touch (Tier‑1): Unibase Explorer (a showcase of onchain “agents/memory” entities).

How it works (very briefly)

  1. The user does: launches/registers an agent and uses memory/messages/tools via AIP.
  2. The system does: stores the agent’s “memory” (structured/unstructured) and enables inter‑agent interactions via the protocol and runtime.
  3. The user gets: persistent, reusable agent memory and compatibility across ecosystems/tools.
  4. Where the blockchain is: Tier‑1 sources claim onchain identity/auth and onchain anchoring/verifiability of data; there is Unibase Explorer as a showcase of onchain entities.
  5. Token role: UB is described as the means of paying protocol fees, governance (veUB) and staking (Tier‑1).

Quick links: AI thesis fit

Project passport

Field Value
Project name Unibase
Also known as (aliases) UB
Logo (logo) ../assets/unibase_logo.svg
Token symbol (ticker) UB
Category AI/Agents | Infra
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x6944E1DF6Bf5972305f9Ab25dF47ef10De01bcc8
Token model (token_type) utility (payments + staking + governance)
Max supply 10,000,000,000 UB
Issuance fixed (minted at deploy)
Tokenomics (tokenomics, brief) 10B UB; the whitepaper gives the distribution/vesting by category
Governance DAO (veUB; claimed)
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) decentralized memory layer for AI agents
Use‑case (use_case) persistent memory + agent interoperability
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 3 / 2 / 2
Last verified 2026-02-11

General project overview

In its Tier‑1 documentation, Unibase positions itself as a “decentralized AI memory layer” for autonomous agents. The core idea: agents should have long‑term memory (rather than being stateless), be able to share knowledge and coordinate across ecosystems, while the data should be verifiable/cryptographically attestable.

Features/modules

  • Membase: the memory layer (storage/reads/integrity proofs; Tier‑1 describes zk‑proofs).
  • AIP (Agent Interoperability Protocol): the agent interaction protocol (Tier‑1 claims MCP + gRPC compatibility).
  • Unibase DA: the data availability/storage layer for real‑time data access (Tier‑1).

Typical scenarios

  • Scenario 1: an agent stores context/knowledge → then reads/updates its memory → continues working with a “history”.
  • Scenario 2: several agents exchange messages and share access to memory via the AIP runtime.
  • Scenario 3: an agent/user interacts with the registry/identity layers for permissions and access.

Getting started (wallet/network)

  • What you need: an EVM wallet (for the UB token) and access to the Unibase tools/SDK/docs.
  • Network/chain: Tier‑1 confirms the UB ERC‑20 contract on Ethereum; product onchain entities are shown in Unibase Explorer.
  • Fees: onchain fees on the base blockchain network + protocol fees (described as a model in the whitepaper).

Architecture/tech (non‑AI)

  • Components: registry/identity layer (contracts), runtime (MCP + gRPC), memory (Membase), DA/storage (Unibase DA), explorer.
  • Participant roles: agent developers/operators, users, (potential) node/storage operators.
  • Where logic runs: memory storage/access and identity accounting are claimed to be onchain/zk‑verified + an offchain runtime for interactions.

Token/economics (expanded, no forecasts)

  • Token utility: the Tier‑1 whitepaper describes UB for protocol fees, governance (veUB), agent staking and “knowledge mining”.
  • Supply: Tier‑1 claims a total supply of 10B UB and gives the distribution/vesting by category.
  • Issuance/burn: the ERC‑20 contract on Etherscan shows a mint of 10B UB in the constructor (fixed supply).

Governance

The Tier‑1 whitepaper describes governance via veUB and a gradual transition to DAO governance.

Security and incidents

  • Security advisories: there are GitHub Security Advisories for the official SDK repository.
  • Audits/bug bounty: no Tier‑1 public programs/reports were found (—).

Project status and timeline

  • Current status: the Tier‑1 docs claim “Testnet Live” and a set of integrations/SDKs; at the same time, the UB token exists as an ERC‑20.
  • Roadmap: — is left in links_* (there is no single explicit Tier‑1 roadmap page).

Ecosystem/integrations

  • Integrations: the Tier‑1 docs claim compatibility/integrations with MCP and some agent frameworks (the list is in the documentation).

AI component of the project

  • What is real AI here? in Tier‑1, Unibase does not “build a model”, but builds infrastructure for AI agents: memory, interoperability, identity.
  • What is truly onchain? Tier‑1 describes onchain identity/registry and the verifiability/auditability of memory; additionally, there is Unibase Explorer.
  • Why is a token needed? UB is claimed as the protocol token for fees/staking/governance; without a token these functions are in principle replaceable by other mechanisms, but this changes the protocol’s economy/incentives.
  • Red flags (based on the information found): check the real scope of the onchain part (addresses of the identity/registry contracts and parameters), and the actual activity (the explorer currently shows zero values).

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): the AI functionality is described as a current product layer (memory/interoperability), not merely a roadmap intent.
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): the whitepaper describes the modules and their purpose, which is more than “intent”.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): a product AI layer: long‑term memory and interoperability of autonomous AI agents.
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): Tier‑1 explicitly describes what the system does for AI agents (memory + interoperability).
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): a live testnet is claimed and there is an explorer for “agents/memory” entities.
  • Evidence: Tier‑1 — https://unibase.gitbook.io/docs ; https://www.explorer.unibase.com/
  • Why sufficient / why not (one line): the Tier‑1 docs claim testnet live; the explorer confirms the existence of an interface.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): quantitative quality/performance metrics for the AI part are not presented as verifiable indicators.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): Tier‑1 has an architecture (Membase/AIP/Unibase DA) and a description of the layers.
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper ; https://openos-labs.gitbook.io/unibase-docs/aip-whitepaper
  • Why sufficient / why not (one line): the architectural modules and interactions are described.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum (UB token)
  • Addresses/identifiers: UB ERC‑20: 0x6944E1DF6Bf5972305f9Ab25dF47ef10De01bcc8
  • Evidence: Tier‑1 — https://etherscan.io/token/0x6944E1DF6Bf5972305f9Ab25dF47ef10De01bcc8
  • Why sufficient / why not (one line): the onchain fact of the token and its supply parameters is verifiable via Etherscan.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: onchain identity/registry and accounting/verifiability for agent memory (as described in Tier‑1).
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/aip-whitepaper ; https://www.explorer.unibase.com/
  • Why sufficient / why not (one line): AIP describes an onchain identity layer; the explorer shows the “agents/memory” domain entities.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: replacing it with an ordinary DB loses the claimed key property — verifiable/trustless memory and identity for agents.
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): “decentralized + cryptographically verifiable” is the stated goal of the product.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): UB exists as an ERC‑20.
  • Evidence: Tier‑1 — https://etherscan.io/token/0x6944E1DF6Bf5972305f9Ab25dF47ef10De01bcc8
  • Why sufficient / why not (one line): the contract and max supply are verifiable onchain.
  • Conflict note (if any): —

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): the Tier‑1 whitepaper describes UB for protocol fees (storage/reads/proofs/bandwidth).
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): the token utility lists fees for using the modules.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): UB is used for agent staking and “knowledge mining” rewards.
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): the token utility lists staking/knowledge mining.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): governance via veUB (lock UB).
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): governance is described as lock UB → veUB.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): fees/governance/staking are theoretically implementable without a native token, but this changes the incentive design.
  • Evidence: Tier‑1 — https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper
  • Why sufficient / why not (one line): Tier‑1 describes UB as a design choice, but does not prove that it is the only possible mechanism.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://openos-labs.gitbook.io/unibase-docs/unibase-whitepaper the modules (Membase/AIP/DA), the “AI memory layer” purpose, token utility and the distribution of 10B UB
Tier‑1 https://openos-labs.gitbook.io/unibase-docs/aip-whitepaper AIP: identity layer, runtime (MCP+gRPC), memory/DA layers
Tier‑1 https://unibase.gitbook.io/docs “Testnet Live” status, description of the modules and integrations
Tier‑1 https://www.explorer.unibase.com/ the existence of an explorer for agents/memory
Tier‑1 https://etherscan.io/token/0x6944E1DF6Bf5972305f9Ab25dF47ef10De01bcc8 onchain fact of UB: max supply 10B and the contract
Tier‑1 https://github.com/unibaseio/unibase-sdk-go/security/advisories security advisories for the official repository

No comments to display

Back to top