Scope of This Document
This page describes public protocol structure, storage boundaries, and record-checking mechanics. It does not disclose implementation hardening details or internal abuse-prevention controls. Implementation documentation is available to qualified partners and regulators.
1. Protocol Overview
The Genesis Protocol defines how pet records are created, anchored, checked, and transferred within the Nebula Genesis Pet Ledger system. It covers record anchoring via cryptographic hashes, wallet isolation for privacy, non-transferable token semantics, veterinary attestation structure, and manifest-based record versioning.
The protocol is specified for compatibility across implementations. Nebula Genesis Pet Ledger is the reference implementation.
Core Properties
- Data minimization — only categorical, non-identifying data is written to public infrastructure
- Cryptographic anchoring — SHA-256 genesis hash for record integrity
- Wallet isolation — unique derived address per record, enforced at the application layer
- Non-transferable tokens — records cannot be sold or traded; ownership changes follow a managed transfer protocol
- Independent checking — genesis hash integrity can be checked without Nebula API access
- Attestation attribution — professional credentials are hashed, not exposed
Current Status
What Is Live Today
Public infrastructure: Records are minted on Solana mainnet (Token-2022). Photos and manifests are stored on Irys/Arweave.
Independent checking: On-chain existence, soulbound status, and genesis hash integrity can be checked without Nebula API access via any public Solana RPC endpoint.
Server-dependent components: Pet metadata (name, species, breed), attestation records, manifest indexing, and record search are served through Nebula's backend API. Attestation data is designed to be encrypted at rest.
In development: Attestation-level public anchoring — storing attestation data on public infrastructure independent of Nebula's servers.
2. System Architecture
Data is distributed across three storage tiers with distinct persistence characteristics and access controls.
Storage Boundaries
| Tier | Location | What's Stored | Persistence |
|---|---|---|---|
| Tier 1: Local | User device | Private keys, recovery phrase, detailed notes, full local records, local photo copies | User-managed backups |
| Tier 2: Backend | Nebula servers | Pet metadata (name, species, breed), attestation records (designed to be encrypted at rest), payment and session data, manifest index | Operational lifecycle |
| Tier 3: Public | Solana + Irys/Arweave | Soulbound NFTs, genesis hash, photos on Irys, manifests on Irys, hashed identifiers, categorical data | Designed for long-term availability |
Tier 2 (Backend) stores operational data required for record search, attestation management, and payment processing. It is not a pass-through — it stores pet metadata and serves as the primary query layer for the system's API.
Access Boundaries
| Access Level | What's Visible | How Access Is Controlled |
|---|---|---|
| Public | Pet name (if owner opts in), species, breed, birth year-month, photos (Irys), health category, hashed identifiers, attestation types | No account required; rate-limited public endpoints and on-chain queries |
| Owner | All public data + clinic name, clinic city/state, attestation notes | Wallet-authenticated requests; attestation fields designed to be encrypted at rest and decrypted on read |
| Vet | All owner data + vet signature, license hash, justification | Credential-authenticated requests |
| Admin | All fields | API key + rate limiting |
Access boundaries are enforced by a privacy gateway service that projects attestation data based on the requester's role. Fields outside a role's scope are omitted from the response, not masked.
Privacy Enforcement Stack
Privacy is enforced through multiple independent mechanisms rather than a single control point:
- Public write guard — deny-by-default schema is designed to block identity-bearing fields before on-chain writes. A pattern-detection backstop scans for common sensitive data formats as a second layer.
- Credential hashing — vet credentials (license number, clinic ID) are hashed on-device using SHA-256 with domain separators and challenge-response for replay protection.
- Privacy screening — uploaded documents are screened for personal information using pattern detection. The system is designed to block uploads when screening is unavailable.
- Wallet isolation — each pet record uses a unique derived wallet address, enforced at the application layer.
- Role-gated access — a privacy gateway enforces role-based projections on attestation data. Attestation fields are designed to be encrypted at rest.
3. Genesis Hash
Each pet record is anchored to a Solana Token-2022 mint via a cryptographic hash computed at creation time. This hash creates a tamper-evident link between the on-chain record and the pet's data.
What's Hashed
The genesis hash is computed from:
- Categorical pet attributes (species, breed, birth year-month)
- Hashed identifiers (microchip numbers are hashed, never stored raw)
- Timestamp and wallet data (for uniqueness and attribution)
- Breeder attribution (kennel hash, if provided)
The specific field ordering, serialization format, and hashing parameters follow a frozen canonical data profile. This profile is versioned and documented to enable independent implementations.
On-Chain Storage
The genesis hash is stored in the Token-2022 metadata URI field as a SHA-256 digest. Additional metadata fields (pet name, designation, genesis tier) are stored as Token-2022 additional metadata key-value pairs.
Independent Checking
Genesis hash integrity can be checked without Nebula API access. The process requires:
- Pet data from the owner (locally stored)
- On-chain genesis hash (queryable via any public Solana RPC endpoint)
- A standard SHA-256 implementation
If the computed hash matches the on-chain hash, the data is authentic and unaltered since mint. This checking path does not require Nebula credentials or API access.
Scope of Independent Checking
Independent checking via genesis hash confirms data integrity — that the pet data presented matches what was recorded at mint time. It does not confirm the truthfulness of the original data entry. Attestation-level checking (vet observations, health records) currently requires Nebula's API. Attestation-level public anchoring is in development.
4. Wallet Derivation
Each pet record is created with a unique wallet address derived deterministically from a single master seed using hierarchical deterministic (HD) wallet derivation.
Properties
- One master seed phrase controls all pet wallets
- Each pet receives a unique, deterministic wallet address
- Addresses cannot be correlated on-chain without the seed
- User backs up one phrase, controls all pet records
Privacy Implications
| Without Wallet Isolation | With Wallet Isolation (Application-Enforced) |
|---|---|
| All pets linked to a single address | Each pet has a unique address |
| Owner behavior trackable across pets on-chain | No direct correlation possible on-chain without the seed |
| Transaction patterns reveal ownership scope | Each pet appears as an independent entity on-chain |
Wallet isolation is mandatory in the protocol. It is enforced at the application layer and is not user-configurable.
The specific derivation path structure is protected as implementation hardening.
5. Non-Transferable Records
Pet records are implemented as non-transferable tokens using Solana's Token-2022 NonTransferable extension. Once minted, a record cannot be sent to another wallet through standard token transfer mechanisms.
Token Properties
- Non-transferable — enforced at the protocol level by Token-2022; cannot be circumvented by the application
- Burnable — owner can irreversibly destroy the record
- Mint account persists — even after burn, the mint account remains on Solana; on-chain history is not erasable
- Metadata stored on-chain — genesis hash, pet name, designation stored via Token-2022 metadata extensions
Managed Transfer Protocol
Ownership changes are handled through a managed transfer pipeline, not standard token transfers. The pipeline follows a defined state machine:
- Initiation — sender and receiver both confirm the transfer via dual-confirmation workflow
- Freeze — the sender's existing record is frozen on-chain (freeze authority held by the system payer wallet)
- Mint — a new non-transferable record is minted on the receiver's derived wallet with the same genesis data
- Migration — database records (attestations, manifests, metadata) are migrated to the new mint address in a coordinated workflow designed to prevent partial completion
Each state transition is recorded in an audit trail. The sender's frozen record remains on-chain as historical provenance. The full documented history — attestations, photos, manifest versions — transfers to the new record.
The transfer pipeline uses a two-transaction architecture to stay within Solana's 1232-byte transaction size limit.
6. Attestation Protocol
Licensed professionals (veterinarians) create structured attestation records attributed to their hashed credentials.
Attestation Structure
Each attestation contains:
- Reference to pet record (mint address)
- Attestation type (categorical)
- Hashed professional credentials (license hash, clinic ID hash, vet name hash)
- Timestamp
- Verification flags (e.g., microchip scanned and matched)
- Optional clinical fields (clinic name, notes, justification) — encrypted at rest, role-gated on read
Attestation Types
| Type | Purpose |
|---|---|
| microchip_verification | Confirm scanned chip matches record |
| health_examination | Document that exam occurred |
| vaccination_record | Record vaccination administered or confirmed |
| ownership_attestation | Professional confirmation of ownership |
| record_confirmation | General record documentation |
| professional_duty_report | Welfare concern (vet-initiated, no owner consent required) |
Credential Handling
Vet credentials are hashed on-device before transmission using SHA-256 with domain separators. The server stores only hashed values. Hashing uses a versioned salt and pepper scheme that supports credential rotation without breaking existing attestation lookups.
Attestation data is stored on Nebula's servers, not on public infrastructure. Attestation-level public anchoring is in development.
7. Manifest System
Manifests are versioned, hash-linked snapshots of record state stored on durable decentralized storage (Irys/Arweave).
Manifest Types
- Profile manifests — pet metadata snapshots (name, species, breed, primary image, genesis references)
- Album manifests — photo history with event types, hashes, moderation status, and Irys transaction IDs
Hash Chain
Each manifest version includes:
- Schema version identifier (frozen per version)
- Content hash of the current manifest (SHA-256)
- Previous manifest Irys transaction ID (backward pointer)
- Previous manifest content hash (for tamper-evident linkage)
- Version number (strictly increasing)
This forms a hash chain that can be walked backward to check the integrity of the full manifest history. Forks, gaps, and hash mismatches are detectable.
On-Chain Anchoring
Manifest hashes and Irys transaction IDs are stored as Token-2022 additional metadata fields on the pet's on-chain record. This allows independent checking of manifest integrity without querying Nebula's servers — the Irys transaction ID can be used to fetch the manifest directly from Arweave, and the content hash can be recomputed and compared.
Storage Characteristics
Manifests are stored on Arweave via Irys. Content is accessible through multiple gateways (gateway.irys.xyz, arweave.net). Manifests are designed for long-term availability independent of Nebula's operational status.
8. Implementation Access
The protocol rules and record-checking mechanics described in this document are public. Specific implementation details — including exact data schemas, derivation path structures, hashing parameters, and internal abuse-prevention controls — are protected as implementation hardening.
What's Public
- Protocol structure and storage boundaries (this document)
- Record-checking mechanics (genesis hash, manifest hash chains)
- Attestation types and credential handling approach
- Frozen canonical data profile (serialization rules for independent implementations)
- On-chain data (queryable via any public Solana RPC endpoint)
- Irys/Arweave content (queryable via public gateways)
What's Hardened
- Exact field schemas and serialization parameters
- Wallet derivation path structure
- Hashing salt and pepper values
- Abuse-prevention and rate-limiting internals
- Backend service architecture
Implementation documentation is available to qualified technical partners, security auditors, regulatory bodies, and enterprise evaluators.
Patent Notice
The Genesis Protocol is protected by U.S. Patent Application No. 19/462,031, filed January 28, 2026. 35 claims covering record anchoring, canonical data serialization, independent record checking, attestation chains, and emergency projection systems for non-human subjects.
This specification is provided for informational purposes. The protocol is designed as an open specification intended for adoption by compatible implementations. For licensing inquiries: [email protected]