Ownership Handling

Created: Thu Jul 10 21:47:22 CEST 2025
Last Updated: Sun 27 Jul 2025 08:40:00 CEST - CRITICAL: Added cryptographic vs. legal ownership analysis
Architecture Version: 3.1 - Trust-Aware Ownership Design
Document Version: 2.2 - Added trust boundary analysis and private key ownership implications
Security Classification: Critical Security Documentation
Target Audience: Manufacturers, Integrators, Business Partners, Developers, Security Team
Author: Paul Wisén

See Also: For detailed information about blockchain-based ownership and payment flows, see Solana Payment Architecture

1. Introduction

Fundamental Principle: In Plings, objects are owned by organizations, not individual users. This is a core architectural decision that affects all aspects of the system.

⚠️ CRITICAL: Ownership vs. Cryptographic Control

Core Trust Principle: Legal Ownership ≠ Cryptographic Key Access

The Plings HD wallet system enables multiple parties to derive private keys for any object identifier, but this does not grant legitimate ownership authority. This section clarifies the critical distinction between:

Legal Ownership: Who has legitimate authority over an object (tracked in this document)
Cryptographic Control: Who can derive private keys for an object (tracked in HD Wallet Trust Boundaries)

Why This Distinction Matters

Dangerous Assumption: “If I can derive the private key, I can control the object”
Reality: Private key access is for specific operational purposes only and does not override legal ownership.

Example of Trust Violation:

Chinese factory manufactures smartwatch for Swedish consumer
Consumer purchases watch and becomes legal owner
2 years later, factory uses HD-derived private key to mark watch as "destroyed"
Consumer's legally-owned watch is now cryptographically marked as worthless
Consumer has no recourse against unauthorized cryptographic action

Safe Approach: Private key operations must respect ownership boundaries and be limited to legitimate operational needs (payment recovery, warranty claims, supply chain verification during manufacturing).

REQUIRED READING: HD Wallet Trust Boundaries and Private Key Use Cases Analysis for complete implementation guidelines.

Organization-Based Ownership

Every object has an owner_organization_id that references the owning organization
Users access objects through their membership in organizations
Individual users are tracked via created_by for audit and creation tracking
Access control uses Row-Level Security (RLS) based on organization membership
Users can belong to multiple organizations and switch context between them
High-value objects may also have NFT representation on Solana blockchain

Why Organizations, Not Users?

Business Reality: Most valuable objects belong to companies, families, or other organizational entities
Shared Access: Multiple users need access to the same objects (employees, family members)
Access Control: Centralized management of permissions through organization membership
Scalability: Easier to manage permissions for groups rather than individual object shares
Blockchain Compatibility: Organization wallets can hold NFTs representing object ownership
Trust Boundary Protection: Organizations provide clear legal entities for ownership disputes and authority validation

Safe vs. Dangerous Ownership Operations

✅ SAFE: Ownership Operations (Respect Legal Authority)

These operations correctly respect the organization-based ownership model and do not conflict with HD wallet trust boundaries:

# ✅ SAFE: Organization-controlled ownership transfer
def transfer_object_ownership(from_org_id: str, to_org_id: str, object_id: str, signed_agreement: str):
    """Transfer ownership via organization system - SAFE"""
    
    # Verify both organizations have signed transfer agreement
    if not verify_transfer_agreement(signed_agreement, from_org_id, to_org_id):
        raise InvalidTransferError("Transfer agreement invalid")
    
    # Update database ownership record
    update_object_owner(object_id, to_org_id)
    
    # Transfer NFT if it exists
    if has_nft(object_id):
        transfer_nft(get_nft_mint(object_id), from_org_id, to_org_id)
    
    # Log transfer event
    log_ownership_transfer(object_id, from_org_id, to_org_id, signed_agreement)
    
    return True

