Cryptfancier

Hyperliquid built one of the strongest on-chain perpetuals markets in crypto. Its EVM layer, however, faces a different problem: how do you give developers more execution capacity without separating them from the liquidity, assets and market infrastructure that made #Hyperliquid valuable in the first place?
That is the gap Kinetiq is stepping into with Elysium, and it is the part of the announcement I find most interesting. As I dug deeper into the architecture, I became less interested in the headline throughput numbers and more interested in the economic design underneath them. Elysium is not simply trying to become another #Layer2 . It is trying to create more execution capacity inside the existing Hyperliquid economy.
Who Is Building Elysium?
Kinetiq already has an established position within Hyperliquid through kHYPE and its liquid-staking infrastructure. Elysium represents a significant expansion of that role, moving from infrastructure around $HYPE staking into execution infrastructure designed for applications that need substantially more capacity than HyperEVM can comfortably provide today.
HyperEVM's architecture deliberately keeps execution closely composed with HyperCore, but that design also creates a throughput trade-off. Elysium is intended to address that constraint by providing a higher-throughput EVM environment while preserving the connection to Hyperliquid's native settlement and market infrastructure.
For @kinetiq_research, that makes the move particularly interesting. The company is no longer positioning itself only around what happens to HYPE after users stake it. Elysium puts Kinetiq much closer to the applications, transactions and markets that could generate another layer of activity across the Hyperliquid ecosystem.
What Elysium Actually Changes
Three parts of the design stand out to me.
1. HYPE Becomes the Gas Asset
Elysium uses HYPE as its native gas token instead of introducing another token for transaction fees. That keeps the economic relationship between HyperCore, HyperEVM and Elysium much tighter.
Users are not being asked to learn another gas economy, while HYPE gains another utility beyond staking, collateral and trading. More importantly, the choice reflects the broader design philosophy: Elysium is meant to extend Hyperliquid rather than create a parallel economy beside it.
That is a subtle but important distinction for any #DeFi ecosystem. Adding an execution layer is easy to describe. Adding one without unnecessarily fragmenting the assets and liquidity around it is considerably harder.
2. More Execution Capacity Without Abandoning HyperCore
Elysium is designed as a high-performance EVM environment using the Arbitrum Orbit and Nitro stack, with a target of 300 Mgas/s and 100–200 ms blocks.
But speed alone is not the interesting part.
The more important question is what that execution environment can access. Elysium is designed to bring HyperCore market information deeper into the EVM environment, including order books, prices, balances and positions, alongside market data such as depth, flow imbalance and expected slippage.
This becomes particularly interesting for PropAMMs. Professional market makers could quote on Elysium while accessing HyperCore market data at high frequency, creating a tightly connected execution and hedging environment that is difficult to reproduce across completely separate chains.
Instead of treating HyperCore as a distant liquidity source that applications constantly have to synchronize with, Elysium is designed to reduce the distance between EVM applications and Hyperliquid's native market infrastructure.
For builders working on trading systems, PropAMMs and other latency-sensitive applications, that distinction could matter more than the raw throughput headline.
The interesting proposition is therefore not simply that Elysium is faster. It is that Elysium is designed to make higher-throughput execution and Hyperliquid-native market infrastructure work together.
3. A Complete Token Lifecycle
The third piece is the path from token creation to deeper liquidity.
The intended lifecycle allows a project to begin on Elysium, bootstrap activity through a long-tail AMM, move into deeper PropAMM liquidity, mirror its token through HyperEVM, and potentially progress into a HyperCore spot market and eventually a HIP-3 perpetual market.
That creates something more interesting than another token-launch chain. A project does not necessarily have to choose between an EVM environment and Hyperliquid's native market structure. The intended path connects the two.
Elysium therefore becomes part of a broader #Elysium lifecycle: launch and bootstrap activity on Elysium, move through HyperEVM, reach HyperCore spot infrastructure, and potentially progress toward HIP-3 perpetual markets.
The significance is easy to miss. Elysium is not being positioned as an isolated chain where projects must build their own liquidity universe from scratch. It is being designed as an entry point into a larger market infrastructure that already exists.
The Sequencer Fee Model Is the Real Story for KNTQ
The architecture answers the execution problem, but the sequencer-fee model answers a different question: where does the economic value created by that execution go?
The proposed allocation is straightforward. Fifty percent of Elysium sequencer revenue goes toward open-market KNTQ purchases, while 25% goes to builders and 25% to Kinetiq's treasury. The purchased KNTQ is then sent to the Hyperliquid Assistance Fund for permanent removal from supply.
That creates a direct relationship between network activity and KNTQ. More Elysium activity can generate more sequencer revenue, which can increase the capital allocated toward KNTQ purchases. The mechanism therefore creates a potential connection between network usage and token supply reduction.
That is what makes the #Kinetiq value-accrual argument worth examining.
But I would make an important distinction here: a value-accrual mechanism is not the same thing as guaranteed value accrual.
The mechanism is clear. Its eventual economic significance depends on adoption. If Elysium generates little activity, the resulting revenue will also be limited. If developers build on it, traders use it, market-makers deploy on it and transaction volume becomes substantial, the same mechanism has a much larger economic effect.
That is why I think the real story is not the 50% number by itself. The real story is whether Elysium can turn additional execution capacity into sustained economic activity.
Where I Would Push Back
Elysium is still pre-launch, and that distinction matters.
Kinetiq has published a technical design covering the execution stack, target throughput, block times, gas asset and settlement architecture. But those are specifications for a network that has not yet demonstrated those targets under production conditions.
The same discipline applies to HyperCore integration. The architecture is designed around deeper access to HyperCore state and, in later stages, the ability for applications to interact with HyperCore through the planned interfaces. Those capabilities should therefore be understood as part of the roadmap rather than treated as already-proven production infrastructure.
That does not invalidate the design. It simply means we should separate what Elysium is designed to do from what Elysium has already proven it can do.
A 300 Mgas/s target is interesting. 100–200 ms blocks are interesting. Native HyperCore connectivity is interesting. But none of those specifications become an economic advantage until developers and users actually put sustained demand through the system.
For me, that is not a weakness in the thesis. It is the test of the thesis.
The Bigger Experiment
Elysium is attempting to solve a very specific infrastructure problem for Hyperliquid.
HyperEVM provides the connection to the ecosystem. Elysium adds a higher-throughput execution environment. HyperCore provides the native market infrastructure. The token lifecycle creates a path from Elysium applications into Hyperliquid's deeper liquidity structure. And the sequencer-fee model attempts to route part of the resulting economic activity back toward KNTQ, builders and the treasury.
That creates a simple but important loop:
Give builders more room to work, and applications follow. Applications bring activity. Activity feeds the sequencer, and the sequencer feeds value back into the system it came from.
Whether that loop becomes meaningful will depend on what gets built on Elysium and how much activity it attracts.
That is ultimately what I will be watching.
Elysium does not need to prove that another Layer 2 can exist. It needs to prove that an additional execution layer can extend Hyperliquid's economic surface area without fragmenting the ecosystem underneath it.
If it succeeds, the interesting achievement will not simply be faster blocks. It will be turning additional execution capacity into additional economic activity while keeping that activity connected to Hyperliquid.
And that, in my view, is the real Elysium experiment.
Continue the discussion:
Official resources: kinetiq.xyz
X Thread: https://x.com/Cryptfancier/status/2101422783909499044

