What becomes possible on ALUX that ordinary smart contracts cannot do?
ALUX extends the smart-contract model into a decentralized durable execution engine for long-running jobs. A workflow can run concurrent processes, suspend across blocks, wait for external tools or people, resume, and join results without exposing half-completed state. Runtime-mediated external channels can interact with supported off-chain services without separate oracle-and-relayer choreography. The architecture is designed to extend the same atomic model horizontally, so cross-shard effects commit or abort together; cross-shard execution remains on the roadmap.
Why is ALUX built for AI agents?
An on-chain agent is naturally a Long Transaction. Calling an LLM or a tool takes time; waiting for a human response also takes time. The workflow cannot be forced into an instant, one-block call. ALUX lets it preserve execution context, suspend, resume when inputs arrive, coordinate concurrent agents, and finalize through replayable execution.
Is ALUX just another faster L1?
No. Faster L1s accelerate the same abstraction: one-shot state updates that happen within one block. ALUX is a decentralized concurrent runtime for Long Transactions that can wait, resume, join across multiple channels, or select whichever channel becomes ready first; their state updates are no longer constrained by a block boundary. Through its GLVM architecture—Virtual Machine Abstraction—the same logical transaction is designed to extend beyond block boundaries toward shard and system boundaries.
Some other chains also claim to support cross-block transactions. How is ALUX different?
The keyword is atomicity.
Compensation / Saga: commit → commit → ✗ fail → run compensating undo
Each step commits locally, intermediate states are visible, compensation can also fail, and external effects cannot always be reversed. This is eventual consistency. Some asynchronous chains, including ICP and Rialo, lean on this model. It is easier to implement, but unsuitable for applications that require stronger ACID guarantees.
ALUX all-or-nothing: stage → stage → ✗ fail → discard everything
Nothing commits until the whole transaction commits. On abort, uncommitted effects are discarded and no partial state becomes observable. That is true ACID atomicity across block heights.
How does ALUX keep Long Transactions deterministic?
ReplayTrie records the non-deterministic COMM choices that affect execution, enabling bit-exact deterministic replay inside the ALUX runtime so validators can reproduce the same execution outcome.
What is Object Capability (OCAP)?
Object Capability (OCAP) is a security model where the only way a piece of code can access a resource is by being explicitly given a reference (a capability) to that resource. In an OCAP system, the same object reference both identifies a resource (designation) and grants permission to use it (authorization).
Why is OCAP a stronger and composable security model?
Object Capability (OCAP) is a stronger security model because authority is represented by explicit, unforgeable capabilities rather than global identities or access control lists. It follows the principle that designation is authorization: possessing a capability both identifies a resource and grants permission to use it, eliminating ambient authority and reducing the attack surface. Because capabilities can be safely delegated, attenuated, and revoked, security policies become local to the objects involved instead of being scattered across a centralized permission system. This makes OCAP naturally composable, allowing complex applications, smart contracts, and AI agent workflows to be built from independently secure components while preserving the principle of least privilege.
What does it mean for OCAP to be natively supported in ALUX?
ALUX’s Tuple-Space Virtual Machine (TVM) implements the Object Capability (OCAP) model directly at the bytecode level. The instruction set contains no operations for forging or constructing arbitrary object references, ensuring that capabilities can only be acquired through explicit delegation. This guarantees that all authority is both unforgeable and explicitly transferred.
Can existing smart contract developers use it?
TVM runs EVM bytecode inside isolated sandboxes, so most EVM contracts can be migrated to ALUX with minimal changes. ALUX also presents an Ethereum-compatible view through a set of commonly used eth_* JSON-RPC methods.
