Skip to main content

ARC / AI Rig Complex

ARC / AI Rig Complex (ARC) — 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).

ARC / AI Rig Complex — an AI/Agents | Infra ecosystem around the Rig Rust framework (building LLM agents) and the claimed “agentic app store” Ryzome; the ARC token on the Solana network.

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: an ecosystem and community around the open‑source Rust framework rig for building AI agents + the claimed “Ryzome” (an agentic app store/visual AI workspace platform).
  • Who it’s for: developers of AI agents/tools and users of agentic applications.
  • Why onchain/token: the ARC token is claimed as the “fuel” of the services/agents economy (payments and revenue distribution), while most of the AI logic runs offchain.
  • What you can actually touch (Tier‑1): the ARC architecture documentation + the public rig repository (code/examples), as well as the public Ryzome pages (ryzome.ai).

How it works (very briefly)

  1. The user/developer does: chooses a model provider and assembles an agent based on rig (or uses agent services from the ecosystem).
  2. The system does: rig orchestrates LLM calls, tools, memory/vector stores and multi‑agent flows; Ryzome (per the litepaper description) connects the agent to Web2/Web3 services via MCP.
  3. The user gets: an agentic workflow (summarization/automation/service calls) and/or ready‑made agentic services.
  4. Where the blockchain is: the ARC token exists onchain on Solana; in the description of the economy (litepaper), payments for services/agents are expected to go through ARC with revenue distribution.
  5. Token role: payments and the economy/incentives of the ARC ecosystem (85/10/5 split in the litepaper).

Quick links: AI thesis fit

Project passport

Field Value
Project name ARC / AI Rig Complex
Also known as (aliases) ARC | AI Rig Complex | arc.fun
Logo (logo) ../assets/45_ai-rig-complex_logo.svg
Token symbol (ticker) ARC
Category AI/Agents | Infra
Primary chain (chain) Solana
Type non-EVM
Network status mainnet
Consensus (consensus) PoS (Solana)
Launch date (launch_date) 2025-03-07 (litepaper date; token launch — not established)
Project status (status) active
Token (standard) SPL
Token contract 61V8vBaqAGMpgDQi4JcAwo1dmBGHsyhzodcPqnEVpump
Token model (token_type) utility (payments + fees)
Max supply —
Issuance —
Tokenomics (tokenomics, brief) revenue split: 85% to providers, 10% growth/treasury, 5% ops (per the litepaper)
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) Playgrounds (as the team/engine in the litepaper)
Funding (investors/funding) —
AI component (ai_component) Rust LLM agent framework (Rig)
Use‑case (use_case) build + orchestrate AI agents
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 1 / token_score 2 / evidence_score 3
Last verified 2026-02-11

General project overview

ARC (AI Rig Complex) describes itself as an ecosystem that aims to “bridge AI and blockchain” for composable agent services. Two levels are distinguishable in the Tier‑1 sources:

  • Rig — an open‑source Rust framework for building LLM agents (orchestration, tools, embeddings, multi‑agent and integrations).
  • Ryzome — a claimed “agentic app store / visual workspace” that connects agents to Web2/Web3 services via a standard interface (MCP) and assumes payment for services/agent calls via the ARC token.

That is, in essence this is not an “AI blockchain network” but AI infrastructure (code/framework) + a community/marketplace idea, where the blockchain figures as the economic layer.

Features/modules

  • Rig framework (Tier‑1): a Rust library for building and orchestrating AI agents, with support for model providers, embeddings, memory/vector stores and multi‑agent.
  • On‑chain integrations (Tier‑1): the architecture description claims a link to Solana/Arbitrum and other networks for reading onchain data/calling contracts (integrations — via the Rig ecosystem).
  • Ryzome (Tier‑1): a public platform/product, “second brain / infinite canvas” + agentic workflows (on the architecture page and in the list of “real‑world users” in the Rig README).
  • ARC economy (Tier‑1 litepaper): the token as the payment layer for services/agents, revenue distribution 85/10/5.

Typical scenarios

  • Scenario 1 (dev): a developer uses rig to assemble an agent (prompting + tools + embeddings/memory) → runs an agentic workflow in their application.
  • Scenario 2 (agentic app store): a user/agent in Ryzome calls services via MCP (Web2/Web3) → the workflow performs the task end‑to‑end → payment/fee is expected in ARC (per the litepaper).
  • Scenario 3 (onchain integration): an agent reads onchain data and initiates an onchain action (claimed as a capability via on‑chain integrations).

