Security & Verification

The Genesis Hash is computed from:

Genesis Hash = SHA-256(
  protocol_version     // "nebula:v1:" - enables algorithm evolution
  pet_id               // Cryptographically random UUID, never reused
  mint_address         // Solana blockchain address
  species              // Categorical (Dog, Cat, etc.)
  breed                // Categorical
  microchip_hash       // SHA-256 with domain separator
  kennel_hash          // SHA-256 of breeder kennel (if attributed)
  timestamp            // ISO-8601 creation time
  block_slot           // Solana blockchain slot number
)

Why this matters: The Genesis Hash is stored on-chain. To forge a record, an attacker would need to find a SHA-256 collision (computationally infeasible), achieve sustained supermajority control of Solana validator stake, and match the exact block slot.

pet_id is a cryptographically random, non-reused UUID generated at creation time and never reassigned.

Each sensitive field gets its own domain prefix before hashing:

microchip_hash  = SHA-256("nebula:microchip:" + microchip_number)
vet_license_hash = SHA-256("nebula:vet_license:" + license_number)
kennel_hash     = SHA-256("nebula:kennel:" + kennel_name)
clinic_hash     = SHA-256("nebula:clinic:" + clinic_name)

This prevents rainbow table attacks—pre-computed hashes for one field type are useless against another.

Microchip collision handling: Microchip numbers follow ISO 11784/11785 standards. Edge cases (legacy formats, regional overlaps) are handled through manufacturer context hashing and genesis timestamp precedence.

Digital Records use Solana Token-2022 with three extensions:

On-chain metadata includes: Species, breed, hashed microchip, genesis hash, "Soulbound: True", "Investment: NO"

Revocation mechanic: The only way to remove a non-transferable digital record is to revoke it—irreversibly deleting the record. Even after revocation, the historical record remains in the public ledger.

Each pet gets its own unique address to prevent linking in the public ledger:

Master Seed (12-word BIP39 mnemonic)
    ↓
BIP44 Derivation: m/44'/501'/0'/0'  → Wallet for Pet #1
BIP44 Derivation: m/44'/501'/1'/0'  → Wallet for Pet #2
BIP44 Derivation: m/44'/501'/2'/0'  → Wallet for Pet #3

What this achieves:

• Unlinkability: No public connection between pets on the blockchain
• Single Recovery: One seed phrase recovers all derived addresses
• Standard Compliance: BIP39/BIP44 compatible with standard recovery tools
• Mandatory Enforcement: The app forces address rotation—users cannot accidentally link pets

Private keys never exist unencrypted outside of active use:

User Password
    ↓
PBKDF2-SHA256 (100,000 iterations, 32-byte random salt)
    ↓
256-bit Encryption Key
    ↓
XSalsa20-Poly1305 (NaCl secretbox, 24-byte random nonce)
    ↓
Stored: "v2:" + base64(salt + nonce + ciphertext)

Why these choices:

• PBKDF2 100K iterations: Each password guess costs ~2-3 seconds of compute time
• XSalsa20-Poly1305: Authenticated encryption detects tampering and wrong passwords
• Device-specific key layer: iOS Keychain / Android Keystore provides hardware-backed protection

Veterinary attestations form a hash chain:

Genesis → Attestation #1 → Attestation #2 → Attestation #3
             ↑                  ↑                  ↑
        previous=genesis   previous=#1       previous=#2

Each attestation includes:

• type: health_exam, vaccination, microchip_verification
• provider_id_hash: SHA-256 of vet license with domain separator
• content_hash: SHA-256 of canonical JSON attestation content
• previous_hash: Links to prior attestation
• emergency_visible: Unhashed fields for emergency access

Emergency-visible fields are intentionally stored unhashed. These are low-sensitivity data (vaccine names, rabies tags—not owner PII), optimized for emergency response, and user-consented at creation time.

A license hash is an identifier, not proof of authority. The system distinguishes:

Key revocation: Revoked clinic keys are recorded on-chain with a revocation timestamp. Verifiers must reject any attestation signed after that timestamp. Attestations created before revocation remain valid.

All content hashing uses deterministic JSON serialization:

• Key ordering: Alphabetically sorted at all nesting levels
• Whitespace: No spaces or newlines (minified)
• Numbers: No trailing zeros, no leading zeros except for values < 1
• Nulls: Explicit null, never omitted
• Unicode: UTF-8, no BOM, NFC normalization

This follows the principles of RFC 8785 (JSON Canonicalization Scheme) adapted for our use case.