The past two weeks were a heads-down stretch for ElastOS: two PC2 release branches moved forward, IPFS durability improved, Runtime authority moved from design into working code, and the Elastos World Computer framing became clearer.
PC2 main stayed at v1.2.7.14 by design. The team’s time went into the next releases, supernode hardening, IPFS network work, Runtime permissions, and the first steps toward opt-in privacy for the Elastos main chain. The team also responded the same day to a responsibly disclosed pre-authentication RCE on the flagship supernode, while opening a technical conversation with the Beam team about an opt-in privacy layer.
In one breath:
- PC2, v1.2.8.0 is ready on its branch with telemetry, self-diagnostics, and one-click support reports.
- v1.2.9.0 is partly shipped, with the new serverless Chipotle proxy already live.
- Around 18,000 historical Elacity pins, roughly 340 GB, are now replicating across three countries.
- A pre-auth RCE on the flagship supernode was patched the day it was disclosed.
- Runtime authority moved into code: Wallet signs, Browser is constrained, and production dApps now run through Runtime providers.
- ENM, the Elastos Node Manager, is close to release shape as a dApp Centre installable app.
- A privacy-layer conversation opened with Beam around an extension-blocks path for the Elastos main chain.
1- PC2: v1.2.8.0 and v1.2.9.0
Most PC2 work went into the next two release branches.
v1.2.8.0 adds a new Health and Support panel. The goal is simple: when a user has an issue, they should be able to send the team a clean system snapshot without hunting for logs or uploading files manually.
The panel checks Runtime, network, storage, wallet, and dDRM status. It looks at version, platform, memory, uptime, IPFS peers, disk space, wallet state, signing keys, Chipotle reach, and session-key expiry. Every check returns structured data, giving the team a clearer picture of what was happening when the user tapped Report.
Nothing leaves the machine silently. A Preview Report button shows exactly what would be submitted, including diagnostics, redacted logs, and a wallet address. Submission is wired, but still gated until the receiving side is ready.
v1.2.9.0 focuses on the Chipotle relayer. A new serverless proxy is now live at chipotle-proxy.cloudfunctions.net. Clients switch the base URL, stop sending the X-Api-Key header, and the proxy injects the key server-side. This removes the Lit Chipotle keystore API key from the client wire path.
The PC2 client switch lands after the consolidated Lit Actions push, covering one encrypt path and one decrypt path across media, non-media content, EOAs, and smart accounts.
PC2 also received IPFS upload-path cleanup, so creator publishing, viewer caching, and supernode pinning now move through one shared path. New pins can land directly into the cluster’s replicated namespace without changing the creator workflow.
2- IPFS: 18,000 pins now replicating across three countries
The IPFS work also moved at the network level.
ipfs.ela.city, hosted on Google Cloud, joined the Elacity IPFS Cluster as a third peer alongside both supernodes. Once it joined, historical pins on ipfs.ela.city began replicating automatically to the other two peers.
- Around 18,000 pins
- Roughly 340 GB
- Mostly historical Elacity NFT content
- Replication across US East, Europe, and Google Cloud
This is the first time the historical Elacity content set has been actively replicated across multiple geographies instead of leaning on a single node.
The same API remains on the outside, but the durability underneath is stronger.
3- Supernode hardening after same-day RCE patch
On May 15, an external researcher responsibly disclosed a pre-authentication shell-injection vulnerability in one of the gateway registration endpoints on the flagship supernode.
The issue was patched the same day. The response included edge kill-switches, patched code deployed to both supernodes, nginx hardening, removal of direct public port exposure, tighter ufw rules, restored TLS verification, and removal of the orphaned NODE_TLS_REJECT_UNAUTHORIZED=0 setting.
map.ela.city also came back online after a nine-hour outage during the same hardening pass.
The more important fix is the deploy process. The patch had already been in main for over three weeks, but had not reached production. That “patched in code, exposed in production” gap is now being closed with a deploy script that smoke-tests the new build, swaps the live process only when tests pass, and rolls back on failure.
The researcher was credited through coordinated disclosure.
4- Runtime authority is now working in code
Runtime work focused on one rule: apps should not get direct access to wallets, chains, or external services. They should ask through Runtime-controlled paths, and important actions should be traceable later.
Wallet is now the main blockchain surface. Accounts, approvals, receive QR, address display, MetaMask linking, BTC groundwork, and ESC/Base/BTC account direction all route through Wallet. Wallet is the only place that signs or sends transactions.
Browser is now a controlled capsule. It opens through Runtime, uses provider contracts, and exposes a constrained window.ethereum. An app running inside Browser can request a signature, but it cannot directly reach a private key, wallet, or chain connection.
ela.city and Glide Finance now run inside this constrained Browser. Account discovery, ESC default chain selection, typed signing, transaction approvals, and read-only chain calls all route through Runtime providers.
Home and System were also cleaned up. System now focuses on policy and Runtime state instead of duplicating Wallet controls. Verification tooling shipped too, including Browser and Home entropy checks, route tests, wallet smokes, and provider decision reports.
The next Runtime branch, review/0.3.0, focuses on Browser stability, multi-window sessions, audit coverage, and further testing around the Carrier and provider boundary.
5- ENM: Elastos Blockchain Node Manager
The Elastos Node Manager moved close to release shape.
ENM is a full-node operations console for the Elastos main chain, built by Elacity to ship as an installable dApp Centre app. The first version is BPoS-aware and built for supernode operators, while also supporting general full-node observer use.
Setup is guided rather than manual. Operators choose a role, pass system checks, download a verified ela binary, choose snapshot or genesis sync, generate the keystore, hand the public key to Essentials, and start the node.
The app includes Dashboard, Logs, Settings, and About. It covers chain state, block height, peers, uptime, host resources, node identity, BPoS status, live logs, severity filters, and activity history.
ENM makes ElastOS useful not only as a personal cloud, but also as a node operations surface.
6- Privacy layer discussion with Beam
A technical conversation opened with the Beam team about whether and how a privacy layer could be added to the Elastos main chain.
Three routes were considered: a side chain, a full Mimblewimble hard fork, and an extension-blocks pattern similar to Litecoin’s MWEB.
The active discussion is the extension-blocks path. A side chain is not the goal because the goal is main-chain privacy. A full Mimblewimble base-chain fork is too disruptive and would make privacy the default, which does not fit every Elastos use case.
The extension-blocks path could add opt-in confidential transactions next to the existing transparent chain. Users would choose per transaction whether to use the private path, while transparent transfers, rights, royalties, settlement, and governance keep working as they do today.
No commitments have been made. Beam is reviewing the Elastos chain code to estimate the work, code touch points, and what would need to change.
The question is simple: can Elastos add opt-in privacy to a Bitcoin-secured main chain without breaking the transparent paths the ecosystem already depends on?
7- The Elastos World Computer
ElacityLabs CEO’s US travel cycle closed with a community update that sharpened the product framing.
Elacity is bringing PC2, Runtime, Carrier, and the Elastos blockchain together as one user-owned computing system: the Elastos World Computer.
- PC2 / Home is the personal cloud and desktop.
- Runtime is the trusted capsule engine.
- Carrier is the private network layer.
- Blockchain is the rights and settlement layer, secured by Bitcoin merge-mining.
The shift is from a web-server-like model, where a session can become broad access, toward an operating-system-like model, where every important action needs a scoped permission and can be audited.
“If we get this right, ElastOS becomes more than software. It becomes a digital home, an agent environment, a rights layer, and a user-owned foundation for the next internet.”
What lands next
- v1.2.8.0 merges into main after final review
- Users get one-click system reports
- v1.2.9.0 follows once the consolidated Lit Actions push
- Chipotle keystore API keys leave the client wire path
- IPFS cluster replication continues across all three peers
- ENM ships as a dApp Centre installable app
- Runtime 0.3.0 planning continues around Browser stability, multi-window isolation, and audit coverage
- Beam returns the next technical readout after reviewing the Elastos chain code
Closing
PC2 is becoming easier to support. Runtime is starting to enforce the authority model in code. IPFS is becoming more durable. ENM is turning ElastOS into an operator surface. And the World Computer framing is becoming clearer across the whole stack.
Full technical write-up with per-commit detail lives in the pc2.net repo.
