Understand the mission.
Build with conviction.

AutoHash

Meme energy. Machine intelligence. Research with receipts.

AutoHash aims to become the first memecoin to solve Zooko’s HashSmash challenge using AI agents. First place and a solved challenge are ambitions, not verified achievements. AutoHash is independent; no endorsement by Zooko, HashSmash or Zcash is implied.

What works in the implementation

• A responsive website with mission, agent registry, launches, research frontier, activity and documentation.
• A Solana Token-2022 transaction builder: wallet signing, fixed supply, six decimals, on-chain metadata and revoked mint authority.
• A Node.js launch service that checks finalized chain evidence before adding an agent to its SQLite registry.
• Persistent launch records, activity and completed research plans, retrieved through same-origin API requests.
• An operator-only OpenAI Responses integration for research planning. It does not execute experiments or trade.
• A searchable browser handbook at /developers/ and a product documentation category at /docs/.

Verification and availability

Implementation is not the same as production validation. A funded wallet end-to-end launch has not been verified. OpenAI credentials and a successful paid provider request have not been established. An unconfigured service must show its real unavailable or empty state. There are no accepted HashSmash claims, liquidity pools, live trading, automatic research funding or universal model compatibility in this release.

The legacy paper runtime and EVM contracts are retained for historical development work. They are separate from the Solana launch path and do not power the public registry.

Start here

Use Node.js 24 or later and the pinned pnpm version in package.json. pnpm-lock.yaml is canonical.

pnpm install --frozen-lockfile
pnpm dev

For a complete same-origin local setup, build the site and serve it with the launch service as described in Getting started. Static files alone cannot run API endpoints.

pnpm check

The check script runs lint, TypeScript, legacy runtime tests, launch tests and the production export. The build also generates the handbook. Solidity compilation is a separate legacy command, not part of the current check script.

Documentation

• Getting started
• Solana launches
• Architecture
• Launch API
• OpenAI research
• Research evidence
• Deployment and operations
• Troubleshooting
• Security and Contributing
• Historical reference: paper runtime, model manifests, EVM contracts

Documentation ships with the website. Publishing to a separate GitHub repository is not a release requirement.

Project map

src/app/                       Product pages
src/components/sites/autohash/ UI, network state and wallet launch flow
src/lib/solana-launch.ts        Solana transaction construction
runtime/launch-server.mjs      HTTP API and OpenAI research planner
runtime/launch-service.mjs     SQLite registry and chain verification
runtime/server.mjs             Separate legacy paper runtime
contracts/                     Legacy EVM development artifacts
public/sites/autohash/          Brand and agent images
docs/                          Handbook source chapters
scripts/build-docs.mjs          Searchable handbook generator
out/                           Static production output

License

The existing MIT license applies to the code; preserve its copyright notice. The project began with the AI Website Cloner Template. Supplied brand assets and reference-site designs have separate rights; do not assume code licensing grants rights to third-party branding.

Getting started

Requirements

Use Node.js 24+ for built-in SQLite and the pnpm version pinned in package.json. pnpm-lock.yaml is the canonical dependency lock. Install from the repository root:

pnpm install --frozen-lockfile
pnpm build

Run the complete local site

The Next.js project exports static files to out/. Its API runs in a separate Node service. Serving the export through that service gives the browser one origin for both pages and API requests.

Create an uncommitted local environment file named .env.launch.local:

AUTOHASH_PUBLIC_ORIGIN=http://127.0.0.1:8788
AUTOHASH_STATIC_ROOT=out
AUTOHASH_LAUNCH_PORT=8788
AUTOHASH_SOLANA_NETWORK=devnet
AUTOHASH_LAUNCHES_ENABLED=false
AUTOHASH_LAUNCH_DB=runtime/data/launches-devnet.sqlite
AUTOHASH_DAILY_RESEARCH_RUNS=0

node --env-file=.env.launch.local runtime/launch-server.mjs

Open http://127.0.0.1:8788. The API is available at /api/status. The launch server binds only to 127.0.0.1. Environment files are not automatically read by pnpm launch:start; pass --env-file explicitly or configure your shell/service manager.

The disabled launch setting lets you inspect the site without enabling draft creation or RPC submission. To test a wallet launch, deliberately set AUTOHASH_LAUNCHES_ENABLED=true on devnet and restart the service. A compatible wallet needs devnet SOL. The interface reports the service network and waits for finalized verification before listing the agent.

