Altlayer
Altlayer provides infrastructure for custom rollups and on-chain agents
Altlayer combines managed rollup deployment with tools for discovering agents, accessing AI models, and connecting automation to blockchain applications. A rollup executes transactions outside its settlement chain and submits data or commitments under its chosen architecture. Its Rollups-as-a-Service offering supports custom deployments, while restaked services address verification, sequencing, and faster confirmation. The agent products cover different jobs: identity through 8004scan, model access through AltLLM, and DeFi interaction through AltClaw.
Dedicated Execution or an Agent on Existing Infrastructure
A custom rollup fits an application needing control over its execution environment, gas configuration, or infrastructure. An agent integration fits software needing to interpret requests and interact with blockchain services. Creating an agent doesn’t inherently require deploying a new chain.
Rollups-as-a-Service, shortened to RaaS, handles deployment and management of configured rollup infrastructure. Agent discovery, model access, and transaction tools operate at the application level. A deployment can use both categories, although their requirements remain separate: chain configuration determines execution behavior, while agent configuration determines available capabilities and permissions.
What Must Be Defined Before Deploying a Rollup?
A rollup deployment needs a compatible execution stack, settlement arrangement, data availability configuration, and operating permissions. These choices determine what the network can execute and how other systems assess its state.
The configuration also needs to distinguish application access from infrastructure administration. Control over upgrades, transaction submission, and service operation can involve different permissions.
Once infrastructure exists, its chain ID and RPC endpoint identify the network applications can contact. RPC means remote procedure call, the interface software uses to request blockchain information or submit transactions. An endpoint’s existence alone doesn’t establish healthy block production or successful settlement.
A deployment record should preserve the selected configuration alongside its network identifiers. That record makes later endpoint, contract, and environment mismatches easier to recognize.
Execution Stack and Data Availability Choices
The execution stack and data availability layer perform different jobs. The selected execution stack must support the chosen data availability configuration.
Execution Stack
RaaS supports OP Stack, Arbitrum Orbit, and ZK Stack. These are distinct software frameworks for building chains, with different architecture and configuration requirements. Support for several frameworks doesn’t make their deployments interchangeable. Contract tooling, proof arrangements, and settlement behavior follow the selected implementation.
Data Availability
Data availability concerns access to the data needed to verify a chain’s operation. The RaaS offering names EigenDA, Celestia, Avail, and NEAR DA among its supported options. A supported provider list doesn’t establish that every provider works with every stack or deployment configuration.
Settlement determines where commitments become authoritative under the deployment’s rules. Data availability determines how the necessary data remains accessible. Treating these as separate configuration choices avoids assuming a chain inherits identical guarantees merely because it uses familiar software.
Does Faster Confirmation Mean Settlement Is Complete?
Faster confirmation doesn’t automatically mean settlement is complete. MACH supplies a fast finality service for rollups, while the underlying settlement system has its own acceptance rules.
MACH evaluates rollup state validity before its network reaches agreement. Its documented designs include re-executing transactions and assessing proofs, with the applicable mode determining what operators verify. This economic confirmation differs from a sequencer’s initial acknowledgment, which indicates an earlier point in transaction processing.
A receiving application needs the confirmation its own rules accept. A status accepted locally may be insufficient for a bridge or settlement contract.
Time-sensitive applications therefore need an explicit policy for the confirmation they consume. A faster signal can support earlier application responses without changing another system’s withdrawal conditions. No single confirmation duration describes every deployment, proof mode, and receiving contract.
Restaked Services and Their Separate Responsibilities
Restaked rollups use operator services backed through EigenLayer’s restaking framework. An actively validated service, or AVS, assigns operators a particular verification or infrastructure task. The design separates those tasks rather than treating security as one interchangeable feature.
VITAL State Verification
VITAL checks proposed rollup states. Its design allows operators to challenge invalid state roots, including through dispute procedures or proof-based verification. A state root is a compact commitment to blockchain state. The applicable verification mode determines how an operator establishes whether that commitment reflects valid execution.
MACH Confirmation
MACH addresses faster confirmation backed by operator participation and economic security. Applications integrating it need to understand the deployed validation mode and acceptance conditions. The existence of MACH in the product family doesn’t establish that a particular rollup has enabled it.
SQUAD Sequencing
SQUAD addresses decentralized sequencing: accepting transactions, ordering them, and coordinating the operators performing that work. Its documented design matches rollup requirements with participating sequencers and collateral conditions. A configured operator requirement has to be met before the corresponding sequencing arrangement can operate.
What Does an Agent Registry Entry Establish?
An agent registry entry establishes an identifiable record and associated metadata. It doesn’t establish that every advertised capability works or every response is correct.
8004scan supports agent discovery and registration using ERC-8004. Its explorer exposes agent listings, capabilities, and feedback. These records help applications identify an agent and inspect its declared services before integrating them.
ERC-8004 defines an agent identity registry based on ERC-721. The specification separates identity from reputation and validation records. Its draft status matters for integrations because implementations need to match the interfaces they actually support.
An agent’s identity includes the chain, registry contract, and assigned agent identifier. A display name alone isn’t sufficient to distinguish records. Metadata describes the service, while an operational endpoint determines whether that service can respond. A registration can remain visible even when the associated application is unavailable.
Model Access Through AltLLM
AltLLM provides AI model access through a shared chat interface and API. An API lets an application request model output programmatically, while chat supports direct interaction. The product also supports agent deployment and connection to on-chain actions through AltClaw.
Model access and transaction authorization remain separate responsibilities. A generated response can describe an operation without authorizing or executing it. Applications need to distinguish text generation, tool selection, and the blockchain transaction a tool may submit.
Model usage consumes the applicable service credits, while blockchain activity follows the transaction charges of the network involved. A model subscription doesn’t by itself establish payment for all downstream blockchain operations.
DeFi Execution Through AltClaw
AltClaw connects AI software with DeFi operations through the Model Context Protocol, or MCP, and private RPC infrastructure. MCP exposes tools and context applications can use. AltClaw’s product scope includes swaps, lending, and staking workflows.
Private transaction routing addresses exposure during submission. It doesn’t determine whether a requested operation is economically sensible, whether a contract call matches the intended action, or whether the receiving contract will accept it. Those questions concern the operation and its permissions.
Execution permissions should match the intended contract operations and assets. An agent able to read protocol information has different authority from one able to sign transactions. Private keys and service credentials don’t belong in publicly accessible agent metadata.
Payment Confirmation Before an Agent Service Responds
An x402-enabled service can use the hosted facilitator to verify a payment payload and submit payment for settlement. Verification checks whether the payload meets the service’s declared requirements. Settlement establishes whether the payment reached the blockchain successfully.
Consider an agent requesting a service that releases its response after payment settlement. The server declares the payment requirements, the client supplies the signed payment payload, and the facilitator returns verification and settlement results. A successful settlement result allows the server to release the requested response under that policy.
If verification succeeds while settlement remains unresolved, the server withholds the response under its settlement-before-release policy. The request remains pending until settlement can be established. A delayed response alone doesn’t prove payment failed, so repeating the charge requires reconciling the existing payment first.
- Confirm the requested payment uses a network and asset the configured facilitator supports.
- Match the signed payload to the server’s declared payment requirements.
- Release the response when the required settlement result establishes payment.
- Keep an unresolved payment pending instead of treating verification as settlement.
- Reconcile the existing payment before requesting another charge.
The completed exchange has both a settled payment and the requested service response. Blockchain confirmation alone doesn’t establish that the application delivered its output.
ALT Staking as a Separate Participation Path
ALT staking is a token participation path distinct from deploying infrastructure or registering an agent. The documented staking arrangement uses ALT on Ethereum, with reALT representing a restaked share token. This token activity doesn’t itself deploy a rollup or grant an agent application permissions.
Token approval authorizes a staking contract to use tokens; approval alone doesn’t establish a staked position. The staking and conversion operations determine the position recorded by the contracts. Displayed rewards depend on the applicable staking arrangement, so a quoted yield shouldn’t be treated as a permanent protocol property.
Withdrawal also has its own conditions. The documented process includes conversion where required, cooldown, and redemption. Tokens undergoing cooldown don’t earn rewards during that period. A withdrawal request and a returned wallet balance therefore represent different states.
Persistent and Ephemeral Rollups
Persistent rollups support continuing operation, while ephemeral rollups serve workloads with a planned end. The ephemeral design includes an end-of-life settlement rather than simply switching off infrastructure. That distinction affects how an application preserves its final state and what users can access afterward. The documented ephemeral architecture commits its closing state to a settlement chain such as Ethereum.
Altlayer questions, answered
Can an ERC-8004 Agent Identity Change Owners?
An ERC-8004 identity can transfer ownership through its ERC-721 representation. Ownership of the registry token identifies the owner of that agent record. Transferring the record doesn’t automatically transfer every external dependency, such as hosting access or API credentials. Those operational arrangements require separate handling.
Do I Need ETH When Staking ALT?
ALT staking on Ethereum requires ETH for transaction gas. ALT is the asset being staked, while ETH pays the network charges for relevant approvals and contract operations. The required gas amount varies with transaction execution and network conditions; an ALT balance alone doesn’t cover it.
Which Virtual Machines Does the in-house Rollup Stack Support?
The in-house rollup stack supports EVM and WASM execution. EVM means Ethereum Virtual Machine, while WASM means WebAssembly. This describes the in-house architecture, rather than promising both runtimes in every managed deployment. A deployment using another rollup framework follows that framework’s runtime and tooling requirements.
Are Agent Payments Part of ERC-8004?
Payments are outside ERC-8004’s scope. The specification addresses agent identity, reputation, and validation, while payment protocols handle payment requirements and settlement. An application can combine ERC-8004 identity with x402 payments without treating registration as proof that a request has been paid.
What Determines the Cost of Using AltLLM?
AltLLM costs follow the selected plan and its credit-based usage terms. Plans differ in included credits, agent hosting provisions, and support. Model usage and included services should be assessed together, since access to a model doesn’t mean every associated agent workload has the same resource requirements.
Is a Custom Rollup Automatically Part of the Superchain?
A custom rollup doesn’t automatically become part of the Superchain merely by using OP Stack. The RaaS offering describes Superchain participation as an opt-in arrangement. Stack selection establishes the software foundation; membership and shared interoperability depend on the applicable configuration and participation requirements.