2.1 System Architecture Overview
Onyx is designed as a coordination platform, not a network operator or financial intermediary. The system unifies connectivity and payments by abstracting regulated infrastructure behind a single control layer that manages identity, entitlements, and service continuity.
The architecture is modular by design. Each capability—connectivity, payments, identity, hardware—operates independently, yet resolves through a shared state model. This allows Onyx to replace or add partners without disrupting the user experience.
Architectural Principles
Onyx follows four non-negotiable architectural principles:
Partner redundancy by default.
No single carrier, issuer, or provider defines system behavior. The platform routes service dynamically based on geography, availability, and capability.
Modularity over vertical integration.
Core services evolve independently. New features attach through defined interfaces rather than rewiring the system.
Single source of truth.
Identity, entitlements, and transaction state resolve through one canonical backend, regardless of entry point.
Minimal persistent state.
The platform stores only what is required to deliver service. Regulated partners retain custody of sensitive infrastructure data.
System Layers (High-Level)
Client Layer
Users interact with Onyx through:
- The Onyx mobile application
- Onyx ONE hardware (when applicable)
- Partner-facing surfaces (events, devices, integrations)
Clients never embed carrier logic or payment rails directly. All service requests route through the control layer.
Onyx Control Layer (Owned)
The control layer coordinates system behavior and enforces product logic.
It is responsible for:
- Identity resolution and session control
- Service activation and lifecycle management
- Network-agnostic plan orchestration
- Payment routing across card and stablecoin rails
- Entitlements and access control
- Referral and rewards coordination (when enabled)
This layer determines what a user is entitled to. It does not execute regulated operations itself.
Partner Infrastructure Layer
Licensed partners provide the underlying infrastructure Onyx does not own.
This includes:
- Mobile network access and provisioning
- Numbering and voice services (when enabled)
- Card issuance and transaction processing
- Stablecoin minting, custody, and redemption
Partners operate independently. Onyx treats them as interchangeable providers behind standardized interfaces.
Hardware Integration Layer
Onyx ONE integrates as a secure endpoint, not a dependency.
The device:
- Authenticates the user at the hardware level
- Enforces device-local security boundaries
- Interfaces with the control layer through defined protocols
Hardware strengthens continuity and trust but never bypasses backend authorization.
Redundancy & Failure Handling
The system is designed to degrade gracefully.
If a provider fails, the control layer:
- Preserves user identity and entitlements
- Re-routes service where possible
- Fails closed where required by regulation
This ensures continuity without exposing users to infrastructure complexity.
User Flow (Conceptual)
- User installs the app or activates a device.
- Onyx resolves identity and service eligibility.
- Connectivity activates through available partner networks.
- Payments clear via card or stablecoin rails.
- Service persists across locations, networks, and devices.
Users never manage providers manually.
Ownership Boundaries
Onyx owns:
- Product logic
- User experience
- State coordination
- Partner abstraction
Partners own:
- Regulatory compliance
- Network operations
- Financial custody
- Infrastructure uptime
This separation is deliberate. It allows Onyx to scale without assuming regulatory risk it does not need to own.
Security Posture (Structural)
Security is enforced through architecture, not claims:
- No direct client access to partner systems
- No long-lived credentials on devices
- Backend verification for all payments and entitlements
- Least-privilege access across services
A detailed treatment follows in the Security & Privacy section.
Why This Architecture Matters
Because Onyx coordinates rather than replaces infrastructure, the platform can expand across regions, partners, and devices without fracturing the user experience.
This is how Onyx delivers continuity at scale.
What This Section Deliberately Avoids
This overview does not disclose:
- Provider identities
- Vendor configurations
- Endpoints or schemas
- Operational tooling
Those details live in internal engineering documentation and are intentionally excluded here.
2.2 Service Activation & Connectivity Lifecycle
Onyx treats mobile connectivity as a managed service lifecycle, not a discrete provisioning event. Users activate mobile service through the Onyx app or supported devices, while the platform coordinates underlying network access through partner carriers.
The user experience remains consistent regardless of how or where the underlying connectivity is delivered.
Activation Model
When a user activates service, Onyx resolves eligibility, plan parameters, and geographic availability through its control layer. The platform then orchestrates activation with an appropriate network partner based on location and service requirements.
From the user’s perspective, service activates once. They do not select carriers, manage profiles, or troubleshoot provisioning states.
Lifecycle Management
Each mobile plan progresses through a defined lifecycle managed by Onyx:
- Activation
- Active service
- Usage tracking
- Expiration or renewal
- Suspension or reactivation (when applicable)
Onyx maintains the authoritative view of service state. Network partners report status changes, but do not dictate user-facing behavior.
This separation allows the platform to adapt service delivery without requiring user intervention.
Network-Agnostic Design
Onyx does not bind users to a single carrier or network implementation.
The system abstracts:
- Network access methods
- Geographic coverage differences
- Provider-specific provisioning constraints
This enables Onyx to introduce redundancy, shift providers, or expand coverage without altering the user experience or requiring reactivation flows.
Known Limitations (Current State)
Early-stage mobile services operate within the constraints of partner carrier capabilities.
These may include:
- Limited reprovisioning after device resets
- Provider-defined plan boundaries
- Geographic restrictions in certain regions
Onyx designs around these constraints at the platform level and evolves the architecture as deeper carrier integrations become available.
Evolution with Deeper Integration
As Onyx expands partnerships with full-service telecom providers, the activation model evolves from profile-based provisioning toward fully integrated mobile service delivery.
This enables:
- Persistent numbering and voice services
- Improved handoff between networks
- Reduced dependency on device-level resets
- Greater control over service continuity
These capabilities layer onto the existing architecture without rewriting core systems.
What Onyx Does Not Do
Onyx does not expose carrier selection, provisioning mechanics, or network configuration to end users. These details remain internal to the platform.
The product is designed to eliminate activation complexity, not repackage it.
Continuity for End Users
By managing connectivity as a lifecycle rather than a transaction, Onyx delivers mobile service that remains reliable across locations, devices, and usage patterns.
This approach supports the most demanding travel scenarios while remaining equally effective for users operating entirely within a single country.
2.3 Security & Privacy Posture
Onyx treats security and privacy as engineering constraints, not brand promises. The system minimizes data exposure by design and relies on clear boundaries between Onyx, its partners, and the underlying networks that deliver service.
The goal is simple: reduce risk for users moving through modern digital systems without forcing them to change how they live or work.
Threat Model and Assumptions
Onyx designs for realistic threats faced by globally mobile users:
- Untrusted or degraded networks
- Cross-border authentication failures
- Payment disruptions and fraud
- Account compromise from reused credentials
- Data overcollection by default systems
The platform does not assume hostile state-level adversaries or attempt to provide absolute anonymity. It prioritizes resilience, continuity, and sensible risk reduction.
Data Minimization
Onyx collects and stores only what is required to operate mobile service and payments.
This includes:
- Core identity attributes needed for service continuity
- Entitlement and usage state
- Payment confirmation metadata required for reconciliation
Sensitive financial data, carrier credentials, and compliance-heavy information remain with licensed partners wherever possible.
Platform Trust Boundaries
Onyx separates responsibilities across the stack:
- The Onyx platform coordinates identity, entitlements, and service state
- Telecom partners deliver network access
- Payment issuers and processors handle regulated financial operations
This separation reduces blast radius and limits the amount of sensitive data any single system must hold.
Optional Network Protection
Onyx supports optional lightweight network protection for users who want additional safeguards on untrusted connections.
This layer:
- Reduces exposure on public or transient networks
- Operates independently of core service activation
- Does not intercept or alter application-level behavior
It exists as a practical tool, not a universal requirement, and remains opt-in by design.
Device-Level Security Philosophy
For Onyx-controlled hardware, security starts at the device boundary.
The platform emphasizes:
- Secure pairing between device and service
- Minimal background processes
- Clear separation between system services and user applications
Hardware exists to strengthen service reliability and trust, not to introduce proprietary lock-in.
Operational Security
Onyx enforces standard operational safeguards across all environments:
- Least-privilege access controls
- Encrypted secrets management
- Audited administrative actions
- Versioned APIs with explicit contracts
Security decisions prioritize clarity and maintainability over obscurity.
Privacy as a System Outcome
Privacy in Onyx emerges from:
- Fewer intermediaries
- Reduced data duplication
- Explicit ownership boundaries
- Optional protections where risk is highest
It is not marketed as invisibility. It is delivered as reduced exposure during everyday use.
2.4 Network Protection Scope (dVPN)
Onyx includes an optional network protection layer designed to reduce exposure on untrusted networks without changing how users normally use their devices. This layer exists to support continuity and safety in real-world conditions, not to reposition Onyx as a privacy tool or anonymization service.
Purpose and Role
The network protection layer provides an additional safeguard when users connect through public, transient, or degraded networks—such as airports, hotels, cafés, or unfamiliar local infrastructure. It focuses on protecting data in transit and reducing passive network-level risks during moments when connectivity matters most.
This capability integrates into the Onyx stack as a supporting system, not a core dependency. Users can enable it when needed and disable it without affecting their underlying mobile service or payments.
Operational Scope
The protection layer operates at the network level, securing traffic between the device and the wider internet while active. It does not alter application logic, intercept content, or require changes to how apps authenticate or communicate. The system avoids deep packet inspection and does not attempt to reshape user behavior.
Activation is lightweight and intentional. The platform treats it as a tool users deploy situationally, not a permanent always-on requirement.
Data Handling Principles
Onyx designs this layer with strict data minimization. It does not retain browsing histories, application payloads, or session content beyond what is required to operate the service in real time. Logs focus on service health and operational integrity rather than user activity.
Relationship to the Core Platform
Network protection remains separate from identity, entitlements, payments, and connectivity provisioning. This separation ensures that optional safeguards do not become a single point of failure or an implicit dependency for core service availability.
The Case for Decentralized VPNs
Mobile connectivity frequently operates over networks that users neither own nor manage. In these environments, reducing unnecessary exposure matters. The decentralized VPN layer exists to provide an additional, optional safeguard when operating on unfamiliar or shared infrastructure.
Unlike traditional VPNs that route traffic through centralized servers operated by a single provider, decentralized VPNs distribute traffic across a network of independent nodes. This reduces single points of failure, limits concentration of trust, and avoids reliance on any one operator’s infrastructure or logging practices.