Skip to main content

GAIB

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

GAIB — an RWA/Infra and DeFi project: an “economic layer” for tokenizing/financing AI infrastructure (GPUs/robots/energy) and issuing related products (AID/sAID); token: GAIB (EVM, multi‑chain).

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 “financial layer” protocol built on top for tokenizing and financing real‑world assets tied to AI infrastructure (compute/robotics), and for their DeFi composition.
  • Who it’s for: investors/liquidity providers, partners/asset operators, validators/participants of the validation network.
  • Why onchain/token: onchain is needed to account for the rights/states of tokenized assets and products; the GAIB token — for staking/validation/slashing, governance and incentive distribution.

How it works (very briefly)

  1. The user does: deposits assets/liquidity and gets access to ecosystem products (e.g., AID/sAID) and to yield tied to the financing of AI infrastructure (per the docs).
  2. The system does: validates and “financializes” (tokenize/attest) real‑world assets (GPUs/robotics/energy) through the PROOF/ONRAMP/REWARD/LIQUID layers, and then reflects economic events in settlement networks (NETWORK).
  3. The user gets: tokenized positions/products, potentially — yield (within the protocol model).
  4. Where the blockchain is: onchain — tokens, product smart contracts, accounting and enforcement of rules (fee logic/governance/staking/slashing).
  5. Token role (if any): GAIB — governance + staking/restaking for AVS/validation, as well as incentives (including access/allocations per the participation model).

Quick links: AI thesis fit

Project passport

Field Value
Project name GAIB
Also known as (aliases) $GAIB
Logo (logo) ../assets/168_gaib_logo.png
Token symbol (ticker) GAIB
Category RWA | Infra | DeFi
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0xC19D38925F9F645337B1D1f37bAf3C0647A48E50
Token model (token_type) utility (staking + incentives + governance)
Max supply 1,000,000,000 GAIB (cap per the docs; the explorer shows a different max total supply)
Issuance fixed cap (per the docs); distribution/emissions are tied to bootstrapping/activity
Tokenomics (tokenomics, brief) staking/restaking for AVS with possible slashing; governance via stGAIB/veGAIB (per the docs)
Governance hybrid onchain governance (stGAIB/veGAIB; progressive decentralization — Atreides Council → tokenholder‑led)
Admins/keys a timelocked upgrade framework is claimed (per the docs); specific keys/addresses are not listed in this card
Audit yes (Audits page in the docs, PDF)
Bug bounty —
Team (team) —
Funding (investors/funding) investors/partners are listed in the docs (see links)
AI component (ai_component) AI as an "asset class" (GPU/robots), not AI models
Use‑case (use_case) financialization of AI infrastructure (RWAiFi)
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 3 / 2 / 3
Last verified 2026-02-11

General project overview

GAIB positions itself as a “Modular Economic Layer for AI Infrastructure”: a protocol that connects DeFi capital with the financing of real AI infrastructure (data centers/“neoclouds”/robotics), and issues onchain representations of assets and products on top of them (e.g., the AI Dollar AID and the yield‑vault token sAID).

Note on networks (passport normalization): the passport lists Ethereum (per the token) as the primary chain. The mention of a bridge to BNB Chain remains in the text as context.

According to the documentation, GAIB builds a multi‑layer architecture (LIQUID/REWARD/ONRAMP/PROOF/NETWORK), where the PROOF layer is a validation/attestation network (AVS) that uses shared security restaking platforms (EigenLayer and Symbiotic are mentioned).

Features/modules

  • Modular protocol architecture: LIQUID/REWARD/ONRAMP/PROOF/NETWORK (per the docs).
  • Tokenization/attestation of AI infrastructure: proof mechanics (location/custody/workload) and recording of states onchain.
  • Ecosystem products: AID and sAID (per the docs).
  • GAIB token: governance + staking/validation and incentives, including access/allocations for participants (per the docs).

Typical scenarios

  • Scenario 1 (liquidity contribution): a user deposits assets into GAIB products → receives a tokenized position (AID/sAID) with yield mechanics per the product rules.
  • Scenario 2 (security/validation): a validator stakes/restakes GAIB → participates in attestations/validation and receives rewards (with slashing risk).

Getting started (wallet/network)

  • What you need: an EVM wallet; for the token/products — the network where the corresponding contracts are deployed; for the bridge — a separate interface.
  • Network/chain: Ethereum; a bridge to BNB Chain is also mentioned.
  • Fees: gas of the chosen EVM network; possible protocol fees (e.g., a tokenization fee and a protocol fee, per the docs).

