VC Holder

A VC Holder is a user who has locked the VC token into the protocol's staking contract. This action grants them specific rights and responsibilities, primarily centered on protocol governance. By staking, they earn the ability to propose, vote on, and ratify changes to the Chainscore system, such as parameter adjustments, treasury allocations, and protocol upgrades.

The primary utility for a VC Holder is on-chain governance. Voting power is typically proportional to the amount of VC staked and the duration of the stake (often implemented via ve-tokenomics). Key governance actions include:

• Voting on Chainscore Improvement Proposals (CSIPs)
• Deciding on the allocation of the protocol treasury
• Adjusting risk parameters for score calculations
• Electing or approving key ecosystem actors (e.g., multisig signers).

Staking VC tokens to become a Holder is incentivized through protocol rewards. These can include:

• A share of protocol revenue (e.g., fees generated from score queries or subscriptions)
• Rewards in VC tokens or other ecosystem assets
• Access to fee discounts or premium data feeds
• The potential for airdrops from integrated protocols. The design aims to align the Holder's financial interest with the long-term health and adoption of the Chainscore network.

Becoming a VC Holder involves interacting with specific smart contracts on the underlying blockchain (e.g., Ethereum, Arbitrum). Users deposit VC tokens into a staking contract, which issues a receipt token (e.g., veVC) representing their locked position and voting power. This process is non-custodial; users retain ownership of their staked assets, which are programmatically locked for a chosen duration.

VC Holders form the decentralized decision-making body of the protocol. By distributing governance power among many independent stakeholders, the system reduces reliance on a central team and mitigates single points of failure. This structure is critical for maintaining the credible neutrality and censorship resistance of the Chainscore oracle and its data outputs, which are relied upon by downstream DeFi applications.

It is crucial to differentiate a VC Holder from other ecosystem roles:

• Data Submitter/Node: Provides raw data but may not govern.
• Score Consumer: Queries and pays for scores but has no governance rights.
• VC Token Holder (Unstaked): Owns the asset speculatively but forfeits governance power and rewards. Only staked participants are VC Holders with active protocol rights.

The Holder's wallet (e.g., a mobile app or browser extension) is the primary vault for their credentials. Its security is paramount.

• Private Key Custody: The holder must securely manage the private keys used to sign presentations. Loss or theft compromises all associated credentials.
• Secure Storage: Credentials and their metadata should be encrypted at rest, protecting against device compromise.
• Wallet Provider Trust: The holder must trust the wallet software's integrity, as malicious code could leak credentials or signing keys.

A core privacy feature of VCs is the ability to prove claims without revealing the entire credential.

• Zero-Knowledge Proofs (ZKPs): Allow a holder to prove they are over 21 from a driver's license VC without revealing their birth date or other attributes.
• Predicate Proofs: Enable proving a statement about a claim (e.g., "balance > 1000") without disclosing the exact value.
• Minimal Attack Surface: By sharing only the necessary data, the holder limits exposure in case of a Verifier's data breach.

The act of presenting a VC must be controlled and auditable by the holder.

• Explicit User Consent: The wallet should require explicit, informed consent for each presentation, detailing what data is being shared and with whom.
• Presentation Nonce & Context: To prevent replay attacks, each presentation should be bound to a unique challenge (nonce) from the Verifier and a specific interaction context.
• Presentation Logs: Holders should maintain logs of when and to whom credentials were presented for their own audit trail.

A holder must be aware of and manage the revocation status of their credentials.

• Status List Monitoring: The holder's wallet should periodically check the revocation status list (e.g., a bitstring on-chain) to ensure a presented credential is still valid.
• Issuer Dependency: Revocation mechanisms often depend on the Issuer's availability and honesty, creating a potential point of failure.
• Stale Credentials: Holders must understand the credential's expiration and ensure they obtain renewals from the Issuer when needed.

Preventing unwanted tracking across different interactions is a major privacy challenge.

• Unique Identifiers: The Decentralized Identifier (DID) or credential ID used in presentations can become a correlation handle if reused across multiple Verifiers.
• Presentation Patterns: Even with ZKPs, the timing, IP address, or other metadata of presentations can be used to link a holder's activities.
• Holder-Binding Strategies: Techniques like using pairwise pseudonymous DIDs (a unique DID for each relationship) are essential to minimize correlation.

The holder's security and privacy ultimately depend on other actors in the ecosystem.

• Issuer Trust: The holder must trust the Issuer's identity, security practices, and commitment to not revoke credentials without cause.
• Verifier Trust: The holder must assess the Verifier's data handling policies, as shared data is now under the Verifier's control.
• Schema Integrity: The holder relies on the credential schema being correctly implemented and understood by all parties to avoid semantic misinterpretation of claims.