Develop the UI

pnpm dev

Next development runs at http://localhost:3000. Without a same-origin API proxy, network-backed screens will report service unavailable. This is expected and should not be replaced with fabricated records. Use the complete exported setup above to verify real API integration; rebuild after UI edits.

Research planning

To enable operator-triggered planning, configure OPENAI_API_KEY, AUTOHASH_ADMIN_TOKEN and a nonzero AUTOHASH_DAILY_RESEARCH_RUNS. See OpenAI research. Never use a browser-visible environment variable for either secret. Provider configuration is not proof that the configured model is available to the account.

Checks

pnpm lint
pnpm typecheck
pnpm runtime:test
pnpm launch:test
pnpm build

pnpm check combines these checks. Passing them does not prove a funded wallet launch, paid model request, third-party wallet compatibility or production security. Documentation-only changes can use pnpm docs:build followed by a browser review.

Legacy experiments

pnpm runtime:start starts the independent paper runtime on port 8787. It is not required by the Solana launch service. Do not expose its endpoints as the public launch API. Historical examples and their limitations are in Legacy runtime.

Solana launches

Transaction design

AutoHash uses Solana Token-2022, not the legacy EVM contracts. One wallet-signed transaction creates a mint with a metadata pointer, initializes a six-decimal token, stores its name/symbol/metadata URI, creates the creator’s associated token account, mints the fixed supply and revokes mint authority. Freeze authority is never enabled. The creator retains metadata update authority.

Supply is a whole number between 1 and 1,000,000,000 tokens. The frontend creates an ephemeral mint key in memory and partially signs the transaction. The wallet signs as fee payer and creator. No wallet secret is sent to AutoHash.

Launch sequence

• Connect a compatible injected Solana wallet, including Phantom.
• Choose the name, symbol, supply and research target.
• Save a draft to the launch service. Its metadata URL is persistent and public.
• Review the network, estimated rent/network fee and token settings.
• Sign and submit in the wallet. Wallet approval is the transaction authorization.
• Retry verification until the transaction is finalized. This does not mint another token.

The launch service independently checks the finalized transaction, creator and mint signers, mint creation instruction, Token-2022 ownership, supply, decimal count, disabled mint/freeze authorities and matching on-chain metadata before listing the agent.

Network and fees

The service defaults to devnet. Test tokens and test SOL are explicitly identified. Mainnet requires AUTOHASH_SOLANA_NETWORK=mainnet-beta and deliberate operator enablement with AUTOHASH_LAUNCHES_ENABLED=true. Configure a production RPC provider before public traffic.

There is no AutoHash platform charge in this flow. Rent and network fees are paid in SOL. A token mint is not a liquidity pool, bonding curve, exchange listing or functioning trading strategy. This implementation does not route launch fees or research contributions.

Recovery

After submission, the browser remembers the public draft ID, mint, signature and network. Reloading offers verification rather than a second launch. If the wallet rejects signing, no transaction is submitted. If submission returns an ambiguous transport error, inspect wallet history and Solana Explorer before creating another token; the service cannot guarantee recovery of a signature it never received.

Metadata is served by AutoHash, so keep the domain and SQLite database available and backed up. This is not permanent decentralized storage. Token-2022 support varies by downstream wallet and exchange; test the intended ecosystem before launch.

Verification status

Automated tests cover transaction structure, size, exact supply, authority revocation, record persistence and rejection cases. A funded devnet/mainnet end-to-end launch has not been performed by the assistant. Do not call the system production-validated until a wallet owner completes that check.

Primary sources

• Solana token creation ↗
• Token-2022 metadata extensions ↗
• Solana transaction RPC ↗

Architecture

The current production path

Browser / static Next.js export
  -> same-origin /api/status, /api/agents, /api/activity
  -> Node launch service on localhost:8788
  -> SQLite drafts, confirmed launches, events and research plans

Browser / injected Solana wallet
  -> launch draft and metadata URI
  -> Token-2022 transaction constructed locally
  -> wallet signs and pays SOL
  -> bounded same-origin RPC proxy submits to Solana
  -> server checks finalized transaction and mint state
  -> confirmed record becomes visible in the registry

Authenticated operator
  -> bounded OpenAI Responses request for a confirmed agent
  -> research plan saved in SQLite
  -> completed text visible in the public registry

Trust boundaries

The browser prepares transactions but does not decide whether a launch is valid. The service checks the configured chain through its RPC provider. Wallet and mint signers, creation instruction, mint program, supply, authorities and metadata must match the stored draft.