Architecture/tech (non‑AI)

  • Components: smart contracts (tokens/products), the PROOF validation network (AVS), bridge/multi‑chain integrations, deposit/product interfaces.
  • Participant roles: users/LPs, validators/attestation operators, partners/AI infrastructure providers, governance participants.
  • Where logic runs: accounting/enforcement of rules and token issuance — onchain (EVM); attestations and verification of the state of real‑world assets — offchain + onchain recording of the results.
  • Dependencies: restaking protocols (EigenLayer, Symbiotic are mentioned), multi‑chain connectivity, offchain providers of asset data.

Token/economics (expanded, no forecasts)

  • Token utility: governance (stGAIB/veGAIB), security/validation (staking/restaking, slashing), access/allocations and incentives (per the docs).
  • Protocol necessity drivers: validators and governance participants use GAIB to participate in AVS/attestations and in decision‑making; incentives are tied to GAIB.
  • Who pays fees: users/protocol participants; the docs describe a tokenization fee (1%) and a protocol fee (20% of AI asset rewards).
  • Where fees go: to the treasury/reserves and onward — per the governance policy (per the docs).
  • Issuance/burn: the docs claim a fixed cap of 1B; distribution details are partially “coming soon” in the Tokenomics & Governance section (as of the verification date).
  • Security/incentive mechanisms: staking/restaking with slashing risk for AVS; incentives/airdrops/TVL programs (per the docs).
  • Distribution and token issuance schedule: available on a separate $GAIB Token page (including diagrams/images); the specific figures in the distribution table are best checked against the primary source (see links).
  • Treasury: managed via the governance process (Atreides Council → Fremen Rule), per the docs.

Governance

  • Who makes decisions: hybrid governance (per the docs: the “Atreides Council” → “tokenholder‑led / Fremen Rule” stages; stGAIB/veGAIB mechanics).
  • How protocol parameters change: via onchain governance structures (stGAIB/veGAIB) and smart contract upgrades within the claimed timelocked upgrade framework (address/key details are not listed in this card).
  • Where decisions are discussed/made: the official docs + public channels (see links_*: Website/X/Discord).
  • Keys/multisig: the docs claim a timelocked upgrade framework, but specific addresses/threshold/signers were not found in the reviewed Tier‑1 sources.

Security and incidents

  • Audits: yes (the audits/transparency page in the docs; see links_* → Audit report(s)).
  • Bug bounty: —.
  • Incidents: — (no public postmortems/incidents were found in the reviewed sources).
  • Threat model: risks of attestations/data from the real world (RWA), dependence on restaking platforms and offchain providers, upgrade risks (upgradeability) and governance centralization at early stages.

Project status and timeline

  • Current status: active (the token on Ethereum; products and governance structures are described in the docs; see links_*).
  • Key releases/milestones: —.
  • Roadmap: — (no separate public roadmap page was found in the reviewed Tier‑1 sources; in links_* the Roadmap field = —).

Ecosystem/integrations

  • Integrations: Ethereum (EVM), a bridge to BNB Chain (per the docs), restaking/shared security (EigenLayer and Symbiotic are mentioned), the onchain products AID/sAID.
  • Partners: investors/partners are listed in the docs (see links_* → Docs/Whitepaper).
  • Where it’s actually used: as an onchain economic layer for tokenized AI infrastructure and DeFi products (described in the docs; see links_*).

