ElastOS Weekly Shipping Report — Week of July 4 – July 10, 2026

[SashaMIT]

Elacity Labs — Weekly Team Update for the World Computer Initiative (WCI)

July 4 – July 10, 2026

The mandate cycle — an agent gets a mandate, not your keys, and the money moves under a provable cap. In the six days since PR #12 consolidated the runtime onto flint-0.5, Runtime raced a single arc end-to-end on the new tree: portable, off-box-verifiable mandate receipts (Sprints 1–4) → the act leg (POST /api/standing-grants/dispatch, closing G-M1/G-M2) → two side-effecting affordances (runtime.notify, runtime.state_put) → the Mandates app in the shell (grant, watch, kill-switch revoke) → durable mandates that survive restart (closing G-M5) → the money rail — a spend-capped runtime.pay affordance backed by a durable money cap, a two-generals-honest payment ledger, and the operator-facing Money panel → the DRM marketplace wedge (DrmMarketplaceProvider + confirmation-aware settlement + on-chain price gate + confirmation scheduler) → the marketplace face where an agent shops under its mandate through runtime.market_quote and runtime.negotiate on an ERC-20 checkout rail → deadlines everywhere so no runtime thread parks on the chain or a hung open/view → SPEC-mandate-v1 pinned by a conformance ratchet → audit-log concurrency safety (group-commit, single-opener flock) → and, closing the cycle, a G8 policy flip making fail-closed ordinary use-records an operator opt-in (S53). Every sprint carries a council fold or guardian/red-team fold commit — the adversarial review pass is now the shipping cadence. The whole arc then merged as PR #13 into flint-0.5 (96 commits), consolidating the feature branch into the mainline tree. In parallel — implemented locally, pre-publication — the runtime grew a multi-shell environment: Home now runs as GUI or CLI over the same Runtime facts, a new ElastOS Shell Protocol (ESP) gives every shell one contract instead of its own private view, and a first elastos.component-bus/v1 (WebAssembly Component Model) replaces broad WASI-style authority with explicit, Runtime-controlled capability imports — no ambient filesystem/network/token back doors. Alongside, Hyper (Android) shipped a mobile battery/carrier-reliability pass plus a live social feed; ElastOS Essentials landed a full mobile-wallet rebuild — new design system, a unified "All Chains" view, a 14-audit code review, and a security pass that cut third-party vulnerabilities ~184→109 and deleted >58k lines of dead attack surface; and ElacityLabs.com landed a real blog engine and used it to announce that Elacity has been accepted into NVIDIA Inception — an outcome of the founder's networking in San Francisco. PC2 stayed quiet post-1.4.0.

Mandate engine end-to-end on flint-0.5 (S1–S53) · portable off-box-verifiable receipts + elastos verify-receipt CLI · spend-capped runtime.pay + durable money cap + two-generals payment ledger + Money panel · DRM marketplace wedge + agent shopping (market_quote / negotiate, ERC-20 + DRM verticals) · deadlines & watchdogs everywhere · SPEC-mandate-v1 pinned by a conformance ratchet · audit-log group-commit + single-opener flock · PR #13 merged into flint-0.5 (96 commits) · multi-shell Home (GUI + CLI) + ElastOS Shell Protocol + component-bus/v1 (no ambient WASI authority) · Hyper-Android battery/carrier hardening + social feed · ElastOS Essentials wallet rebuild + "All Chains" view + security pass (~184→109 vulns, >58k dead lines removed) · ElacityLabs.com blog engine + Elacity accepted into NVIDIA Inception · PC2 quiet post-1.4.0.

---

Key Links This Week