# ✅ SAFE: Owner-controlled object retirement
def retire_object_by_owner(owner_org_id: str, object_id: str, owner_signature: str):
    """Object retirement controlled by legal owner - SAFE"""
    
    # Verify ownership
    if not verify_organization_owns_object(owner_org_id, object_id):
        raise UnauthorizedError("Organization does not own object")
    
    # Verify authorized signature
    if not verify_organization_signature(owner_signature, owner_org_id):
        raise UnauthorizedError("Invalid organization signature")
    
    # Update object status
    update_object_status(object_id, "retired", owner_org_id)
    
    return True

❌ DANGEROUS: Cryptographic “Ownership” Operations (Trust Violations)

These operations incorrectly use HD wallet private key access to override legal ownership - NEVER IMPLEMENT:

# ❌ DANGEROUS: Private key "ownership" transfer
def transfer_ownership_via_private_key(identifier_path: str, new_owner: str):
    """
    DANGEROUS - Uses cryptographic capability to override legal ownership
    Manufacturer could "steal" objects years after sale
    """
    # This violates trust boundaries - DO NOT IMPLEMENT
    signature = derive_and_sign(identifier_path, {"transfer_to": new_owner})
    blockchain.transfer_ownership(signature)  # TRUST VIOLATION

# ❌ DANGEROUS: Private key object retirement
def retire_object_via_private_key(identifier_path: str):
    """
    DANGEROUS - Allows supply chain participants to "destroy" objects post-sale
    Factory could mark consumer's watch as destroyed years later
    """
    # This violates trust boundaries - DO NOT IMPLEMENT
    signature = derive_and_sign(identifier_path, {"action": "retire"})
    blockchain.mark_object_destroyed(signature)  # TRUST VIOLATION

# ❌ DANGEROUS: Autonomous ownership decisions
def autonomous_ownership_operation(identifier_path: str, operation: dict):
    """
    DANGEROUS - Allows post-sale control over ownership decisions
    Manufacturer retains permanent control over user property
    """
    # This violates trust boundaries - DO NOT IMPLEMENT
    signature = derive_and_sign(identifier_path, operation)
    execute_ownership_operation(signature)  # TRUST VIOLATION

Key Differences

Safe Operations	Dangerous Operations
✅ Use organization-based ownership system	❌ Use HD wallet private keys for ownership
✅ Require explicit owner consent	❌ Allow unauthorized post-sale control
✅ Respect legal ownership boundaries	❌ Confuse cryptographic capability with authority
✅ Provide owner recourse mechanisms	❌ No recourse for unauthorized actions
✅ Follow established legal frameworks	❌ Create new trust assumptions

Objects in the Universal Object Graph System (UOGS) can be nested many levels deep—Batch → Pallet → Box → Can, Bike → Wheel → Tyre, etc. This document explains how Plings models ownership across those levels without exploding the instance count while still providing precise, auditable transfers.

Key principles:

Explicit instance ⇒ Explicit ownership. Only instantiated objects store their own owner_organization_id.
Implicit ownership inheritance. Non-instantiated components inherit ownership from the closest instantiated ancestor (their container).
Instantiate at the level of transaction. Create an ObjectInstance the moment something must be sold, transferred, or tracked independently.

2. The Container Pattern

Every ObjectClass that represents a container can list component requirements. When an ObjectInstance of that class is created it implicitly owns all of its components until one of them is instantiated explicitly.

Example hierarchy for canned drinks:

BatchOfCans — may contain N pallets.
PalletOfCans — may contain M boxes.
BoxOfCans — contains K cans.
Can — the single drink unit.

A manufacturer might create:

BatchInstance ─┐
               ├─(implicit)─ Pallet #1
               ├─(implicit)─ Pallet #2
               └─ … Pallet #10

No pallet instances exist yet; the batch implicitly owns every pallet, box, and can.

Instantiation-on-Demand

If the producer sells the entire batch to a store, no new instances are needed—just update BatchInstance.owner_organization_id.

If the store then sells Pallet #7 to a distributor, the system:

