Quick answers for builders and operators using Grape protocol tools.
Grape is protocol infrastructure for identity, reputation, access control, governance, and token distribution workflows on Solana.
Core state and permission checks are on-chain. Off-chain components provide UI, indexing, and automation around those primitives.
Identity and verification establish trust, reputation captures contribution, access gates experiences, and governance executes decisions.
Yes. The hub and product suite are built for mainnet usage and include operator tooling for setup, claims, and authority operations.
OG Reputation Spaces is Grape's on-chain reputation layer where communities define contribution signals and track earned reputation over time.
Reputation can be granted via authorized operators, DAO-managed workflows, and automation paths such as community actions and contribution policies.
Yes. Reputation systems can run in seasons and include reset/rotation patterns depending on your DAO's governance and policy design.
Reputation can be consumed by access checks and governance-adjacent workflows so higher-trust contributors can unlock advanced roles or actions.
Grape Verification provides identity and attestation primitives used to prove membership, eligibility, and trust signals in composable workflows.
Authorized attestors can issue and manage verification records according to community policy, with support for lifecycle updates and revocation.
Yes. Verification records can include validity controls and can be revoked by the appropriate authority when requirements are no longer met.
No. Verification flows can be designed to store minimal on-chain data while keeping sensitive context off-chain and policy-governed.
Grape Access is a composable gating layer for products and communities, supporting token, credential, and trust-based entry rules.
Common targets include channels, product features, mint phases, premium tools, DAO operations, and any app action that needs policy checks.
Yes. Access rules can combine multiple checks such as wallet state, token holdings, verification status, and reputation thresholds.
Start with explicit policy definitions, run staged test wallets against each rule path, and validate expected allow/deny outcomes before production roll-out.
Upload a manifest JSON, then share the generated /claims link with the manifest query param from the Claim/User panel.
Include realm and governance program settings in your manifest (or Quick Wizard), then claim flow can deposit governing tokens into the realm.
Most common causes are wrong realm, wrong governance program id/version, or governing mint mismatch. Use the in-app simulation logs to debug.
Wizard allocation and funding inputs are token units (decimal-aware). Claim proofs and manifest amounts are stored and validated as base units.
Governance UI is the operational interface layer for SPL Governance workflows, letting communities execute DAO actions with a user-friendly flow.
Governance UI executes decisions, while Reputation, Verification, and Access provide trust and policy context that can shape who participates and what actions are enabled.
Use Governance UI for day-to-day DAO operations and contributor workflows. Use direct instruction building when you need custom automation or tightly integrated product flows.
Yes. Claim manifests can deposit governing tokens into a realm, after which participants can continue governance actions through Governance UI.