Getting started (wallet/network)

  • What you need: for a developer — the rig repository (Rust), a choice of model provider and an environment; for a user — access to Ryzome (a public product). For onchain operations — a Solana wallet and the ARC token.
  • Network/chain: Solana (the ARC SPL token).
  • Fees: Solana fees for onchain operations; fees inside Ryzome/marketplace services depend on the specific provider (the litepaper describes a revenue split).

Architecture/tech (non‑AI)

  • Components: the ARC SPL token (Solana), website/docs, rig (Rust library), Ryzome (web product), integrations with LLM providers and vector stores.
  • Participant roles: developers (builders), service/agent providers, Ryzome users, token holders.
  • Where logic runs: AI computation and orchestration — offchain (LLM providers/infrastructure); onchain — the token and (potentially) settlement/accounting of payments.
  • Dependencies: LLM providers (Anthropic/OpenAI/and others), MCP integrations with services, Solana as the token’s network.

Token/economics (expanded, no forecasts)

  • Token utility: the token is described as the means of payment for services/agents and the “fuel” of the agent economy.
  • Protocol necessity drivers: the litepaper links payments for services/agent calls to ARC and records the revenue split.
  • Who pays fees: users of services/agent calls (per the litepaper description) + participants in onchain operations (Solana fees).
  • Where fees go: revenue split: 85% service providers, 10% Arc growth/treasury, 5% ops (per the litepaper).
  • Issuance/burn: — (not extracted as Tier‑1 from the available sources).
  • Security/incentive mechanisms: incentives for providers/developers via fee flows; an anti‑spam measure in Handshake: “small ARC deposit to prevent spam” (architecture page).
  • Distribution/vesting: — (not extracted).
  • Treasury: the litepaper mentions an “Arc treasury” (10% of flows), but the control mechanics are not disclosed in the extracted Tier‑1.

Governance

  • Who makes decisions: — (not established from the reviewed Tier‑1 sources).
  • How protocol parameters change: —.
  • Where decisions are discussed/made: —.
  • Keys/multisig: —.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: — (not established).
  • Threat model: centralization of Ryzome/model providers; absence of Tier‑1 parameters for issuance/treasury control; a separate check is also required of where exactly ARC is a mandatory element of the product.

Project status and timeline

  • Current status: the website/architecture and litepaper are public; the rig repository is active; Ryzome is publicly available.
  • Key releases/milestones: litepaper v1 is dated 2025‑03‑07; rig releases are published in GitHub releases.
  • Roadmap: — (there is no roadmap in links_*; not extracted as Tier‑1).

Ecosystem/integrations

  • Integrations: model providers (Anthropic/OpenAI/and others — on the architecture page); integrations with vector stores (via the rig ecosystem); on‑chain integrations (Solana/Arbitrum are claimed).
  • Partners: the website has a list of ecosystem partners (for example Solana/Eternal AI/Hyperbolic and others); the details of the partnerships require re‑checking.
  • Where it’s actually used: rig is used as a library for LLM applications; the README gives examples of real users/projects, including Ryzome.