Instantiates ObjectInstance/Pallet-007.
Links it via -[:PART_OF]-> to BatchInstance.
Copies owner_organization_id = BatchInstance.owner_organization_id (the store).
Executes a transfer, setting owner_organization_id = Distributor on Pallet-007.

All boxes and cans inside Pallet-007 now implicitly belong to the distributor.

3. Ownership Inheritance Rule

When a child instance C is created under parent P:

C.owner_organization_id  ←  P.owner_organization_id          (inherit at creation)
C.parent ←  P.id             (PART_OF / CONTAINS relation)

The rule is enforced in the backend procedure that performs instantiation, guaranteeing consistency across databases.

4. Database Representation

4.1 Supabase / Postgres

object_instances

column	type	note
id	uuid	PK
class_id	uuid	FK → `object_classes.id`
owner_organization_id	uuid	FK → `organizations.id` (THE OWNER)
created_by	uuid	FK → `auth.users.id` (for audit)
parent_id	uuid	Nullable FK → `object_instances.id`
neo4j_id	text	Pointer to graph node
statuses	jsonb	Multi-status field (see object-status doc)
nft_mint	text	Solana NFT mint address (high-value items)

Note: The owner_organization_id field determines object ownership. The created_by field is for audit tracking only. The nft_mint field links to blockchain NFT for high-value items (> €5).

Row-Level Security example (simplified):

create function create_instance(_class uuid, _parent uuid, _statuses jsonb)
returns uuid as $$
declare
  _owner_org_id uuid;
  _new_id uuid := gen_random_uuid();
begin
  select owner_organization_id into _owner_org_id from object_instances where id = _parent;
  insert into object_instances(id, class_id, owner_organization_id, parent_id, statuses)
  values(_new_id, _class, _owner_org_id, _parent, _statuses);
  return _new_id;
end;
$$ language plpgsql security definer;

4.2 Neo4j

Cypher helper:

MATCH (p:ObjectInstance {id: $parentId})
CREATE (c:ObjectInstance {
  id: randomUUID(),
  owner_organization_id: p.owner_organization_id,
  statuses: $statuses
})-[:PART_OF]->(p)
SET c:InstanceOf_$classLabel
RETURN c;

5. Transfer Workflow

Offer Creation – Seller creates a TransferOffer object (optional escrow terms).
Acceptance – Buyer authenticates and signs the offer.
Atomic Update – Backend: a. Validates signatures & RLS permissions. b. Updates owner_organization_id on the target instance. c. If NFT exists, transfers NFT to buyer’s organization wallet. d. Logs TransferEvent (instance_id, from_owner, to_owner, timestamp).
Notification – Push update to both parties.

Bulk moves (e.g., entire pallet) require only one owner_organization_id change at the pallet level. For high-value items with NFTs, the NFT transfer provides additional cryptographic proof of ownership change.

6. Object-to-Object Ownership Model

6.1 Overview

Beyond organization-based ownership, Plings supports object-to-object ownership where one object can own other objects. This creates natural ownership hierarchies that reflect real-world relationships.

Example Hierarchy:

