Answers,
Not Marketing.

Infrastructure for useful machine work. ExergyNet gives AI systems a model-independent way to hold authoritative state, measure the resource cost of a validated task, and interoperate across administrative boundaries — so an agent's institutional record survives a model swap, a session restart, or a change of vendor.

No. ExergyNet is model-independent by design — it sits alongside whatever model or provider you already use (OpenAI, Anthropic, a local Nemotron deployment, or a future model you haven't adopted yet) and does not require switching. See What ExergyNet Does Not Require.

In your own systems. ExergyNet does not require migrating your data off your infrastructure. It draws a distinction between context (what a model is shown for one task), memory (a local recall layer, e.g. VMN), and authoritative state (the externally maintained record your organization treats as canonical) — and is built to hold the third without displacing systems you already run.

H200 campaign (single NVIDIA H200, Nemotron-class model, corpus 8K–285K): xLMP held staged prompt cost roughly flat (~660–820 tokens) as the corpus grew, showed a 24.4-point accuracy advantage over a tested RAG baseline at equal evidence budget, and reached roughly 11.3× the correct-task throughput of full-context replay — all bounded, tested-envelope results.

A100 corpus scaling campaign (4× A100-SXM4-40GB, TP=4, NVIDIA NIM, corpus 32K–4M): Across nine development points plus a sealed 5-rep holdout, a 125× increase in corpus size produced no detected material positive global scaling of mean active model-facing context. Local K upturn from the 1M trough through 2M and 4M is disclosed and measured. Retrieval work scaled approximately linearly. These two campaigns are separate experiments on separate hardware and must not be merged.

Full detail on Benchmarks.

ExergyNet coordinates externally defined authority. It does not originate institutional authority, does not decide your organization's policy, and a consequential action is constrained only where the applicable enforcement boundary is actually present and active — never as a blanket guarantee. Full detail on Security.

Bring a bounded, state-heavy workload and we measure ExergyNet/xLMP against your own already-optimized baseline — not against an intentionally expensive replay architecture. See Design Partnership.

Deployed, recommended path (not yet routing real capital): LNES-04 on Base L2 is the recommended settlement layer for new integrations. The Base Mainnet contract is deployed but currently operating in mock-only mode — do not route real capital through it yet. Base Sepolia is available for test and demonstration use today. Execution-state portability is validated for same-process restoration and short fresh-process continuity.

Deployed, under investigation: LNES-03 on Solana has settled successfully before but is currently under active investigation for transaction failures — see verification status.

In development / not yet achieved: production-scale zero-knowledge verification in the evidence-query path; live real-capital settlement on Base Mainnet; medium- and long-context fresh-process continuity (0/10 in tested runs); cross-node execution-state portability (not yet reported).

Agents that persist across sessions, models, or organizations need somewhere authoritative to keep state and a way to prove a piece of work actually happened. Running heavy verification logic directly on-chain is expensive; relying on a single centralized API for that record requires blind trust in that one vendor. ExergyNet lets agents outsource verification and settlement with a checkable proof before any consequential action is taken.

Through the MCP Neural Gateway and SDKs. Agents can call estimateExergyGate to determine profitability, then programmatically execute an open_job transaction if conditions are favorable. See developer docs.

LNES-03 is the Solana Mainnet-Beta deployment. LNES-04 is the Base L2 (EVM) deployment. LNES-03 is deployed and has settled successfully before, but is currently under active investigation for transaction failures — see verification status. Base Mainnet USDC is the primary and recommended settlement layer for new integrations.

Through ZK-STARK proofs. Any alteration of logic invalidates the proof, the smart contract rejects invalid proofs, and dishonest nodes receive zero yield.

No — reasoning and authorization are architecturally separate. In a live test, a reasoning model partially complied with a prompt-injection payload; the deterministic validation layer rejected the request outright before any signed review could be produced, reproduced twice. Full result on Security.

No. ExergyNet is execution infrastructure for machine intelligence — the layer that turns model outputs into state-aware, authorized, attributable, verifiable actions. It has optional settlement and proof subsystems (LNES-03 on Solana, LNES-04 on Base L2) for verifiable compute use cases, but these are supporting mechanisms, not ExergyNet’s primary category. Settlement and blockchain rails are available where economic finality is needed; they do not define what ExergyNet is. The primary architecture is: Persistent State (Exergy Vault / xLMP) → Bounded Evidence → Reasoning (Vanguard) → Authority (xISA / LNES-22) → Verified Action → Evidence → Settlement where required.

HISTORICAL ARCHITECTURE — Proof-of-Exergy belongs to an earlier ExergyNet architectural generation. The current ExergyNet architecture does not describe its primary operation as a consensus protocol.

Proof-of-Exergy (PoX) was an early ExergyNet consensus design in which hardware-bound compute work, verified via ZK-STARK proof (RISC Zero zkVM), replaced synthetic hashing (Proof-of-Work) or capital-staking (Proof-of-Stake) as the proof-of-participation mechanism. See the Protocol page for historical details and the current architecture overview for the live component map.

Pricing depends on the integration path. The LNES-03 Solana settlement path (under investigation for transaction failures) used 0.002 SOL per cycle. The LNES-04 Base L2 path uses USDC-denominated tolls — see the API Integration guide for current configuration. Vanguard API and Omega Carrier usage is metered through your portal account balance (USDC-denominated). See verification status for current LNES-03 and LNES-04 operational state.

LEGACY TOKEN — $EXG was the internal accounting token for the LNES-03 Solana settlement subsystem. Current portal economics use USDC-denominated account balances.

$EXG was a transient internal accounting token used with the LNES-03 Solana settlement path. It was minted when capital was locked and burned upon successful settlement — never tradable, no speculative value. The current ExergyNet Portal uses USDC-denominated account balances (micro-USDC) for Vanguard API, Omega Carrier, and agent economics. RHO is the protocol-layer accounting concept for certain settlement pathways — it is not a stablecoin, not USD-redeemable, and has no canonical market price. See Token Info for the historical LNES-03 accounting model.

In the Solana LNES-03 model, 30% of every toll was routed atomically to the node operator’s wallet upon successful proof verification. The Base LNES-04 model uses an equivalent USDC operator split. See the Compute Partner Access page and verification status for current settlement liveness on each path.