Contributor Credit Token

The most direct form of contribution, tokenized for open-source development. This includes:

• Pull Requests: Merged code that adds features or fixes bugs.
• Smart Contract Audits: Security reviews and vulnerability reports.
• Documentation: Writing technical specs, API docs, or user guides.
• Issue Triage: Managing bug reports and feature requests.

Example: A developer receives CCTs for a PR that implements a core protocol upgrade, with the token metadata linking to the commit hash.

Tokenizes active participation in a project's decentralized decision-making processes. Contributions include:

• Proposal Submission: Drafting and publishing governance proposals.
• Voting: Casting informed votes on key protocol parameters.
• Forum Discussion: High-quality analysis and debate that shapes proposals.
• Delegation: Serving as a knowledgeable delegate for other token holders.

This creates a permanent, verifiable record of a contributor's governance footprint beyond mere token ownership.

Captures value created through narrative building and knowledge sharing. This encompasses:

• Technical Writing: Blog posts, tutorials, and explainer threads that educate the community.
• Video Content: Educational videos, project explainers, or livestream analysis.
• Translation Work: Localizing documentation and content for global audiences.
• Community Moderation: Managing social channels and fostering productive discussion.

These contributions are vital for onboarding and retention but are often the hardest to quantify off-chain.

Tokenizes contributions that improve a project's usability and aesthetic appeal. Key areas include:

• UI/UX Design: Creating intuitive interfaces for dApps or governance dashboards.
• Brand & Graphic Design: Developing logos, marketing materials, and visual identities.
• Product Feedback: Submitting detailed user experience reports and usability testing.
• Front-End Development: Implementing the designed interfaces into functional code.

These contributions bridge the gap between complex technology and end-user adoption.

Recognizes contributions to a project's organizational and strategic growth. This includes:

• Grant Writing: Securing funding from ecosystem grants or foundations.
• Partnership Development: Forging strategic alliances with other protocols or DAOs.
• Legal & Compliance Research: Navigating regulatory landscapes.
• Treasury Management: Proposing or executing strategies for protocol-owned assets.

These high-level contributions are critical for long-term sustainability but lack traditional on-chain proof of work.

Tokenizes contributions that enhance a project's security and reliability through rigorous testing. This covers:

• Beta Testing: Identifying bugs and providing feedback during testnet phases.
• Bug Bounty Submissions: Reporting critical security vulnerabilities.
• Load & Stress Testing: Evaluating protocol performance under extreme conditions.
• Economic Mechanism Testing: Modeling tokenomics and incentive structures.

CCTs provide immutable proof of these contributions, which are essential for trust and safety but often anonymous.

CCTs are typically implemented as Soulbound Tokens (SBTs), a specialized form of ERC-721 non-fungible token. Key technical constraints include:

• Non-Transferability: The token's transferFrom and safeTransferFrom functions are overridden to revert, permanently binding it to a single wallet address.
• Immutable Metadata: Contribution data (e.g., commits, governance votes, bug reports) is often hashed and stored on-chain or referenced via a decentralized storage protocol like IPFS or Arweave.
• This design ensures the token is a persistent, verifiable record of provenance that cannot be bought or sold.

The integrity of a CCT relies on a robust attestation system. Common patterns include:

• On-Chain Attestations: Using standards like EAS (Ethereum Attestation Service) to create a verifiable, timestamped record linking a contributor's wallet to a specific action (e.g., a successful pull request merge).
• Off-Chain Signatures with On-Chain Verification: A project's authorized signer (or multi-sig) cryptographically signs contribution data; the CCT minting contract verifies this signature.
• Oracle-Based Verification: For contributions on external platforms (GitHub, Discourse), a decentralized oracle network attests to the event, triggering the mint.

Not all contributions are equal. CCT systems implement logic to quantify contribution value. This involves:

• Contribution Scoring: Algorithms that assign weights to different action types (e.g., core code commit = 10 points, documentation edit = 2 points).
• Decay Functions: To prioritize recent activity, some systems apply time decay (e.g., halving score weight annually) to contributions.
• On-Chain Calculation vs. Off-Chain Indexing: Scores can be calculated in the smart contract state or computed off-chain by an indexer (like The Graph) with results stored in the token's metadata URI.