Imagine a company where anyone can propose a wire transfer. Marketing can request one, engineering can request one, HR can request one. But no matter who initiates it, the money does not move until it passes through a single approvals desk that applies the same checks every time. No department gets a side door. That is the basic idea behind NEAR AI's IronClaw 1.0: the agent can reason about what it wants to do, but the action itself must pass through a single coordination layer before it can execute.
That distinction matters because AI agents are moving beyond generating text and answering questions. They can browse websites, manipulate files, interact with external services, use credentials, send messages, and complete multi-step tasks on a user’s behalf. Once an agent can act in the real world, the challenge is no longer simply whether its underlying model is intelligent enough. It is whether the infrastructure surrounding that model can reliably control what it is allowed to do.
The Architecture: Separating Thinking from Acting
#IronClaw 1.0 takes a fundamentally different architectural approach. Rather than allowing reasoning, execution, memory, secrets, and tools to operate as tightly coupled components, it separates the reasoning layer from the execution layer and places a single coordination point called the “guard” between them. Every action, regardless of which capability initiated it, must pass through that checkpoint before execution.
The significance of that design is easy to underestimate. When safeguards are implemented independently across different tools and capabilities, every new feature creates another place where those controls have to be implemented correctly. A centralized guard creates a common enforcement path instead, allowing the same permission and safety logic to govern actions across the system. In practical terms, the architecture is closer to Think ➔ Guard ➔ Act than the conventional Think ➔ Act model.
The architecture also addresses a less obvious problem: continuity. IronClaw uses continuous checkpointing so an interrupted task can resume from its previous state rather than forcing the agent to start over. If a workflow pauses while waiting for approval, encounters a restart, or is interrupted midway through execution, the progress already made can be preserved and the task resumed from its last checkpoint.
Benchmarks: Performance Across Different Failure Surfaces
Architecture alone is not enough. An agent can be extremely cautious and still be practically useless if it cannot complete the tasks it is given. Using the same deepseek-v4-flash base model across the comparisons, #IronClaw currently leads three different agent benchmarks, each testing a different dimension of real-world performance.
On PinchBench, #IronClaw scores 93.5% across 147 practical tasks covering scheduling, email triage, coding, research, and file management. On ClawBench, which evaluates multi-step interactions across more than 140 live production websites, it records 88.6%. OfficeQA tests grounded reasoning over a large corpus of U.S. Treasury Bulletins spanning nearly a century, 89,000 pages, and more than 26 million numerical values; IronClaw scores 76.4%.
These benchmarks stress different capabilities: PinchBench emphasizes practical task completion, ClawBench introduces the unpredictability of live web environments, and OfficeQA tests reasoning over complex documents and numerical information. Leading across all three suggests that performance is not solely a function of the underlying model; the agent harness and architecture surrounding it are contributing meaningfully as well.
From a Demo to a System People Can Actually Use
The architecture becomes more compelling when paired with the controls designed for real-world use. IronClaw can require explicit approval before sensitive actions execute, rather than allowing an agent to act first and explain itself afterward. It also supports single-use secrets that can be scrubbed from logs after use, reducing the amount of sensitive information that persists within the system.
The same philosophy extends to memory and collaboration. IronClaw maintains consistent memory and safety rules across CLI, web, Slack, and Telegram rather than treating each interface as an isolated assistant. For organizations, team isolation allows tools and skills to be shared while keeping individual workspaces private by default, alongside a fully isolated single-tenant option for teams that require stronger separation. @NEAR Protocol and #NEARAI are already running IronClaw internally across their teams, giving these design choices a practical testing ground beyond a product demonstration.
Where NEARAI and Staking Fit
A capable agent still needs inference, compute, and reliable infrastructure to operate continuously. This is where #NEARAI enters the picture. Rather than treating AI compute as an entirely separate service paid for through conventional infrastructure contracts, NEAR AI connects access to AI services with participation in the NEAR ecosystem through its staking model.
For agent hosting, the structure uses a fixed ratio: staked NEAR ÷ 100 equals the monthly credit budget in dollars. Stake 500 NEAR and you receive $5 in credits every month for as long as the tokens remain staked. The Starter tier begins at 50 NEAR and activates the first IronClaw agent, while higher tiers unlock larger credit allocations and additional parallel agents. The underlying NEAR is not consumed; it remains the user’s asset.
Confidential inference works differently. Here, the staking rewards generated by the user’s position (current network APY sits around 4.5–4.7%) are directed toward NEAR AI in exchange for compute credits rather than being paid out as income. The principal stays under the user’s control and can be unstaked through the normal protocol process. The broader infrastructure also provides access to models from providers including Anthropic, OpenAI, and Google.
Importantly, staking on NEAR is not just about yields. It secures the underlying decentralized infrastructure that these AI agents, including the upcoming OpenClaw will rely on. By tying access to compute with network participation, #NEARAI creates a tighter relationship between securing the network and powering the applications that run on it.
The Bigger Picture
This is ultimately why #IronClaw 1.0 is more interesting than another announcement about a more capable AI agent. The important shift in autonomous AI is not simply that models are learning to do more. It is that the infrastructure around those models is beginning to treat autonomy as a systems problem involving permissions, execution, memory, recovery, isolation, and compute rather than intelligence alone.
IronClaw addresses that problem at the execution layer by separating reasoning from action, routing actions through a centralized guard, preserving state through interruptions, controlling sensitive operations, and maintaining consistent safety rules across different interfaces. #NEARAI addresses another part of the stack by connecting AI compute access to decentralized network participation and providing infrastructure that agents can actually run on.
Taken together, these pieces point toward a broader direction for AI infrastructure. The future of autonomous agents may not be determined simply by how much a model can accomplish without human intervention, but by how reliably the systems around that model can constrain its actions, recover when something goes wrong, preserve context over time, and provide the infrastructure required to keep it running.
Smarter agents are only one part of the equation. The more consequential challenge may be building the infrastructure that makes those agents trustworthy enough to act.
You can read on this on 𝕏: https://x.com/Cryptfancier/status/2096337705550434561
Sources
╰─➤ Introducing IronClaw 1.0 (NEAR AI Blog): https://near.ai/blog/introducing-ironclaw-1-0
╰─➤ Staking for NEAR AI (NEAR AI Blog): https://near.ai/blog/staking-for-near-ai
╰─➤ NEAR Protocol official announcement: https://x.com/NEARProtocol/status/2082875217995796606
╰─➤ IronClaw GitHub repository: https://github.com/nearai/ironclaw
╰─➤ NEAR AI Private Inference documentation: https://docs.near.ai/cloud/private-inference
╰─➤ Staking Rewards – NEAR live yield data: https://www.stakingrewards.com/asset/near-protocol