AI component of the project

  • What is real AI here? Tier‑1 records the real AI component as infrastructure for LLM agents (rig): orchestration of completion/embeddings, tool‑calling, multi‑agent and memory/vector stores.
  • What is truly onchain? Onchain fact: the ARC token on Solana. In the ecosystem description, onchain figures as the economic layer (payments/accounting), but specific protocol‑level onchain logic other than the token is not proven in the reviewed Tier‑1 sources.
  • Why is a token needed? In the litepaper, the token is described as the “fuel” of the agent economy and the means of settlement for services/agent calls, with revenue distribution 85/10/5.
  • Red flags (based on the information found): token‑washing risk (it must be checked where ARC is actually mandatory vs optional), centralization of the AI part (model providers/the Ryzome platform), lack of Tier‑1 on supply/issuance and control of the “treasury”.

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity low 1
Token necessity medium 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): There are signs of AI reality per Tier‑1 (see AI_1..AI_4), so the AI_0 flag (intent‑only) does not apply.
  • Evidence: Tier‑1 — see Evidence/links in AI_1..AI_4.
  • Why sufficient / why not (one line): AI_0=1 is admissible only when AI_1..AI_4=0; here ai_score without AI_0 = 3.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): rig is a Rust library for building LLM applications/agents (workflows, completion/embeddings, tool‑calling, multi‑agent).
  • Evidence: Tier‑1 — https://github.com/0xPlaygrounds/rig
  • Why sufficient / why not (one line): the Tier‑1 repository describes specific AI functionality as a library for LLM agents.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there are reproducible examples: the rig repository with usage examples (Simple example) and the public ARC pages with architecture/docs (as well as the public Ryzome product).
  • Evidence: Tier‑1 — https://github.com/0xPlaygrounds/rig, https://www.arc.fun/architecture, https://ryzome.ai/
  • Why sufficient / why not (one line): the existence of code examples + a public product page/platform provides “what you can touch”.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://github.com/0xPlaygrounds/rig
  • Why sufficient / why not (one line): Tier‑1 contains no formal benchmarks/“quality” metrics of AI models/agents as part of the protocol.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): there is a technical description of the ecosystem components (Rig framework, on‑chain integrations, memory/vector stores) and documentation/architecture.
  • Evidence: Tier‑1 — https://www.arc.fun/architecture, https://github.com/0xPlaygrounds/rig
  • Why sufficient / why not (one line): the architecture page + the README/repository structure provide technical context.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Solana
  • Addresses/identifiers: token ARC (SPL): 61V8vBaqAGMpgDQi4JcAwo1dmBGHsyhzodcPqnEVpump
  • Evidence: Tier‑1 — https://www.arc.fun/index.html, https://solscan.io/token/61V8vBaqAGMpgDQi4JcAwo1dmBGHsyhzodcPqnEVpump
  • Why sufficient / why not (one line): the token address is listed on the official website; an explorer link is present in links_*.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: within the extracted Tier‑1, no protocol‑level onchain logic is recorded beyond the existence of the token and claims about payments.
  • Evidence: Tier‑1 — https://www.arc.fun/blog/arc_litepaper_v1
  • Why sufficient / why not (one line): the litepaper describes the economy/payments, but does not provide verifiable onchain contracts/modules beyond the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the key AI component (Rig/agents/platform) can run offchain; the necessity of “specifically a blockchain” is not proven by Tier‑1 as mandatory for the core function.
  • Evidence: Tier‑1 — https://github.com/0xPlaygrounds/rig, https://www.arc.fun/blog/arc_litepaper_v1
  • Why sufficient / why not (one line): the token adds an economy, but the criticality of onchain for the operation of the AI framework is not shown.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, ARC (SPL) on Solana.
  • Evidence: Tier‑1 — https://www.arc.fun/index.html
  • Why sufficient / why not (one line): the token and the contract address are listed on the official website.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): the litepaper describes payment for services/agent calls via ARC (settlement in Arc tokens) in Ryzome.
  • Evidence: Tier‑1 — https://www.arc.fun/blog/arc_litepaper_v1
  • Why sufficient / why not (one line): Tier‑1 directly links payments for services to the ARC token.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): revenue is distributed between providers and the ecosystem (85/10/5), and an “ARC deposit to prevent spam” for Handshake is mentioned.
  • Evidence: Tier‑1 — https://www.arc.fun/blog/arc_litepaper_v1, https://www.arc.fun/architecture
  • Why sufficient / why not (one line): Tier‑1 describes economic incentives and an anti‑spam deposit.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance via the ARC token is not confirmed in the reviewed Tier‑1 sources.
  • Evidence: Tier‑1 — https://www.arc.fun/blog/arc_litepaper_v1
  • Why sufficient / why not (one line): the litepaper speaks about the economy/payments, but does not record onchain governance mechanics for the token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the token is not established per Tier‑1 (no strict comparison with alternatives).
  • Evidence: Tier‑1 — https://www.arc.fun/blog/arc_litepaper_v1
  • Why sufficient / why not (one line): there is a description of the token’s role in the economy, but no argument for “why it cannot be replaced”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://www.arc.fun/index.html Official ARC page; the ARC (SPL) token address and basic positioning; links to the architecture and the litepaper.
Tier‑1 https://www.arc.fun/architecture Tier‑1: description of the ecosystem components (Rig framework, on‑chain integrations, memory/vector stores, Handshake deposit).
Tier‑1 https://www.arc.fun/blog/arc_litepaper_v1 Tier‑1: description of Ryzome (agentic app store), the MCP approach and the ARC payment economy (85/10/5).
Tier‑1 https://github.com/0xPlaygrounds/rig Tier‑1: open‑source rig — a Rust framework for LLM agents (features + examples).
Tier‑1 https://github.com/0xPlaygrounds/rig/releases Tier‑1: rig releases/changes (changelog/versions).
Tier‑1 https://ryzome.ai/ Tier‑1: the public page of the Ryzome product (what you can “touch”).
Tier‑2 https://dexscreener.com/solana/j3b6dvhes2y1cbmtvz5tcwxnegsjjdbukxduvdpoqms7 Context on the trading pair/liquidity (not proof).
Tier‑3 — —

No comments to display

Back to top