ALUX

At @alux_network, we bring all types of state transitions on-chain. $ALUX #Concurrent #Composite

As far as we know, we are the first blockchain to deliver vertical atomicity. Imagine buying an on-chain ticket: payment runs in block 100, but the ticket transfer waits for approval and fails in block 103. With Saga, the payment may already be committed. If the seller was allowed to spend it, there may no longer be enough money left to refund you. The purchase failed, and now the refund can fail too. Escrow or reserves can protect against that, but the application has to arrange them and handle the compensation. ALUX’s cross-block model keeps the payment and ticket transfer inside one transaction. While it waits for approval, the payment remains uncommitted, so the seller cannot spend it. If the ticket transfer fails, the pending payment is discarded. If both steps succeed, they commit together. You don’t end up paying for a ticket you never received and then waiting for someone to return the money. All other blockchains, such as Rialo and ICP, use the saga pattern. @alux_network $ALUX #Atomicity #Blockchain #DistributedSystems #Web3

ALUX Q3 2026 build update 🚀 New Tolang features, first system contracts, a more reliable TVM, and better developer tools. What shipped, what's in review, and our roadmap toward testnet in Q1 2027. Read the full update ↓

Another foundation block is in place. 🧱 Version 1 of the ALUX Programming Guidelines is complete—a shared baseline for writing, reviewing, and evolving the codebase. Clearer code. Smoother collaboration. A stronger foundation for the global computer we’re building. Read the guide: alux-network.github.io/alux-… $ALUX @alux_network

Today, a CEO asks an Agent to work on one of Bob’s records. If access is granted through the CEO’s identity, the task may carry the CEO’s entire “master badge.” The Agent came for Bob, yet Alice, Carol, and even Financials may also fall within its reach. The problem is not that the Agent will necessarily look. The problem is that the task should never receive unrelated authority in the first place. In ALUX’s Global Logical Virtual Machine (GLVM), OCAP takes a different approach: do not pass the CEO’s identity into the task. Give the Agent one “key” that points to Bob’s record. The key is not a password. It is an unforgeable object-capability reference. Without a reference to another object, the Agent cannot name or reach it. The TVM enforces that boundary at runtime. If the main Agent delegates work to sub-agents, it does not need to copy all of its authority. Through capability attenuation, it can narrow the key before passing it on. Each sub-agent receives a smaller key—just enough for its own subtask. Authority can be reduced, but it cannot expand out of thin air. Capabilities can also carry rules. An email service, for example, can provide a capability that permits only one send. Once the email is sent, that capability is gone. A temporary task does not need a permanent master key. These smaller capabilities can also be composed: access Bob’s record, delegate a bounded subtask, send one email, and return the result. Together, they form a complete workflow while every step remains inside a clear boundary. OCAP is not about giving an Agent every permission and hoping it behaves. It is about giving each task exactly the authority it needs. One task. A set of just-enough keys. No master badge. No unnecessary authority. $ALUX @alux_network #web3 #web4 #aiagent

2026 Q2 marks a major execution milestone for ALUX. ✅ We have reached the initial demo stage: full end-to-end integration testing of cross-block atomic execution on top of consensus is now complete, with cross-block execution and atomic finalization visualized in our customized block explorer. ⚙️ We also continued making the system more robust. A new unified testing framework has been built to replace the previous isolated test cases and support both standalone and network-based testing. 🧩 Tolang also became easier to use. Built on top of a native Tolang parser, we added compile-time constant support, a Tolang language server, and a VS Code extension. 🛠️ The Node API and CLI are mostly complete, with partial progress on Ethereum toolchain integration. Several PRs remain to be merged, including the new trap-based EVM sandbox. 🔌 Looking ahead to 2026 Q3, our focus shifts to logical clocks, isolation-level enforcement, TVM debugging and observability, synchronous function support, system registry and account abstraction contracts, and Solidity examples for smart contract / agent orchestration patterns such as async/await, join, and select. 🔭 Step by step, ALUX is moving toward a more powerful execution layer for decentralized agents and cross-block smart contract orchestration. 🚀 Stay tuned! 👉🏻 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

Everyone's shipping AI agents. Almost nobody's shipping agents that survive production. The gap isn't a smarter model — it's 4 things every agent needs to be production-ready. We call it RISC: 💪 R — Robust (Body): durable execution, geo-replication, horizontal scale, deterministic replay 🧠 I — Intelligent (Brain): agent loop, context, memory, skills, orchestration 🛡️ S — Secure (Immune system): sandboxing, authentication, authorization 🤝 C — Connected (Social): all of the above — across org boundaries Today's tools excel at I. The other three are barely built. Here's our edge: under the hood, a production agent is just an agent loop running on a distributed, replicated state machine, composable across org boundaries — exactly what we've spent years building: the TVM (Tuple-space Virtual Machine). So R, S & C aren't bolt-ons. They're native: ⚙️ durable execution on a replicated state machine + atomic transactions → R 🔑 object-capability security (unforgeable permissions) → S 🧩 decentralized capability delegation + agent coordination → C And that C — Connected — is where ALUX lives: a neutral network with no single owner, where agents from different companies discover, orchestrate, and exchange capabilities with each other — safely. Your agents get a brain. ALUX connects them all. A federated LangChain. 🔗 Robust. Intelligent. Secure. Connected — and the network that fuses them into one. We're building it in the open. 👉 @alux_network #AIagents #AgenticAI #BlockChain #Web3 #Web4 #Concurrent #Composite #Blockchain $ALUX