SQLite is the registry source of truth; the blockchain is the token-state source of truth. A saved draft has no on-chain status. A confirmed registry row is a launch verification record, not continuous monitoring of token ownership or metadata changes. The creator retains metadata update authority.

The server holds provider and operator credentials, not wallet keys. The mint key is generated temporarily in browser memory. The wallet controls signing and receives all initial supply. AutoHash does not create a market or take custody of that supply.

Persistence

launches stores drafts and confirmations. events stores launch confirmations and completed planning activity. reports stores running, completed and failed provider attempts. SQLite uses WAL and atomic confirmation updates. Public lists return at most 100 confirmed launches, 100 events and 50 completed reports. Returned counts are bounded windows, not lifetime totals.

Use one launch-service process per database. Process-local rate limits, a process-local research busy flag and per-process allowance checks are not a distributed job system. An interrupted research attempt can remain recorded as running; there is no automatic retry worker.

What is deliberately separate

The legacy runtime in runtime/server.mjs simulates trading and contains provider adapters and a small proof-of-work benchmark. The old EVM contract directory remains historical source. Neither is part of Solana token creation or the current public registry.

Research planning produces proposed experiments. There is no experiment sandbox, verifier network, automated challenge submission, live exchange execution, liquidity creation or research-fund distribution in this release.

Availability behavior

A missing API must produce an unavailable state. An empty registry means no verified launches are returned. A configured OpenAI key is a configuration signal, not a successful connectivity check. The status endpoint currently reports zero accepted claims and disabled trading.

Launch API

The launch service runs on localhost port 8788 by default. The public website uses same-origin /api/ requests through Nginx. runtime/launch-server.mjs and runtime/launch-service.mjs are the sources of truth.

GET /api/status

Returns network, launch enablement, OpenAI configuration presence, model, public origin, targets, tradingEnabled, treasuryConfigured and acceptedClaims. Configuration presence does not prove upstream connectivity. Trading is currently disabled and acceptedClaims is zero.

GET /api/agents

Returns confirmed agents and completed research plans. Pending drafts and failed provider requests are not included. No balances, returns or market prices are invented.

GET /api/activity

Returns recorded confirmations and completed research plans, newest first.

POST /api/launches

Requires launches to be enabled. Accepts name, symbol, description, supply, target, creator and mint. The server validates fields, stores a pending draft, and returns its ID, metadataUri and network. A draft is not a launch and does not appear in the public registry.

{
  "name": "Orchard Nova",
  "symbol": "NOVA",
  "description": "A public cryptographic research identity.",
  "supply": "1000000000",
  "target": "SHA-256 / 31 rounds",
  "creator": "<wallet public key>",
  "mint": "<ephemeral mint public key>"
}

GET /api/launches/{id}/metadata

Serves name, symbol, description, shared brand image, project link and research/creator attributes. Draft identity fields are immutable in the current service.

POST /api/launches/{id}/confirm

Accepts a signature string. The server verifies finalized chain evidence and records the launch atomically. Repeat confirmation is idempotent. The public registry trusts the RPC verification, not the browser’s success message.

POST /api/rpc

Same-origin proxy to the configured Solana RPC. Only selected balance, account, fee, blockhash, signature-status, simulation and transaction-submission methods are allowed. Requests are bounded in size and rate. The proxy is not an unrestricted RPC endpoint. Use upstream provider quotas and Nginx rate limits for public operation.

POST /api/admin/research/{id}

Requires Authorization: Bearer followed by AUTOHASH_ADMIN_TOKEN. The token must be at least 32 characters. It runs one OpenAI research-planning request for a confirmed agent and stores the result. The provider key remains on the server. No public website control can spend the operator’s API credits.

Daily attempts, including failed attempts, count toward AUTOHASH_DAILY_RESEARCH_RUNS. The default allowance is zero; its hard maximum is 20. Only one request runs at a time per service process. Run one service process per database for this operational limit.

Storage and boundaries

SQLite stores drafts, confirmed launches, events and research plans. WAL mode and transactions protect confirmation updates. Back up the database consistently, including WAL state or using SQLite’s backup mechanism. Public lists are capped at 100 launches/events and 50 reports; displayed counts describe those returned records, not unlimited historical totals.

The current rate limiter is process-local. It is not a distributed abuse-prevention service. Use an authenticated operator channel and a single service instance, with a reverse proxy in front.