The minting process is governed by strict access control logic to prevent sybil attacks and spam.

• Permissioned Minting: Typically, only a designated minter role (a smart contract or multi-sig wallet) can call the mint function.
• Claim-Based Design: A more decentralized pattern uses a "claim" function where any user can invoke a mint, but the contract first validates a pre-approved attestation or proof.
• Revocation Mechanisms: In case of malicious activity, some implementations include a revoke function (callable by governance) that can burn the token or mark it as invalid in an on-chain registry.

A primary utility for CCTs is weighting governance votes. Implementation involves:

• Snapshot Integration: Using the CCT token ID or the holder's reputation score as a voting weight in Snapshot off-chain voting strategies.
• On-Chain Voting: Direct integration with governance contracts (e.g., Compound Governor), where voting power is calculated as a function of the CCT's metadata or a separate reputation score derived from it.
• This creates a contributor-centric governance model, distinct from pure token-weighted (plutocratic) models.

CCTs interact with a broader ecosystem of identity and reputation primitives.

• ERC-5114: A proposed standard for Soulbound Badges, providing a canonical interface for non-transferable reputation.
• Verifiable Credentials (VCs): The W3C standard for digital credentials; CCTs can be seen as a blockchain-native, publicly verifiable subset of VCs.
• Decentralized Identifiers (DIDs): The holder's wallet address acts as a simple DID, with the CCT serving as a verifiable credential issued to that DID.
• These standards collectively form the foundation for decentralized reputation graphs.

A lending model where creditworthiness is derived from on-chain reputation and contribution history, rather than traditional collateral. This is the foundational mechanism for CCTs.

• Key Mechanism: Uses soulbound tokens (SBTs) and contribution records to assess risk.
• Contrast: Differs from overcollateralized (e.g., MakerDAO) or undercollateralized (e.g., Aave) models by using social capital.
• Purpose: Enables uncollateralized borrowing for builders and contributors based on proven track records.

A non-transferable, non-financialized token that represents identity, affiliations, and achievements. SBTs are the reputation backbone for CCT issuance.

• Function: Encodes a contributor's history, memberships, and verifiable credentials on-chain.
• Use Case: In CCT systems, SBTs act as the primary data source for reputation oracles to score creditworthiness.
• Example: A developer's SBT might hold records of merged pull requests, governance participation, and project tenure.

A specialized oracle that aggregates and scores off-chain and on-chain reputation data to feed into smart contracts. It is the scoring engine for CCT platforms.

• Process: Pulls data from sources like GitHub, governance forums, and DAO contribution graphs.
• Output: Computes a reputation score or credit limit used to mint CCTs.
• Analogy: Functions like a decentralized credit bureau, providing verifiable attestations for lending protocols.

A mechanism in DeFi that allows a user to delegate their borrowing capacity to another address. CCTs can be integrated into or enabled by this pattern.

• How it Relates: A DAO or protocol with a high credit limit could delegate a portion of it via a CCT to a trusted contributor.
• Protocol Example: Aave's credit delegation allows for uncollateralized loans between known parties, a concept CCTs aim to automate and scale.
• Difference: CCTs often automate delegation through programmable reputation, reducing the need for manual, peer-to-peer agreements.

A broad category of tokens that cannot be transferred between wallets after minting. CCTs are a financialized subset of NTTs.

• Characteristic: Enforced at the smart contract level, preventing secondary market sales.
• Purpose for CCTs: Ensures the credit line is bound to the contributor, preventing speculation and aligning incentives with ongoing work.
• Contrast: Unlike ERC-20 tokens, NTTs like CCTs represent a personal utility right rather than a fungible asset.

Future revenue or income streams that are tokenized and made programmable on-chain. This is a potential collateral source or repayment mechanism for CCTs.

• Connection: Contributors could use future protocol fees, grant distributions, or subscription revenues to back or repay their CCT debt.
• Primitives: Built using streaming payment tools like Superfluid or vesting contracts.
• Vision: Enables earn-now, pay-later models where future work income automatically services credit.