Grass
Grass (GRASS) — 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).
Grass — infrastructure for collecting public web data through a distributed network of nodes (nodes/routers/validators) and turning it into structured datasets. The project describes ZK proofs and checkpointing of data “to the blockchain” to verify provenance and distribute rewards; the GRASS token is used for payments/staking/incentives and governance.
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 network where users/nodes share internet resources, while the system collects public web data and packages it as verifiable datasets.
- Who it’s for: (1) people/node operators who want to earn rewards; (2) data buyers/developers who need datasets.
- Why onchain/token: the project promises verifiable data provenance and reward calculation via onchain checkpoints; GRASS is used to pay for operations, for staking to routers, and for governance.
How it works (very briefly)
- The user does: runs the Grass App/Grass Node and provides unused network resources (traffic relay).
- The system does: routers and the validator route/verify web transactions, form sessions, generate proofs and publish onchain checkpoints.
- The user gets: rewards in GRASS (and/or “points” within the ecosystem — as a mechanism for accounting activity).
- Where the blockchain is: the documentation describes ZK proofs and checkpoints of session data “on L1” for provable provenance and transparent reward distribution.
- Token role: GRASS — settlement for network operations/datasets, staking to routers, incentives and governance.
Quick links: AI thesis fit
Project passport
| Field | Value |
|---|---|
| Project name | Grass |
| Also known as (aliases) | GRASS |
| Logo (logo) | ../assets/36_grass_logo.svg |
| Token symbol (ticker) | GRASS |
| Category | AI/Data | Infra |
| Primary chain (chain) | Solana |
| Type | non-EVM |
| Network status | mainnet |
| Consensus (consensus) | PoS (Solana) |
| Launch date (launch_date) | — |
| Project status (status) | active |
| Token (standard) | SPL |
| Token contract | Grass7B4RdKfBCjTKgSqnXkqjwiGvQyFbuSCUJr3XXjs |
| Token model (token_type) | utility (payments + staking + governance) |
| Max supply | 1,000,000,000 GRASS (fixed total supply) |
| Issuance | fixed cap + unlock/vesting by allocation |
| Tokenomics (tokenomics, brief) | fixed supply; allocations to community/ecosystem/investors/contributors; GRASS is used for network payments and staking to routers |
| Governance | token governance (described in the documentation) |
| Admins/keys | — |
| Audit | — |
| Bug bounty | — |
| Team (team) | — |
| Funding (investors/funding) | — |
| AI component (ai_component) | web data → structured datasets + provenance |
| Use‑case (use_case) | crowd bandwidth → datasets for AI |
| DecAI Fit — AI thesis fit | 5/6 — high alignment with the Decentralized AI thesis |
| DecAI Fit component summary | 2 / 3 / 3 / 3 |
| Last verified | 2026-02-11 |
Links (links_*)
| Type | Link |
|---|---|
| Website | https://www.getgrass.io/ |
| Docs | https://grass-foundation.gitbook.io/grass-docs |
| GitHub | — |
| Releases / Changelog | — |
| Whitepaper | — |
| Roadmap | — |
| Security advisories | — |
| Explorer | https://solscan.io/token/Grass7B4RdKfBCjTKgSqnXkqjwiGvQyFbuSCUJr3XXjs |
| Dashboard | https://app.grass.io/ |
| Blog | https://www.grass.io/learn |
| X | https://twitter.com/getgrass_io/ |
| Discord | https://discord.gg/getgrass |
| Telegram | https://t.me/grassannouncementschannel |
| Medium | — |
| Audit report(s) | — |
| Bug bounty | — |
| CoinGecko (profile, reference) | https://www.coingecko.com/en/coins/grass |
| CoinMarketCap (profile, reference) | https://coinmarketcap.com/currencies/grass/ |
General project overview
Grass positions itself as infrastructure that combines a distributed network of nodes (grass nodes) and routers to perform web transactions (requests to public sources) and to subsequently verify/aggregate the data in a validator. The documentation emphasizes the goal: turning public web data into structured datasets suitable for AI and enterprise use, with verifiable provenance.
From the standpoint of “what has actually been done” per Tier‑1: there is a described architecture (node/router/validator), the mechanics of the fee market and of staking to routers, as well as documented GRASS tokenomics and the token’s purpose in the ecosystem.
Features/modules
- Grass App / Grass Node: software for participating in the network (traffic relay/participation in collection).
- Router: a geo‑distributed hub connecting nodes and the validator; accounting of metrics/latency/volume.
- Validator: initiates web requests and verifies web transactions; then passes the data to the ZK processor to form proofs and checkpoints.
- ZK Processor (described): batches proofs of session data and publishes them “on L1”.
- Fee market (described): a dynamic “gas” model for web transactions.
Typical scenarios
- Scenario 1 (node operator): installs Grass → the node relays traffic → the network counts the contribution → the operator receives rewards in GRASS.
- Scenario 2 (staker): holds GRASS → delegates stake to a router → receives a share of the rewards (a lock‑up period applies on unstake).
- Scenario 3 (data buyer/developer): pays for web transactions/datasets → receives structured data (per the project’s claim — with verifiable provenance).
Getting started (wallet/network)
- What you need: a wallet in the Solana ecosystem (for the GRASS token) and a Grass account/app to participate in the network.
- Network/chain: Solana (GRASS token).
- Fees: network fees (Solana) for token operations; plus “gas/fees” at the Grass protocol level for web transactions (per the documentation).
Architecture/tech (non‑AI)
- Components: nodes → routers → validator → (ZK processor) → onchain settlement/checkpoints.
- Participant roles: node operators, router operators, stake delegators, validator(s), data buyers.
- Where logic runs: relay/metrics — in the routers and the validator (offchain); publication of proofs/checkpoints — onchain (as described).
- Dependencies: public web sources; TLS connections; blockchain network(s) for settlement (the documentation does not explicitly fix a specific L1 for checkpoints).
Token/economics (expanded, no forecasts)
- Token utility: payment for network operations (web scraping transactions / dataset purchases), staking to routers, governance.
- Protocol necessity drivers: rewards and incentives within the network are described as settlements “in GRASS”; staking to routers is described as a security/traffic distribution mechanism.
- Who pays fees: ecosystem users (transaction participants/data buyers); payment in USD/USDC with subsequent conversion into GRASS is also possible (per the documentation).
- Where fees go: to compensate network stakeholders (routers/delegators) — per the description of the economics.
- Issuance/burn: supply is fixed; details of the burn mechanics were not identified in the Tier‑1 sources for this card.
- Security/incentive mechanisms: stake is delegated to routers; slashing is described as an expected/future risk (in the current implementation slashing is “not in the protocol”).
- Distribution and token issuance schedule: the documentation describes allocations (community/foundation+ecosystem/early investors/contributors) and cliff/vesting for investors/contributors.
- Treasury: a foundation & ecosystem growth allocation is mentioned; details of treasury management are not established in this card.
Governance
- Who makes decisions: the documentation declares network governance via GRASS (details of the process/venues are not disclosed in the selected Tier‑1 sources).
- How protocol parameters change: — (not established from the current Tier‑1 pages).
- Where decisions are discussed/made: — (not established).
- Keys/multisig: — (not established).
Security and incidents
- Audits: — (no Tier‑1 confirmation of audits was found).
- Bug bounty: — (no Tier‑1 confirmation of a bug bounty was found).
- Incidents: — (not established).
- Threat model: key risks — centralization of the validator at an early stage, correctness of metrics/reputation, quality of “anti‑fraud” in data collection, and trust in offchain components until full decentralization.
Project status and timeline
- Current status: the product and documentation describe a working network and token (mainnet by virtue of the existence of the token/staking).
- Key milestones: — (not formalized as Tier‑1 release notes/roadmap for this card).
- Roadmap: —.
Ecosystem/integrations
- Integrations: Solana wallets and infrastructure for the token; the project’s own web applications/dashboards.
- Where it’s actually used: the claimed area — data collection and dataset preparation for AI/enterprise; specific public cases/buyers are not listed in the selected Tier‑1 sources.
AI component of the project
- What is real AI here? The architecture explicitly lists an Edge Embedding Models block — the transformation of unstructured web data into “structured models/representations”, which is the AI/ML‑relevant part of the data preparation pipeline.
- What is truly onchain? The documentation describes ZK proofs and checkpoints of session data “on L1” so that provenance and the transparency of settlements/rewards can be verified.
- Why is a token needed? GRASS is described as the “native token” for paying for network operations, staking to routers (rewards/security) and governance.
- Red flags (based on the information found): AI‑washing (the AI part is described at the level of “embedding models”, but without demos/metrics), onchain‑washing (L1 settlement is mentioned without specifics on the network/contracts other than the token address), token‑washing (some payments are allowed in USD/USDC with conversion; it is important to understand what exactly does not work without the token).
DecAI Fit component summary
- DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
| Component | Level | Score |
|---|---|---|
| AI reality | medium | 2 |
| Onchain necessity | high | 3 |
| Token necessity | high | 3 |
| Evidence | Tier‑1 present | 3 |
Details
AI reality
AI_0 — AI intent (Tier‑1 roadmap) (1/0)
- AI_0 (decision): 0
- Claim (one line): AI intent is not used as a substitute for a working AI component, because Tier‑1 already describes an AI‑relevant block (embedding models).
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/architecture/overview
- Why sufficient / why not (one line): AI is mentioned not only as “intent” but also as part of the pipeline architecture.
- Conflict note (if any): —
AI_1 — what the AI does (1/0)
- AI_1 (decision): 1
- Claim (one line): edge embedding models transform unstructured web data into structured representations.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/architecture/overview
- Why sufficient / why not (one line): an explicitly identified AI‑relevant component in the architecture.
- Conflict note (if any): —
AI_2 — demos/examples (1/0)
- AI_2 (decision): 0
- Claim (one line): public demos/examples of specific embeddings/datasets are not recorded in the selected Tier‑1 pages.
- Evidence: Tier‑1 — — | No Tier‑1 source for claim “there are public demos/examples of embeddings/datasets” was found.
- Why sufficient / why not (one line): there are no specific reproducible examples in Tier‑1.
- Conflict note (if any): —
AI_3 — metrics/quality (1/0)
- AI_3 (decision): 0
- Metrics: —
- Context (version/date/how measured): —
- Evidence: Tier‑1 — — | No Tier‑1 source on embedding/data quality metrics was found.
- Why sufficient / why not (one line): without numbers/context the metric is not counted.
- Conflict note (if any): —
AI_4 — tech description/architecture/versions (1/0)
- AI_4 (decision): 1
- Claim (one line): the architecture of nodes/routers/validator and the pipeline with ZK proofs and an embedding component are described.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/architecture/overview, https://grass-foundation.gitbook.io/grass-docs/architecture/validator
- Why sufficient / why not (one line): there is a structured description of components and roles.
- Conflict note (if any): —
Onchain necessity
OC_1 — contracts/addresses/chain (1/0)
- OC_1 (decision): 1
- Chain: Solana (GRASS token)
- Addresses/identifiers: Grass7B4RdKfBCjTKgSqnXkqjwiGvQyFbuSCUJr3XXjs
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/introduction/grass
- Why sufficient / why not (one line): the Tier‑1 docs publish the token’s contract address.
- Conflict note (if any): —
OC_2 — onchain beyond just a token (1/0)
- OC_2 (decision): 1
- What useful logic is onchain: checkpointing/publication of ZK proofs of session data for provenance and verification of distribution.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/architecture/overview
- Why sufficient / why not (one line): proofs/checkpoints are recorded onchain, not just the token.
- Conflict note (if any): —
OC_3 — onchain is critical (1/0)
- OC_3 (decision): 1
- “Replace the blockchain” test: without public onchain proofs/checkpoints, the verifiable provenance and the transparency of reward distribution on which the project’s trust model relies are lost.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/introduction/grass, https://grass-foundation.gitbook.io/grass-docs/architecture/overview
- Why sufficient / why not (one line): Tier‑1 directly justifies the need for a blockchain (transparency + provenance + settlement).
- Conflict note (if any): —
Token necessity
TK_0 — no token (1/0)
- TK_0 (decision): 0
- Claim (one line): the GRASS token exists.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/introduction/grass
- Why sufficient / why not (one line): Tier‑1 lists the token and the contract address.
- Conflict note (if any): —
TK_1 — payment for the service (1/0)
- TK_1 (decision): 1
- Claim (one line): GRASS is used for web scraping transactions / dataset purchases / LCR usage.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/introduction/grass
- Why sufficient / why not (one line): the direct purpose of the token in the documentation.
- Conflict note (if any): —
TK_2 — incentives/collateral/penalties (1/0)
- TK_2 (decision): 1
- Claim (one line): staking of GRASS to routers + rewards; an unstake period and potential slashing in the future are described.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/introduction/grass/grass-staking, https://grass-foundation.gitbook.io/grass-docs/architecture/router
- Why sufficient / why not (one line): staking/rewards are described as the economic “stickiness” of the network.
- Conflict note (if any): —
TK_3 — governance (1/0)
- TK_3 (decision): 1
- Claim (one line): the token allows participation in network governance (proposals/votes).
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/introduction/grass
- Why sufficient / why not (one line): governance is explicitly listed as a use of the token.
- Conflict note (if any): —
TK_4 — token is replaceable (1/0)
- TK_4 (decision): 0
- Claim (one line): there is no Tier‑1 evidence that the token can be fully replaced without losing staking/governance.
- Evidence: Tier‑1 — https://grass-foundation.gitbook.io/grass-docs/introduction/grass
- Why sufficient / why not (one line): the option to pay in USD/USDC is described, but this does not prove the token’s replaceability in staking/governance.
- Conflict note (if any): —
Evidence (table)
| Tier | Source | What it proves |
|---|---|---|
| Tier‑1 | https://grass-foundation.gitbook.io/grass-docs/introduction/grass | the GRASS token exists; the contract address is listed; use cases (payments/staking/governance) and the motivation for “why a blockchain is needed” are described |
| Tier‑1 | https://grass-foundation.gitbook.io/grass-docs/introduction/grass/grass-tokenomics | fixed total supply of 1,000,000,000; allocations and cliff/vesting for investors/contributors |
| Tier‑1 | https://grass-foundation.gitbook.io/grass-docs/introduction/grass/grass-staking | staking to routers; rewards “every second”; 7‑day unstake; slashing not yet implemented |
| Tier‑1 | https://grass-foundation.gitbook.io/grass-docs/architecture/overview | architecture (node/router/validator); ZK proofs and onchain checkpoint; edge embedding models |
| Tier‑1 | https://grass-foundation.gitbook.io/grass-docs/architecture/validator | the validator’s role; ZK processor and batching of proofs to the blockchain |
| Tier‑1 | https://grass-foundation.gitbook.io/grass-docs/architecture/router | the router’s role; metrics/rewards; link between rewards and stake |
| Tier‑1 | https://grass-foundation.gitbook.io/grass-docs/architecture/fee-market | formula and parameters of the fee market (G) for web transactions |
| Tier‑2 | https://www.coingecko.com/en/coins/grass | reference profile (not evidence) |
| Tier‑2 | https://coinmarketcap.com/currencies/grass/ | reference profile (not evidence) |
No comments to display
No comments to display