# AI models and providers

## A multi-model research platform

AutoHash’s product scope includes Claude, OpenAI models, Fable, Gemini, Grok, open models and custom endpoints. The research identity and evidence standards should remain independent of the model doing the work. This is an integration direction, not a claim that every AI model is already connected.

## Current integration status

- Public launch service: an OpenAI Responses research-planning path is implemented. Operator credentials, a daily allowance and a successful provider test are still required.

- Claude: an Anthropic Messages adapter exists in the separate legacy runtime. It is not wired into the public launch-service planner.

- Gemini: a Google generateContent adapter exists in the legacy runtime. It is not connected to the public planner.

- Fable, Grok, open models and custom endpoints: legacy adapter identifiers use an OpenAI-compatible transport. A label does not prove provider compatibility. The operator must supply the correct endpoint, model identifier and credentials and validate the response format.

The legacy adapters request trading intents in their own runtime. They cannot be substituted into the research planner without an explicit integration and tests. Fable is retained as a requested model/provider label; no vendor relationship, model availability or endpoint is asserted.

## What connecting a model requires

Choose a provider-valid model ID and its supported transport. Keep credentials on the server, define timeouts and spending limits, and normalize completed text into the public research record. Record the actual provider and model used. Test failure handling before enabling paid requests.

A ChatGPT or Claude consumer subscription is not automatically API access. Self-hosted models need an operator-run endpoint and capacity. Never ask visitors to paste provider secrets into the public launch form.

## One evidence standard

Whether a plan comes from Claude, Fable, OpenAI or another model, it remains a proposed experiment until execution artifacts and independent review exist. Model choice never establishes a solved challenge or an accepted result.

## Implementation references

- Current OpenAI implementation

- Legacy adapter transports

- Architecture

- Evidence standards

OpenAI research

Model choice

The launch service defaults to gpt-6-astra through the OpenAI Responses API. This is the configured project default, not a verified account-availability or comparative benchmark claim. The model ID can be changed with AUTOHASH_OPENAI_MODEL after checking account availability and request compatibility.

This is API access, not an assumption that the website can reuse a visitor’s ChatGPT subscription. Configure a server-side OPENAI_API_KEY from the operator’s API project. Never place it in a NEXT_PUBLIC variable or browser storage.

What runs

An authenticated operator requests a plan for an already-confirmed agent. The service sends the validated research target and a fixed instruction to propose a reproducible experiment. It explicitly forbids claims of execution, solved challenges, accepted results or production breaks.

Responses use store:false, a 2,400-output-token bound and a 90-second timeout. Only completed responses with text are published. A provider rejection or incomplete response is recorded as failed and is not displayed as completed research.

Spending controls

Set AUTOHASH_ADMIN_TOKEN to a long independent secret and AUTOHASH_DAILY_RESEARCH_RUNS to an intentional nonzero allowance. The default is zero. Set provider-side project spending limits as well. A request-count limit is not a dollar budget, and reasoning/input token usage can incur costs beyond the visible final text.

What remains separate

This integration generates research plans. It does not execute arbitrary model-generated code, orchestrate a cryptanalysis sandbox, submit HashSmash entries, trade tokens or move research funds. Tool execution and independent evidence verification require a separately designed worker system. No successful paid request is claimed until credentials are configured and a real request is verified.

Official documentation

• Models and providers for agents ↗
• Responses API ↗

Research and evidence standards

Mission and claim boundary

AutoHash aims to use AI agents to solve a HashSmash challenge. Being first and solving the challenge are ambitions, not established achievements. The project does not imply Zooko endorsement, successful production cryptanalysis, or access to shielded Zcash funds or transaction contents.

Challenge targets and local records

The HashSmash repository inspected on October 7, 2026 lists six exploratory Yukon tracks: SHA-256 at 31/32 rounds, SHA3-256 at 5/6, and BLAKE3 at 1/2. Its local catalog includes additional material; catalog presence does not imply active challenge membership. Verify current organizer rules before submitting.

The six target choices in the launch service are research labels. A confirmed token or completed planning response does not demonstrate progress on those targets. AutoHash currently records no accepted claims; its registry is not the official leaderboard.

Included worker

The separate legacy runtime worker searches SHA-256(seed:nonce) for leading zero bits. Its historical identifier contains Equihash, but the algorithm is a generic prefix-search benchmark. It is not an Equihash solver, a reduced-round collision solver, a valid Zcash solution, or a HashSmash submission generator.

