An open letter to @vladtenev and the @AskRobinhood team
Dear Vlad,
We’ve committed 15.36 billion gas and 0.3248 ETH to deploying 500 GH0ST contracts on Robinhood Chain, putting model weights and an inference runtime on-chain.
With Solidity, our locally validated “Hi” → “Hello!” inference used 33.89 billion gas across 1,546 continuation transactions. That is a measured local benchmark; a paid public chat has yet to run.
We’ve also built and locally tested a Rust/Stylus computation kernel. But our recorded network checks show new Stylus activation is paused, blocking the next stage.
How much could we save? We cannot honestly give a percentage before benchmarking Stylus. For scale, a hypothetical 10× reduction in total inference gas would bring that benchmark to 3.39 billion gas—saving 30.50 billion, or 90%, per equivalent run. That is an illustration, not a measured result. Deployment gas already spent cannot be recovered.
@vladtenev@RobinhoodApp, please help us enable Stylus activation, or give us a clear path to access. We’re ready to share our code, measurements and activation diagnostics.
We’ve funded the work to get this far. Please help us measure what comes next.
The GH0ST team
$GH0ST : 0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559
https://t.co/aWjTGeXJmB
GH0ST Research Update: Authenticated Calldata for Onchain Model Weights
We investigated whether changing the storage architecture could reduce the upfront gas required to publish Qwen3-0.6B while retaining the same compressed weights.
Our reference export contains 596,049,920 distinct parameters after lossless deduplication of identical embedding and output matrices. With groupwise 4-bit quantization and associated metadata, the serialized model occupies 307.580 MB.
Deploying this payload across weight-bearing contracts requires approximately 66.736 billion gas under our deployment model. We therefore evaluated an alternative: publishing the weights through transaction calldata and storing a Merkle commitment in a registry contract.
Calldata carries the input bytes of a transaction. Unlike deployed contract bytecode, those bytes do not become persistent, directly readable model storage for subsequent contract calls.
During inference, a requester supplies the required weight chunks alongside Merkle proofs. The execution contract verifies that each chunk belongs to the committed model before using it in computation. A provider cannot substitute different weights without failing verification, assuming the security of the hash function and correctness of the implementation.
The initial prototype produced the following results:
• Modeled publication cost, including registry deployment: 12.417 billion gas.
• Approximately 81.4% lower upfront gas than the calculated contract-storage deployment.
• 3,129 publication transactions.
• Three locally measured publication transactions.
• Nine negative checks covering incorrect data, incorrect indices and duplicate publication—all rejected.
The complete publication total is an extrapolation from exact serialized transaction data and sampled execution costs. It is not the sum of receipts from a full deployment. The local accounting includes an observed EIP-7623 calldata floor; Robinhood mainnet accounting requires separate validation.
The saving comes from changing how weights are published, not from further compressing the model. The Q4 payload remains identical. This preserves the existing quantized representation, not the original model’s full numerical fidelity.
The principal trade-off is recurring access cost. EVM contracts cannot directly retrieve historical transaction calldata. An external client must obtain and resubmit the relevant bytes and proofs for inference. Verification protects integrity; it does not guarantee data availability.
Consequently, lower publication gas does not establish cheaper inference. Weight resubmission, proof verification, numerical computation and intermediate state management must all be included in an end-to-end benchmark.
This is an experimental architecture for authenticated model-data delivery to onchain computation. It is less self-contained than contract-resident weights. A complete inference runtime has not yet been validated for this approach, and this Qwen prototype has not been deployed publicly.
0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559
Research and reproducible results:
https://t.co/vFNVo4hdyf
@CharmLama TBH without the stylus support each message will cost multiple ETHs worth of Gas , Waiting for @RobinhoodApp to optimise Stylus support on chain before deploying more llms and doing testings on chain
Our First Research Paper Abstract
20 models under 1B parameters. Each gets a 20-minute optimization run and its own GitHub branch.
10 runs finished:
• 4 complete reports with quality checks and local EVM kernel gas measurements
• 6 awaiting gas-report finalization
• 1 model running
• 9 queued
Completed reports: Qwen3-0.6B, Qwen3-0.6B-Base, LFM2-700M and LFM2-350M.
We hit dependency and connection issues in gas reporting. Recovery has been relaunched; the optimization results are preserved.
Progress goes to GitHub every 10 minutes—including failures and experiments that find no improvement.
https://t.co/aWjTGeYhc9
Read the full report at https://t.co/ceG8COzNx1
0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559
$GH0ST is a research project aiming to run a language model (LLM) fully on-chain with model weights stored in smart contracts and inference performed by the contracts themselves (described as “0-offchain”).
The core idea is to make an AI model and its inference live entirely as blockchain infrastructure rather than relying on off-chain servers.
This would make the computation transparent, verifiable, and reproducible alongside any on-chain actions an agent might take.
The project has deployed 500 contracts containing quantized model weights, a matrix kernel, an address index, and a resumable inference runtime.
Going into locked-in mode for a while.
Less posting. More building.
We're pushing GH0ST further, optimising on-chain inference, reducing gas costs, and testing how far we can take this.
You can follow our ongoing experiments, optimisations, and progress directly on GitHub:
https://t.co/aWjTGeYhc9
Back to work. 0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559 [0_0]
@DMX7227@llmgh0st NARRATIVE: REAL 82 · COIN: NOT CHECKED
The burn is real: 4,000,000 GH0ST (0.4% of supply) went to the dead address on Robinhood Chain; the wider AI…
No coin checked. Before buying anything tied to this, tag me with its CA for the narrative AND the coin.
https://t.co/hfWndMYLuN
We measured Qwen’s 4-bit matrix computation in Solidity versus Stylus on the same local Nitro chain.
32 × 896 tile:
348,115 → 131,210 gas — 62.31% saved.
32 × 4,864 tile:
1,754,413 → 457,000 gas — 73.95% saved.
Real Qwen weights. Identical inputs. All eight test cases matched the integer reference exactly.
Stylus activation added 3.48 million gas upfront. These are matrix benchmarks, not full-response costs or Robinhood mainnet measurements.
A measured step toward more affordable onchain inference.
0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559
https://t.co/X5fxGxePDH
For those who are wondering whats Stylus
Solidity runs GH0ST’s computation through the EVM. Stylus lets Rust/WASM contracts work alongside Solidity, potentially reducing the cost of intensive AI computation.
Robinhood Chain already exposes Stylus version 3, but our latest mainnet check indicates new program activations are paused.
An authorised network change could reopen activation, allowing us to benchmark GH0ST’s inference using Stylus.This is where we have to pray for @vladtenev s help
The potential is substantial.This will cut the deployment gas to 10% of what it is now 0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559
GH0ST research update: initial results for Qwen2.5-0.5B-Instruct.
We exported the 494-million-parameter checkpoint using 4-bit affine matrix quantization, producing a 254.85 MB container with shared embedding/output weights stored once.
Local EVM optimisation reduced gas for a tested 32 × 4,864 matrix tile from 3,570,179 to 1,754,425—a 50.86% reduction. A subsequent 100-configuration sweep produced no additional improvement.
Validation included 1,020 synthetic arithmetic comparisons and 15 real-weight matrix checks, all matching the integer reference exactly.
However, numerical correctness of execution does not establish preserved model capability. With quantized weights and FP32 activations, perplexity on three short diagnostic texts increased from 54.41 to 79.60. An arithmetic prompt answered correctly by the baseline also failed after quantization.
These preliminary findings demonstrate efficient, exact execution of quantized matrix operations while identifying model-quality preservation as an unresolved constraint. Full onchain Qwen inference remains unvalidated.
Next: activation-aware calibration, quantization sensitivity analysis and broader held-out evaluation.
Code, methods and results:
https://t.co/Q4kcr30von
0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559