Everything you need to understand Grape.

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.

The current product suite targets Solana mainnet and includes simulation and operator safeguards. Teams should still validate their own configuration, authority model, and transactions before production use.

Grape is not a custodial wallet. It provides interfaces and protocol tooling around the wallet you connect; transaction approval remains with the connected signer.

Grape serves community members managing an on-chain identity as well as DAO operators and builders composing reputation, verification, access, distribution, and governance workflows.

Identity combines SOL and token holdings with delegate exposure, close authorities, NFT permissions, staking accounts, program buffers, and other signer relationships in one workspace.

The score is a wallet-health signal based on external delegates, external close authorities, and NFT delegate exposure. Conservative, Balanced, and Aggressive policies change how strongly those risks are weighted.

No. The score covers risks Grape can observe from supported on-chain account relationships; it cannot prove device security, seed phrase safety, or the intent of every program you may sign with.

Yes. Open /identity/[publickey] with a Solana address for a read-only holdings view. Signing and authority-management actions still require the controlling wallet.

Supported transaction flows can simulate first and show instruction details, balance changes, estimated fees, rent impact, runtime logs, risk flags, and common failure hints.

It prepares a containment plan for a potentially compromised wallet, including delegate revocation, token and SOL sweeps, and eligible authority rotations. You review the plan before execution.

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.

No. Token holdings can be one input, but access policies can also use verification records, reputation thresholds, and other wallet or community-defined conditions.

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.

Yes. The protocol is organized as focused primitives and workflows so builders can use identity, reputation, verification, access, claims, or governance capabilities where they fit their product.

They make on-chain state easier to search, present, and act on. The authoritative state and permission checks remain on-chain where the underlying workflow requires them.

Use a reliable Solana RPC for the intended network, keep server credentials private, simulate write operations, and provide clear network and signer context to users before they approve a transaction.

Join the Grape Discord for protocol and integration questions. When asking for help, include the product area, network, transaction signature or simulation error, and non-sensitive configuration details.