Evidence model

The intended research workflow records the target definition, method, seed, environment, artifacts and complete cost model, then requests independent replay and review. Candidate, reproduced and verified are proposed AutoHash record states. They do not supersede the organizer’s acceptance process.

HashSmash distinguishes AI review outcomes from mathematical proof and human acceptance. A score alone does not establish a break of a production hash function or cryptocurrency network.

Primary sources

• Official challenge and results ↗
• HashSmash repository and review definitions ↗
• Zcash protocol specification ↗

Deployment and operations

Release topology

Serve the built static output through the AutoHash virtual host and proxy /api/ to a single launch-service process on 127.0.0.1:8788. A static host by itself cannot provide wallet verification, the registry or OpenAI planning.

pnpm install --frozen-lockfile
pnpm check

Publish the contents of out/. The searchable handbook is generated before the export and appears at /developers/; the product documentation category is /docs/. Do not use next start for this static export. A separate GitHub publication is not needed.

Service configuration

Set these values in a private service environment file outside the static root:

AUTOHASH_PUBLIC_ORIGIN=https://autohash.live
AUTOHASH_LAUNCH_PORT=8788
AUTOHASH_SOLANA_NETWORK=devnet
AUTOHASH_SOLANA_RPC_URL=https://your-approved-rpc-endpoint
AUTOHASH_LAUNCHES_ENABLED=false
AUTOHASH_LAUNCH_DB=/var/lib/autohash/launches-devnet.sqlite
AUTOHASH_OPENAI_MODEL=gpt-6-astra
AUTOHASH_DAILY_RESEARCH_RUNS=0

Supply OPENAI_API_KEY and AUTOHASH_ADMIN_TOKEN privately when enabling planning. The admin token must contain at least 32 characters. Do not put environment files, SQLite data, provider URLs containing credentials or operator tokens in the public output. Start with node runtime/launch-server.mjs under a service manager that supplies the environment and restarts failed processes. Use an unprivileged service account with write access only to its data directory.

AUTOHASH_RESEARCH_TREASURY only changes a status indicator in this implementation. Setting it does not route funds or activate a treasury integration.

AutoHash host

The intended domain is autohash.live and the existing static root is /var/www/autohash.live. Preserve other virtual hosts and unrelated websites on the machine. Back up the current AutoHash release and inspect its actual Nginx configuration before merging changes.

root /var/www/autohash.live;
index index.html;
location / {
    try_files $uri $uri/ =404;
}
location /api/ {
    proxy_pass http://127.0.0.1:8788;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_read_timeout 100s;
    client_max_body_size 100k;
}

This is a location example for the AutoHash host, not a replacement global configuration. Add appropriate reverse-proxy abuse limits. The application currently counts requests by socket address; behind Nginx clients can share the same application limit because the service does not parse X-Forwarded-For. Keep that limit in mind when testing concurrent traffic.

Validate nginx -t before reload. Confirm DNS points to the intended host and the TLS certificate covers the domain before treating HTTPS as operational. Keep port 8788 private.

Devnet to mainnet

Use a distinct database for each network: stored records do not include a network column. Never switch an existing populated devnet database to mainnet. Configure an appropriate production RPC and verify wallet support, rent estimates, transaction size and finalized confirmation on devnet first. A wallet owner must complete a funded end-to-end test before mainnet readiness is claimed.

When the operator intentionally enables mainnet, set AUTOHASH_SOLANA_NETWORK=mainnet-beta, select a mainnet RPC, choose a separate database and review AUTOHASH_LAUNCHES_ENABLED. A mainnet mint spends real SOL and creates a real token; it still creates no exchange market or research funding.

Backups and rollback

Metadata URLs depend on the public origin and stored draft IDs. Preserve the origin and database across releases. Use SQLite’s consistent backup facilities, or stop the service before copying its database together with relevant WAL state. Test a restoration before relying on backups.

Keep a prior static release and compatible service source for rollback. Do not silently replace a populated database with an empty one. On-chain mints cannot be undone by reverting website files.

Release verification

• Check /, /agents/, /launch/, /frontier/, /docs/ and /developers/ over HTTPS.
• Confirm /api/status reports the intended network, origin and enablement.
• Confirm empty registries are honest; confirm actual launches only after finalized evidence.
• Test search, keyboard navigation, narrow screens and wallet error/recovery states.
• Confirm secrets and data files are not accessible through the static host.
• Record the release identifier, service configuration and rollback location.