AI component of the project

  • What is real AI here? In Tier‑1 sources, “AI” mostly appears as a class of financed assets (GPUs/robotics/energy) and as market context, not as an embedded ML system/model in the product.
  • What is truly onchain? the GAIB token, the products (AID/sAID) and governance/staking/validation and event accounting in settlement networks (per the docs).
  • Why is a token needed? governance + AVS security/validation (staking/slashing) + incentives/coordination (per the docs).
  • Red flags (based on the information found): AI‑washing — high risk of interpretation: “AI” may mean only the asset/market; double‑check the presence of AI models/inference in the system itself (if the project starts claiming otherwise).

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity high 3
Token necessity high 2
Evidence Tier‑1 present 3
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): in Tier‑1 sources, “AI” describes the domain of assets/infrastructure; plans to build AI models/inference as a product are not singled out.
  • Evidence: Tier‑1 — https://docs.gaib.ai/gaib-overview/gaib-protocol
  • Why sufficient / why not (one line): this is not an “intent to build an AI product”, but positioning around AI infrastructure.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): the documentation contains no description of an AI model/inference/training as a protocol function.
  • Evidence: Tier‑1 — https://docs.gaib.ai/gaib-overview/gaib-protocol ; https://docs.gaib.ai/products/gaib-products
  • Why sufficient / why not (one line): the product is financial/validation infrastructure for assets, not an AI system.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a demo specifically of an AI module/model is not claimed as part of the protocol.
  • Evidence: Tier‑1 — https://docs.gaib.ai/gaib-overview/gaib-protocol
  • Why sufficient / why not (one line): the project does not position an “AI demo” as a product module.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.gaib.ai/gaib-overview/gaib-protocol
  • Why sufficient / why not (one line): AI models are not described as a product component; metrics are absent.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is a protocol architecture, but no technical description of an AI model/inference as a component.
  • Evidence: Tier‑1 — https://docs.gaib.ai/gaib-overview/gaib-protocol
  • Why sufficient / why not (one line): the “tech” concerns onchain layers/asset validation, not AI systems.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: GAIB token: 0xC19D38925F9F645337B1D1f37bAf3C0647A48E50
  • Evidence: Tier‑1 — https://etherscan.io/token/0xC19D38925F9F645337B1D1f37bAf3C0647A48E50
  • Why sufficient / why not (one line): the token address and parameters (including max total supply/decimals) are confirmed by the explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: tokenized products (AID/sAID), fee logic and governance/staking (stGAIB/veGAIB) are described as onchain mechanics.
  • Evidence: Tier‑1 — https://docs.gaib.ai/products/gaib-products ; https://docs.gaib.ai/products/tokenomics-and-governance
  • Why sufficient / why not (one line): the Tier‑1 documentation describes onchain products and rule structures on top of the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without a blockchain, tokenization/DeFi composition and the verifiable onchain accounting of economic events/rights under the products break down.
  • Evidence: Tier‑1 — https://docs.gaib.ai/gaib-overview/gaib-protocol
  • Why sufficient / why not (one line): the protocol’s core mission is to “bring real-world compute onto blockchain rails”.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, GAIB.
  • Evidence: Tier‑1 — https://docs.gaib.ai/gaib-overview/usdgaib-token ; https://etherscan.io/token/0xC19D38925F9F645337B1D1f37bAf3C0647A48E50
  • Why sufficient / why not (one line): the token is confirmed by the docs and the explorer.
  • 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): a direct “payment with the token for a service” as a mandatory mechanic is not described; the utility is governance/validation/incentives.
  • Evidence: Tier‑1 — https://docs.gaib.ai/products/tokenomics-and-governance
  • Why sufficient / why not (one line): the tokenomics frames the role as coordination/security, not as a payment token for a service.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): GAIB is staked/restaked for AVS, and violations lead to slashing; incentive programs (airdrop/TVL/ongoing) are also described.
  • Evidence: Tier‑1 — https://docs.gaib.ai/products/tokenomics-and-governance ; https://docs.gaib.ai/gaib-overview/usdgaib-token
  • Why sufficient / why not (one line): the docs explicitly describe staking/slashing as part of the security model.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): governance via stGAIB/veGAIB, voting on parameters/asset classes/deployments.
  • Evidence: Tier‑1 — https://docs.gaib.ai/products/tokenomics-and-governance ; https://docs.gaib.ai/gaib-overview/usdgaib-token
  • Why sufficient / why not (one line): the docs describe the governance framework and the role of locked/escrowed tokens.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the token is described as the core of security/validation/incentives and governance, i.e. by design — not an optional component.
  • Evidence: Tier‑1 — https://docs.gaib.ai/products/tokenomics-and-governance
  • Why sufficient / why not (one line): staking/slashing and governance are tied to the token.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.gaib.ai/gaib-overview/gaib-protocol Protocol architecture (the LIQUID/REWARD/ONRAMP/PROOF/NETWORK layers), the “bring compute onchain rails” thesis, the role of restaking security
Tier‑1 https://docs.gaib.ai/products/tokenomics-and-governance Token utility: governance, security/validation, fee model (tokenization fee 1%, protocol fee 20% rewards)
Tier‑1 https://docs.gaib.ai/gaib-overview/usdgaib-token A more detailed description of the utility, governance structures and the 1B cap (per the docs)
Tier‑1 https://etherscan.io/token/0xC19D38925F9F645337B1D1f37bAf3C0647A48E50 The GAIB token address on Ethereum, decimals and onchain parameters (including max total supply in the explorer)
Tier‑1 https://docs.gaib.ai/transparency-and-audit/audit The presence of audit PDFs for the AID/sAID (and related) contracts

No comments to display

Back to top