Windows workspaces.
Open compute.

Project in one sentence

SDCN is a peer-to-peer cloud computing network in which Solana coordinates economic relationships and settlement while individual users and professional operators supply compute resources. Consumers receive an interactive Windows cloud desktop and can call CPU or GPU capacity from the wider network on demand.

Essential product boundaries

• The network is distributed, but a general-purpose Windows instance should be anchored to one primary Provider at any moment so its kernel, memory, and disk state remain coherent.
• Task-level workloads can be parallelized across nodes; arbitrary Windows instruction execution cannot be transparently split across the internet.
• Solana is the trusted economic state layer, not the system for high-frequency heartbeats, scheduling, or per-second resource metering.
• The incubation stage should prove a verifiable economic loop before pursuing full decentralization.

Decision table

1.1 Vision

Organize globally distributed, idle, and heterogeneous personal computers, workstations, servers, and GPU nodes into an open compute network. Node owners earn tokens by contributing resources; consumers stake and pay for Windows workspaces and elastic remote compute.

1.2 The product is not Windows on Solana

Windows does not run on Solana validators. Solana is the economic consensus layer; the P2P network is the real-time control layer; KVM, virtualization, and future trusted execution environments form the execution layer; Windows is the user workspace layer.

1.3 Three primary product forms

2.1 A Consumer and Provider may be the same party

A user with local hardware can sell idle resources to earn tokens and later buy network capacity when local resources are insufficient. This two-way participation model creates a natural supply-and-demand loop.

Role map

The recommended architecture separates economic consensus, real-time control, execution, and end-user experience. Each layer has a distinct trust and latency profile.

3.1 Why the entire system cannot be on-chain

Node heartbeats, millisecond scheduling, and per-second CPU or GPU metering are high-frequency real-time data. Writing each event to Solana would increase cost, latency, and complexity, and on-chain consensus still cannot prove how much work an external CPU actually performed. Usage should be aggregated and signed off-chain; only lease state and final settlement belong on-chain.

4.1 Anchor VM

Each Windows Workspace is assigned to one primary Provider. That Provider supplies virtual CPU, RAM, the system disk, the user's persistent disk, and interactive streaming, preserving operating-system and application state coherently.

4.2 Remote Compute Fabric

Windows includes a Compute Agent. When an application or SDK starts a divisible job, the Agent submits the job description, input data, and resource requirements to the P2P Scheduler. One or more Providers execute the job independently and return results.

Responsibility boundary

5.1 Provider Resource Manifest

When a Provider Agent starts, it creates and signs a Resource Manifest. The manifest should describe both raw capacity and the policy conditions under which that capacity can be sold.

5.2 Compute resources are not fully homogeneous goods

CPU and GPU models, memory bandwidth, storage performance, and network quality vary widely. The protocol should standardize metering dimensions without forcing all hardware into one fixed price. Providers quote offers and market supply and demand determine the clearing price.

6.1 Stake determines eligibility and limits, not free compute

6.2 Network Resource Unit

The protocol can define an internal billing abstraction called the Network Resource Unit, or NRU. It records usage across different resource classes, while final prices remain market-driven. NRU must not be confused with Solana Compute Units.

7.1 On-chain state objects

7.2 Recommended state machine

A simple Lease state machine is sufficient: Requested -> Matched -> Active -> Closing -> Settled. Exception paths include Expired, ProviderFault, ConsumerFault, and Disputed. High-frequency measurements stay off-chain; the chain receives only usage summaries and monetary amounts.

7.3 Responsibility boundary

• Must be on-chain: stake changes, Lease creation and closure, escrow balance, settlement outcome, slashing, and material reputation events.
• Should stay off-chain: per-second CPU utilization, node heartbeats, live network latency, Scheduler candidate lists, and complete logs.

8.1 Core control-plane modules

8.2 Scheduling does not need to be fully decentralized at first

During incubation, one official Scheduler can coordinate supply and demand while critical lease relationships and funds remain controlled by the Solana Program. The system can later evolve toward multiple Schedulers, a P2P DHT, or open bidding. This sharply reduces early implementation risk.

Starting a virtual machine is not the hardest problem. The difficult question is how to show that a Provider delivered the claimed resources and that the Consumer actually used them. Trust should improve in stages.

9.1 Usage Receipt logic

Every one to five minutes, the system creates a Usage Epoch. The Host Meter measures resource consumption and the Windows Guest Agent observes key metrics independently. Both sides sign the same usageHash and amount. Matching records can settle automatically; mismatches enter the dispute process.

Illustrative receipt

10.1 The role of Provider Stake

Provider Stake is service-quality collateral. The amount of capacity a Provider may sell, the maximum value of Leases it may accept, and the speed at which its reputation recovers can all be linked to stake.

Reputation and enforcement events

11.1 Protect the Provider

• Run user code only inside strongly isolated KVM, QEMU, MicroVM, or equivalent environments; never grant direct Host access.
• Restrict device passthrough, system calls, disk mounts, network privileges, and management interfaces.
• Let Providers publish Policy Profiles covering public inbound traffic, SMTP, bulk scanning, GPU passthrough, and other sensitive capabilities.
• Detect anomalous traffic, abusive resource behavior, and malicious workloads at the platform layer.