🎯 From Demo to Vision The upcoming demo is more than a technical milestone—it is a concrete step toward a broader vision for ALUX. At its core, ALUX is designed around composability: the ability to coordinate computation, state, and access across distributed systems in a unified and reliable way. 🧩 1. Composability of State Transitions ALUX enables composable state transitions across two key dimensions: ⏳ Temporal composability — State transitions can occur across different blocks (over time) while still achieving atomic finalization. This is realized through cross-block atomic execution. 🌐 Spatial composability — State transitions can occur across different systems (e.g., shards) and still be finalized atomically, enabling true cross-shard execution and horizontal scalability. 🔐 2. Composability of Access Control In ALUX, processes interact exclusively through unforgeable names, enabling what we call composable security. Unlike traditional ACL-based systems, which struggle when multiple principals are involved, this model allows secure, flexible, and scalable coordination across many participants. 🖥️ Toward a Virtual Machine Abstraction These two forms of composability form the foundation of a distributed concurrent runtime. In this model: Many physical machines (on-chain and off-chain) → operate together as → one logical virtual machine We refer to this as the Virtual Machine Abstraction. 🌍 Long-Term Vision: A World Operating System Building on this abstraction, ALUX enables something more ambitious: A world operating system — a unified execution layer where services, agents, and contracts can coordinate seamlessly and safely across heterogeneous infrastructure. This is particularly critical for the emerging agent-driven future 🤖, where autonomous systems require reliable coordination, composability, and security at scale. 🏗️ Architecture Overview The following chart illustrates the architectural hierarchy of this vision — from physical infrastructure to the unified runtime (through virtual machine abstraction), and ultimately to the world operating system layer. #Web3 #Web4 #Concurrent #Composite #Blockchain $ALUX

🔗 ALUX Roadmap Update In the first quarter of 2026, the team continued progressing toward a fully functional, integrated system. During this period, several critical issues were identified—particularly bugs that caused cross-block execution to stall and replay mechanisms to fail. These findings led us to redesign the replay mechanism into a simpler and more elegant solution, enabling reliable cross-block atomic execution. At the same time, significant portions of the codebase are being refactored to improve modularity and extensibility. A new EVM sandbox architecture has also been proposed, simplifying the interaction between the EVM and TVM while improving overall performance. 🚀 Looking Ahead to Q2 In Q2, our primary goal is to close the loop by successfully completing a full end-to-end integration test of the entire system. The upcoming demo will showcase: ⚡ Atomic cross-block execution in action 🔧 A real-world use case: orchestration of smart contracts using async/await, join, and select This milestone represents a critical step toward validating the system as a cohesive whole—demonstrating not just individual components, but their integration into a working runtime. 💡 Why This Matters Achieving reliable cross-block atomic execution is foundational. It transforms blockchain systems from isolated transaction processors into coordinated execution environments 🧱→🌐, enabling more complex, stateful, and concurrent applications. The Q2 demo is not just a feature milestone—it is a system-level validation of ALUX's core architecture. Stay tuned! 👉 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

The 2026 Web3 inflection point won’t be faster blockchains, but trustless collaboration between AI agents. Today, the execution model of most blockchains is still based on: instant short transactions, ordering, and then sequential or parallel execution with synchronous calls. This model is almost unusable for an agent economy. A blockchain that can truly support an agent economy needs: ⚡️ Coroutine-style transactions (pause / wait / resume + ACID) ⚡️ Process orchestration primitives (join, select, async coordination) ⚡️ ACID cross-shard execution (true horizontal scalability) ⚡️ OCAP-native security (secure agent-to-agent interactions, preventing prompt injection attacks) When AI agents begin executing autonomously on-chain: Blockchains without a concurrency model will become the biggest architectural bottleneck, and systems without capability-based security will become the largest security vulnerability. A distributed concurrency control layer will be the key infrastructure for the Web3 × Agents era. $ALUX #Web3 #AI #Blockchain #AIagent

