2. Protocol Architecture

2.1 Nodes

A Node is the atomic unit of physical infrastructure in the Synaptika network. It represents a discrete compute resource -- a server, a rack, or a partition of a data center -- that has been registered on the protocol via the Synaptika sideloading software.

The sideloading software serves as the bridge between a node operator’s hardware and the Synaptika network. Upon registration, the software publishes a capability manifest describing the node’s hardware profile, including but not limited to:

• Accelerator type and count (e.g., GPU model, VRAM)
• Available memory and storage
• Network bandwidth and latency characteristics
• Geographic location

Nodes do not serve inference requests directly to end consumers. Instead, nodes commit capacity to one or more Pools, which handle routing, load balancing, and quality-of-service enforcement.

Capacity Commitment Model: A node may participate in multiple pools simultaneously, but capacity committed to a given pool is considered locked for that pool’s use. This prevents double-allocation of resources. For example, a node with 48GB of VRAM could commit 24GB to Pool A and 24GB to Pool B, but the committed slices are mutually exclusive. Uncommitted capacity remains available for new pool commitments.

2.2 Pools

A Pool is the protocol’s coordination and abstraction layer. Pools aggregate capacity from multiple nodes into a single logical unit with consistent properties, enabling the protocol to offer reliability guarantees that no individual node could provide alone.

Each pool is defined by the following attributes:

• Model: The inference model deployed across all participating nodes. Pools enforce model homogeneity -- every node in a pool runs the same model with the same configuration, ensuring deterministic behavior for consumers regardless of which underlying node serves a given request.
• Capacity: The total aggregated compute available, derived from the sum of committed node resources within the pool.
• Region: The geographic scope of the pool. Region enforcement may be strict (all nodes must reside within a defined boundary) or relaxed (nodes are geographically distributed). Region enforcement is a pool-level configuration decision.
• Price Per Unit: The cost paid to node providers for inference capacity within the pool, expressed in a standardized unit. This is set at the pool level and applies uniformly to all VPIs minted against the pool.

Pool as Gateway: The pool serves as the entry point for all inference traffic destined for its constituent nodes. Consumers and VPI holders interact exclusively with the pool interface -- the pool handles request routing, load distribution, and failover across its node set. Individual nodes are not directly addressable by consumers.

Pool Governance: In the initial phase of the network, pools will be created and managed by Synaptika to ensure baseline quality and reliability standards. As the protocol matures, pool creation will be opened to third-party Pool Curators -- entities or individuals who create, configure, and manage pools. Pool curators control the operational parameters of their pool (model selection, region policy, pricing, node admission criteria) and bear responsibility for maintaining the pool’s service quality.

2.3 Virtual Private Instances (VPIs)

A Virtual Private Instance (VPI) is a tokenized slice of pool capacity. It is the consumer-facing primitive of the Synaptika protocol -- the unit through which end users, applications, and investors interact with the network’s inference infrastructure.

Key properties of a VPI:

• Bound to a Pool, not a Node: A VPI represents an allocation of capacity from a specific pool. It is not tied to any individual node. If a node within the pool fails, the pool redistributes the workload across remaining nodes. The VPI holder experiences no change in their interface.
• Tokenized and Transferable: VPIs are represented on-chain as tokens, enabling ownership transfer, leasing, and secondary market trading.
• Defined Capacity: Each VPI specifies a guaranteed allocation of inference throughput from the pool, denominated in standardized units.

VPI Lifecycle:

1. Minting: A VPI is created by allocating a slice of available pool capacity. Minting consumes capacity from the pool -- once issued, that capacity is reserved for the VPI holder.
2. Active Use (Inference): The VPI holder routes inference requests through their VPI, which the pool fulfills using its node infrastructure.
3. Transfer: The VPI may be sold, leased, or otherwise transferred to another party. The capacity allocation moves with the token.
4. Release: The VPI is released back to the pool, freeing the underlying capacity for reallocation.

2.4 Instance Owners

An Instance Owner is any entity that holds one or more VPIs. Instance owners may be:

• End consumers using VPIs for direct inference access in their applications.
• Resellers or gateways that aggregate VPIs and offer downstream inference services.
• Financial participants who hold VPIs as yield-generating assets, leasing them to active consumers.

The protocol is agnostic to the owner’s intent -- it enforces the same capacity guarantees and interface regardless of whether the VPI is being used for inference, held as an investment, or offered for lease.

2.5 Validators

Validators are responsible for verifying the integrity of protocol state transitions: VPI minting, transfers, releases, node registrations, and pool operations. The validator set ensures that capacity commitments are honored, tokens are correctly issued, and economic rules are enforced.

The validator role encompasses consensus participation, state verification, and coordination with service monitors to maintain network integrity. Validator set composition and staking requirements will be finalized through testnet experimentation.

2.5 Service Monitors

Service monitors are protocol-level agents responsible for verifying that nodes and pools are meeting their stated service commitments. Monitors perform:

• Liveness checks: Periodic probes to verify node and pool availability.
• Performance audits: Benchmarking inference latency, throughput, and model correctness against the pool’s stated parameters.
• SLA enforcement: Triggering penalties (slashing, reputation reduction) when nodes or pools fall below committed service levels.

Service monitoring is critical to the protocol’s credibility -- VPI holders must trust that their capacity allocations correspond to real, performant infrastructure. The monitoring layer provides this assurance through continuous, automated verification.