bonuz ID Protocol
A permissioned, portable onchain identity bound to a self-custodial wallet. Verified social handles, attestations, engagement history, and a consent-gated permission system.
Apps read enriched profiles with permission. Users control what is shared, with whom, and can revoke access at any time.
Identity Architecture
Four layers that compose a portable, verifiable onchain identity.
Self-Custodial Wallet (EOA)
Created via social login (email, Google, Apple). MPC/TSS key management ensures no single point of failure. Keys stay with the user.
bonuz ID (Onchain Identity)
Profile data, verified handles, and attestations bound to the wallet address. Stored as onchain records with IPFS metadata.
Permission Layer
Consent-based access control. Apps request scoped permissions (read/write) and users approve or deny per-scope, per-app.
Engagement Layer (DNFTs)
Passes, vouchers, tickets, and certificates owned by the ID. Each entitlement is a verifiable, programmable onchain object.
Anatomy of a bonuz ID
Every bonuz ID carries six categories of verifiable information.
Verified Handles
Social accounts (X, Telegram, Discord, Instagram, GitHub) linked through OAuth and stored as onchain attestations. No passwords shared, no manual entry.
Bio & Display Name
User-controlled profile data that travels with the bonuz ID. Apps get a pre-populated profile from day one, no onboarding friction.
Avatar (IPFS)
Profile images stored on IPFS for permanence. No centralized CDN, no broken links. The avatar is part of the portable identity.
Engagement History
Every DNFT claimed, redeemed, or owned is part of the identity graph. Brands see consented engagement context, not raw personal data.
Attestations
Third-party verifiable claims attached to the ID: KYC status, age bracket, location, skill completion. Stored as onchain attestations, not raw PII.
Social Graph
Mutual connections within the bonuz network. Friend lists, shared community memberships, and co-attendance records, all consent-gated.
Permission Model
Scoped, consent-based access control. Apps request exactly what they need. Users approve or deny per-scope.
Low-sensitivity data. Display name, avatar, verified handles.
Personal context. Attestation details and social connections.
Write access. Only authorized issuers can add attestations or entitlements.
How Verification Works
Four mechanisms ensure every claim attached to a bonuz ID is genuine and tamper-proof.
OAuth Verification
Social handles verified through OAuth flow. The user authenticates directly with the platform (X, Discord, Telegram, etc.) and bonuz stores the attestation onchain.
Cryptographic Signatures
Every attestation is signed by the issuing authority and verifiable onchain. Cannot be forged, spoofed, or altered after issuance.
Zero-Knowledge Proofs
Coming SoonProve attributes (age > 18, location = EU) without revealing the underlying data. The verifier learns the fact, not the details.
Onchain State
The smart contract holds the canonical identity state. External systems verify by reading the chain directly, no API calls to a centralized service.
Social Graph
The bonuz social graph maps connections between users, brands, and communities. Every connection is mutual, consent-based, and portable across the ecosystem.
- ✓Mutual connections visible to both parties
- ✓Shared community memberships surface in discovery
- ✓Co-attendance and co-ownership signals
- ✓Graph queries respect permission scopes
- ✓Brands can request graph reads with user consent
SDK Integration
Three calls to read a bonuz ID. Zero infrastructure to manage.
Use Cases
How apps use bonuz ID to build better, more personalized experiences.
Login Enrichment
When a user authenticates with bonuz, the app receives verified social handles, display name, and avatar. No registration form needed. Profile is pre-populated from day one.
KYC-lite Gating
Gate access based on attestations (verified age, region, membership tier) without storing PII. The attestation is onchain, the personal data is not.
Community Discovery
Find users who share verified handles on specific platforms. Surface mutual connections and co-attendance signals for social features.
Portable Reputation
Users carry their verified identity, engagement history, and credentials across every app that integrates bonuz. Build once, recognized everywhere.
Cross-App Engagement
A loyalty card earned in one app can unlock perks in another. The bonuz ID ties entitlements together into a unified identity graph.
Targeted Experiences
Reach users based on consented onchain signals: ownership of specific DNFTs, attestation status, or engagement frequency. No cookies, no tracking pixels.
Connected to DNFTs
Every DNFT (pass, voucher, ticket, certificate) is linked to the holder's bonuz ID. Entitlements are not just tokens. They are part of a verifiable identity graph.
- ✓DNFT ownership enriches the bonuz ID profile
- ✓Brands target by entitlement history (with consent)
- ✓Engagement travels with the user across apps
- ✓Attestations from DNFTs feed into reputation signals
bonuz ID + Engagement + Social
Design Principles
User-Sovereign
The user owns their identity. No platform can lock them out, delete their profile, or prevent them from using their data elsewhere.
Consent-First
Every piece of data shared requires explicit user approval. Scoped permissions ensure apps only access what they need.
Privacy by Default
Raw personal data stays off-chain. Onchain records contain attestations and proofs, not PII. Zero-knowledge proofs for sensitive attributes are on the roadmap.
Interoperable
bonuz ID works across any chain and any app in the ecosystem. One identity, portable everywhere.
Start building with bonuz ID
Integrate portable identity into your app. Three lines of code to read a verified profile.