# Power and Network: trust boundaries and provider contract

Status: implemented optional hosted-model connections, tested provider foundations and a future marketplace architecture. `packages/power/` implements protected connection profiles, exact data disclosure and native approval, bounded streamed requests, persistent accounting, cancellation and cleanup boundaries. The desktop exposes connection/request/history controls. Thirty-three focused connection/protocol regressions, five actual-model loopback HTTP endpoint checks and four native UI groups pass; see [current Power scope](/reference/docs/power-connections-v2.md). The separate synthetic provider requires explicit test opt-in. Runpod Pod lifecycle/recovery protocol support is prepared but gated; live/serverless deployment, provider-enforced total costs and settlement remain incomplete. Nosana remains a researched integration boundary. **No funded provider account, paid rental, billing transaction, remote attestation or operational marketplace is claimed as tested.** Updated 2026-10-15.

## Four distinct processing modes

| Mode | Processing location | Authorization |
| --- | --- | --- |
| Local | Current device and installed model | Model/file setup; no paid provider |
| My Computer | A paired device the user owns | Mutual authentication, named device, scoped permissions, revocation |
| Remote Model | Hosted inference endpoint | Explicit data-sharing approval, provider identity, model, maximum charge |
| Rent GPU | Provisioned remote hardware | Explicit workload/image, hardware, runtime, data, storage, budget, release policy |

A rented GPU is capacity, not a new capability added to a hosted model. The selected model and execution environment determine behavior. The local app must remain functional when every external provider is unavailable.

## Current provider research

