Hey everyone,
I’m excited to share Haven Protocol, a privacy reputation layer I’ve been building natively on Nervos CKB.
The Problem
Reputation systems today force a choice: either your identity is public and your reputation is meaningful, or your identity is private and your reputation is non-existent. There’s no way to prove you’re a trustworthy participant without revealing who you are.
What Haven Does
Haven flips this. Your score is public. Your identity is private.
Every user gets a Haven Score (0-1000) based on their real activity - CKB on-chain transactions, GitHub contributions, Twitter engagement. The score lives on-chain as a CKB cell, readable by any dApp. But the identity behind that score? Known only inside a Phala Network TEE. Nobody - not Haven, not the chain, not other users - can link a score to a real person.
How It Works
-
Connect your wallet - your CKB wallet is the only required connection. Social accounts (Twitter, GitHub, LinkedIn) are optional and boost your score.
-
TEE computes your score - the Phala TEE collects your activity, runs the scoring formulas (privacy hygiene, contribution, humanity, community), and generates a DCAP attestation that cryptographically binds the scoring result to the TEE’s execution environment, proving the computation ran inside a genuine Intel TDX enclave.
-
SP1 proves correct computation - the attestation is sent to an SP1 proof worker that generates a ZK proof (SP1 PLONK) verifying that the TEE executed the scoring program correctly - that each component score was computed honestly from real activity data and the final score was produced without tampering.
-
CKB verifies it - the proof is submitted on-chain. The Haven type script checks the SP1 PLONK proof before allowing the score cell to update. If the proof is invalid - meaning the computation was tampered with - the score cell cannot be updated.
-
dApps read it - any CKB dApp can read your score directly from the chain using the Haven SDK. No API keys, no Haven server dependency.
Architecture
User → Dashboard → SDK → CKB (read scores)
↓
Phala TEE → Proof Worker → CKB (write scores)
↓ ↓
dstack (DCAP) Automata SP1
Five components:
- CKB Scripts - Type script (SP1 PLONK verification) + dual-path lock script (TEE update / user direct control). Deployed on testnet.
- Phala TEE Service - NestJS app running inside a Phala TEE. Handles identity, scoring, attestation, and chain submission. PostgreSQL for storage. Modular connection system - adding new providers is just a database row.
- SP1 Proof Worker - Rust binary using Automata’s DCAP verifier. Generates PLONK proofs from TDX attestation quotes.
- TypeScript SDK -
@haven-protocol/ckb-sdkwith React hooks. Everything a dApp needs to read scores, verify tiers, manage deposits, and connect accounts. - Dashboard - React app with a custom design system. Score visualization, leaderboard, identity management, ecosystem page with Shadow Job Board.
Score Breakdown
| Component | Weight | What It Measures |
|---|---|---|
| Privacy Hygiene | 40% | Address rotation, transaction diversity, account age |
| Ecosystem Contribution | 30% | On-chain activity, DAO deposits, GitHub commits |
| Proof of Human | 20% | Account age, cross-platform consistency |
| Community Engagement | 10% | Interaction diversity, recent activity |
Scores update every 24 hours in production (every 5 minutes during testnet testing). A user with real CKB testnet activity and no social accounts can score in the 200-400 range. Linking social accounts pushes it higher.
Score Tiers
| Tier | Range | Access |
|---|---|---|
| Observer | 0-199 | Dashboard, score tracking |
| Initiate | 200-399 | Funding pools, basic passes |
| Trusted | 400-649 | Shadow Job Board, whitelists |
| Guardian | 650-849 | Governance, multiplier bonuses |
| Sovereign | 850-1000 | Full access, exclusive pools |
Why CKB
- RISC-V VM - SP1 PLONK proofs verify natively in CKB scripts
- Cell model - score state lives in a user-owned cell. The TEE updates it, the user owns it
- Dual-path lock script - TEE can update scores, users always retain full ownership and can reclaim CKBytes
- Type scripts as validators - score update rules enforced on-chain. No override possible
- Composability - any dApp reads score cells directly. No Haven server needed
Current Status
- CKB type script + lock script deployed on Pudge testnet (upgradable via type-id)
- TEE service running with Phala dstack, connected to PostgreSQL
- Proof worker generating SP1 PLONK proofs from DCAP attestations
- Dashboard live with wallet connect, score display, leaderboard, notifications
- SDK published with React hooks for dApp integration
- On-chain scoring working for any CKB wallet type (secp256k1, omnilock, JoyID)
Links
What’s Next
- Deploy proof worker to a server - currently runs locally. Moving it to a cloud server so it’s always available for proof generation
- Deploy TEE to Phala Cloud - currently running on a local dstack simulator for testing. On real Phala hardware, the DCAP attestation will use genuine Intel TDX quotes, which unlocks the full end-to-end flow: TEE scores → real attestation → SP1 proof → on-chain score update
- Twitter and GitHub OAuth - social account integration for enhanced scoring
- More provider connections - LinkedIn, Discord, Telegram
- CKB mainnet deployment
- RGB++ cross-chain score signals
- DAO governance with score-weighted voting
- Shadow Job Board with anonymous talent matching
I’d love feedback on the architecture, the scoring model, or anything else. Happy to answer questions.