Watchlists
Screener
Monitoring
Projects
Analytics
Research
News
More
Project
© Blockworks 2026
Product
ResearchNewsIntelScreenerRankingsWatchlistsCharts
Company
NewsletterPodcastsEventsBrand Assets
Resources
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
NewsletterPodcastsEventsBrand Assets

AI Rig Complex

AI · Agent Frameworks
OverviewChartsResearchNewsMarkets
OverviewChartsResearchNewsMarkets

Token Transparency Filing

B1 v1.1 · Filed 21 Sep 2026Partial - 6 gaps
This page was compiled by Blockworks using publicly available information reviewed consistent with the TTF. Certain categories of information are more likely to include undisclosed items (e.g., non-announced fundraisings or material relationships).

Project & Team

01

Description of Project

Provide a concise narrative that clearly states each of (a)–(e) below.

  • (a) Problem the project solves — The problem the project is solving.
  • (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
  • (c) High-level project overview — How the project works at a high level.
  • (d) Primary token functions — The primary functions of the token (e.g. gov participation).
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.

(a) Problem the project solves

AI Rig Complex describes Arc as a tokenized ecosystem for agentic AI built to help developers, enterprises, and users create, access, and monetize advanced AI agents and the services those agents use. Fragmentation across AI services and payment infrastructure is the core problem Ryzome is designed to address.

(Source: ARC Litepaper)

(b) Operational priorities

Current operational priorities include growing the Ryzome agent marketplace, funding and curating developers through the Handshake program, listing services in the Arc Registry after security and quality checks, and expanding the set of AI services that can transact through ARC-based payment rails. The litepaper states Ryzome aims to become a universal hub for AI services by 2026.

(Source: ARC Litepaper)

(c) High-level project overview

AI Rig Complex is an open-source Solana project built around the Rust-based Rig framework and a broader Arc ecosystem that includes the Arc Registry, Handshake, Arc Forge, and the planned Ryzome marketplace. Rig lets developers assemble modular AI agents using large-language-model endpoints, vector stores, and on-chain hooks. Ryzome is designed to connect those agents to Web2 and Web3 services through MCP (Model Context Protocol).

(Source: Kraken White Paper, ARC Litepaper)

(d) Primary token functions

ARC currently functions as an incentive and medium-of-exchange token inside the ecosystem, including rewards for ARC Experiments and other community challenges. ARC is the designated payment-and-reward token for the forthcoming Ryzome marketplace, and Arc Forge requires ARC for token launches and trading on its launchpad.

(Source: Kraken White Paper, ARC Litepaper)

(e) Control surface reliance

ARC token ownership does not confer currently exercisable governance rights. The Kraken white paper states that owning ARC does not grant governance rights, does not provide rights to revenue or assets of the issuer, and does not create special contractual rights against the issuer. The white paper identifies future applications that may include decentralized governance, but no on-chain governance mechanism is presently active.

(Source: Kraken White Paper)

02

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Full Name

Entity

Official Title

Prior Experience

Jephthah Akene

Labs / DevCo

Co-Founder and CEO, Playgrounds Analytics Inc.

Founder of Open Fusion Electronics (hardware/electronics venture); prior on-chain data analytics work via the Subgrounds/Playgrounds API product before pivoting to AI agent infrastructure.

Christophe Vauclair

Labs / DevCo

Co-Founder and CTO, Playgrounds Analytics Inc.

Prior experience at Protean Labs; Bachelor of Engineering in Computer Software Engineering, McGill University (2016–2020).

(Source: Kraken White Paper, RocketReach — Christophe Vauclair, GitHub — Jephthah Akene)

Labs / DevCo

The project does not operate a foundation entity. No public foundation entity or foundation leadership roster was identified in cited sources.
(Source: Kraken White Paper, arc.fun)

Foundation

The project does not have a DAO or on-chain governance mechanism. The Kraken white paper states that owning ARC does not grant governance rights, and no active on-chain voting system or governance forum has been publicly disclosed. The white paper acknowledges future governance applications may be developed but identifies none as presently active.
(Source: Kraken White Paper)

DAO / Onchain Governance

03

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).

  • (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
  • (b) Contract/admin powers — List onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
  • (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
  • (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
  • (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

The project does not have a DAO or on-chain governance mechanism. The answers below reflect that structure.

The public record does not disclose which entity formally owns the Rig framework codebase, Arc trademarks, or related IP. The Ryzome Terms of Service state that Playgrounds Analytics Inc. and its licensors retain rights in the Ryzome services, software, and underlying technology, but no formal IP assignment, license grant to a DAO, or trademark registration record has been publicly confirmed.

(Source: Ryzome Privacy & ToS)

(b) Contract/admin powers

The project does not have an active DAO governance structure with on-chain voting thresholds, executor powers, or multisig-controlled authority. The Kraken white paper states that owning ARC does not grant governance rights or special contractual rights against the issuer. Ecosystem access gates that exist outside a DAO context include a refundable 500 ARC Handshake deposit and security and quality review before services can be listed in the ARC Registry.

(Source: Kraken White Paper)

(c) Locked-token rights (conditional)

No locking or staking mechanism that grants additional governance rights has been identified.

(Source: Kraken White Paper)

(d) Value accrual & holder rights

ARC token ownership does not provide rights to revenue or assets of the issuer and does not create special contractual rights against the issuer. The litepaper describes a fee-flow model for the forthcoming Ryzome marketplace that allocates 85% of service fees to service providers, 10% to the Arc treasury, and 5% to Playgrounds operational costs. These fee flows are not currently active pending the Ryzome marketplace launch and have not been approved through a governance process.

(Source: Kraken White Paper, ARC Litepaper)

(e) Dissolution authority

No public disclosure of dissolution authority or wind-up mechanism for the project or any associated entity was identified.

04

Primary Foundation

For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

The project does not operate a foundation entity. No primary foundation entity directly involved in ARC issuance was identified in cited sources. Items (a)–(f) do not apply.

(Source: Kraken White Paper, arc.fun)

05

Primary Dev Co

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Playgrounds Analytics Inc. is a privately held corporation incorporated in the United States, with a registered address at 8122 Carver Heights, San Antonio, TX 78253, USA.

(Source: Kraken White Paper)

(b) IP ownership & control

Playgrounds Analytics Inc. and its licensors retain rights in the Ryzome services, software, and underlying technology per the Ryzome Terms of Service. The public 0xPlaygrounds/rig repository on GitHub hosts the Rig framework codebase. No formal trademark registration, patent filing, or IP assignment agreement has been publicly disclosed to confirm the precise scope of Playgrounds' IP ownership relative to its open-source contributions.

(Source: Ryzome Privacy & ToS, Rig GitHub, What is Ryzome)

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No DAO exists. Playgrounds Analytics Inc. controls the Arc Registry admission process, the Handshake program review flow, and Arc Forge token launch mechanics. The litepaper describes a 10% Arc treasury allocation from Ryzome service fees, but no public disclosure confirms the treasury's wallet address, control mechanism, or governance threshold.

(Source: Kraken White Paper, ARC Litepaper)

(d) Powers over Foundation

The project does not operate a foundation entity. This item does not apply.

(e) Contract/admin powers

No public disclosure of multisig configuration, smart contract upgrade authority, pause role holders, or governance-executor thresholds for Playgrounds Analytics Inc. was identified in cited sources.

(Source: Kraken White Paper)

(f) Current economic arrangements and distribution policies

The white paper states the project has primarily been funded by its founders and that exact budget or capital sources have not been publicly disclosed. The litepaper describes a forthcoming fee-flow model allocating 5% of Ryzome service fees to Playgrounds operational costs, but this mechanism is not yet active. No governance-approved, contractual, or programmatic distribution of protocol-controlled resources to Playgrounds Analytics Inc. or its equity holders has been publicly confirmed as currently operative.

(Source: Kraken White Paper, ARC Litepaper)

Token Supply & Allocations

06

Initial Allocation

Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.

  • (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
  • (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
  • (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
  • (d) Ticker / market symbol — The ticker/market symbol.
  • (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
  • (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).

(a) Launch supply totals

The maximum supply of ARC is 999,998,319 tokens. All tokens entered circulation or were allocated at launch: 90% (approximately 900 million ARC) entered open circulation through bonding-curve trading on Pump.fun, 5.5% (approximately 55 million ARC) was allocated to the Prize Pool and Treasury, and 4.5% (45 million ARC) was retained by the team and locked in escrow.

(Source: Kraken White Paper, ARC Tokenomics)

(b) Recipient categories & use of funds

  • Recipient Category: Open market fair launch (90%)
    • Publicly Described Use: Approximately 900 million ARC entered circulation via open bonding-curve trading on Pump.fun at TGE in December 2024 rather than through a pre-sale.
  • Recipient Category: Prize Pool and Treasury (5.5%)
    • Publicly Described Use: Approximately 55 million ARC is reserved to reward participants and winners of recurring gamified hackathons called ARC Experiments. The official tokenomics page describes this allocation as the reward pool for ARC Experiment participants and winners. Tokens are released at the conclusion of each ARC Experiment.
  • Recipient Category: Team / issuer retained (4.5%)
    • Publicly Described Use: 45 million ARC is retained by Playgrounds Analytics Inc. and locked in escrow. The official tokenomics page states this allocation supports ongoing development of the Rig framework, Arc ecosystem, and community.

(Source: Kraken White Paper, ARC Tokenomics)

(c) Initial price per token (if applicable)

No fixed public issue price was set. ARC was fair-launched on Pump.fun through open bonding-curve trading in December 2024. The token reached a trading low of approximately $0.029 on December 12–13, 2024, and an all-time high of approximately $0.45 on January 6–15, 2025.

(Source: Kraken White Paper, Gate.com ARC Price)

(d) Ticker / market symbol

ARC

(Source: Kraken White Paper)

(e) Total supply & supply regime

The maximum supply is 999,998,319 ARC. The supply is fixed with no inflation protocol, no supply adjustment mechanisms, and no token value protection or compensation schemes. The white paper states ARC has no supply adjustment protocols.

(Source: Kraken White Paper, ARC Tokenomics)

(f) Initial vesting / release schedules

The 4.5% team allocation (45 million ARC) is locked in escrow and vests over 12 months from TGE to support long-term alignment and reduce market disruption.

The precise escrow contract address, cliff period (if any), and tranche-by-tranche unlock schedule for the team allocation have not been publicly disclosed.

The 5.5% Prize Pool and Treasury allocation is released at the conclusion of each ARC Experiment on a rolling basis. No multi-year unlock calendar or maximum per-experiment release amount has been publicly disclosed.

The 90% fair-launch supply entered circulation immediately at TGE with no lock-up.

(Source: ARC Tokenomics, LBank ARC)

07

Airdrop Process

Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.

  • (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").

No token airdrop has been conducted and no TGE airdrop was identified in cited sources. Official sources describe a 5.5% prize pool and treasury allocation distributed to ARC Experiment participants and winners, and a Handshake developer program requiring a 500 ARC refundable deposit. Neither mechanism constitutes a public airdrop with per-address eligibility data.

(Source: Kraken White Paper, ARC Tokenomics, ARC Handshake)

Transactions & Market Structures

08

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:

  • (a) Market maker's name — the market maker's name;
  • (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
  • (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
  • (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.

If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.

No public market maker agreement involving Playgrounds Analytics Inc. or AI Rig Complex (ARC) was identified in cited sources. The Kraken white paper does not disclose a market maker arrangement, and no official announcement from Playgrounds or the arc.fun domain confirms a market maker engagement. Readers should note that a July 2023 press release announced an "ARC" token partnership with Gotbit, but that release names a Delaware entity with a different CEO (TJ Dunham) and is not associated with Playgrounds Analytics Inc. or this filing.

(Source: Kraken White Paper)

09

CEX / DEX Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:

  • (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
  • (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
  • (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
  • (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.

If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

The Kraken white paper discloses that Kraken sought admission to trading under MiCA. Additional CEX listings identified in public sources include CoinEx (December 12, 2024), Bitget (December 16, 2024), BingX Innovation Zone (December 25, 2024), Gate.io, MEXC, and KuCoin. No exchange-side token allocations, listing lockup terms, or native-token listing fees were disclosed for any of these listings in cited public sources.

(Source: Kraken White Paper, CoinEx Listing Announcement, Bitget Listing Announcement via Chainwire)

Financial Disclosures & Risks

10

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:

  • (a) Series Name
  • (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
  • (c) Date of sale (at least month & year)
  • (d) Number of tokens sold (or % of total supply)
  • (e) Vesting schedule

If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").

No prior token sales occurred. ARC was fair-launched on Pump.fun in December 2024, with 90% of supply entering circulation through open bonding-curve trading rather than a pre-sale. The Kraken white paper states the project has primarily been funded by its founders and that exact budget or capital sources have not been publicly disclosed. The official tokenomics page independently describes the circulating supply as fairly launched and available to the world from day one.

(Source: Kraken White Paper, ARC Tokenomics)

11

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

  • (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
  • (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
  • (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
  • (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
  • (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
  • (f) References (optional) — References (optional): link(s) to post-mortem/advisory/PR.

(a) Date & component affected

No exploits affecting tokenholders or protocol funds have been identified in cited sources as of June 17, 2026. The Kraken white paper's audit field is marked false with outcome listed as N/A, indicating no completed security audit had been conducted as of the white paper filing date.

(Source: Kraken White Paper, ARC Litepaper)

12

Material Risk Factors (Regulation, Technology, Token Economics)

Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.

  • (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:

  • Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?

  • Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?

  • Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?

  • Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?

  • (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:

  • Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?

  • Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?

  • (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:

  • Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?

  • Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?

(a) Regulatory, Legal & Tax Risks

The Kraken white paper states the document has not been approved by an EU competent authority and that ARC may lose value, may not always be transferable, and may not be liquid. Legal or regulatory action against Playgrounds Analytics Inc. in any jurisdiction could negatively affect ARC. ARC token holders do not obtain governance rights, revenue rights, or asset claims against the issuer, so tokenholder expectations are tied solely to functional ecosystem use rather than legal ownership or profit participation. The token's SPL-token structure on Solana and its MiCA-adjacent Kraken listing create regulatory exposure across multiple jurisdictions. Tokenholders are responsible for understanding and satisfying their own tax obligations in their respective jurisdictions, as the project does not provide tax guidance.

(Source: Kraken White Paper)

(b) Protocol, Technology & Security Risks

ARC relies on Solana smart contracts, uses the SPL token standard on Solana, and depends on third-party AI APIs including OpenAI and Anthropic. The Rig framework connects large-language-model endpoints, vector stores, and on-chain hooks, expanding the project's technical dependency surface across multiple third-party providers. The Kraken white paper's audit field is marked false with outcome N/A, meaning no completed security audit of the ARC smart contracts or Rig framework had been publicly confirmed as of that filing. The project's planned Ryzome marketplace introduces additional smart contract surface not yet publicly audited.

(Source: Kraken White Paper)

(c) Token Economics, Unlocks & Incentive Risks

ARC was fair-launched on Pump.fun with 90% of supply entering open circulation immediately at TGE. The 4.5% team allocation (45 million ARC) unlocks over 12 months from the December 2024 TGE, creating a finite but undisclosed unlock schedule that could introduce selling pressure. The 5.5% Prize Pool and Treasury allocation (approximately 55 million ARC) is released on a rolling basis at the conclusion of each ARC Experiment, with no maximum per-experiment release cap disclosed. ARC's utility model depends on continued participation in ARC Experiments, Arc Forge usage, and the future Ryzome marketplace launch, which carries no publicly disclosed launch date. The litepaper's fee-flow model — allocating 85% to service providers, 10% to the Arc treasury, and 5% to Playgrounds operating costs — is not yet operative pending the Ryzome marketplace launch.

(Source: Kraken White Paper, ARC Litepaper, ARC Tokenomics)

This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.

Project
OverviewChartsToken DisclosuresResearchNewsMarkets
Curious what full access looks like?
Access premium insights on ETH and BTC pages for free.
BTCETH