• Previous report — Week of June 26 – July 3, 2026 (#27)
• This cycle's PR (MERGED) — Flint mandate engine — give your agent a mandate, not your keys (+ MKT-1 fix + 0.01% audit) #13 — merged 2026-07-11 (claude/git-proxy-auth-roadmap-c214hu → flint-0.5, 96 commits, +29,593 / −872, 83 files)
• Runtime consolidation PR (base for this one) — Flint 0.5 ElastOS Weekly Shipping Report — Week of Mar 28 – Apr 3, 2026 #9 (open; flint-0.5 → upstream/0.6-dev)
• Top Runtime commits this week — 094b6bba S38 Marketplace face · 9a611fa S39 market_quote · 095c60f S34 Flint↔DRM wedge · 9be2731 S30 payment ledger · f6a7089 S50 runtime.negotiate · d60a76b S33 money-authorization perimeter · 741fc44c S53 G8 policy flip · 133c340 repo-wide rustfmt
• Active Runtime branches (in-window) — flint-0.5 (consolidated mainline; the feature branch merged via PR FEAT: metadata and protection alignment #13 and was deleted)
• Active PC2 branches (in-window) — none (post-1.4.0 quiet cycle; main and feature/elastos-node-manager untouched since 2026-06-26)
• Install (PC2 node) — bash <(curl -fsSL https://raw.githubusercontent.com/Elacity/pc2.net/main/scripts/update.sh)
• Install (Runtime) — curl -fsSL https://elastos.elacitylabs.com/install.sh | bash
• Live surfaces — map.ela.city · portal.ela.city

Table of Contents

1. The Big Picture — The Mandate Cycle
2. Runtime — Mandate Engine Core (Sprints 1–11)
3. Runtime — Mandates in the Shell (Sprints 12–18)
4. Runtime — Durability & Rate-Budget Hardening (Sprints 19–23, closing G-M4/G-M5/G-M7)
5. Runtime — Fail-Closed Mint + Attested Agent State (Sprints 24–26)
6. Runtime — The Money Rail (Sprints 27–31)
7. Runtime — Responsible-Entity Binding + Perimeter Hardening (Sprints 32–33)
8. Runtime — The DRM Marketplace Wedge (Sprints 34–37)
9. Runtime — The Marketplace Face + Agent Shopping (Sprints 38–39, S48–S50)
10. Runtime — Deadlines & Watchdogs (Sprints 40–42)
11. Runtime — Ledger Typing + Live Testnet + Repo-Wide rustfmt (Sprints 43–46)
12. Runtime — Bounded Viewer Sessions + SPEC-mandate-v1 (Sprints 47, 49)
13. Runtime — Audit-Log Concurrency Safety + Fail-Closed Use-Records (Sprints 51–53)
14. Runtime — Multi-Shell, ElastOS Shell Protocol (ESP) & component-bus/v1
15. PC2 — Post-1.4.0 Quiet Cycle
16. Hyper (Android) — Mobile Battery/Carrier Hardening + Social Feed
17. ElacityLabs.com — Blog Engine + NVIDIA Inception Announcement
18. ElastOS Essentials — Wallet Rebuild, Unified Multi-Chain View & Security Hardening
19. Convergence Lens — PC2 ↔ Runtime
20. Looking Ahead
21. Summary Statistics
22. Data-Quality & Off-Repo Notes
23. Off-Repo Context — San Francisco & NVIDIA Inception

---

1. The Big Picture — The Mandate Cycle

Last cycle consolidated three parallel storylines onto flint-0.5 and closed the W2 consent path. This cycle picks up on that base and races a single arc through the runtime, top to bottom, over six days:

• The receipt primitive lands first. Before anything is granted, a portable, off-box-verifiable mandate receipt ships as the standalone "admissible receipt" primitive (4601c9a), then a per-mandate, set-bound version scoped to one capability (178d3f9), then a CLI verifier — elastos verify-receipt, independent, fail-closed (ab7e329). The proof is buildable before the thing being proved.
• The lifecycle wires up. Operator grant → durably-attested revoke → receipt export (7846c9c) → list + one-command demo (028e88a) → the act leg via POST /api/standing-grants/dispatch closing G-M1/G-M2 (43eb867) → a real executor seam so reconciliation is an independent observation, closing G-M6 (6bfdd88).
• The shell makes it visible. The Flint mandate-card dashboard (7b76a7b, 399 insertions, single file) → Mandates opens as a native ElastOS shell app (f95ea43) → LIVE data over the home-gateway (c9c6700) → in-shell kill-switch revoke (7eced9b) → in-shell issue (c5922ff).
• The money moves under a cap. runtime.pay as a spend-capped affordance (S27) → durable money cap that survives restart (S28) → real payment rail, two-generals-honest, over HTTP (S29) → payment ledger custodying every rail attempt with reconcilable indeterminate outcomes (S30) → the Money panel (S31). Every step folds in a council review before moving on.
• The marketplace face closes the loop. DrmMarketplaceProvider + rail_ref receipt (S34) → confirmation-aware settlement (S35) → on-chain price gate (S36) → confirmation scheduler (S37) → the Marketplace face where an agent shops under its mandate and the operator watches (S38) → runtime.market_quote (S39) → a second market vertical, ERC-20 checkout with a market-provider contract (S48) → runtime.negotiate (S50).
• The runtime never parks. Chain-read deadline (S40) → sibling-provider watchdog with bounded reap (S41) → access-path content-sidecar bound (S42). No thread hangs forever on a chain read, a hung open/view, or a sibling provider.
• The spec is pinned. SPEC-mandate-v1 — receipt + signed-intent wire format, pinned by a conformance ratchet (S49). And repo-wide rustfmt (133c340, 1,934 insertions / 669 deletions, mechanical, zero logic delta) makes the CI fmt gate truthful.
• The policy closes fail-closed. G8 policy flip (S53) makes fail-closed ordinary use-records an explicit operator opt-in, with the council fold naming the availability cliff and the best-effort deny-record rationale — then the whole arc merges into flint-0.5 (PR FEAT: metadata and protection alignment #13).

The through-line: an operator can grant an agent a scoped, revocable mandate with an on-chain money cap; the agent can act, spend, buy, quote, and negotiate under it; every action produces a portable receipt that a third party can verify without the runtime being online. The operator never surrenders keys.

2. Runtime — Mandate Engine Core (Sprints 1–11)

The first eleven commits (all on 2026-07-04, ~5 hours of continuous shipping) built the mandate engine end-to-end, with a fold commit after every sprint:

• S1 (4601c9a, +416/−1, 2 files) — portable mandate receipt as the standalone "admissible receipt" primitive.
• S2 (178d3f9) — per-mandate receipt scoped to one capability, set-bound against holder tampering.
• S3 (ab7e329) — elastos verify-receipt CLI: independent, fail-closed verification.
• S4 (7846c9c) — operator mandate lifecycle: grant, durably-attested revoke, receipt export. Guardian + red-team fold (42696bf): durable enforcement, casing desync, honest CLI.
• S4.5 → S5 — list + one-command demo of the full loop (028e88a); Sprint 4 fold (2e94f48): "no LIVE lie after revoke-all, demo cleanup, honest pin labeling".
• S6 (43eb867) — wire the act leg: POST /api/standing-grants/dispatch, closes G-M1/G-M2. Sprint 5 fold (0a3a300): replay guard, agent-key binding, epoch liveness, "honest 'authorized'".
• S7 (6bfdd88) — real executor seam behind dispatch, making reconciliation an independent observation (G-M6).
• S8 (8dd17b6) — the first real affordance: runtime.audit_verify makes "performed" literal.
• S9 (6eeff99) — demo performs a real agent act end-to-end: grant → perform → revoke → deny → prove.
• S10 (1ca0f47) — second real affordance: runtime.content_seen, a state-dependent read.

Combined footprint for S1–S10: ~2,700 insertions, 25 files. This is where the mandate stops being a doc and becomes a runnable primitive with a CLI verifier.

3. Runtime — Mandates in the Shell (Sprints 12–18)

With the primitive in place, the operator surface goes up quickly:

• Sprint 11 (7b76a7b) — Flint mandate-card dashboard: the accountability loop, made visible (single 399-line HTML file). Followed by dashboard fold (8fdc134): "never fabricate a receipt, honest badges".
• Sprint 11.5 (f95ea43) — Mandates opens as a native app in the ElastOS shell.
• Sprint 12 (c9c6700) — Mandates app reads LIVE data over the home-gateway (12 files, +465).
• Sprint 13 (7eced9b) — in-shell revoke — the mandate kill switch. Followed by council fold (4bb1fcb): "wrong-target kill switch race + prove-surface honesty".
• Sprint 15 (c5922ff) — grant from the shell: issue a mandate in the Mandates app.
• Sprint 16 (0884689, +578) — runtime.notify, the first side-effecting affordance.
• Sprint 17 (7927145, +626) — runtime.state_put, second side-effecting affordance, durable agent state.
• Sprint 18 (b31a925) — Agent State panel: the operator watches what agents write.

The Mandates app is now a full accountability loop: grant → watch → revoke → prove, driven from a native shell surface reading live gateway data.

4. Runtime — Durability & Rate-Budget Hardening (Sprints 19–23, closing G-M4/G-M5/G-M7)

Three gaps closed here — the ones a serious operator would ask about first: does the mandate survive a restart, is the agent key really required, and can a runaway mandate flood the runtime?

• Sprint 14 (b9a83ac, +534) — durable mandates: registry + replay guard survive restart, closes G-M5. Council fold (31bd767): power-loss durability + widen-proof reload + "honest claims".
• Sprint 19 (60b6418, +538) — bounded time-windowed replay guard — pays down G-M7.
• S19 consolidation (c29c909) — docs/FLINT_MANDATE_ENGINE.md: "the Flint mandate engine, one reviewable map".
• Sprint 20 (bf80226) — G-M4: agent-key binding by default, surfaced, and weak-key-proof.
• Sprint 21 (4064da0) — per-mandate dispatch rate budget + grant-existence gate (G-M7).
• Sprint 22 (ed5fd9c) — dispatch rate is a first-class mandate property (dispatch_limit per grant). Council fold (d5b23d9): "honest 429, service-layer budget invariant, upper clamp, widen-proof wording".
• Sprint 23 (9acd60a) — bounded grant-registry retention (closes G-M7). Council fold (5237a80): "honest bounds on the retention claim" (doc-only).
• Plus a one-line house-keeping commit on flint-0.5 proper: 037eaf6 — "chore: forgotten Cargo.lock".

5. Runtime — Fail-Closed Mint + Attested Agent State (Sprints 24–26)

• Sprint 24 (8c05818) — fail-closed mandate mint: grant_durable emits CapabilityGrant before issuing. Two folds: guardian (78ede17, doc-only durability-bound + reconciliation-scope wording) and red-team (f2cf61a, F1 memory-log warn + F2 compensating revoke on abort).
• Sprint 25 (3e4395c) — runtime.state_get: the attested-read side of the mandate-scoped agent-state KV. Council fold (c6dcde2): "honest one-bit semantics (F1/F3) + require binding for state_get (F2)".
• Sprint 26 (c8bbbaf) — agent-facing dispatch: an agent acts under its bound mandate — no operator keys required at act time.

6. Runtime — The Money Rail (Sprints 27–31)

Five sprints, ~3,400 insertions combined. The single biggest coherent arc of the cycle:

• Sprint 27 (a598c48) — the spend-capped runtime.pay affordance: an agent spends money under a provable cap. Council fold (47ece5a): "harden the pay affordance's money invariants".
• Sprint 28 (2ade592, +670) — durable money cap + operator provisioning: the money survives a restart. Council fold (654c826): "honest failure edges on the durable money cap".
• Sprint 29 (258c6bc, +699) — the real payment rail: two-generals-honest money over HTTP. Council fold (081cac5): "honest failure surfaces + hardened rail edges".
• Sprint 30 (9be2731, +973) — the payment ledger: every rail attempt custodied, indeterminate outcomes reconcilable. Council fold (f727815): "the ledger joins the money-trusted core, honestly".
• Sprint 31 (565a510, +722) — the Money panel in the Mandates app: budgets, pending payments, reconciliation. Council fold (6658d2a): "narrow the money surface, close the poisoned-reconcile trap, honest pixels".

By S31 an operator can, from a shell surface, see the mandate's budget in the same view they see the audit tally — the money story shares the same custody surface as the intent-proof story.

7. Runtime — Responsible-Entity Binding + Perimeter Hardening (Sprints 32–33)

• Sprint 32 (a7f994c) — responsible-entity binding: the liability DID lands in the grant and the receipt. Council fold (6d5cb62): "responsible-entity honesty (declared, not attested)" — the receipt says whose it is, and honestly says that's a declaration.
• Sprint 33 (d60a76b, +839) — harden the shell money-authorization perimeter (S31 F1). Council fold (11fa980): canonical single-use key + pre-effect re-credit.

8. Runtime — The DRM Marketplace Wedge (Sprints 34–37)

Where mandate money meets DRM content:

• Sprint 34 (095c60f, +995) — DrmMarketplaceProvider + rail_ref receipt: the Flint↔DRM wedge. Council fold (3dfa14f): money-invariant classifier + broadcast-accepted honesty.
• Sprint 35 (a297bdb, +602) — confirmation-aware DRM settlement + on-chain idempotency. Council fold (2d7927b): "record-before-broadcast + confirmation fail-closed".
• Sprint 36 (f55b477) — DRM price gate: the spend cap is a literal on-chain ceiling. Council fold (ef08d27): quantity pin + pay-token drift + declared token.
• Sprint 36.5 (3d4bf39, +719 / −373, 22 files) — quality audit fold: money-path hygiene + open-source presentability. The largest deletion count of the cycle — a deliberate polish pass across the money path.
• Sprint 37 (5a187a9, +664) — the confirmation scheduler: pending DRM buys resolve themselves.

9. Runtime — The Marketplace Face + Agent Shopping (Sprints 38–39, S48–S50)

• Sprint 38 (94b6bba, +984) — the Marketplace face: an agent shops under a mandate, the operator watches.
• Sprint 39 (9a611fa, +1,058) — runtime.market_quote: the agent shops within its mandate.
• Sprint 48 (1ad189b, +715) — the second market vertical: ERC-20 checkout + the market-provider contract (Track D1+D2). Red-team fold (6eae3b8): "erc20 mode parse fail-closed + mock-reservation boot warn". Guardian fold (0cd66ae): zero-warning workspace + closed-world rail selector + wiring ratchet.
• Sprint 50 (f6a7089, +877) — runtime.negotiate: the shop loop's middle leg (Track D3). Council fold (2d29c43): shared price-gate conversion + bounded seller reason + read-only seam contract.

The shop loop now has all three legs: quote → negotiate → pay, all under the same mandate cap.

10. Runtime — Deadlines & Watchdogs (Sprints 40–42)

A tight three-sprint sequence removes every way a runtime thread could park forever:

• Sprint 40 (fa680b7) — the chain-read deadline: no runtime thread parks forever on the chain.
• Sprint 41 (7bf3dde, +502) — deadline the sibling providers: one shared capsule watchdog, bounded reap.
• Sprint 42 (d7f3e65, +572) — bound the access-path content sidecars — no thread parks on a hung open/view.

11. Runtime — Ledger Typing + Live Testnet + Repo-Wide rustfmt (Sprints 43–46)

• Sprint 43 (4bb26d9, +549 / −263) — type the pre/post-broadcast outcome: retire the string refund classifier.
• Sprint 44 (2a35b85) — structured rail discriminator on the ledger record — closes MKT-DRM 2d.
• Sprint 45 (14db6ce) — live testnet buy: verify-receipt CLI round-trip (gated) + live-chain scaffold. Docs: LIVE_BUY_RUNBOOK.md.
• Repo-wide rustfmt (133c340, +1,934 / −669, 24 files, mechanical) — makes the CI fmt gate truthful. Explicit "no logic delta" commit message.
• Sprint 46 (ecae553) — Track B: close the trust residuals — P16 secrets strip, prepare-leg ratchet, spawn_blocking. Council fold (e726956): "strip secrets at EVERY capsule seam + structural guard + gate the dev-modes lane".

12. Runtime — Bounded Viewer Sessions + SPEC-mandate-v1 (Sprints 47, 49)

• Sprint 47 (3f6c341) — bounded viewer sessions: sweep + cap with deferred off-lock reaps (Track C1). Bounds the viewer surface the same way the shop loop is bounded.
• Sprint 49 (538500a) — SPEC-mandate-v1: the receipt + signed-intent wire format, pinned by a conformance ratchet (Track D4). Docs: docs/SPEC-mandate-v1.md, docs/SPEC-market-provider-v1.md. Council fold (7ef8fbb): "spec honesty + verify_strict + revoke/preimage ratchets".

The spec is what makes a receipt independently checkable a year from now on a machine that never ran ElastOS.

13. Runtime — Audit-Log Concurrency Safety + Fail-Closed Use-Records (Sprints 51–53)

The cycle closes on the audit log — the same file every affordance writes to — and on the record-retention policy:

• Sprint 51 (c8dca99) — audit group commit: concurrent emits share fsyncs, contract unchanged (Track C2). Council fold (71710bb): "poison-under-chain-lock + torn-tail quarantine + flusher unwind guard".
• Sprint 52 (42b1ece) — audit-log single-opener flock + off-lock stdout echo + auditor packet Flint scope. Docs: docs/AUDITOR_PACKET.md.
• Sprint 53 (741fc44c) — G8 policy flip: fail-closed ordinary use-records become an explicit operator opt-in. Council fold (a6b9fa71): "name the availability cliff + best-effort deny-record rationale".
• Consolidation merge (32f0f160, 2026-07-11) — folds a teammate CI-drift fix + the forgotten Cargo.lock chore into flint-0.5 as PR FEAT: metadata and protection alignment #13 merges.

The audit log now handles the concurrency the money rail and shop loop generate — group-committed, single-opener, torn-tail quarantined — while keeping the on-disk contract unchanged, and record retention is a fail-closed operator choice rather than a silent default.

14. Runtime — Multi-Shell, ElastOS Shell Protocol (ESP) & component-bus/v1

A parallel runtime workstream, implemented locally and pre-publication — the architectural foundation and much of the product experience are done, but reconciliation, verification, and commit slicing remain before it lands in the repo (hence no row in the §21 stats table).

This cycle also advanced ElastOS from a single Home interface toward a runtime-owned, multi-shell environment with explicit authority boundaries — the same fail-closed, single-authority principle the mandate engine follows, applied to the shell layer:

• Multi-shell Home (GUI + CLI). Home now supports GUI and CLI shell identities over the same Runtime facts and permissions. The CLI exposes Home, Inbox, People, Apps, and System views through a Runtime-owned terminal session, with shell switching and failure recovery implemented. Users are beginning to get a genuine choice of Home interface without a second code path.
• ElastOS Shell Protocol (ESP). ESP defines how shells discover capsule facts, interfaces, gates, and approval flows. Shells remain projections and consent surfaces; the Runtime continues to own identity, authority, dispatch, and audit. ESP exists to stop each shell (Home GUI, System, Marketplace, a future CLI) from inventing its own private view of the Runtime — before it, each could call different gateway routes, interpret capsule manifests differently, and drift into separate products with inconsistent permissions. ESP is the one shell-facing contract for facts the Runtime already owns, letting a shell ask: which capsules are installed/active? which interfaces and methods do they declare? which operations are actually executable? which actions require approval? what identity, provenance, and audit info may be displayed? which Runtime route currently adapts that operation?
• elastos.component-bus/v1 (WebAssembly Component Model). A first version replaces broad WASI-style environment, filesystem, and transport authority with explicit Runtime-controlled interfaces for identity, capabilities, providers, streams, cancellation, and audit. The rationale: WASI asks "which OS-like resources does this module receive?" while ElastOS asks "which capability-scoped operation may this capsule request through Runtime?" — two fundamentally different authority models. WASI Preview 1 could hand capsules filesystem preopens, environment values, inherited stdio, and transport details, creating a second permission system alongside ElastOS capabilities. The new contract exposes only explicit imports (Runtime/identity context, capability inspection + requests, provider invocation, sessions/streams, cancellation, audit, capsule lifecycle) and deliberately no raw filesystem, network, socket, gateway-URL, bearer-token, or provider-selection imports. Benefits: one authority model; no ambient-authority back doors (a forgotten preopen or env var can't leak); no host-topology leakage (no FIFOs, local paths, gateway ports, or Mac/Linux differences); pre-launch inspectability of exactly which interfaces a component imports; stronger portability; and cleaner audit, since operations pass through a structured Runtime invocation instead of disappearing into generic filesystem/process activity.
• Authority hardening. Home CLI actions now require explicit host authorization; chat-peer operations were narrowed; generic capsule invocation only permits methods with a concrete Runtime binding; and provider-only or approval-sensitive actions continue to fail closed. In progress: Home, System, Marketplace, and CLI showing only capsules that are actually installed and active, with System gaining a user-facing Apps & Services view and deeper permission/provenance detail moving under technical details.
• Media / transport reliability. WebRTC audio negotiation, candidate diagnostics, media health reporting, stale-stream cleanup, and Browser VM staging diagnostics were strengthened.

The practical outcome: users get a choice of Home interfaces, a clearer view of installed apps and services, and consistent behavior across GUI and CLI — without creating parallel authority paths.

15. PC2 — Post-1.4.0 Quiet Cycle

Zero in-window PC2 commits. After the 1.4.0 publish and ENM store flip last cycle, main and feature/elastos-node-manager were untouched in this window. This is expected — the release just landed, the store entry is live, and this cycle's work was on the runtime side of the stack.

Field observations on ENM installs, migration off AWS, and remaining Essentials-service moves (see prior report §11) belong in the human off-repo pass in §23.

16. Hyper (Android) — Mobile Battery/Carrier Hardening + Social Feed

The Hyper mobile build got a focused power-and-reliability pass this cycle — 8 commits, +1,824 / −221, ~40 file-touches (2026-07-06 → 07-07). Two arcs:

• Battery / carrier reliability for a phone. Right-size the iroh gossip mesh for a phone and gate background re-dials (b0714b36); idle background housekeeping loops while keeping the network-agnostic default bind (0b48f5c4); back off offline-peer re-dials + adaptive background call-poll (b92a369e); a network-agnostic fix for cross-network dead-path background churn (27f91bc9); pause UI-refresh polls while the app is backgrounded (16c50be8); and call-audio fixes + carrier reliability + O(active) wake-on-arrival receive (d6940c26). Net effect: the P2P carrier stops draining the battery when the app is backgrounded or off-network.
• Social feed. Live refresh, comment collapsing, and comment avatars (50ec802f); feed scaling — profile live-refresh, drain-only-woken ingest, capped re-affirm, plus a dep bump (d2becedf).

Dependabot also opened a wide wave of Cargo/Gradle dependency-bump branches across hey-core, hey-mobile-runtime, and hey-social-app — routine supply-chain hygiene, not yet merged.

17. ElacityLabs.com — Blog Engine + NVIDIA Inception Announcement

The marketing site landed a real blog engine — and used it to publish a milestone. 6 commits, +208 / −31, 17 file-touches (2026-07-08):

• Blog CMS. A YouTube video-embed block for articles (251a9432); durable image uploads — uploaded images now persist in Postgres, with the NVIDIA article images added (0c62a063); EXIF-based auto-orientation of uploaded images (04a348ff); and admin hardening — attach the auth token to image-upload + category mutations (b16eedcf), attach the auth token on post-editor load (df8c0454), and a loose-typing fix so the fetched post satisfies the tsc build (516d3087).
• The milestone it shipped. The engine went straight to work publishing "Elacity Joins NVIDIA Inception" (July 8) and swapping the site's prior Ethereum badge for an NVIDIA Inception program badge (df8c0454). Elacity was accepted into NVIDIA Inception — NVIDIA's global program for startups building with accelerated computing (free to join, but application- and review-gated, not automatic). See §23 for the off-repo backstory.

18. ElastOS Essentials — Wallet Rebuild, Unified Multi-Chain View & Security Hardening

A July 2026 status update on the Essentials mobile wallet — an ongoing effort; everything below is implemented and running on the current build.

• Design & interface foundation. A full visual redesign landed across the app: the old multi-theme arrangement collapsed to two defined themes (dark default, light alternate) on a single system of design tokens (backgrounds, raised/sheet surfaces, accent, type, spacing), and every screen was rebuilt against it. A reusable component library (balance/token rows, amount display, action tiles/grids, chip rows, bottom-sheet headers, key-value rows, empty states, content-shaped loaders, inline price sparkline, buttons, tab bar, title bar) was adopted app-wide. The app typeface — found to have never actually rendered — was replaced with a variable font; token icons were separated from network logos so each renders correctly; and header wave texture, gradients, 3D action-tile icons, and glass effects were composited in at full resolution. Shared amount/percentage formatters were extracted, and an on-device 24-hour price-history service now drives per-token change, portfolio P&L, and the sparkline with no external dependency. Several obsolete modules were removed to shrink surface area — a >4,700-line bridging feature, a >2,600-line voting subsystem, a legacy storage-manager interface, the lightweight/advanced wallet-mode split, a polls module, and a discontinued network.
• Core screens rebuilt. Every primary screen was rebuilt on the new components — Home (live status cards: active networks, identity-published, connected apps; balance + P&L; proposals/suggestions merged into one voting screen), Wallet (holdings grouped, value-first), Send (two-step amount→recipient: centered entry, 25/50/75/Max, in-app keypad, type-time validation, up-front per-chain network fee for EVM/Bitcoin/ELA/Tron, recent recipients, restored scan, bottom-sheet confirm/success), Token detail (balance/actions/history, native↔fiat toggle, press-and-hold price scrubber; stale-token bug fixed), Transaction detail (explicit sender/receiver, full-precision amounts, live confirmation count, correct icon; fee double-count fixed), Receive (full untruncated address, reliable QR), Onboarding (dark flow), the network chooser (searchable sheet), the scanner (camera-unavailable/permission states), Settings (labelled cards; tabs renamed browser→"dApps", menu→"Settings"), and a new bottom tab bar with instant switching, correct back-stack, and safe-area handling. Content-shaped loading was added across the main screens.
• Unified "All Chains" view. A combined view reads balances across every network and presents one aggregate total with a composite multi-network indicator on Home and Wallet — implemented as a display mode that keeps a real active network underneath, so the dApp browser, widgets, and connect/sign requests keep working. Per-network reads use cached values with no background timers, shown progressively as each network reports in. Receive/send/swap were all wired to the combined view; receive now selects a network (what actually determines the address) rather than a held token; staking/swapping resolve to the correct underlying network automatically; and identity + network controls merged into one header selector.
• Full code review. The codebase was reviewed across 14 separate audits, producing complete technical documentation and a prioritised list of several hundred issues — this defines the remaining-work plan.
• On-device testing & correctness fixes. The rebuild was tested on real devices across 180+ screens, including empty/invalid/extreme inputs and full exercise of the money-critical flows (send/confirm, receive, staking, voting, network switch) with no transaction broadcast. 12 issues from testing were fixed, plus further correctness fixes: token-withdrawal decimal scaling corrected to proper power-of-ten; standardised decimal/currency precision; scanned addresses validated like pasted ones; a fund-risk signing request disabled by default; voting-rank + node-status corrected and a hidden vote button restored; keystore import fully implemented (main-chain sub-wallet + Bitcoin/Tron key derivation); network-identifier verification on custom node URLs; and several display fixes (token symbol vs +/− sign, dropped total row, collectibles send-disabled regression, dead filter/history controls removed).
• Security hardening. Known third-party vulnerabilities cut from ~184 to 109. Crypto libraries pinned clear of known CVEs (elliptic 6.6.1, secp256k1 5.0.1, ethereum-cryptography 4.0.4, Kava signing 3.8.1), clearing five elliptic-curve vulns plus one further disclosed vuln. WalletConnect v1 removed entirely (dropping a vulnerable networking dep; v1 links rejected with a clear message, v2 fully supported). An unused account-abstraction subsystem was removed with its wallet type, routes, and special cases — >51,000 lines. Hardcoded third-party service keys were moved out of tracked source into ignored config with a documented rotation procedure. The dApp signing surface was hardened (high-risk method disabled by default with the standard error code, proper errors instead of indefinite hangs, correct network-switch rejection codes), and a shared requesting-origin header (which site/app is asking, whether the connection is secure, whether a session is verified) was wired onto most signing/connection sheets across chains.
• Dependency & code-quality cleanup. Debug logging stripped from release builds; un-cancelled-subscription memory leaks fixed; an automated unit-test setup added with initial tests + auto-discovery; standardised on a single package manager; unused deps removed and build-only packages moved to devDependencies; stricter compiler checks switched on; and the wallet loader made tolerant of a single unreadable wallet so one bad entry no longer blocks the rest.

This is the "own your wallet" half of the sovereignty thesis getting the same fail-closed, audited treatment the runtime got: a hardened signing surface, secrets out of source, dead attack surface deleted (>58k lines across the bridge/voting/account-abstraction removals), and money-critical flows exercised on real devices before any broadcast.

19. Convergence Lens — PC2 ↔ Runtime

Concern	PC2 (pc2.net)	Runtime (elastos-runtime)
Release cadence	1.4.0 shipped last cycle; quiet this week	PR #13 merged into flint-0.5 (96 commits) — mandate engine end-to-end
Custody / authority	ENM as a fail-closed service-type app	Fail-closed mandate mint (S24) + agent-key binding by default (S20/G-M4)
Consent / grant	(out of scope this cycle)	Mandates app: grant, revoke, list, prove — shell-native
Metering	ENM operator UI	Money rail S27–S31: spend-capped runtime.pay + durable money cap + payment ledger + Money panel
Marketplace	ENM service catalog	DrmMarketplaceProvider (S34) + confirmation-aware settlement (S35) + price gate (S36) + confirmation scheduler (S37) + Marketplace face (S38) + market_quote (S39) + ERC-20 vertical (S48) + negotiate (S50)
Reliability / hangs	Stream-safe gzip, multi-arch packaging	Chain-read deadline (S40) + sibling watchdog (S41) + sidecar bounds (S42)
Spec / auditability	Ed25519 verify for service-type installs	SPEC-mandate-v1 (S49) + audit group commit + single-opener flock (S51/S52) + fail-closed use-records opt-in (S53)
Shell / authority surface	ENM operator UI as one consent surface	ESP: one shell-facing contract + component-bus/v1 — no ambient authority, Runtime owns identity/dispatch/audit (§14)

The convergence line is the same as last cycle, sharpened: capsules whose authorities, consent, custody, and metering are all fail-closed and independently auditable — from a portable receipt the operator can hand to a third party.

20. Looking Ahead

• PR FEAT: metadata and protection alignment #13 merged — now cut the tag. With the mandate engine + money rail + marketplace face + deadlines all landed on flint-0.5 (PR FEAT: metadata and protection alignment #13, 2026-07-11), the next natural step is merge flint-0.5 → main / cut the v0.5.0 tag. review/0.5.0 remains open; latest published Runtime tag is still v0.4.0. The PR body records G-M3 (shell as grant root) and residual G-M4 operational-hardening items as still open — track the reviewed-remaining list into the tag cut.
• Track D wrap. runtime.negotiate (S50) is the middle leg; the shop loop is complete on ERC-20 and DRM verticals. Any third vertical (fiat rail? off-chain settlement?) becomes the next Track D slice.
• Live testnet buy end-to-end. LIVE_BUY_RUNBOOK.md and the gated verify-receipt round-trip (S45) are the scaffolding; the next step is a real testnet transaction against the confirmation scheduler and the audit ledger.
• PC2 next release drivers. With 1.4.0 stable, the pipeline for 1.4.1 / 1.5 candidates: bare-metal RPC follow-through, remaining Essentials-off-AWS moves, and any 1.4.0 install regressions surfaced by the fleet update.
• ELA ↔ Base bridge — executeRotation. Carried forward from last cycle: the automatic council-rotation entrypoint, rehearsed against a real rotation transaction from our own testnet.
• Audit packet ready. docs/AUDITOR_PACKET.md (S52) is the standing-invitation surface — external auditors can start on the mandate engine independently of any other integration.
• Hyper mobile — merge the Dependabot dep-bump wave and continue the battery/carrier reliability pass on the Android build.
• ElastOS Essentials remediation (§18). The 14-audit review produced a prioritised list of several hundred issues; the near-term Essentials plan is to work that list down on top of the rebuilt, hardened base (third-party vulns already cut ~184→109).
• Multi-shell / ESP / component-bus/v1 — reconcile and publish (§14). The architecture and much of the product experience are implemented locally; reconciliation, verification, and commit slicing remain before it lands in the repo. Then: finish "show only installed + active capsules" across Home, System, Marketplace, and CLI.

21. Summary Statistics

Window (UTC): 2026-07-04 → 2026-07-11 (~7 days, incl. the PR #13 consolidation merge). Previous report #27 was posted 2026-07-04T22:12:45Z; runtime sprint work began 2026-07-04T01:47Z — after #27's June 26 – July 3 window, so there is no overlap.

Repository (active branch)	Commits	Insertions	Deletions	Files
elastos-runtime — flint-0.5 (consolidated, SHA-deduped)	89	~31,813*	~4,333	~470
Hyper-Android — main	8	1,824	221	40
ElacityLabsWeb — main	6	208	31	17
pc2.net — main	0	0	0	0
Combined	103	~33,845	~4,585	~527

*Runtime line-counts are the S1–S52 arc computation (86 commits); S53 (G8 policy flip + fold) and the PR #13 consolidation merge landed at the window's edge and add a small amount on top. The commit count (89 = 88 AI-pair + 1 teammate Cargo.lock) reflects the full consolidated in-window set on flint-0.5.

• PRs in window: Runtime FEAT: metadata and protection alignment #13 Flint mandate engine — MERGED into flint-0.5 2026-07-11T02:25Z (96 commits since the 2026-07-03 branch point, +29,593 / −872, 83 files); Runtime ElastOS Weekly Shipping Report — Week of Mar 28 – Apr 3, 2026 #9 Flint 0.5 still open (flint-0.5 → upstream/0.6-dev). PC2 — none.
• Releases in window: none. Runtime latest published tag remains v0.4.0 (2026-06-09); PC2 latest is 1.4.0 (2026-06-26).
• Line-count caveats. The repo-wide rustfmt commit (133c340) contributes +1,934 / −669 mechanical churn with zero logic delta — the narrative sprint count (~53 numbered sprints plus folds) is the truer effort signal.

22. Data-Quality & Off-Repo Notes

• Attribution. All work this cycle is reported as the Elacity team's output, without individual names. Commits authored under the name "Claude" are AI-pair-programmed under the team's direction and review — counted as real shipped work, attributed to the team.
• Windowing. Cutoff lower-bound = 2026-07-04T00:00:00Z (the prior report #27 was posted 2026-07-04T22:12:45Z, but its content window ended July 3, so the 07-04 sprints are new here). Runtime is now consolidated on flint-0.5 after PR FEAT: metadata and protection alignment #13 merged and the feature branch was deleted; counts are SHA-deduped on that branch.
• Private-repo sweep. A full Elacity-org scan was run: only elastos-runtime, Hyper-Android (07-07), and ElacityLabsWeb (07-08) had in-window pushes. Every other private repo (v3-drm-protocol, drm-contracts, media-player, elacity-web, lit-keystore-moleculer, transcoder-gcloud, js-sdk, ddrm-reader, chipotle-functions, events-watcher, and others) last pushed before 2026-07-04 — zero in-window commits.
• ELA ↔ Base bridge carries no in-repo commits this window; it remains R&D carried from last cycle (executeRotation still pending) and is tracked in Looking Ahead, not the stats table.
• ElastOS Essentials (§18) is a team-reported July 2026 build status, not derived from in-window commits in the scanned Elacity-org repos (the Essentials app lives outside them); its figures (14 audits, 180+ screens, ~184→109 vulns, >51k-line account-abstraction removal) are reported from the current build, so it carries no row in the §21 stats table.
• Runtime multi-shell / ESP / component-bus/v1 (§14) is likewise team-reported and implemented locally, pre-publication — reconciliation, verification, and commit slicing remain before it lands in the repo, so it also carries no row in the §21 stats table.
• Off-repo context (§23) is reported at the team level except where an item is location-specific to the founder — the NVIDIA Inception acceptance is credited to the founder's networking in San Francisco because that presence is the material fact.

23. Off-Repo Context — San Francisco & NVIDIA Inception

The headline off-repo item this cycle is a direct product of being in the room. Founder Sasha Mitchell was on the ground in San Francisco at the AI Agent World's Fair, and the trip converted into a concrete outcome:

• How it happened. Conversations with members of NVIDIA's developer community at the fair — talking through what ElastOS is and where it runs — led to an encouragement to apply to NVIDIA Inception. The application went in, cleared NVIDIA's review, and was approved this month. It's a membership, not a partnership — but for a team building AI at the edge (on devices people own, not in distant data centers), it's the right room to be in.
• What membership brings. Preferred pricing and member access to NVIDIA hardware (including NVIDIA DGX Spark, named as our next target device); cloud credits from NVIDIA's cloud partners; engineering depth via the Deep Learning Institute and sessions with NVIDIA experts; SDK and early-access programs across the stack; investor reach through Inception Capital Connect; and go-to-market support with co-marketing and a seat at events like GTC.
• Why it fits the thesis. Sovereign computing needs two halves — software that answers only to its owner, and hardware powerful enough to carry a private AI. We build the first; NVIDIA's line, from the Jetson Orin in a home appliance to DGX Spark on a desk, is the second. ElastOS runs on Jetson Orin today, with the AI accelerated on the device's own GPU so conversations never leave the house — exactly the "own the hardware, own the AI, own your work" story the architecture serves.
• Concrete near-term path. Jetson support ships today; DGX Spark (128GB unified memory — enough to run far larger models at home) is the named next target; and we're evaluating TensorRT-LLM and NVIDIA NIM for the AI layer. Targets, not shipped features — published as such.

Announcement: "Elacity Joins NVIDIA Inception" (elacitylabs.com, July 8, 2026), published through the new blog engine in §17.

---

Cadence: weekly updates. Previous report — Week of June 26 – July 3, 2026 (#27).