11.2 Protect the Consumer

• Encrypt persistent user volumes by default and destroy keys when an ephemeral VM is closed.
• Introduce confidential-computing capabilities such as AMD SEV-SNP or Intel TDX for high-security nodes in later phases.
• Use the Windows Guest Agent to verify the boot image, Agent version, and metering-module integrity.
• Allow sensitive jobs to select only Providers with hardware attestation.

12.1 Two instance modes

12.2 User flow

1. 01Sign in with a wallet
2. 02Check the Consumer Stake tier
3. 03Choose Windows performance and budget
4. 04Lock funds in Escrow
5. 05Match with a Provider through the Scheduler
6. 06Start the VM on the Provider
7. 07Return encrypted session credentials
8. 08Connect through RDP or WebRTC
9. 09Produce periodic Usage Receipts
10. 10Close and settle the Lease

12.3 Failure and migration

The incubation release does not need seamless live migration. The first version can stop billing immediately when a Provider goes offline and let the Consumer restart the Workspace on another Provider. With an encrypted persistent Volume, the Workspace resumes from the latest synchronized state. Snapshot replication, incremental synchronization, and live migration can follow later.

13.1 First workloads to support

13.2 Workloads that are not an early priority

Workloads that require strongly shared memory, hard real-time synchronization, or extremely low-latency interconnects are poor fits for the first phase. General Windows applications also cannot transparently migrate arbitrary threads to remote nodes.

14.1 Three sources of token demand

14.2 Illustrative fee allocation

14.3 Price formation

The protocol should not impose one hardware price. Providers quote by Resource Profile, and the Scheduler matches offers against the Consumer's maximum budget, region, latency, reputation, and performance needs. A protocol reference price or fixed packages may reduce user-facing volatility, with the protocol assuming part of the matching risk.

15.1 Provider joins the network

1. 01Create wallet
2. 02Install Provider Agent
3. 03Run hardware checks and benchmark
4. 04Select sellable resources
5. 05Post Provider Stake
6. 06Register ProviderAccount
7. 07Publish heartbeat
8. 08Accept Lease
9. 09Run VM or task
10. 10Receive settlement

15.2 Consumer starts Windows

1. 01Wallet sign-in
2. 02Meet target stake tier
3. 03Fund or authorize Usage Budget
4. 04Create Lease Request
5. 05Scheduler match
6. 06Lock Escrow
7. 07Provider starts Windows
8. 08Consumer connects
9. 09Meter usage
10. 10Settle periodically
11. 11Shut down or renew

15.3 Windows calls network compute

1. 01Windows application or SDK submits a Remote Job
2. 02Compute Agent describes requirements
3. 03Scheduler selects one or more Providers
4. 04Encrypt and transfer input data
5. 05Execute
6. 06Verify results
7. 07Return results to Windows
8. 08Settle usage

16.1 Minimum M1 technical scope

• Solana Program: Provider Registry, Stake, Lease, Escrow, and Settlement.
• Provider Agent: hardware reporting, KVM VM creation, metering, signatures, and session management.
• Windows Image: preinstalled Guest Agent, dual-signed Usage Receipts, and remote access.
• Scheduler: centralized in the first stage, responsible for node selection and Lease sessions.
• Web Console: wallet sign-in, plan selection, balance and usage, and Workspace start or stop.

Evolution path

18.1 Supply side

• Online Provider count and sellable vCPU, RAM, and GPU capacity.
• Seven-day Provider uptime, order acceptance rate, and average VM startup time.
• Actual resource utilization and Provider return per hardware unit.

18.2 Demand side

• Workspace creation success rate, average session length, repeat purchase rate, and renewal rate.
• Average Usage Spend per user and the distribution of Consumer Stake tiers.
• Remote-job adoption: the share of Windows users who actually use the Compute Fabric.

18.3 Protocol side

• Usage Receipt agreement rate, Dispute rate, refund rate, and slashing frequency.
• P50 and P95 time from clicking Start to a usable desktop.
• On-chain settlement cost and off-chain metering cost per settlement.

SDCN is a decentralized cloud computing protocol in which Solana manages economic relationships and an open Provider network supplies real compute resources. Its first product is Windows Workspace. Its long-term capability is a distributed Compute Fabric callable by Windows, SDKs, and third-party applications.

The definition preserves four core values

• Users can contribute idle capacity from their own nodes and earn revenue.
• Users without nodes can pay for a complete Windows virtual system.
• Consumer Stake determines performance tiers and network entitlements, while actual consumption is settled with usage payments.
• Solana provides trusted economic state for identity, staking, leases, escrow, usage settlement, and penalties.

The Anchor VM plus Remote Compute Fabric design avoids relying on impractical instruction-level Windows execution across arbitrary internet nodes. It preserves the decentralized compute-market thesis and leaves room for GPU, AI, rendering, transcoding, compilation, confidential computing, and multiple Schedulers.

• Final token supply, release schedule, governance weight, or exchange-listing mechanics.
• A commercial Windows licensing plan.
• A commitment to decentralized scheduling, cross-Provider live migration, or fully trustless metering.
• A final virtualization stack or P2P protocol implementation.
• Transparent instruction-level parallelism for general Windows applications.
• Treating incubation-stage parameters as production security or economic parameters.