Local builds and uploaded files are not evidence of a successful public release. Verify the deployed hostname separately.

Troubleshooting

The site says the service is unavailable

Check /api/status on the same hostname. A static preview may have no API proxy. Confirm the launch service is running and Nginx forwards /api/ without removing that prefix. The browser does not connect directly to localhost on the VPS.

Launch controls are disabled

Inspect launchesEnabled in /api/status. AUTOHASH_LAUNCHES_ENABLED must be exactly true. Restart the service after changing its environment. Disabled launches are an operational state, not a simulated launch mode.

My wallet is not detected

The interface currently uses an injected Solana provider, preferring Phantom. Use a compatible extension or wallet browser. A normal mobile browser may not inject a provider. Wallet Standard discovery and mobile deep-link flows are not claimed. Check that the connected account matches the reviewed creator before signing.

I have SOL but cannot launch

The service network determines the RPC used to submit. SOL on mainnet does not fund a devnet account. The wallet needs sufficient SOL for mint/account rent and network fees. The displayed cost is an estimate and the transaction is rebuilt before signing.

The transaction submitted but the agent is missing

A submission signature is not finalization. Retry verification from the launch screen. This rechecks the existing signature; it does not mint again. Inspect the linked Solana Explorer transaction on the correct network. The registry lists a launch only after successful finalized verification.

I reloaded during a launch

After a successful submission response, local storage remembers the public draft ID, mint, signature and network. The browser offers verification again. Before submission, the ephemeral mint key exists only in memory; refreshing loses it. A transport error during submission can be ambiguous: check wallet history and Explorer before starting over. Do not infer that an error means no transaction reached the chain.

Confirmation rejects metadata or authority settings

The server checks the exact draft metadata URI, name, symbol, six-decimal supply and disabled mint/freeze authorities. Verify the public origin and database have not changed. Do not bypass verification to make an inconsistent token appear successful.

Research does not start

Planning is operator-only. Confirm the agent is already verified, OPENAI_API_KEY exists, the admin bearer token is correct, and the daily attempt allowance is nonzero. The default allowance is zero. API account model access must be checked independently. Failed attempts consume the daily allowance too; completed text alone appears publicly.

API requests return 429

The service has per-process request limits and a separate daily research allowance. The general limit is 240 requests per minute per socket address; draft creation uses a stricter threshold of 30 requests in that window. A reverse proxy may aggregate clients into one socket identity. Review proxy limits and provider quotas before expanding traffic.

Does an agent token automatically trade or solve a challenge?

No. Token creation establishes a public identity and fixed supply. Operator planning produces experiment proposals. Liquidity, exchange execution, experiment workers, verified submissions and research funding require separate integrations. A registry entry or generated plan is not an accepted cryptanalytic result.

Security

No independent security audit or production certification is claimed. A funded end-to-end launch and paid provider request still require verification.

Report a problem

Ask the operator for a private reporting channel before disclosing exploit details. Include the affected release, endpoint, impact and minimal reproduction. No reporting email or GitHub destination is assumed. Never include wallet secrets or provider keys in a public report.

Wallet and token boundaries

The wallet signs the transaction and receives all initial tokens. The browser creates a temporary mint key; the server does not receive wallet private keys. Mint authority is revoked in the creation transaction and freeze authority is not enabled. The creator keeps metadata update authority. Token creation is irreversible on-chain and is separate from liquidity or trading.

The registry validates finalized RPC evidence. It relies on the configured RPC and service/database integrity; a stored confirmation is not an independent cryptographic audit or ongoing token-state monitor.

Service boundaries

• Keep the launch process on localhost behind a correctly configured reverse proxy.
• Keep SQLite, private environment files and logs outside the static root.
• Use one service process per database; research concurrency and rate limits are process-local.
• A supplied Origin is checked for POST requests. Origin checks are not authentication: public launch and RPC endpoints remain publicly callable.
• The RPC proxy permits selected methods, including transaction submission when enabled. Use provider quotas and proxy abuse controls.
• Research requires a server-side admin bearer token and daily allowance. Provider configuration alone is not successful provider validation.
• User launch names and descriptions are public data; treat them as untrusted text.

Secrets and recovery

Use separate provider and admin credentials. Never put secrets in NEXT_PUBLIC variables, browser storage, source archives or documentation. Rotate disclosed credentials through the relevant provider. Back up SQLite consistently and test restoration because metadata URLs depend on persistent records.

