Credible

Credible — performance‑based reputation layer, milestone proofs and issuer‑verified completion.

Credible

Created At

ETHOnline 2025

Project Description

Credible is a decentralized, performance‑based reputation app. Users complete issuer‑defined milestone packs, submit encrypted proofs, and mint a non‑transferable ERC‑1155 credential upon approval. Built on a modular stack with IPFS/Filecoin (Lighthouse) for persistence, Lit Protocol for programmable access control, and an indexer for fast reads, Credible turns static certificates into verifiable journeys.

How it's Made

Credible is a modular Web3 app for performance‑based credentials. We stitched together an EVM stack for on‑chain state, permanent storage for encrypted proofs, and programmable access control so issuers can verify privately and holders stay in control.

  • Smart contracts
    • Solidity with ERC‑1155 for “Pack” credentials. Each pack is a tokenId; minting is holder‑initiated after all milestones are approved.
    • Non‑transferable behavior enforced via transfer hook to make packs SBT‑like.
    • Events drive the app and indexer: PackCreated, MilestoneSubmitted, MilestoneApproved, PackMinted.
  • Execution and data availability
    • EVM rollup (Polygon CDK‑style approach) for low‑fee, high‑throughput interactions.
    • Avail as a DA layer to keep per‑milestone interactions cheap while retaining verifiability.
  • Persistence and privacy
    • Lighthouse (IPFS/Filecoin) stores both milestone proofs and the final credential metadata.
    • Lit Protocol provides Access Control Conditions:
      • Ephemeral, state‑based access for issuers during “Pending” review.
      • Time‑bound access for third‑party verifiers post‑mint.
    • Client encrypts proofs before upload; Lit nodes release key shares only when ACC checks pass.
  • Indexing and reads
    • Envio HyperIndex listens to contract events and exposes a fast GraphQL API for UI reads, progress bars, and issuer review queues.
  • Frontend
    • Next.js + React with Wagmi/Ethers for wallet and contract interactions.
    • Holder flow: encrypt proof → upload to Lighthouse → submitMilestone(tx).
    • Issuer flow: fetch encrypted blob → Lit decrypt if status is Pending → approve on‑chain.
  • DevXP and CI
    • Monorepo layout: apps/web, packages/contracts, packages/sdk.
    • Conventional Commits, Prettier, ESLint, Solhint.
    • GitHub Actions: install, build, test on PRs to develop and main.
    • Branch strategy: main (release), develop (integration), feature/* (short‑lived).
  • Why these partners helped
    • Avail: decouples execution from data availability so the “chatty” milestone loop is affordable.
    • Lighthouse: “pay once, store forever” for proofs and metadata with stable IPFS CIDs.
    • Lit Protocol: lets us express privacy as code tied to on‑chain state, eliminating manual access revocation.
    • Envio: real‑time indexing without operating our own subgraph infra.
  • Hacky but notable
    • State‑bound decryption: we piggyback the MilestoneSubmitted event to pre‑register Lit ACCs keyed to the submission status. When the issuer approves, the on‑chain state flip automatically kills decryption access without any extra cleanup.
    • Holder‑pull minting guard: a single require compares holderProgress vs. pack.milestoneCount to make minting atomic and trust‑minimized.
    • “Dry‑run” developer mode: a toggle that swaps real Lit decryption with mocked envelopes so frontend and CI run without secrets during early iterations.
  • Future polish
    • Auto‑verified milestones for on‑chain achievements.
    • Hardhat test matrix with forked chains and gas snapshots.
    • Role‑gated issuer dashboards and richer analytics plugged into the Envio index.
background image mobile

Join the mailing list

Get the latest news and updates

Credible | ETHGlobal