Just like last week, ElastOS is moving toward one system built from four parts: the Elastos blockchain, Runtime, Personal Cloud Compute, and Carrier. The blockchain anchors identity, ownership, settlement, staking, and governance. Runtime is the local authority layer where apps run with permissions instead of open access. PC2 is the personal cloud product users can use today. Carrier is the private network layer that lets nodes, apps, and users communicate without depending on the old cloud model.
Last week was about proving those pieces were starting to connect. This week, Runtime crossed fully into release, and PC2 reached release-ready shape.
Runtime v0.3.0 is out, with its authority surfaces declared in code: Wallet signs, Browser runs through Runtime, Recovery Kit protects recoverable identity and built-in Wallet keys, and ordinary capsules do not receive raw wallet, chain, node, IPFS, network, or host access by default.
PC2 v1.3.0 is tagged and ready for public rollout in the next release window, after one of its most concentrated security cycles this year. Updates to the launcher also landed to simplify the install path, especially on MacOS.
The short version of what shipped:
- PC2 v1.3.0 closed four real access-control gaps found in a pre-release audit.
- dDRM decrypt moved into a WASM-contained sandbox so the content key does not touch the host process.
- The Monetisation Agent is shipped dormant behind a kill-switch, ready to promote once validation completes.
- Runtime v0.3.0 declares Wallet, Browser, Home, System, and Recovery Kit as real authority surfaces.
- The macOS isolation path continued toward bridged-mode networking, the last step before full Linux parity.
- Elastos Node Manager is in review with the service supervisor and the full multi-chain dashboard.
- Raspberry Pi OS joined the CI gate on every push.
1- PC2 v1.3.0: security first
PC2 v1.3.0 is the most security-focused PC2 cycle of the year so far, closing four real access-control gaps before public rollout.
The first was in protected content ownership checks. When a user opened paid content, PC2 checked ownership through a blockchain endpoint. The issue was that the request could influence where that check went, meaning a hostile caller could try to route it to a fake endpoint that always answered yes. That path is now closed. The server picks from a trusted, health-tracked RPC pool, and the user request no longer decides where ownership is verified. This also reduces intermittent access errors on content the user already owns, because unhealthy endpoints can be avoided.
The second fix was in the skills system. Skills are like apps for the AI assistant. The install path used to trust wallet data sent in the request, which created a session mismatch risk. It now reads the wallet from the active session instead.
The third fix was live session revocation. When a user signs out or a session is revoked, related tokens now stop working immediately, and the underlying decryption state is cleared. Revocation is also owner-bound, so someone else cannot end your session to harass you.
The fourth fix was file capability links. PC2 gives apps short-lived links to reach a specific file. Those links now carry a mandatory server-side signature. If a link is changed in transit, the signature fails, and the server rejects it.
The short version: PC2 moved trust away from local request data and back to the server, the active session, and wallet proof.
2- dDRM moves into a safer shape
The dDRM path also moved forward this cycle. The step that actually unlocks paid content now runs inside a sealed sandbox. PC2 can ask the sandbox to unlock a file or a video segment, but cannot ask for the unlock key itself. The key stays inside the sandbox and is wiped to zero the moment it is no longer needed.
dDRM has to be strict. Content is stored through PC2, checked against on-chain ownership, opened through a player, and later routed through Runtime and Carrier. The goal is one chain of trust: the wallet proves you own it, the server verifies that, the player only sees what it needs, and a local user cannot fake their way past any of it.
The dDRM module is also moving to a shared library, so the native player, the WASM image viewer, ela.city, and base.ela.city all use the same code instead of separate copies that drift apart over time.
3- Monetisation AI Agent
PC2’s AI chat now has a new mode that helps creators package and sell their work. It is included in v1.3.0 but turned off by default until live testing finishes. An operator can flip it on later with one config setting.
Today, selling a file on the Elacity marketplace means opening the Creator app and filling in a multi-step form: pick the file, set the price, set the royalty split, write a description. In the new mode, the user drops the file into chat instead and describes what they want in plain language. The agent fills in the same form behind the scenes and hands the user into the Creator app at the final review step.
Minting and wallet signing still happen in the Creator app. The encryption pipeline does not change. Wallet signing stays in the same place. On-chain output is identical. A gating test makes that a release rule: an intent built by the agent and the same fields entered by hand must produce a byte-identical mint, or v1.3.0 does not ship.
4- Runtime v0.3.0 is out
Runtime v0.3.0 makes the security model visible in code, not just in design docs.
The Runtime will be the local OS layer of ElastOS. Each app runs in its own sandbox called a capsule, and the Runtime decides what each capsule can do. v0.3.0 names five trusted surfaces and makes every other capsule start with nothing.
Wallet is the only place that signs a transaction or releases a key. Browser is the only place a web page can run, and it talks to the chain through Wallet rather than directly. Home is the passkey-first front door (the same kind of login Face ID and Touch ID use, where the private key never leaves your device). System is the control panel for policy, recovery, and diagnostics. Recovery Kit is the backup that protects your identity and built-in Wallet keys.
Every other capsule starts with no access to the wallet, the chain, your files, your network, your IPFS node, or anything else on the host. If an app needs to sign, it asks Wallet, and the user approves the action.
The strongest real-world test was Glide Finance, a decentralised exchange on the Elastos Smart Chain. Glide’s web interface ran end to end through the Runtime: account discovery, chain switching between ESC and Base, signing, approvals, and read-only chain calls. The page never received raw wallet or chain access. The user still saw and approved each action. Glide still worked the way it always has. The bridge between today’s web dApps and tomorrow’s capsule model held under a real workload.
A security cleanup pass followed the tag, updating dependencies to close 18 of 21 known issues in one sweep.
5- macOS gets real capsule isolation
A capsule is a sandboxed app on ElastOS. The strongest sandbox the runtime can offer is a hardware-isolated virtual machine: the app runs inside a small VM that the chip itself enforces, so a bug in one capsule cannot escape to other apps or to the rest of your machine.
On Linux, that isolation comes from KVM, a built-in kernel feature. On macOS, the supported path is Apple’s Virtualization framework, the same building block Docker Desktop uses on Mac.
The Mac backend now boots a real ElastOS capsule inside a hardware-isolated Apple Silicon VM. The capsule can call out to host services (file system, wallet, network), and other capsules can reach in over Apple’s vsock channel, which is a fast direct line between a VM and its host.
One gap remains: bridged networking, the mode where a capsule appears on your home network as if it were a separate computer. Apple requires a signed entitlement for this. Until it is approved, the runtime fails closed with a clear “entitlement required” message rather than quietly opening a less protected path. That is the right behaviour: do not pretend a security guarantee exists before the platform can enforce it.
6- Elastos Node Manager moves through review
Elastos Node Manager moved forward this week. The two-PR set is now in review: the service-type supervisor and the full multi-chain node dashboard.
A Council node is not one service. It is eight services running together: the main chain, three sidechains, three oracles, and the arbiter. Node Manager brings those into one dashboard so operators can see status, control services, track logs, watch sync progress, and recover from common issues without living in the command line.
That matters for the Elastos DAO because Council infrastructure should be easier to run well. If reliable nodes are easier to operate, more candidates can participate seriously.
7- Launcher, media player, and supporting work
The PC2 install scripts got a friendlier touch. On Raspberry Pi and Jetson, the installer now asks for the sudo password once instead of prompting through every step. A new startup check looks for ffmpeg (the standard video and audio library PC2 uses for playback) and fails with a clear message if it is missing, rather than crashing later. Mac launcher work continued toward a signed and notarised installer, so a Mac user can install PC2 by double-clicking a file instead of running terminal commands.
The native media player (the playback engine that decodes protected content) landed the new image viewer module and kept moving the dDRM decrypt logic toward a portable WebAssembly module that can run anywhere it is loaded. The goal is one code path used by every consumer (PC2, the native player, the image viewer, ela.city) instead of each one carrying its own copy.
The lit-keystore-moleculer service (which mediates content-key fetches through the Lit Protocol network) and the ffmpeg-installer helper (which downloads the right ffmpeg build for the user’s platform) were both updated to match the new decrypt path.
These are the pieces that turn PC2 v1.3.0 and Runtime v0.3.0 from tagged code into something a regular user can actually install and run.
What ships next
Runtime v0.3.0 is out. PC2 v1.3.0 is tagged and ready for public rollout in the next release window. The Apple-notarised launcher DMG remains the final public install-path piece. Fresh verification on Mac, Linux, and Windows is complete, and the public test runs are green.
Elastos is not building four separate things. The blockchain, Runtime, PC2, and Carrier are starting to connect into one system: a user-owned computer where identity, apps, content, permissions, networking, and settlement can work together without handing control back to the old cloud model.
The stack is still being built piece by piece, but the pieces are no longer moving separately.
Full technical write-up lives in Elacity portal