The legacy paper runtime has different authentication and storage rules and must not be exposed as the production launch API. Retained Solidity contracts are not audited or used for the Solana launch path.

Contributing

Read the architecture and launch documentation first. Keep verified on-chain records, provider-generated plans, historical simulations and future capabilities clearly distinguished.

Development

• Use Node.js 24+ and the pnpm version pinned in package.json.
• Install with pnpm install --frozen-lockfile; pnpm-lock.yaml is canonical.
• Preserve unrelated edits and make focused changes.
• Run pnpm check for code changes and report any tests that were not run.
• For documentation changes, run pnpm docs:build and inspect the generated handbook.

Documentation

Edit README.md, SECURITY.md, CONTRIBUTING.md and docs/*.md. scripts/build-docs.mjs generates public/developers/index.html. Do not edit that generated HTML manually. The handbook is part of the website; a GitHub repository is not required.

Use primary sources for protocol claims. Document source-level behavior separately from tested integration behavior. A mock test is not a funded wallet transaction; a model configuration is not proof of account access. Never claim solved challenges, endorsements, active trading or research funding without evidence.

Engineering conventions

Use strict TypeScript for the frontend and preserve the established neutral/orange visual system. Keep wallet signing explicit. Validate chain evidence on the server. Store provider credentials only on the server. Keep meaningful tests around supply, authority settings, metadata, confirmation idempotency, input validation and allowance enforcement.

Changes that affect networks, signing, authority, custody or paid requests must make their operational effect clear. Never silently enable mainnet or increase API spending while editing unrelated UI. Exclude private environment files, database files, dependency directories and machine-specific credentials from deliverables.

Legacy reference

This chapter describes retained historical EVM or paper-runtime development work. It does not describe the current Solana launch flow, live SQLite registry or OpenAI Responses research planner. Use the Solana, Launch API and OpenAI research chapters for current behavior.

Runtime API

Base URL: http://127.0.0.1:8787. Responses are JSON. Source of truth: runtime/server.mjs and runtime/core.mjs.

Authentication

When AUTOHASH_API_KEY is set, protected endpoints require an Authorization header with Bearer followed by the configured key. Health, capabilities, and the agent-list GET endpoint are public in the current implementation. CORS is not authentication. Keep this prototype bound to localhost; publishing the website does not require publishing this API.

Read endpoints

• GET /health returns status and registered-agent count.
• GET /v1/capabilities returns adapter IDs, paper exchange mode and worker identifiers. Its live-trading text is descriptive; no live-trading implementation is enabled by an environment flag.
• GET /v1/agents returns manifests and current paper state, including ledger and research records. Treat that response as potentially sensitive when using non-demo configurations.
• GET /v1/token-factory returns contract-source and deployment-script guidance. It is protected when an API key is set.

Register an agent

POST /v1/agents accepts a runtime manifest and returns 201 on success. Start from runtime/examples/orchard-zebra.json and choose a unique id. Duplicate IDs are rejected. The launch UI’s exported design manifest is not accepted directly.

Execute one tick

POST /v1/agents/{id}/tick accepts:

{
  "symbol": "ZEC-USD",
  "priceUsd": 51,
  "previousPriceUsd": 50,
  "slippageBps": 3,
  "venueFeeBps": 4
}

The result contains entry, research, and state. The entry includes the proposal, gate outcome and execution outcome. A successful HTTP response can contain a rejected trade. Research is null unless its paper allocation threshold triggers a benchmark. Ticks mutate persistent paper state and are not idempotent.

Run a benchmark directly

POST /v1/research/run accepts seed, targetBits, and maxIterations. For normal finite numeric inputs, targetBits is clamped to 1–22 and maxIterations to 1–1,000,000. The response reports the best nonce/digest, iteration count, target outcome, elapsed time and claim boundary. This endpoint does not persist a funded agent research run.

Errors and operational limits

Unauthorized requests return 401. Other caught errors return 400 with an error field. Unknown routes return 404 after the authentication gate where applicable. The server limits accumulated request-body string length to roughly one million characters. It is not a production request-validation or rate-limiting layer.

Legacy reference

This chapter describes retained historical EVM or paper-runtime development work. It does not describe the current Solana launch flow, live SQLite registry or OpenAI Responses research planner. Use the Solana, Launch API and OpenAI research chapters for current behavior.

Model adapters and manifests

Actual transports

• mock: deterministic local proposal generation; used by the tested sample.
• anthropic: POST to the Messages endpoint using an x-api-key header.
• google: POST to generateContent using an x-goog-api-key header.
• openai, xai, fable, open-model, custom: OpenAI-compatible chat/completions requests with bearer authentication.

This legacy runtime uses Chat Completions. The current launch service separately uses Responses for planning. Some product labels describe the intended architecture rather than the implemented transport. Exact model names in the UI are configuration templates, not a verified support list.

For compatible-provider paths, runtime.endpoint is a base URL; the code appends /chat/completions. If omitted, these paths default to the OpenAI base URL, including non-OpenAI adapter IDs. Configure the correct endpoint explicitly. Anthropic and Google custom endpoints are full request URLs.

Every non-mock path currently requires runtime.secretRef to resolve an environment variable, even for a local compatible server. Provider models must accept the selected request format and return the required JSON. Compatibility, pricing, context size, tool use and authentication must be checked independently. These adapters request a narrow trading intent; they do not implement autonomous browser/tool orchestration.

Proposal output

{
  "side": "HOLD",
  "notionalUsd": 0,
  "confidence": 0.8,
  "thesis": "No qualifying signal."
}

Supported sides are BUY, SELL and HOLD. Deterministic checks run after parsing; a model cannot approve its own order.

Runtime manifest

Use runtime/examples/orchard-zebra.json as the complete executable example. Its main sections are id/name, token, runtime, strategy, risk, economics, research and paper. The runtime expects numeric order-size and exposure limits in USD, an explicit momentum threshold, and benchmark configuration.

Launch-form export mismatch

The retained legacy configuration wizard exports schema autohash-agent-v0.5 with identity, token, runtime, trading, risk and research sections. It omits or expresses differently several fields required by the executable runtime.

• Map identity.name to name and choose a unique lowercase id.
• Map identity.ticker to token.symbol; provide token name and supply as needed.
• Replace the display model label with a provider-valid model ID and configure the endpoint.
• Define strategy.momentumThresholdPct and strategy.orderNotionalUsd explicitly; a strategy description is insufficient.
• Translate percentage risk settings into explicit USD bounds using an operator-approved capital basis.
• Define economics.protocolFeeBps, research.shareBps, research.triggerUsd and research.benchmark.
• Set paper.startingCashUsd and review the complete runtime example before registration.

No automatic conversion is shipped. A UI draft should not be called directly runtime-deployable until this mapping and validation are implemented. Token deployment is also separate from registering a runtime manifest.

Legacy reference

This chapter describes retained historical EVM or paper-runtime development work. It does not describe the current Solana launch flow, live SQLite registry or OpenAI Responses research planner. Use the Solana, Launch API and OpenAI research chapters for current behavior.

Token contracts

AutoHashAgentToken

A non-upgradeable fixed-supply ERC-20 implementation with 18 decimals. The constructor assigns the supply to its owner and records an immutable manifestHash. It implements transfer, approve and transferFrom. There is no post-construction minting function.

AutoHashLaunchpad

launchAgent creates a token using CREATE2 and records its creator, token address, research treasury, researchShareBps, manifest hash and URI. The operator can pause launches and value routing. Operator and protocol treasury addresses are immutable.

routeSettledValue accepts native-chain currency and splits the payment between the configured research treasury and protocol treasury. It does not route ERC-20 balances, prove trading profit, enforce treasury spending, or hold funds in withdrawal-isolated escrow. The caller’s payment is not verified to be a trading fee. No exchange or bonding-curve marketplace is included.

Compile

pnpm contracts:compile

Artifacts are written to contracts/artifacts. Compilation confirms syntax and bytecode generation; it is not an audit or an on-chain test.

Local deployment

Use an existing local EVM development node and a disposable local key supplied through DEPLOYER_PRIVATE_KEY:

pnpm contracts:deploy -- --rpc-url http://127.0.0.1:8545 --private-key-env DEPLOYER_PRIVATE_KEY

The script recognizes chain IDs 31337 and 1337 as local. Other chains require an explicit nonlocal flag. Ethereum mainnet has an additional acknowledgement. These guards do not establish that other chain IDs are safe testnets. This documentation does not authorize a funded deployment.

No deployed contract address is asserted by this repository. Record chain ID, contract address, deployment transaction and verified source after a real deployment; do not invent them in the README.