| Provider | Documented integration surface | Adapter boundary / unresolved work |
| --- | --- | --- |
| [Runpod Pods](https://docs.runpod.io/pods/overview) | GPU/CPU provisioning, templates, storage, networking, management APIs | Explicit instance lifecycle, disk charges, deletion confirmation, orphan recovery. Accounts and current price quotes required before paid tests. |
| [Runpod Serverless](https://docs.runpod.io/serverless/overview) | Managed endpoint execution | Different adapter from a GPU lease: request IDs, queue state, limits, cancellation, usage reconciliation. |
| [Nosana](https://learn.nosana.com/) | Deployment REST API and TypeScript SDK; container job definitions; credit-based deployment path; separate advanced protocol/Solana layer | Keep service API separate from settlement. Validate job/image restrictions, status transitions, cancel semantics, retention, and billing in an owner-authorized account. |
| [Vast.ai](https://docs.vast.ai/) | GPU marketplace documentation | Additional provider candidate. No compatibility, pricing, trust level, or integration success inferred. |
| Hosted model APIs | Provider-specific or compatible chat endpoints | An OpenAI-compatible payload does not imply identical billing, privacy, tokenization, cancellation, or retention. Each provider needs its own verified profile. |

Prices are intentionally absent: no account-specific live quote was obtained. No infrastructure was provisioned. No paid test is authorized by the existence of an adapter.

## Required provider interface

Use typed, versioned requests and responses. Every provider instance must expose its mode and an explicit `mock`, `sandbox`, or `live` environment. Mock jobs must carry that label through storage, logs, and UI.

1. `discoverCapabilities`: models or hardware, regions, image/runtime restrictions, maximum duration, data-retention references, and supported cancellation semantics.
2. `estimate`: short-lived quote with currency, upper-bound assumptions, compute, storage, egress, minimum charges, and expiration. Never present a point estimate as a hard cap.
3. `authorize`: backend-created consent record bound to user, provider, environment, payload digest, scope, quote version, maximum charge, and expiration. The model cannot create this record.
4. `provision` / `submit`: idempotency key, checked authorization, durable job ID, reserved budget, bounded duration, resource metadata.
5. `observe`: state, usage, logs after redaction, last heartbeat, provider request ID, retry hints.
6. `cancel`: authenticated cancellation, idempotent retries, recorded acknowledgment; distinguish requested from confirmed cancellation.
7. `release`: delete or stop all billable resources according to explicit retention settings. Verify provider state; a disconnected client is not cleanup.
8. `reconcile`: final usage against the reservation, signed or authenticated provider receipts, discrepancy state, and refund/dispute path.

State machine: `draft → quoted → approved → reserved → provisioning → running → cancelling/completing → releasing → reconciled`. Failures transition to `cleanup_required` when resources might remain billable. Worker restarts must recover incomplete cleanup. A provider timeout must never trigger a duplicate chargeable submission without the same idempotency key.

## Spending and secret protection

Reserve the maximum authorized amount atomically before submission. Concurrent jobs share one ledger, not independent UI counters. Reject stale quotes, changed payloads, expired consent, unsupported currencies, insufficient reservation, invalid amounts, and user/model attempts to increase the cap. Meter conservatively and stop before the cap using an allowance for provider reporting delays and unavoidable minimum charges. Providers that cannot enforce a defensible upper bound must not be offered as hard-capped service.

Provider credentials belong in platform-protected local storage or a server-side secret store. Do not serialize them into chat history, exports, URLs, logs, front-end bundles, or repository examples. Credentials grant no spending authority without a valid consent record. Log only identifiers, scopes, redacted errors, and accounting evidence.

## Network isolation and attestation

Assume a submitted image, binary, model file, dataset, and tool output can be malicious. Never run customer jobs directly in the provider's personal desktop session. Use a separately administered worker, hardened virtualization, read-only base images, ephemeral storage, bounded CPU/memory/disk/network quotas, restricted egress, signed image allowlists, and a revocable worker identity. Container isolation alone is not a sufficient default for arbitrary hostile workloads.

[Firecracker](https://firecracker-microvm.github.io/) documents KVM microVM isolation, a minimal device model, rate limits, and a jailer. It is useful evidence for CPU sandbox design, **not proof of GPU passthrough support or safe GPU multi-tenancy**. GPU driver/device isolation, DMA/IOMMU behavior, host compromise, and resource leakage need a separate hardware-specific review. A local Windows folder boundary is not a marketplace sandbox.

[NVIDIA attestation documentation](https://docs.nvidia.com/attestation/) is a research entry point for supported hardware and software attestation flows. Attestation must validate a fresh nonce, certificate chain, revocation, measured configuration, firmware policy, and workload/session binding. Do not invent attestation for consumer GPUs or treat an attestation response as proof that model output is correct. The exact supported GPU/CPU combination remains an integration gate.

## Pairing boundary

The implemented [private pairing protocol](/reference/docs/pairing.md) binds a fresh one-time challenge to both device identities, uses pinned TLS and signed scoped requests, shows identity and permissions, protects keys, and permits revocation at either endpoint. Replays, expired codes, unknown identities, changed certificates and revoked devices fail closed. Phone tasks need saved-agent grants and a fresh desktop approval. Reachability is not identity. Hostile LAN tests and actual Android/native transport results are recorded separately from independent penetration review. HOLD never opens an unauthenticated public model endpoint.

## Settlement is replaceable

Keep `PaymentAuthorization`, `UsageLedger`, `SettlementProvider`, and `ProviderPayout` separate from inference and scheduling. Traditional payments and a future optional USDC/Solana settlement adapter can consume the same finalized ledger. Do not issue a token, require a wallet for local chat, create financial guarantees, or treat simulated balances as earnings. Legal, tax, sanctions, dispute, and payment-provider requirements require owner-reviewed launch decisions.

## Required verification before availability changes

- Mock contracts: quote expiration, invalid budgets, duplicate submission, concurrent reservations, cancellation races, retries, orphan cleanup, failed receipts, and redacted errors.
- Authorized provider sandbox/live tests: actual request format, credential scope, quote accuracy, upper-bound enforcement, remote cancellation acknowledgment, resource deletion, and final invoice reconciliation.
- Adversarial worker tests: malicious filesystem access, escape attempts, network scanning, secret extraction, quota exhaustion, persistence, untrusted images, and stale/replayed attestation.
- Pairing tests: mutual identity, wrong/expired challenge, replay, revocation, reconnect, packet capture, and hostile LAN clients.
- UX: provider, destination, exact shared data, model/hardware, estimate, cap, current usage, cancellation state, and cleanup failure must remain visible.

Owner-hosted model connections are available through explicit review. Funded provisioning and public Network operations remain unavailable until their own engineering, provider-enforcement and owner-authorization gates pass. Any local mock adapter is a development fixture only, never a real provider result or advertised earning.