Organization: ACME Corp
    └─ OWNS → TV Instance (Samsung 55" QLED)
              ├─ OWNS → Remote Instance (Samsung Smart Remote)
              ├─ OWNS → Manual Instance (Quick Start Guide)
              ├─ OWNS → Cable Instance (HDMI Cable)
              └─ OWNS → Warranty Instance (2-Year Extended)

6.2 Use Cases

Electronics & Accessories

TV: Owns remote, manual, cables, warranty card
Laptop: Owns charger, mouse, carrying case, software licenses
Phone: Owns charger, earbuds, case, screen protector

Vehicles & Components

Car: Owns spare tire, jack, owner’s manual, first aid kit
Bike: Owns helmet, lock, repair kit, water bottle

Furniture & Parts

Desk: Owns assembly hardware, instruction manual, warranty
Chair: Owns cushions, armrest covers, assembly tools

6.3 Ownership Types

Ownership Type	Description	Example	Transfer Behavior
Direct Organization	Organization directly owns object	ACME Corp → TV	Manual transfer
Object Hierarchy	Object owns other objects	TV → Remote	Automatic transfer
Mixed Chain	Combination of both	ACME → TV → Remote	Follows chain

6.4 Ownership Resolution

Finding Ultimate Owner

Every object, regardless of hierarchy depth, has an ultimate organization owner:

def get_ultimate_owner(object_id: str) -> str:
    """
    Traverse ownership chain upward until reaching organization.
    
    Example chain: Remote → TV → ACME Corp
    Returns: ACME Corp organization ID
    """
    current_object = get_object(object_id)
    
    while current_object.owner_object_id is not None:
        current_object = get_object(current_object.owner_object_id)
    
    return current_object.owner_organization_id

Finding Owned Objects

Get all objects owned by a given object (recursive):

def get_owned_objects_tree(object_id: str) -> dict:
    """
    Returns hierarchical tree of all owned objects.
    
    TV → {
        "remote": {...},
        "manual": {...},
        "cables": [
            {"hdmi_cable_1": {...}},
            {"hdmi_cable_2": {...}}
        ]
    }
    """
    owned_objects = {}
    direct_children = get_objects_owned_by(object_id)
    
    for child in direct_children:
        child_tree = get_owned_objects_tree(child.id)
        owned_objects[child.id] = {
            "object": child,
            "children": child_tree
        }
    
    return owned_objects

6.5 Transfer Behavior

Automatic Child Transfer

When an object is transferred, all owned objects transfer automatically:

graph TD A[Transfer TV] --> B{Check Owned Objects} B --> C[TV has: Remote, Manual, Cable] C --> D[Transfer TV to New Owner] D --> E[Auto-transfer Remote to New Owner] E --> F[Auto-transfer Manual to New Owner] F --> G[Auto-transfer Cable to New Owner] G --> H[Update All Ownership Records]

Transfer Confirmation

Before transfer, show user complete ownership tree:

Transfer Confirmation:
┌─ Samsung 55" QLED TV
├─ Samsung Smart Remote
├─ Quick Start Manual
├─ HDMI Cable (3ft)
└─ Extended Warranty Card

Total items: 5
Estimated value: $1,299

Partial Transfers (Advanced)

Users can optionally exclude certain owned objects:

Transfer Options:
☑ Samsung 55" QLED TV (required)
☑ Samsung Smart Remote  
☑ Quick Start Manual
☐ HDMI Cable (keep separately)
☑ Extended Warranty Card

6.6 Database Implementation

PostgreSQL Schema Enhancement

-- Add polymorphic ownership to object_instances
ALTER TABLE object_instances 
ADD COLUMN owner_object_id uuid REFERENCES object_instances(id);

-- Ensure exactly one owner type
ALTER TABLE object_instances
ADD CONSTRAINT check_single_owner 
CHECK (
    (owner_organization_id IS NOT NULL AND owner_object_id IS NULL) OR
    (owner_organization_id IS NULL AND owner_object_id IS NOT NULL)
);

-- Prevent circular ownership
CREATE OR REPLACE FUNCTION prevent_circular_ownership()
RETURNS TRIGGER AS $$
BEGIN
    -- Check if NEW.owner_object_id would create a cycle
    IF NEW.owner_object_id IS NOT NULL THEN
        WITH RECURSIVE ownership_chain AS (
            SELECT id, owner_object_id, 1 as depth
            FROM object_instances 
            WHERE id = NEW.owner_object_id
            
            UNION ALL
            
            SELECT oi.id, oi.owner_object_id, oc.depth + 1
            FROM object_instances oi
            JOIN ownership_chain oc ON oi.id = oc.owner_object_id
            WHERE oc.depth < 10 -- Prevent infinite recursion
        )
        SELECT 1 FROM ownership_chain WHERE id = NEW.id;
        
        IF FOUND THEN
            RAISE EXCEPTION 'Circular ownership detected';
        END IF;
    END IF;
    
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trigger_prevent_circular_ownership
    BEFORE INSERT OR UPDATE ON object_instances
    FOR EACH ROW EXECUTE FUNCTION prevent_circular_ownership();

Neo4j Schema Enhancement

// Support polymorphic OWNS relationships
// Organization → Object
(:Organization)-[:OWNS]->(:ObjectInstance)

// Object → Object  
(:ObjectInstance)-[:OWNS]->(:ObjectInstance)

// Query: Find ultimate owner
MATCH (obj:ObjectInstance {id: $objectId})
MATCH (obj)-[:OWNS*0..]-(parent)-[:OWNS]-(org:Organization)
WHERE NOT exists((org)-[:OWNS]-())
RETURN org

// Query: Get ownership tree
MATCH (obj:ObjectInstance {id: $objectId})
OPTIONAL MATCH (obj)-[:OWNS*]->(children:ObjectInstance)
RETURN obj, collect(children) as owned_objects

6.7 Edge Cases & Rules

Ownership Depth Limits

Maximum depth: 5 levels to prevent complexity
Performance: Deep trees cached in materialized views
Validation: UI warns when approaching limits

Circular Reference Prevention

Database constraint: Triggers prevent cycles
Application logic: Validation before ownership changes
Error handling: Clear messages when cycles detected

Conflicting Ownership Claims

Rule: Object can only have one owner (org OR object)
Resolution: Most recent valid ownership wins
Audit: All ownership changes logged with timestamps

Orphaned Objects

Prevention: Cascade rules ensure no orphans
Recovery: Background jobs find and fix orphans
Default: Orphaned objects revert to creating organization

7. Edge Cases & Extensions

Fractional / Shared Ownership
- Table instance_owners(instance_id, owner_id, share_percent).
Rental / Lease
- Separate possessor_id with start & end timestamps.
Lost / Stolen Items
- Transfer blocked while statuses contains lost or stolen, unless override token.
Regulated Items
- restricted_countries property on ObjectClass; transfer API checks destination.

8. FAQs

Q: Do I need a new batch per pallet? No. Instantiate pallets only if you transact by pallet; otherwise the batch alone suffices.

Q: What about traceability to a single can? As soon as the can is sold or needs its own history, instantiate it—otherwise inherit from its container.

9. Current Ownership Determination

8.1 Database-Level Ownership

Currently, object ownership is determined primarily through database queries:

-- Check ownership via Supabase RLS
SELECT * FROM object_instances 
WHERE id = $instance_id 
AND owner_organization_id IN (
  SELECT organization_id FROM organization_members 
  WHERE user_id = auth.uid()
);

Key Points:

Primary Source: PostgreSQL owner_organization_id field
Access Control: Row-Level Security (RLS) policies
Graph Sync: Neo4j maintains duplicate ownership data
API Access: RESTful endpoints validate organization membership

8.2 Ownership Query Flow

graph TD A[User Request] --> B{Auth Check} B -->|Valid| C[Organization Membership] C --> D[RLS Policy Check] D -->|Allowed| E[Return Object Data] D -->|Denied| F[403 Forbidden] B -->|Invalid| F

10. NFT-Based Ownership (Solana Integration)

9.1 Overview

While the database remains the primary ownership source today, Plings is building Solana blockchain integration for:

Cryptographic ownership proof via NFTs
Direct peer-to-peer transfers without intermediaries
Global verifiability independent of Plings infrastructure

9.2 Value-Based NFT Strategy

Not all objects require blockchain NFTs due to Solana’s rent economics:

Low-Value Items (< €0.95)

No persistent NFT created
Event-based tracking only
Database remains source of truth
Example: €0.50 bottle return

// Micropayment handler - no NFT minted
emit!(MicroPaymentProcessed {
    path: identifier.path,
    buyer: ctx.accounts.payer.key(),
    payment_amount,
    timestamp: Clock::get()?.unix_timestamp,
});

Medium-Value Items (€0.95 - €5.00)

Batched NFT accounts (future implementation)
Shared rent costs across multiple items
Hybrid database + blockchain tracking

High-Value Items (> €5.00)

Full persistent NFT minted on first payment
On-chain ownership record
NFT transfer = ownership transfer
Example: €999 iPhone, €50M jet

// High-value payment - mint NFT
pub fn mint_object_nft(ctx: Context<MintNFT>) -> Result<()> {
    // Create NFT representing object ownership
    let nft_mint = create_nft_mint(&ctx)?;
    mint_to_buyer(&ctx, &nft_mint)?;
    
    // Update object instance with NFT mint address
    ctx.accounts.object_instance.nft_mint = Some(nft_mint);
    Ok(())
}

9.3 NFT ↔ Database Synchronization

class OwnershipSyncService:
    async def sync_nft_to_database(self, nft_mint: str):
        # Get current NFT owner from Solana
        owner = await self.solana.get_nft_owner(nft_mint)
        
        # Update database ownership
        await self.supabase.update_instance_owner(
            nft_mint=nft_mint,
            new_owner=owner
        )
        
        # Update Neo4j graph
        await self.neo4j.update_ownership(
            nft_mint=nft_mint,
            new_owner=owner
        )

11. Ownership Verification Methods

10.1 Trust-Aware Multi-Source Verification

Plings uses a fallback hierarchy for ownership verification that respects trust boundaries and never relies on HD wallet private key derivation for ownership proof:

def verify_ownership(user_id: str, object_id: str) -> bool:
    """
    Trust-aware ownership verification - NEVER uses HD wallet private keys
    for ownership determination
    """
    
    # 1. Database check (fastest, primary source of legal ownership)
    if database_shows_ownership(user_id, object_id):
        return True
    
    # 2. NFT check (for high-value items - cryptographic ownership proof)
    if has_nft(object_id):
        nft_owner = get_nft_owner(object_id)
        user_org = get_user_organization(user_id)
        if nft_owner == get_organization_wallet(user_org):
            return True
    
    # 3. Event history check (for micropayments - transaction-based proof)
    if payment_event_exists(user_id, object_id):
        return True
    
    # 4. Transaction history (last resort - verified payment proof)
    if blockchain_tx_proves_ownership(user_id, object_id):
        return True
        
    # ❌ NEVER USE: HD wallet private key derivation for ownership
    # This would be a trust boundary violation:
    # if can_derive_private_key(manufacturer, object_id):
    #     return True  # DANGEROUS - Key access ≠ ownership
        
    return False

def verify_ownership_authority(requesting_party: str, object_id: str, operation: str) -> bool:
    """
    Verify if requesting party has legitimate authority for ownership operations
    """
    
    # Check legal ownership first
    if not verify_legal_ownership(requesting_party, object_id):
        return False
    
    # Validate operation scope
    if operation in ["transfer", "retire", "modify"]:
        # Only legal owner can perform ownership operations
        return verify_organization_authority(requesting_party, object_id)
    
    # Special case: HD wallet operations have different authority model
    if operation in ["payment_recovery", "warranty_claim", "supply_chain_verification"]:
        # These use HD wallet trust boundaries, not ownership verification
        return validate_hd_wallet_authority(requesting_party, object_id, operation)
    
    return False

10.2 Trust-Aware Verification Contexts

Context	Primary Method	Fallback	❌ NEVER USE	Use Case
API Access	Database RLS	Organization membership	HD private key derivation	Real-time queries
Transfer Request	Database + NFT	Event history	Manufacturer key access	Legal ownership changes
Dispute Resolution	NFT (if exists)	Transaction history	Private key capability	Legal proof
Micropayment	Event history	Transaction signature	Supply chain authority	Low-value items
HD Wallet Operations	Trust boundary validation	Temporal/scope limits	Ownership system	Recovery/warranty only

Critical Verification Rules

✅ SAFE VERIFICATION PATTERNS:

# Safe: Legal ownership verification
if verify_organization_owns_object(org_id, object_id):
    allow_ownership_operation()

# Safe: NFT-based verification  
if verify_nft_ownership(org_wallet, object_nft):
    allow_blockchain_operation()

# Safe: HD wallet authority for specific operations
if validate_hd_wallet_authority(actor, object_id, "payment_recovery"):
    allow_recovery_operation()

❌ DANGEROUS VERIFICATION PATTERNS:

# Dangerous: Using HD key derivation for ownership
if can_derive_private_key(manufacturer, object_id):
    allow_ownership_operation()  # TRUST VIOLATION

# Dangerous: Confusing operational authority with ownership
if has_warranty_authority(manufacturer, object_id):
    allow_ownership_transfer()  # TRUST VIOLATION

# Dangerous: Permanent post-sale authority
if is_original_manufacturer(actor, object_id):
    allow_any_operation()  # TRUST VIOLATION

12. Future Ownership Solutions

11.1 Blockchain as Primary Source

Vision: Transition from database-centric to blockchain-centric ownership by 2027.

Benefits:

Immutability: Ownership history cannot be altered
Decentralization: No single point of failure
Global Access: Anyone can verify ownership
Direct Transfers: Peer-to-peer without Plings involvement

11.2 Migration Strategy

Phase 1: Hybrid Model (Current)

Database = primary source
NFTs = high-value items only
Events = micropayment tracking

Phase 2: Blockchain Priority (2026)

NFTs minted for all items > €1
Database mirrors blockchain state
Smart contracts handle transfers

Phase 3: Full Decentralization (2027+)

Blockchain = single source of truth
Database = cache/index only
Users control their own data

11.3 Technical Challenges

Scalability: Waiting for Solana Firedancer (600k TPS)
Cost: Rent economics for billions of objects
User Experience: Wallet management complexity
Regulatory: Compliance with ownership laws

11.4 Opportunities

Fractional Ownership: NFTs enable easy share splitting
Smart Contracts: Automated inheritance, insurance claims
Cross-Chain: Bridge to other blockchains
DeFi Integration: Objects as collateral

13. Summary

Plings ownership system is evolving from a traditional database model to a hybrid blockchain approach while maintaining strict trust boundaries:

Today: PostgreSQL + Neo4j with organization-based ownership and trust-aware HD wallet operations
In Progress: Solana NFTs for high-value items with clear separation of ownership vs. operational authority
Future: Full blockchain ownership with database as cache, maintaining trust boundary enforcement

Key Principles

✅ SAFE OWNERSHIP MODEL:

Legal Ownership: Tracked via organization-based database system and NFTs
Operational Authority: Limited HD wallet operations with strict trust boundaries
Clear Separation: Never conflate cryptographic capability with ownership rights
Owner Supremacy: Legal owners always have final authority over their objects

❌ DANGEROUS PATTERNS TO AVOID:

Using HD wallet private key derivation for ownership verification
Allowing post-sale control via manufacturer private keys
Confusing operational authority with ownership rights
Implementing cryptographic “ownership” transfer systems

Trust Boundary Enforcement

The container pattern, inheritance rules, and lazy instantiation remain valid across all ownership models. Whether tracking via database fields or NFT ownership, the principles of precision and efficiency guide the architecture with the critical addition of trust boundary respect.

Core Rule: Just because you can derive a private key doesn’t mean you should use it for ownership operations. Trust boundaries must guide all implementation decisions.

HD Wallet Trust Boundaries - CRITICAL: Required reading for any HD wallet implementation
Private Key Use Cases Analysis - Risk assessment for all private key operations
Wallet Security Model - Complete security framework including trust delegation

Implementation Rule: All ownership-related features must be reviewed against trust boundary documentation before implementation.

Search Results: