Why This Architecture Matters
For Veterinarians: Your attestations become permanent, verifiable records that travel with pets for life. You build their professional record while building documented professional reputation.
For Breeders: Your kennel name is permanently attributed to healthy lines. Health screenings become cryptographically provable—not just claims, but verified documentation buyers can check in 30 seconds.
For Everyone: Privacy-preserving design means verified records prove claims without exposing sensitive data. The market can finally reward transparency.
Implementation Hardening Notice
This document describes the conceptual architecture and protocol rules of Nebula Genesis Pet Ledger. The protocol itself is open and verifiable. However, specific implementation details—including exact data schemas, derivation path structures, hashing parameters, and verification algorithms—are protected as implementation hardening to maintain system security and integrity.
Technical implementation documentation is available to qualified partners, investors, and regulators. Contact: [email protected] for partnership inquiries. See Implementation Details section for more information.
Core Principle: Privacy by Design
What "Privacy-Preserving" Means
Data Minimization: Only categorical, non-identifying data is stored in verified records. Full records remain under owner control on their device.
Cryptographic Verification: Records can be verified using cryptographic hashes without revealing the underlying sensitive data. Anyone can verify that a claim is true without learning anything beyond that truth.
Architectural Enforcement: Privacy is guaranteed by the system design itself, not just policy promises.
This architecture addresses a fundamental tension in identity systems: the need for accountability without surveillance, and verification without exposure.
Current Architecture Note
The current implementation uses a semi-trusted backend for session management, payment processing, and vet verification. Our roadmap includes transitioning to fully decentralized verification as the protocol matures. Contact [email protected] for details on our Zero Trust architecture roadmap.
Design Philosophy
- Operator Independence: If Nebula Genesis Tech ceases to exist, records remain verifiable forever using only public verified record data.
- Data Minimization: Only categorical, non-identifying data is stored in verified records. Full records remain under owner control.
- Cryptographic Accountability: Professional attestations are attributable through hashed credentials, not exposed identities.
- Architectural Enforcement: Privacy guarantees are enforced by system design, not policy promises.
How Genesis Protocol Differs
Traditional pet registries operate as centralized databases where your data lives on someone else's servers. The Genesis Protocol fundamentally reimagines this model.
| Feature | Traditional Registries | Genesis Protocol |
|---|---|---|
| Data Storage | Centralized database controlled by registry | Your device + cryptographic commitments on blockchain |
| Operator Dependency | Registry must exist to verify records | Verifiable forever, even if Nebula disappears |
| Privacy Model | Registry sees and stores all your data | Only hashes on-chain; full data remains owner-controlled |
| Transferability | Paper certificates can change hands without record | Soulbound tokens; transfer requires burn + re-mint with clear audit trail |
| Professional Attribution | Vet signatures on paper, difficult to verify remotely | Cryptographic attestations linked to hashed credentials |
| Data Security | Centralized database creates single point of vulnerability | No central database; local data encrypted on your device |
The Key Insight
Traditional registries ask you to trust them with your data. The Genesis Protocol lets you prove claims without trusting anyone. Verification is mathematical, not institutional.
Three-Tier Data Architecture
| Tier | Location | Data Stored | Access | Persistence |
|---|---|---|---|---|
| Tier 1: Local | User device | Full pet details, photos, complete health records, wallet keypairs | Owner only | User-managed backups |
| Tier 2: Backend | Nebula servers | Session IDs, payment records, mint status (no pet data) | Nebula operations | Operational lifecycle |
| Tier 3: Chain | Public distributed network | Genesis hash, categorical assertions, hashed attestations | Public (non-identifying) | Permanent |
Three-Tier Architecture Flow
┌─────────────────────────────────────────────────────────────────┐
│ THREE-TIER DATA ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ TIER 1: LOCAL TIER 2: BACKEND TIER 3: VERIFIED │
│ ┌──────────────┐ ┌─────────────┐ ┌──────────┐ │
│ │ Your Device │ │ Nebula │ │ Verified │ │
│ │ │ │ Servers │ │ Records │ │
│ │ • Full pet │ │ │ │ │ │
│ │ details │ │ • Session │ │ • Genesis│ │
│ │ • Photos │ │ IDs │ │ Hash │ │
│ │ • Health │ │ • Payment │ │ • Categ. │ │
│ │ records │ │ records │ │ data │ │
│ │ • Wallet │ │ • No pet │ │ • Hashed │ │
│ │ keys │ │ data │ │ IDs │ │
│ └──────────────┘ └─────────────┘ └──────────┘ │
│ │ │ │ │
│ │ MINTING │ │ │
│ └───────────────────────────┼───────────────────┘ │
│ │ │
│ │ VERIFICATION │ │
│ └───────────────────────────┼───────────────────────────┘ │
│ (Direct: Owner data ↔ Verified record hash) │
│ (No backend required) │
│ │
└─────────────────────────────────────────────────────────────────┘
KEY INSIGHT: Verification happens directly between Tier 1 and Tier 3,
bypassing Tier 2 entirely. This ensures operator independence.
Genesis Hash Anchoring
Each pet record is anchored to a permanent verified record via a cryptographic hash computed at creation time. This creates a permanent, tamper-evident digital fingerprint of the record.
Simple Analogy: The Sealed Envelope
Imagine writing a document, sealing it in an envelope, and writing a unique code on the outside that represents exactly what's inside. If someone opens the envelope and changes even one word, the code won't match anymore. The Genesis Hash works the same way: it's a unique code that represents your pet's data. Anyone can verify the code matches the data, but the code itself doesn't reveal what's inside—it only proves nothing has been changed.
How It Works (Conceptual)
The Genesis Hash is computed from:
- Categorical pet attributes (species, breed, birth year — non-identifying)
- Hashed identifiers (microchip numbers are hashed, never stored raw)
- Timestamp and wallet data (for uniqueness and attribution)
The specific data schema, field ordering, and hashing parameters are protected as implementation hardening to maintain system security.
Verification Flow
- Owner presents pet data (locally stored)
- Verifier computes hash from presented data using public algorithm
- Verifier compares computed hash to Genesis Hash in verified records
- Match = data is authentic and unaltered since mint
Key Property: Independent Verifiability
Verification requires only: (1) the pet data from the owner, (2) public verified record data, and (3) a standard cryptographic library. No Nebula API access, credentials, or trust required.
Identity Commitment Protocol
Beyond categorical data, the Genesis Protocol enables owners to create cryptographic commitments to their pet's core identity—without ever storing that identity on-chain.
Simple Analogy: The Notarized Seal
Imagine a notary stamps "This pet named Max, born March 2023, is a male Golden Retriever" without writing any of that information on the stamp itself. The stamp only proves that these exact facts were verified—anyone who knows the facts can check the stamp, but the stamp itself reveals nothing to observers.
How Identity Fingerprints Work
The Identity Fingerprint creates a one-way cryptographic commitment to a pet's core identity fields:
- Pet's name (the actual name, not a pseudonym)
- Date of birth (precise date, not just year)
- Gender (male, female, or unknown)
- Species (dog, cat, etc.)
These fields are combined with a cryptographic salt and hashed using SHA-256. The resulting fingerprint is stored on-chain, but the original data never leaves the owner's device.
What This Enables
| Use Case | How It Works |
|---|---|
| Ownership Verification | Prove you know the pet's real name without revealing it publicly. Only the true owner knows the fields that produce the fingerprint. |
| Duplicate Prevention | The same pet data produces the same fingerprint, making it easy to identify if a record already exists for this pet. |
| Lost Pet Recovery | A found pet's details can be hashed and compared against registered fingerprints to identify the owner. |
| Privacy Preservation | Your pet's name never appears on any public blockchain. The commitment proves identity without revealing it. |
Important: Fingerprints Are Irreversible
The identity fingerprint cannot be "decoded" to reveal your pet's name. It's a one-way function—like how a blender can turn fruit into a smoothie, but you can't turn a smoothie back into whole fruit. The only way to verify is to blend the same ingredients and compare results.
Mandatory Wallet Rotation
A critical privacy feature: each pet verified record is created with a unique wallet address derived deterministically from a single master seed.
Simple Analogy: Master Key and Individual Locks
Think of it like a master key system: you have one master key (your seed phrase) that can generate unlimited individual keys (wallet addresses), each opening a different lock (pet record). From the outside, each lock appears completely independent—there's no visible connection between them. Only someone with your master key knows they're all controlled by you.
How It Works (Conceptual)
Using industry-standard hierarchical deterministic (HD) wallet derivation:
- One master seed phrase controls all pet wallets
- Each pet receives a unique, deterministic wallet address
- Addresses cannot be correlated in verified records without the seed
- User backs up one phrase, controls unlimited pet wallets
The specific derivation path structure is protected as implementation hardening to maintain system security.
Privacy Implications
| Without Rotation | With Mandatory Rotation |
|---|---|
| All pets linked to single address | Each pet has unique address |
| Owner behavior trackable across pets | No correlation possible in verified records |
| Transaction patterns reveal ownership | Each pet appears as independent entity |
Implementation Note
Wallet rotation is mandatory in the protocol, not optional. The client enforces this at the application layer. This is a critical privacy guarantee that cannot be disabled by users or operators.
Soulbound Token Implementation
What Are Soulbound Tokens?
Soulbound tokens are verified digital records that are permanently linked to a specific identity and cannot be transferred to another owner. Think of them like a driver's license or passport—they prove your identity and belong to you, but you can't sell or give them away. This ensures that verified records stay connected to the pet they document, maintaining the integrity of the verification system.
Pet Passport verified records are implemented as soulbound (non-transferable) permanent records using industry-standard protocols that ensure records cannot be transferred but can be permanently destroyed when needed.
Key Properties
- Non-transferable: Once created, the verified record cannot be sent to another wallet
- Burnable: Owner can permanently destroy the verified record (for ownership transfers or removal)
- Permanent metadata: Essential verification data stored permanently with the verified record
Implementation details and extension configuration are protected as implementation hardening and available to qualified partners.
Why Soulbound?
- Anti-speculation: Verified records cannot be traded on secondary markets
- Ownership integrity: Certificates cannot be separated from documented ownership chains
- Meaningful burn: Ownership change requires explicit burn + re-mint, creating clear audit trail
Ownership Transfer Protocol
- Current owner initiates burn (free, gas paid by master wallet)
- Burn transaction recorded permanently in verified records
- New owner creates fresh verified record with updated Genesis Hash
- New verified record references burn transaction as provenance
Professional Attestation Protocol
Licensed professionals (veterinarians) can create verified attestations in permanent records without exposing their personal credentials.
How Attestations Work (Conceptual)
Each attestation contains:
- Reference to pet record (links attestation to specific animal)
- Attestation type (categorical: exam, vaccination, etc.)
- Hashed professional credentials (verifiable but not exposed)
- Timestamp (proves when attestation occurred)
- Verification flags (e.g., microchip scanned and matched)
The exact data schema and hashing methodology are protected as implementation hardening.
Attestation Types
| Type | Purpose | Data Recorded |
|---|---|---|
microchip_verification |
Confirm scanned chip matches record | Hash of scanned chip, timestamp |
health_examination |
Record that exam occurred | Categorical health status, timestamp |
vaccination_record |
Verify vaccination administered | Vaccine type (categorical), timestamp |
ownership_attestation |
Professional judgment on ownership | Attestation flag, timestamp |
professional_duty_report |
Welfare concern (no owner consent) | Report type, timestamp, attributed to vet |
Transparency Signals
The Genesis Protocol helps responsible breeders and pet owners stand out by creating verifiable patterns of consistent, quality record-keeping. Those who do things right can demonstrate it.
Elevating Transparency
When a breeder consistently creates well-documented records over time, those patterns become visible markers of professionalism. Buyers can see: "This source has a consistent history of thorough documentation." The protocol rewards those who invest in doing things right.
How It Works
When a Blockchain ID is minted, the protocol collects privacy-preserving signals that help establish source consistency without identifying individuals:
| Signal Type | What's Collected | What's NOT Collected |
|---|---|---|
| Device Characteristics | Screen size, OS type/version | Device serial numbers, IMEI, hardware IDs |
| Locale Settings | Timezone, language preference | Exact location, IP address, GPS coordinates |
| Interaction Patterns | Form completion timing (anonymized) | Keystroke patterns, personal typing habits |
| App Context | App version, session timing | Other apps installed, browsing history |
The Privacy Guarantee
All collected signals are immediately converted into one-way cryptographic hashes. These hashes:
- Cannot be reversed to reveal your device or identity
- Establish source consistency when the same source creates multiple records over time
- Expire with account deletion—we stop correlating new activity to your hash
Example: How Consistency Benefits Responsible Breeders
A breeder who documents 20 litters over three years builds a verifiable track record. Buyers can see that records from this source show consistent documentation practices and positive health outcomes. The breeder's reputation becomes mathematically demonstrable—not just claimed.
Legal Basis
Transparency signals operate under legitimate interests (GDPR Article 6(1)(f)) for marketplace trust. The privacy impact is minimal because:
- Hashed signals cannot identify individuals
- No personally identifiable information is collected
- Users are informed via transparency disclosure before first mint
- Data correlation stops when users delete their accounts
Privacy Guarantees
What This Means For Veterinarians
Your license number is hashed—verifiable but not exposed. Your attestations create permanent records without revealing your personal details. You maintain professional accountability while preserving privacy.
What This Means For Breeders
Your kennel name CAN be included (by choice) for attribution. Individual pet details stay private. Health screenings are verified without exposing specifics. You control what's visible.
What IS in Verified Records (Attestations)
- Hashed vet license number (verifiable, not exposed)
- Hashed vet name (verifiable, not exposed)
- Clinic name (plain text, publicly visible)
- Clinic city/state (plain text, publicly visible)
- Attestation type and timestamp
What is NEVER in Verified Records
- Pet names
- Owner names, addresses, or contact info
- Exact birth dates (only birth year)
- Raw microchip numbers (only hashes)
- Raw veterinarian license numbers or full names
- Clinic street addresses or contact info
- Specific diagnoses or medical details
- Genetic markers or DNA data
Anonymity Set Analysis
What Is an Anonymity Set?
An anonymity set is the group of records that share the same characteristics as yours. The larger the anonymity set, the more privacy protection you have. Think of it like being in a crowded room where many people share your characteristics. If someone says "find the person wearing a blue shirt," and there are 100,000 people wearing blue shirts, you're effectively hidden in that crowd.
Our system ensures that every piece of verified record data describes thousands or millions of pets, not just yours. Even combining multiple pieces of information still leaves your pet in a large group—making individual identification impossible.
Verified record data is designed to have large anonymity sets:
| Verified Record Data | Approximate Anonymity Set |
|---|---|
| "Golden Retriever" | ~500,000+ in US alone |
| "Born 2023" | ~10,000,000+ pets |
| "Health status: clear" | ~80% of pets |
| Combined: Golden Retriever + 2023 + clear | ~100,000+ pets (non-identifying) |
Independent Verification
Any party can verify records without Nebula access.
Verification Flow
┌─────────────────────────────────────────────────────────────────┐
│ INDEPENDENT VERIFICATION │
├─────────────────────────────────────────────────────────────────┤
│ │
│ STEP 1: OWNER PRESENTS DATA │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Pet data from owner's device │ │
│ │ (species, breed, birth year, microchip, etc.) │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ STEP 2: VERIFIER COMPUTES HASH │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Standard cryptographic library │ │
│ │ SHA-256 hash computation │ │
│ │ Result: Computed Hash │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ STEP 3: FETCH VERIFIED RECORD DATA │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Public network endpoint │ │
│ │ Fetch Genesis Hash from verified records │ │
│ │ Result: Verified Record Hash │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ STEP 4: COMPARE │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Computed Hash == Verified Record Hash? │ │
│ │ │ │
│ │ ✅ MATCH = Data is authentic and unaltered │ │
│ │ ❌ MISMATCH = Data has been modified │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ NO NEBULA ACCESS REQUIRED • NO CREDENTIALS NEEDED │
│ VERIFICATION IS COMPLETELY INDEPENDENT │
│ │
└─────────────────────────────────────────────────────────────────┘
Verification Process (Conceptual)
- Fetch verified record data using any public Solana RPC endpoint
- Compute hash from the pet data presented by the owner
- Compare hashes — if they match, the data is authentic
What's Required for Verification
| Required | NOT Required |
|---|---|
| Pet data from owner | Nebula API access |
| Public verified record data | Nebula credentials |
| Standard cryptographic library | Trust in any single party |
Verification libraries and reference implementations are available to qualified partners. See Implementation Details section below.
Trust & Accountability Model
The Genesis Protocol creates accountability through architecture, not enforcement. We believe most people want to do the right thing—the protocol simply makes it easy to prove when they do.
Our Philosophy
The Genesis Protocol does not claim to be "unbreakable" but rather "accountable." Every mechanism creates cryptographic accountability, enabling trust through verifiability rather than blind faith. We elevate those who demonstrate transparency.
What the Protocol Enables
The architecture naturally supports accountability across common scenarios:
| Scenario | Accountability Mechanism |
|---|---|
| Proving you're a consistent source | Transparency signals show patterns of quality documentation over time |
| Demonstrating ownership | Identity fingerprint lets you prove you know the pet's details; soulbound tokens link records to you |
| Building professional reputation | License hash creates permanent, verifiable attribution for veterinary attestations |
| Maintaining record integrity | Genesis Hash verification confirms data hasn't changed since creation |
| Protecting personal privacy | No PII on-chain; only hashes and categorical data; large anonymity sets |
| Ensuring long-term access | Wallet rotation prevents unwanted correlation; local encryption protects your data |
System Resilience
| Concern | How the Protocol Addresses It |
|---|---|
| What if Nebula changes direction? | Records verifiable without Nebula. Protocol is open. Alternative clients possible. |
| What if Nebula ceases operation? | Verified record data is permanent. Local data owned by users. Verification requires only on-chain records. |
| What about regulatory inquiries? | Nebula doesn't store pet data. On-chain data is non-identifying. Local data is user-controlled. |
| Can my wallets be linked together? | Mandatory wallet rotation ensures no correlation possible without your seed phrase. |
| How are professional credentials protected? | Vet credentials are hashed. Verification requires presenting original credentials. |
| Can records be altered after creation? | No. Once created, verified records are immutable. Any modification is detectable via hash mismatch. |
What's Outside Protocol Scope
The Genesis Protocol provides tools for accountability, but cannot enforce truthfulness at the point of data entry, protect against physical device theft, or prevent users from sharing their own credentials. These considerations require good operational practices alongside the protocol.
Protocol Specification: Genesis Protocol
The Genesis Protocol defines the standards for creating Verified Practice Records on public distributed networks while preserving privacy.
Core Requirements
- Data Minimization: Only categorical, non-identifying data in verified records
- Cryptographic Anchoring: SHA-256 Genesis Hash for record integrity
- Wallet Rotation: Unique address per identity (mandatory)
- Soulbound Tokens: Non-transferable, ensuring records stay linked to documented ownership
- Independent Verification: Verifiable without operator participation
- Professional Attestations: Hashed credentials, categorical assertions
Open Protocol
The Genesis Protocol is designed as an open specification. While Nebula Genesis Pet Ledger is the reference implementation, the protocol is intended for adoption by other parties building Verified Practice Record systems.
Schema Evolution & Upgrades
The Genesis Protocol is designed to evolve. As new privacy-preserving features are developed, existing records can be upgraded without losing their verification history.
Current Schema Versions
| Version | Features | Status |
|---|---|---|
| v1 | Species, breed, microchip hash, lineage reference, categorical health data | Legacy (upgradeable) |
| v2 | All v1 features + Identity Fingerprint (name, DOB, gender, species commitment) | Current |
Upgrade Philosophy
- Forward Compatible: Older records remain valid and verifiable
- Voluntary Upgrades: Owners choose when to upgrade their records
- Regulatory Upgrades: Compliance-related features are always free to adopt
- Audit Trail: Upgrades are recorded on-chain, maintaining verification history
Why Schema Versioning Matters
Unlike traditional databases where schema changes can break old records, the Genesis Protocol ensures your pet's Blockchain ID remains valid indefinitely. A record minted in 2026 will be verifiable in 2046—even as the protocol adds new capabilities.
Planned Future Enhancements
The protocol roadmap includes (subject to change):
- Professional Attestation Chains: Linked sequences of veterinary attestations
- Selective Disclosure Proofs: Prove specific facts without revealing full records
- Cross-Border Verification: Standardized formats for international pet travel
- Decentralized Authority Registry: On-chain verification of licensed professionals
Implementation Details & Partnership Access
The Genesis Protocol rules and verification methods described in this document are public and open. However, specific implementation details are protected as implementation hardening—a security practice that maintains system integrity by protecting exact internal mechanisms.
Why Implementation Hardening?
Just as a bank doesn't publish its exact vault combination but does publish its security standards, we protect implementation specifics while maintaining protocol transparency. This approach:
- Maintains security posture: Keeps cryptographic parameters and data structures confidential
- Preserves system integrity: Ensures implementation details remain secure
- Preserves trust: Protocol rules remain verifiable while implementation stays secure
What's Available
Technical implementation documentation—including data schemas, derivation paths, hashing parameters, and verification algorithms—is available to:
- Qualified technical partners building compatible systems
- Security auditors and researchers
- Regulatory bodies conducting compliance reviews
- Enterprise evaluators assessing integration
Contact: [email protected] for partnership inquiries.
Build With Us
Interested in implementing the Genesis Protocol or integrating with Nebula Genesis Pet Ledger? Technical partnerships welcome.