👨🏻‍🎨 ALUX roadmap update! 1/ In Q4 2025, we continued advancing atomic cross-block long-transaction (long-TX) support. Long-TX test cases now run successfully with hardcoded sync points—putting us one step away from our first major milestone. 2/ Next step: replace those sync points with BlockGit consensus. That unlocks our first working demo: fully on-chain, atomic long-TX execution across multiple blocks. 3/ We also refactored the codebase to improve modularity. These upgrades lay the groundwork for: - faster, more flexible evolution toward sharding - extensions beyond blockchain-only use cases 4/ In parallel, we explored several logical clock designs to capture execution traces efficiently—enabling analysis and enforcement of different transaction isolation levels. Implementation is now underway. 5/ Looking ahead to Q1 2026, our primary objective is clear: Pass integrated tests for atomic long-TX execution on top of BlockGit consensus. This milestone will serve as a proof of concept for our novel blockchain design. 6/ After that, we’ll focus on production-ready features needed to launch a functional testnet. 7/ We’re community-driven—and we wouldn’t be here without you. Our small but capable team continues to deliver, addressing engineering challenges rarely faced by other teams. 8/ A quick look back at our journey: 2022: Built an OCAP-enabled bytecode interpreter + the Tolang compiler 2023: Implemented the tuplespace virtual machine (TVM) with replayability 2024: Built the EVM sandbox on TVM, implemented the Block Merge algorithm, and developed BlockGit 2025: Introduced behavior channel types + completed key components required for atomic long-TX support 9/ Even as the industry cools again, our vision is clearer than ever: Make all forms of state transitions possible in centralized systems equally possible in decentralized ones. A real world computer as a unified logical VM—composed of many smaller VMs across sharded chains, L2s, private clouds, and browsers. 10/ Smart contracts on this unified VM can call one another seamlessly and finalize atomically—even across different sub-VMs. The OCAP-enabled VM ensures these interactions remain safe and controlled. Atomic on-chain long-TX support is the first critical technology we must deliver—and we’re very close. ----------------- As we enter 2026, thank you for building with us! Stay tuned! 👉🏻 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

🙋🏻‍♂️ In Q3 2025, we focused on building a key mechanism to enable long transactions — on-chain transactions that can be temporarily suspended and later resumed, allowing execution to span multiple blocks while remaining atomically finalized. This marks a major step toward true scalability, paving the way for the world’s first blockchain capable of actively interacting with the off-chain world, instead of relying solely on oracles. The same mechanism will also power atomic cross-chain transactions in the upcoming sharding phase. Meanwhile, we have continued improving code quality and modularity through multiple refactors across the TVM and database modules, as the system grows in complexity. Next quarter, we will focus on integration and testing, moving closer to a working demo — the first blockchain capable of concurrent, on-chain long-transaction processing. Stay tuned! 👉🏻 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

🧑‍🏭 In Q2 2025, we completed a critical enhancement to our TupleSpace Virtual Machine (TVM): the introduction of simple behavioral channel types. The TVM bytecode standard now enforces three channel types—Single-Owner, Affine, and Linear—enabling significantly faster execution and a much smaller replay log, all while maintaining replay consistency. 🦿 Our Weaklink feature in BlockGit has also passed full testing. Unique to ALUX’s protocol, Weaklink decouples a block’s two roles: contributing to consensus state and to virtual machine state. This separation is vital to achieving ALUX’s vision of supporting on-chain long transactions and atomic cross-shard transactions. 🤖 As we integrate all modules toward a working demo, we have introduced a more advanced test framework. Using Rust’s proptest crate, we built a system that generates millions of random Tolang programs to test TVM execution under various concurrent schedules. Each test ensures state consistency between play and replay across hundreds of execution paths. 🫶 Looking ahead to Q3, we remain focused on delivering a demo showcasing a blockchain capable of processing long-running transactions on-chain. Stay tuned! 👉🏻 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

As part of a recent upgrade to our TupleSpace Virtual Machine (TVM), ALUX has introduced new behavioral channel types to enhance performance and predictability: ※ Single-Owner: A name (channel) is exclusively owned by one process at any time. ※ Affine: A name may be used at most once. ※ Linear: A name must be used exactly once. These constraints are enforced at runtime by our bytecode VM, enabling more efficient execution paths. Why it matters: ALUX is building a Pi/Rho calculus-based VM designed for composable, long-running concurrent transactions on-chain. To scale without compromising performance, we’ve introduced a class of channel types that unlock key optimizations. For example, Single-Owner channels support lock-free access and can be used to hold sequential VM sandboxes like the EVM. Affine and Linear channels ensure deterministic usage, reducing the overhead of recording extra information for validator replay. This is where formal theory meets practical engineering—ALUX brings it to life. $ALUX #Web3 #Blockchain #Concurrent #EVM

The evolution of the Ethereum Virtual Machine (EVM) can be understood across four distinct levels: Level 1: Sequential EVM (e.g., Ethereum) * Transactions are processed sequentially, one after another. Level 2: Parallel EVM (e.g., Sei, Aptos, Monad) * Enables parallel transaction processing for improved throughput. * Limitations: Depends on trusted oracles (such as Chainlink) to interact with the external world. Level 3: Concurrent EVM (ALUX – Single-Shard Stage) * Supports asynchronous, long-running transactions that can be temporarily suspended and resumed. * Enables direct, active communication with the external world—without relying on intermediaries. Level 4: Composable EVM (ALUX – Multi-Shard Stage) * Allows transactions to run across multiple shards while preserving atomicity. * Unifies shards into a single, logically cohesive virtual EVM. * The only approach to achieve horizontal scalability without compromising usability. $ALUX #Web3 #Blockchain #Concurrent #EVM