Technology Stack Decisions

Core Philosophy: Infrastructure for Global Commerce Revolution

Plings technology choices are driven by one primary goal: enabling every physical object to become an autonomous commerce endpoint. This revolutionary requirement shaped every architectural decision, prioritizing:

  1. Payment Infrastructure Integration: HD wallet → Solana address mapping
  2. Global Scale: Handle Visa/Mastercard transaction volumes (600K+ TPS with Firedancer)
  3. Offline Capability: Objects must verify authenticity without network
  4. Economic Efficiency: Minimal fees to enable $1 candy bar purchases

1. Blockchain Foundation: Solana

Why Solana Instead of Ethereum/Bitcoin?

Core Requirement: Every Plings identifier must be a native blockchain address capable of receiving payments.

Blockchain Transaction Fee Confirmation Time TPS NFT Support HD Wallet Integration Verdict
Solana $0.00025 400ms 4,500 (600K w/ Firedancer) Native (Metaplex) Ed25519 + PDAs ✅ CHOSEN
Ethereum $5-50 12 seconds 15 ERC-721/1155 Requires proxy contracts ❌ Too expensive
Bitcoin $1-20 10 minutes 7 None Limited smart contracts ❌ Not suitable
Cardano $0.30 20 seconds 250 Native UTXO compatibility ⚠️ Too slow for retail

Decision: Solana enables universal cost structure - same infrastructure for $1 candy bars and $50M corporate jets.

Program Derived Addresses (PDAs) - The Security Breakthrough

Problem: If HD wallet private keys are controlled by manufacturers, they could steal payments intended for objects.

Solution: Solana’s PDAs enable deterministic addresses controlled by Plings smart contracts:

// Payment goes to PDA (Plings controlled), not raw HD address (manufacturer controlled)
let payment_address = Pubkey::find_program_address(&[
    b"object_payment",
    "1.15.1.1.C3.1.158".as_bytes()  // HD path as seed
], &plings_program_id);

Result: Manufacturers retain cryptographic verification capabilities while Plings controls payment routing.

2. Databases: Dual Architecture for Different Strengths

Neo4j Aura (Graph Database)

Purpose: Complex relationship traversal and spatial hierarchies

Why Neo4j Over Alternatives:

Use Cases:

Supabase PostgreSQL

Purpose: User authentication, financial data, and compliance

Why PostgreSQL Over NoSQL:

Why Supabase Over AWS RDS:

3. API Layer: GraphQL for Commerce Complexity

Why GraphQL Over REST?

Commerce Complexity Requirements:

Example: Object scan query needs:

query ObjectScan($identifier: String!) {
  object(identifier: $identifier) {
    name
    manufacturer { name, verification }
    currentLocation { name, hierarchy }
    owner { name, contact }
    availableServices {
      type # rent, repair, insurance
      provider { name, rating }
      pricing { amount, duration }
      availability
    }
    paymentAddress # Solana PDA
    verificationStatus
  }
}

REST Equivalent: Would require 6-8 separate API calls.

Ariadne Over Alternatives

Library Performance Python Integration Async Support Schema-First Verdict
Ariadne High Excellent Native Yes ✅ CHOSEN
Strawberry High Good Yes Code-first ⚠️ Schema complexity
Graphene Medium Excellent Limited Code-first ❌ Performance issues

Decision: Ariadne’s schema-first approach enables clear API contracts for commerce integrations.

4. Frontend: Progressive Web App for Universal Access

React 18 + TypeScript

Rationale:

Why PWA Over Native Apps?

Universal Commerce Requirements:

Commerce Flow Example:

  1. No app: Scan QR → Web page → Basic payment via Web3 wallet
  2. With app: Scan QR → Enhanced UI → Integrated payment + history
  3. Future: NFC scanning → Instant payment without camera

5. Payment Integration: Solana Wallet Ecosystem

Multi-Wallet Support Strategy

Core Wallets:

Integration Architecture:

interface WalletAdapter {
  connect(): Promise<PublicKey>;
  signTransaction(transaction: Transaction): Promise<Transaction>;
  disconnect(): Promise<void>;
}

// Universal payment flow regardless of wallet
async function payObject(objectPDA: PublicKey, amount: number, wallet: WalletAdapter) {
  const transaction = await buildPaymentTransaction(objectPDA, amount);
  const signed = await wallet.signTransaction(transaction);
  return await sendTransaction(signed);
}

6. HD Wallet Cryptography: BIP32 + Ed25519

Why HD Wallets Over PKI?

Critical Business Requirements:

  1. Payment Integration: Each identifier must function as a blockchain wallet
  2. Manufacturing Control: Secure delegation of object creation to subcontractors and plants

HD wallets uniquely enable both:

Why BIP32 Standard?

Why Ed25519 Over secp256k1?

7. Hosting & Deployment: Edge-First Architecture

Vercel for Global Edge Distribution

Requirements:

Database Distribution Strategy

8. Real-Time Infrastructure: Critical for Commerce

GraphQL Subscriptions via WebSockets

Use Cases:

Fallback Strategies

9. Security Architecture: Financial-Grade Requirements

HSM Integration for Master Keys

Audit Trail Requirements

10. Future Scalability: Visa/Mastercard Replacement Timeline

Current Limitations

Firedancer Upgrade Path (2025-2026)

Mass Adoption Strategy

These technology decisions position Plings to become the global payment infrastructure by making every physical object a commerce endpoint. Each choice prioritizes the revolutionary goal of replacing traditional payment systems with direct object commerce.