Development Update — June 27, 2026

Snapshot from June 27, 2026.

Sakviti's June work pushed the project from "what services should exist" toward "how services are uploaded, funded, staffed, inspected, and opened from Nexus." The largest changes are not one feature toggle. They are the runtime pieces needed for stateful Hydra services to behave like durable network applications instead of local demos.

Stateful Services Take Shape

Hydra service registration now carries more of the information an operator or user actually needs. Stateful services can declare storage requirements, service tiers, executor and StorageHost needs, degraded-mode policy, funding posture, and binary-readiness state. Nexus and the App Store can read those states as deployment information: registered, waiting for committee, waiting for binary, awaiting executors, or live.

The Register Service flow also gained an explicit publication pipeline. The browser path now separates history sync, upload peer selection, upload request construction, settlement observation, registration, visibility confirmation, committee wait, binary seeding, and executor readiness. That detail matters because a failed launch is no longer a single opaque "registration failed" moment; it can point to the upload peer, the settlement window, service discovery, staffing, or binary distribution.

This remains on the production-style P2P/WebSocket path. The public browser and operator flow is not supposed to depend on REST shortcuts for service registration or runtime state.

Wardgrove Becomes A Real Test Service

Wardgrove is now encoded as a stateful Sakviti service with its own manifest, service metadata, game UI, card assets, and V1 game loops. The service describes itself as a games-category, stateful UI service and includes persistent player profiles, 4x4 plots, starter cards, farming resources, fusion, NPC scout and forage raids, replay-visible advice, and activity records.

The point is larger than one game. Wardgrove is being used as the reference pressure test for Nexus-launched stateful services: a UI that cannot refresh by rerunning consensus tasks, a game state that needs exact reads and bounded prefix subscriptions, and a replay/retention model that cannot leak hidden rows or private player evidence. That makes it a useful forcing function for proof-verified state reads, service-owned storage, shard routing, wallet permissions, and bridge diagnostics.

There is still an important caveat: Wardgrove is not being presented as a finished public game. The repository now has a playable local MVP surface and broad automated coverage, but the 50-node Nexus deployment path has been treated as a blocker, not as solved. The remaining release work is about repeatable canary preservation, live-service validation, operations sign-off, and public playthrough readiness.

Consensus And Runtime Hardening

A large part of the range went into making the network behave better under sparse fanout, large local networks, and branch-sensitive union-block history. The consensus work tightened parent-union validation, anchored branch-sensitive transactions to their validation union view, made fork-choice use branch-derived producer state, improved selected union publication and repair, and added checks that inconsistent union-block diffs are rejected before reconstruction.

Those changes are not cosmetic. They reduce cases where a node can locally accept a block that peers reject, where late producer announcements are penalized on a sibling branch, or where sparse peers keep extending different union-block branches without enough evidence to reconcile. The latest consensus slice also requires normal blocks and live union blocks to match dynamic puzzle targets and ranks union candidates by validated target and solved work.

The runtime side received its own cleanup: bounded Hydra memory retention, capped pending transaction connection state, bounded outbound I/O growth, tighter resource-guard sampling, and large-run network manager safeguards. The performance harness now records wallet ceilings, generation backpressure, phase timings, selected-union counters, and invalid measurement states so local 50-node tests are harder to misread as throughput evidence when they are really readiness or setup failures.

What This Means

The practical direction is clearer now: Sakviti services are becoming uploaded, funded, stateful network artifacts that can be inspected and launched through Nexus, while the core network is being hardened against the kinds of convergence, memory, and measurement failures that only appear under larger runs.

The work is still deliberately conservative. The update does not claim that public Wardgrove deployment or high-scale throughput targets are complete. It does show that the project has moved from broad roadmap language into concrete service lifecycle machinery, a real stateful game exercising that machinery, and a stricter set of tests and diagnostics for the network underneath it.