Skip to main content

Common

Common (Common Protocol, COMMON) — 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).

Common — an Infra protocol/client for “programmable communities”: it allows creating onchain “loops” (incentive structures) around user actions (onchain transactions and offchain activities) and paying out rewards; token: COMMON (ERC‑20 on the Base 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: a coordination protocol for communities: “loops” define actions, reward rules, duration and hooks into external contracts.
  • Who it’s for: communities/projects that need to manage incentives around actions (posts, votes, transactions); developers who want to build their own clients around loops.
  • Why onchain/token: onchain is needed to record loop state and distribute rewards; the role of the COMMON token (beyond the existence of the contract) is not detailed in Tier‑1.

How it works (very briefly)

  1. The user does: participates in a loop (for example, makes a post/upvote/onchain action) and submits an “action” (including via a relayer).
  2. The system does: accepts intents, checks hook conditions (gating/calls to external contracts), computes the result and distributes rewards according to the schedule.
  3. The user gets: an NFT/token reward (or another prize), depending on the reward schedule.
  4. Where the blockchain is: loop creation and hooks — onchain; actions can be an offchain intent with a relayer, while payouts — onchain.
  5. Token role (if any): the COMMON token exists on the Base network; specific mandatory utilities are not recorded in Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name Common
Also known as (aliases) Common Protocol; Commonwealth; commondotxyz; COMMON
Logo (logo) ../assets/157_common_logo.png
Token symbol (ticker) COMMON
Category Infra | Social
Primary chain (chain) Base
Type EVM
Network status mainnet
Consensus (consensus) L2 (Optimistic Rollup, Base on Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x4c87da04887a1F9F21F777E3A8dD55C3C9f84701
Token model (token_type) —
Max supply 10,000,000,000 COMMON (BaseScan “Max Total Supply”); the contract contains a mint() function (issuance above the initial supply is possible if roles exist).
Issuance fixed initial supply (10B) / potentially inflationary (if the minter is active) — requires checking governance/roles.
Tokenomics (tokenomics, brief) Initial mint to a vault (per the contract code); distribution goals/utility are not disclosed in Tier‑1 sources.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI agents as future loop participants
Use‑case (use_case) programmable incentives for communities
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 2 / 0 / 2
Last verified 2026-02-11

General project overview

Common Protocol describes itself as a “primitive” for community coordination: instead of manual management (content, votes, grants, funding, onchain actions), it proposes assembling loops — programmable incentive structures. A loop defines:

  • actions: for example, posts/upvotes on a forum, onchain transactions, or proofs from a zkTLS operator;
  • reward schedule: which rewards are issued (NFT/FT, etc.) and under which rules;
  • duration: a one‑time or recurring cycle;
  • hooks: calls to external contracts before/after an action (for example, governance calls or gating by token ownership).

The post emphasizes that actions can be submitted as offchain intents (directly or via a relayer), while rewards and hooks are executed onchain. The “agents” direction is also noted separately: the expectation that loops will become infrastructure where AI agents can coordinate with humans and perform onchain activity.

Features/modules

  • Loops (core primitive): onchain objects with actions/rewards/duration/hooks.
  • Hooks into external contracts: calls to governance contracts, DeFi contracts, etc. (claimed).
  • Relayers/intents: submission of actions by users without having to make a transaction themselves at every step.
  • Integrations with offchain activities: examples (forum posts/upvotes), plus “proofs from zkTLS operator” (claimed).

Typical scenarios

  • Scenario 1 (community/DAO): creates a contest loop → participants perform actions (posts/upvotes/transactions) → winners receive rewards.
  • Scenario 2 (builder): writes a new client on top of loops → connects external contracts via hooks → automates coordination.
  • Scenario 3 (agents): (intent) AI agents perform actions and drive onchain activity within loops.

Getting started (wallet/network)

  • What you need: an EVM wallet for Base + an account/access to common.xyz.
  • Network/chain: Base.
  • Fees: Base fees when creating loops/paying out rewards and calling hooks; when relayers are used, some actions may be hidden from the user.

Architecture/tech (non‑AI)

  • Components: onchain loop contracts and the COMMON token (Base); clients (common.xyz and potentially third‑party ones), relayers for intents.
  • Participant roles: loop creator, participants (submit actions), relayer, external protocols/contracts for hooks.
  • Where logic runs: creation of loops and hooks — onchain; actions can be an offchain intent; reward payouts — onchain.
  • Dependencies: Base RPC, external contracts (governance/DeFi) for hooks, a zkTLS operator (for some proofs — claimed).

Token/economics (expanded, no forecasts)

  • Token utility: the Tier‑1 sources used do not disclose whether COMMON is mandatory for loops (beyond the fact that the token exists onchain).
  • Supply: BaseScan shows a max total supply of 10B COMMON; the code has initialSupply and a mint() function with the MINTER_ROLE role → potential issuance requires checking who holds the roles.

Governance

  • Governance: not described in the Tier‑1 sources used.

Security and incidents

  • Audits/bug bounty/incidents: not recorded in the Tier‑1 sources used.
  • Risks: hook/relayer errors, abuse of reward schemes, centralization risks of token/contract roles.

Project status and timeline

  • Current status: active (there is a public post about Common Protocol and an onchain token on Base).
  • Roadmap: the post provides a high‑level roadmap (Q1–Q4 2025) and development directions for loops/agents.

Ecosystem/integrations

  • Integrations: examples of hooks into external contracts (governance/DeFi) and integrations with social platforms (Farcaster — “soon”, per the post).
  • Where it’s actually used: the post provides an example of a contest loop for the Common forum (posts and upvotes).

AI component of the project

  • What is real AI here? Tier‑1 contains no description of an own AI system; there is a claimed direction that loops will become infrastructure where AI agents can coordinate with humans and perform onchain activity.
  • What is truly onchain? Creation of loops, hooks into external contracts and payouts of reward schemes; also the COMMON token on Base.
  • Why is a token needed? The COMMON token exists onchain; a mandatory utility in the protocol (payment/stake/governance) is not confirmed by Tier‑1.
  • Red flags (based on the information found): AI‑washing — AI is mentioned as “agents” without artifacts; onchain‑washing — offchain intents and onchain execution need to be distinguished; token‑washing — the token utility is not disclosed; “max supply” versus mint() — the roles need to be checked.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): A direction is claimed that loops may become infrastructure where AI agents will coordinate with humans and perform onchain activity.
  • Evidence: Tier‑1 — https://blog.common.xyz/common-protocol/
  • Why sufficient / why not (one line): This is a Tier‑1 intent/positioning about agents, without proof of a working AI component (AI_1..AI_4 = 0).
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): Tier‑1 does not describe an own AI module/model/agent — only compatibility/future scenarios.
  • Evidence: Tier‑1 — https://blog.common.xyz/common-protocol/
  • Why sufficient / why not (one line): The mentions of agents do not describe “what the AI does” as a product component.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): No demo of AI agents operating within loops is presented.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There are no examples of outputs/agent actions as an artifact.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Quality metrics for the AI component are absent (the AI component is not described).
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): The technical description of the AI agents/models is not disclosed.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): The post about the protocol describes loops/hooks, but not an AI architecture.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base (EVM L2)
  • Addresses/identifiers: COMMON ERC‑20: 0x4c87da04887a1F9F21F777E3A8dD55C3C9f84701
  • Evidence: Tier‑1 — https://basescan.org/token/0x4c87da04887a1F9F21F777E3A8dD55C3C9f84701
  • Why sufficient / why not (one line): The explorer confirms the token contract 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: Loops are created onchain and can execute hooks into external contracts; reward payouts are described as part of the mechanics.
  • Evidence: Tier‑1 — https://blog.common.xyz/common-protocol/
  • Why sufficient / why not (one line): The post describes “once a loop has been created onchain…” and hooks into external contracts.
  • Conflict note (if any): Technical details/addresses of the loop contracts are not provided in the post.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the incentive scheme can be implemented in a centralized way; an argument at the level of “without onchain the rationale breaks down” is not given in Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): OC_3 requires an explicit “replace the blockchain” test, which is absent.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, COMMON, on the Base network.
  • Evidence: Tier‑1 — https://basescan.org/token/0x4c87da04887a1F9F21F777E3A8dD55C3C9f84701
  • Why sufficient / why not (one line): The contract and supply are visible in 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): Tier‑1 contains no statement that COMMON is mandatory as payment for the service.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): The description of loops talks about a reward schedule, but not about payment in the COMMON token.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): Staking/collateral/slashing via COMMON are not described.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no description of incentives tied specifically to COMMON (rewards in any tokens/NFTs are possible).
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): Governance via COMMON is not confirmed by Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Governance is mentioned as hooks into external contracts, not as governance of the COMMON protocol.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): Per Tier‑1, no unique role of COMMON is visible; loops can use NFTs/any FT for rewards → COMMON is potentially replaceable.
  • Evidence: Tier‑1 — https://blog.common.xyz/common-protocol/
  • Why sufficient / why not (one line): The description of the reward schedule does not record COMMON as mandatory.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://blog.common.xyz/common-protocol/ What loops are (actions/reward schedule/hooks), that loops are created onchain; the “agents” direction.
Tier‑1 https://basescan.org/token/0x4c87da04887a1F9F21F777E3A8dD55C3C9f84701 Onchain confirmation of the COMMON token on Base (supply, mint/vault roles per the code).
Tier‑1 https://github.com/hicommonwealth/commonwealth The existence of a public repository of the client/platform (development context).
Tier‑2 — —
Tier‑3 — —

No comments to display

Back to top