This Technical Overview is provided for informational purposes only. It is NOT part of the Privacy Policy or Terms of Service and does not create any legal obligations. In the event of any inconsistency, the Privacy Policy and Terms of Service govern exclusively. Technical details may change without notice.
Purpose of This Document
This page provides technical architecture and implementation information for users, auditors, and interested parties. All legal disclosures, rights, and obligations are contained exclusively in the Privacy Policy and Terms of Service.
1. Blockchain Architecture & Digital Records
Digital records are non-transferable tokens minted on the Solana blockchain using the Token-2022 standard with the NonTransferable extension. Under the current implementation, each record is assigned to a unique, isolated derived wallet address through per-pet wallet rotation enforced at the application layer.
Implementation details in this section reflect the current system as of April 6, 2026. Details may change without notice; the Privacy Policy and Terms of Service govern in all cases.
On-Chain Metadata Fields (Token-2022)
| Field | Description |
|---|---|
| name | System-generated identifier (e.g., "PET-LEDGER #42-A1B2C3D4") — does not contain the pet's actual name |
| symbol | Token symbol: "NEBULA" |
| uri | Genesis hash in the format nebula:v1:{sha256} — a cryptographic hash of the pet's genesis metadata, not a URL |
| Designation | Series identifier (e.g., "ground-zero"), stored as additional metadata if applicable |
| Genesis Tier | Mapped tier classification (e.g., "PIONEER", "FOUNDER"), stored as additional metadata |
Not stored directly on Solana: Pet names, owner names, owner contact information, veterinary records, vaccination history, species, breed, date of birth, sex, color, microchip numbers, device fingerprints. These are stored on the user's device or on Nebula's servers (encrypted at rest where applicable).
Stored on public decentralized storage: Photos and manifests may be stored on Irys/Arweave as part of the pet's record. This content is publicly accessible through multiple gateways and is separate from Solana on-chain data.
Genesis Hash
The URI field contains a SHA-256 hash computed from the pet's genesis metadata (species, breed, birth year and month, and other categorical attributes) serialized using a frozen canonical data profile. This hash enables independent integrity checking: anyone with the original data, the same canonicalization profile version, and a SHA-256 implementation can recompute the hash and compare it to the on-chain value via any public Solana RPC endpoint.
2. Three-Tier Storage Architecture
| Tier | Location | What's Stored |
|---|---|---|
| Tier 1: Local | User device | Private keys, recovery phrase, detailed notes, full local records, local photo copies |
| Tier 2: Backend | Nebula servers | Pet metadata (name, species, breed), attestation records (designed to be encrypted at rest), payment and session data, manifest index |
| Tier 3: Public | Solana + Irys/Arweave | Non-transferable NFTs, genesis hash, photos and manifests on Irys/Arweave, hashed identifiers, categorical data |
Pet names are stored on the backend. Under the current implementation, pet names are not publicly searchable by default — owners may opt in to make their pet's name visible for public record lookup. Users should review the Privacy Policy for details on how record lookup operates. Photos are stored on Irys/Arweave as part of the pet's record. Attestation fields (clinic name, notes, veterinary attestation attribution) are designed to be encrypted at rest, and access is role-gated (Public, Owner, Vet, Admin).
3. Privacy Enforcement
Privacy is enforced through multiple independent mechanisms:
- 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
- Credential hashing — under the current implementation, vet credentials are hashed on-device before transmission
- 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 — under the current implementation, 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
4. Wallet & Key Management
- Seed phrases and private keys are encrypted with PBKDF2 (100,000 iterations) + NaCl (XSalsa20-Poly1305 AEAD)
- Encrypted keys are stored in device secure storage (iOS Secure Enclave / Android Keystore)
- The system is designed so that Nebula does not have access to unencrypted keys under normal operation
- For supported devices, biometric authentication (Face ID / Touch ID) is required before minting operations
5. Recovery Phrase & Compromise Scenarios
The 12-word recovery phrase is the master key to the wallet. A compromise allows full wallet recreation and signing authority on any device.
Protected at the protocol level: Non-transferable records cannot be transferred via standard token mechanisms. On-chain history is designed to be tamper-evident; inconsistencies in anchored data should produce detectable hash mismatches.
6. Record Transfer Protocol
Record transfers follow a managed pipeline with dual confirmation:
- Initiation — sender and receiver both confirm the transfer
- Freeze — the sender's existing record is frozen on-chain
- Mint — a new non-transferable record is minted on the receiver's derived wallet
- 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. Transfer session metadata is retained for fraud prevention as described in the Privacy Policy.
7. Manifest System
Manifests are versioned, hash-linked snapshots of record state stored on Irys/Arweave. Each manifest includes the content hash of the previous version, forming a tamper-evident chain that can be walked backward to check integrity. Manifest hashes are anchored to the pet's on-chain record via Token-2022 additional metadata fields.
8. Third-Party Integrations
- Payments: Stripe, Inc.
- CDN and edge security: Cloudflare, Inc.
- Error monitoring: Sentry
- Blockchain network: Solana mainnet
- Token standard: Token-2022 (Solana)
- Decentralized storage: Irys / Arweave
9. Cross-Border & Validator Network
Blockchain transactions are replicated across Solana validators worldwide. Irys/Arweave content is accessible through multiple public gateways. We do not control where independent validators and gateway operators are located or how long replicated or publicly available data may remain accessible.
Change Log
Version 2.0 (April 6, 2026) — Full rewrite: corrected on-chain metadata fields to match current implementation, added three-tier storage architecture, added privacy enforcement mechanisms, updated transfer protocol to current freeze/mint/migrate pipeline, added manifest system, removed fields no longer stored on-chain (microchip, deviceFingerprint, species, breed, color, dob, sex as individual fields).
Version 1.0.1 (Feb 21, 2026) — Initial public version.