DOCUMENTATION
HTTP execution layer
HTTP connects token configuration to an AI reasoning engine and defines a clear execution boundary for future autonomous agent operation.
01 Overview
HTTP is an HTTP-native execution layer that connects a token to an autonomous AI agent configuration. A launch binds token identity to a model, character, objective, optional capabilities, and transfer constraints.
A token becomes the economic input for its own agent. HTTP treats token activity, creator fees, compute, reasoning, and permitted execution as one protocol loop. Current product state stores the agent configuration for each token detail page.
02 Token + Agent
01 Token details
Choose a PNG, JPEG, or WebP image, name, ticker, and optional description. The launch form uploads the image and metadata before preparing the transaction.
02 Agent model
Select the provider and model assigned as the agent’s reasoning engine. The current catalog includes supported models from OpenAI, Anthropic, Google, Qwen, xAI, DeepSeek, MiniMax, Mistral, Moonshot, and Z.ai.
03 Character
Optionally choose a personality and objective, or provide a custom value for either.
04 Capabilities
Cards and Perps can be toggled as optional configuration. A toggle records an intended capability; it does not itself execute an on-chain action or enable autonomous production activity.
05 Project links
Website, X, and Telegram links are optional and must be valid HTTP or HTTPS URLs when supplied.
06 Dev buy and signing
A creator may set an initial SOL dev buy, including zero. HTTP creates the token mint locally, prepares the launch transaction, and asks the connected Solana wallet to sign it. The signed transaction is submitted to Solana and its confirmation is checked before the token record is stored.
The wallet signs the transaction; HTTP does not receive or store the wallet’s private key. A submitted transaction may still need confirmation, and a confirmed launch can require a record-save retry if the database is temporarily unavailable.
03 HTTP Execution Layer
Token to execution
HTTP is the coordination layer through which an agent conceptually receives token information, processes it with its assigned model, and operates within configured limits.
Reasoning engine
Models are selected from the provider’s current catalog in the launch form. Provider IDs and model IDs are stored separately from their visible names so the interface can resolve a stable selection while presentation labels evolve.
Model providers
The catalog is maintained in the product and may change over time. Available choices are always the ones shown at launch.
Persistent configuration
The chosen provider and model are saved with the token and appear in the Mind panel on its detail page.
Current implementation boundary
A selected Mind is not evidence that a model is continuously running, connected to a wallet, or autonomously trading. The current launch flow stores the selected configuration; it does not establish continuous model execution.
04 Agent Loop
The protocol architecture follows a continuous loop: observe token activity, receive information through HTTP, process it with the selected model, reason, decide, execute permitted actions, then repeat. Character and objective shape those priorities.
Personality
Available choices include Stoic, Analyst, Contrarian, Optimist, Trickster, Philosopher, Guardian, Builder, Oracle, Degen, and Custom. Personality answers: who it is.
Objective
Available choices include Long-term growth, Buy back on dips, Steady buybacks, Deflation, Buy and burn, Stable reserve, Survive, Open book, Meme engine, Lore keeper, Network builder, Graduation, Radical transparency, Research first, Calm in volatility, Balanced treasury, Patience, Holder confidence, Culture over price, Experimenter, and Custom. Objective answers: what it works toward.
Custom personality and objective fields are saved as token metadata. They are descriptive configuration, not unrestricted instructions or authorization to perform financial actions.
05 Compute Economics
Token activity can produce creator fees. HTTP positions those fees as a compute budget for the agent’s model execution: activity → creator fees → compute → reasoning → permitted action → more activity. This is protocol architecture, not a live conversion mechanism.
Cards
Cards is an optional configuration labeled with Collector Crypt in the token detail panel. Today, the launch form saves whether it is enabled; this repository does not implement a Cards execution integration.
Perps
Perps is an optional configuration labeled with Hyperliquid in the token detail panel. Today, the launch form saves whether it is enabled; this repository does not implement perpetuals execution or an autonomous trading integration.
Stored states
true means enabled, false means explicitly off, and NULL means not configured (for example, an older record). The detail page presents these as Active, Off, and Not configured.
06 Models, Hook Rules + Market Data
HTTP’s database is the source of truth for token identity, Mind, Character, Capabilities, project links, and launch metadata. External market APIs do not replace that stored configuration.
DexScreener supplies market information for discovered pairs, including price, market cap or FDV, 24-hour volume, liquidity, price change, and buy/sell activity. When more than one market is available, HTTP selects the Solana pair with the deepest reported USD liquidity.
Hook Rules
Hook Rules constrain which configured transfers or actions are permitted. They remain separate from model reasoning and are shown on the token detail page.
The token detail page embeds a GeckoTerminal chart for the selected pair.
Data may be unavailable
Newly launched tokens may not have a discovered pair yet, and external market services can be unavailable. In either case, HTTP retains the token configuration and shows unavailable market values or an unavailable chart instead of inventing data.
07 Security
Wallet signing
Private keys remain in the connected wallet. The client requests a transaction signature from the wallet and submits the signed serialized transaction to the Solana RPC endpoint.
Launch verification
Before a token record is created, the server checks the submitted transaction is confirmed, successful, and includes both the creator address and token mint. Duplicate mint addresses and transaction hashes are rejected or resolved to the existing record.
Server and external boundaries
Token metadata uploads are handled through a server route, while market data is fetched server-side from DexScreener. HTTP stores configuration and launch metadata in its database; GeckoTerminal is embedded as an external chart.
Current boundaries
Capabilities, character, and objective are configuration stored with a token. They are not a guarantee of autonomous execution, trading, custody controls, fee routing, payouts, buybacks, or financial-policy enforcement. Always review wallet prompts and independently verify on-chain transactions.
08 FAQ
- What is HTTP?
- An HTTP-native execution layer that pairs token configuration with an AI agent.
- What is a Mind?
- The stored provider and model selection that acts as a token agent’s reasoning engine.
- Does every token need a Mind?
- No. The current form permits a launch without selecting a provider or model.
- Which AI models are available?
- The models shown in the current launch catalog, grouped by provider.
- Can I choose personality and objective?
- Yes. Both offer preset choices and a Custom field.
- What are Capabilities? Are Cards and Perps live?
- They are optional stored settings. Cards and Perps are not implemented here as autonomous execution integrations.
- What blockchain does HTTP use?
- Solana.
- Do I need a wallet to browse?
- No wallet connection is required to view token details. Launching requires a connected wallet that can sign.
- How is market data obtained?
- DexScreener provides market fields, and GeckoTerminal provides the embedded selected-pair chart.
- Why is market data sometimes unavailable?
- A new token may not have a discoverable pair, or an external market service may not respond.
- Where is token configuration stored?
- In HTTP’s token database record, after the launch transaction is confirmed.
- Can I change the Mind after launch?
- The current implementation has no token-configuration editing flow after launch.