Derived Credential

In DeFi, derived credentials enable trust-based lending without over-collateralization. A lender can issue a loan based on a borrower's creditworthiness score, derived from their on-chain financial behavior. Key data points include:

• Consistent repayment history
• Wallet age and activity
• Diversity of assets and protocols used This creates a reputational collateral layer, allowing for capital-efficient loans similar to traditional credit but with transparent, algorithmic scoring.

Decentralized Autonomous Organizations (DAOs) use derived credentials to weight voting power and delegate authority. A governance credential can be derived from a member's contributions, such as:

• Length of membership
• Number of successful proposals authored
• Consistent participation in votes This moves governance beyond simple token-weighted voting, creating a system where reputation and proven engagement grant increased influence, aligning incentives with long-term contributors.

Derived credentials control access to exclusive digital and physical spaces. Instead of just checking for a specific NFT, a gate can verify a more nuanced credential. Examples include:

• Access to a private Discord channel for wallets with >1 year of activity in the ecosystem.
• Entry to an IRL event for users with a credential proving attendance at three prior events.
• Premium API access for developers whose wallets show a history of building on the protocol. This allows for dynamic, behavior-based gating beyond static asset ownership.

Institutions use derived credentials to demonstrate compliance without exposing raw user data. A protocol can generate a zero-knowledge proof that a user has passed KYC/AML checks with a verified provider. This creates a portable, privacy-preserving credential that can be presented to multiple DeFi platforms. It enables regulated DeFi participation by proving eligibility (e.g., accredited investor status, jurisdiction) while maintaining user privacy and data minimization principles.

A user's reputation built on one platform becomes a usable asset on another. A contribution credential earned in a governance DAO could be used to get a discount on fees in a lending protocol. A liquidity provider score from one AMM could lower collateral requirements on a different borrowing platform. This breaks down reputation silos, creating a composable identity layer where positive behavior in one ecosystem provides tangible benefits across the broader Web3 landscape.

The most common method for deriving credentials uses zero-knowledge proofs (ZKPs). A prover generates a proof that they possess a valid credential meeting certain criteria (e.g., 'over 18') without revealing the credential itself (e.g., exact birth date). This proof becomes the new, derived credential. Key components include:

• Witness: The private input (the original credential data).
• Constraint System: The rules to be proven (the predicate).
• Proof: The compact, verifiable output.

Derived credentials enable selective disclosure. Instead of sharing a full credential, a user proves a specific predicate about it. Common predicate types include:

• Range Proofs: 'Age ≥ 21', 'Balance > $1000'.
• Set Membership: 'Citizenship is in {Country A, Country B}'.
• Logical Operations: 'Credential A AND Credential B are valid'. This transforms a broad identity document into a minimal, context-specific attestation.

A critical feature is controlling linkability. Derived credentials can be crafted to be:

• Unlinkable: Each use generates a unique, non-correlatable proof, preventing service providers from tracking a user across sessions.
• Linkable by Design: Some systems use pseudonyms or scope-specific keys to allow controlled linking within a single application (e.g., a user's recurring activity on one platform) without exposing their global identity. The choice depends on the use case's privacy requirements.

Verification is the process where a verifier checks the derived credential's proof against the public parameters of the system.

• On-Chain Verification: The proof and verification logic are executed as a smart contract. This is used for decentralized applications, like proving eligibility for a token airdrop. Gas costs are a consideration.
• Off-Chain Verification: The proof is verified by a server or client application. This is common for traditional web2 login flows or access control, offering lower latency and cost. The verification key is public and often stored in a decentralized registry.

Derived credentials are often an advanced feature within the W3C Verifiable Credentials (VC) data model. A standard VC is a signed JSON-LD or JWT document. A derived credential can be thought of as a ZK-Proof Verifiable Presentation. Key distinctions:

• Standard VC Presentation: Reveals the credential's contents, with optional blinding.
• Derived Credential (ZK Presentation): Reveals only the truth of a statement about the credential. This makes derived credentials a privacy-enhancing layer atop existing VC ecosystems.

A core privacy mechanism where a derived credential proves a specific claim (e.g., "over 21") without revealing the entire source document (e.g., a driver's license). This is achieved using zero-knowledge proofs (ZKPs) or BBS+ signatures, minimizing data exposure and adhering to the principle of data minimization.

Managing the lifecycle of derived credentials is critical for security. Systems must handle:

• Revocation Status: Checking if the source credential has been revoked (e.g., via a revocation list or accumulator).
• Expiration: Enforcing time-bound validity periods on the derived proof.
• Compromise Response: Mechanisms to invalidate all derived credentials if the root private key is compromised.

A major privacy threat is correlation, where multiple uses of a derived credential can be linked back to the same user or primary identity. Mitigations include:

• Unlinkable Proofs: Using ZKPs that generate unique, non-correlatable signatures for each presentation.
• Blinding Techniques: Employing cryptographic blinding to sever the link between issuance and presentation.
• Credential Scope: Limiting the contexts in which a specific derived credential can be used.

Security depends on the trustworthiness of the ecosystem participants:

• Issuer Authenticity: Verifying the cryptographic signature of the issuing authority (DID, public key).
• Verifier Policies: Assessing what data the verifier requests and how it will be stored/processed.
• Schema Integrity: Ensuring the credential schema is well-defined and tamper-proof to prevent semantic attacks.

The security of the private key used to generate and present derived credentials is paramount. Considerations include:

• Secure Enclaves: Using hardware security modules (HSMs) or trusted execution environments (TEEs) for key storage.
• Decentralized Identifiers (DIDs): Allowing user-controlled key rotation and recovery.
• Wallet Security: Relying on the security model of the user's wallet (custodial vs. non-custodial, seed phrase management).

Derived credential systems must be designed for compliance with data protection regulations:

• Right to Erasure: Technical feasibility of deleting or revoking credentials.
• Data Portability: Ability to transfer credentials between providers.
• Purpose Limitation: Ensuring derived proofs are only used for their intended, disclosed purpose.
• Audit Trails: Maintaining necessary logs for regulated issuers without compromising user privacy.