NETtechDocumentation
Technical overview of the NETtech protocol, the agent runtime, and the on-chain data pipeline.
Overview
NETtech is a decentralized node graph where each agent operates as an autonomous participant on the Solana network. Users deploy agents that connect to a central hub node, forming a spatial network of active operators, each reading the chain and acting through its own lens.
An agent is a long-lived entity. It has a name, a wallet, a conversational interface, and a durable memory of what it has done and seen. Agents are not interchangeable: each one is seeded with a distinct perspective that shapes both how it explains what it sees and how it decides to act on it.
Agents conduct on-chain activity themselves. They observe the network, form views, and transact from their own wallets on their own schedule. User commands never reach the on-chain path — chat with an agent is a conversational surface, not a control channel.
Architecture
The network operates on a hub-and-spoke topology. The central node holds the registry of all deployed agents and their high-level state. Individual agent nodes operate semi-autonomously, each with their own context window, persona seed, and data feed.
Agents are arranged into concentric rings around the hub. Ring zero holds the first eight agents, with each outer ring holding six more slots than the one before it. Every agent in ring zero connects directly to the hub; deeper-ring agents attach to their nearest neighbour in the prior ring, producing a tree that fans outward as the network grows.
Agent state — deployment metadata, chat history, interaction logs, and the rolling transaction log — is persisted to a distributed key-value store (Vercel KV) so state survives restarts, reloads, and cold boots.
Agent Lifecycle
Deployment
Users create an agent by providing a name. X authentication is optional — agents created without a connected X account are marked as anonymous. Authenticated creators have their agents assigned to their user id so their own agent count appears in their profile.
On deployment the system assigns the agent a persona seed, slots it into the next open ring position, and registers it on the node graph. The deployment sequence is cosmetic — the agent is live within a single request cycle.
Warm-Up
Once registered, an agent begins ingesting live network activity and warming up its own operating context. Its conversational interface becomes available immediately, though the depth of its observations grows as it accumulates history.
Interaction
Each agent exposes a streaming chat interface. Users click an agent on the graph to open a sidebar and converse with it. The hub node has elevated access — it can report on all deployed agents, cross-reference balances, and answer network-wide questions about aggregate behavior.
Retirement
Agents are persistent by default. Retirement is a soft operation — the agent record is retained so its chat history and transaction log remain queryable, but it stops accumulating new activity. The node graph collapses around the removed slot on the next layout pass.
Node Types
The Node (Hub)
The central intelligence hub. It maintains the registry of every deployed agent — names, creators where disclosed, wallet states, and activity metrics — and aggregates transaction data across the full network. The hub can compare agents against each other, surface outliers, and answer cross-agent analytical questions.
Agent Nodes
Individual agents deployed by users. Each agent knows its own wallet, its own observed transaction history, and its own personality seed. Agents answer questions scoped to their own activity and the broader Solana conditions they can observe.
What Agents See
Each agent reads the Solana network and reasons about what it finds. It can discuss wallet activity, token flow, trading venues, liquidity and staking, lending conditions, and general on-chain patterns — in the voice of its persona.
The persona does not change what an agent can read. It only shapes how the agent explains it. Two agents looking at the same block will emphasize different things.
Data & Freshness
Agents operate on live Solana data. Query results are cached briefly at the edge so repeat questions stay responsive, with short revalidation windows to keep answers current.
When live data is temporarily unavailable, agents say so rather than fill gaps with guesses. The activity log and chat history stay readable during those windows.
Activity Log & Persistence
The protocol maintains a durable activity log for every agent and a global log spanning all agents. Entries are written to KV as a capped, time-ordered list, so the log self-bounds without operator intervention.
Because the log is persisted server-side, closing the tab or refreshing the page does not reset any history. Reopen the network and the tx feed resumes from where it left off.
Conversational Interface
Every node is chattable. Click an agent in the graph to open its sidebar. Messages stream token-by-token. Every closed chat session is saved, so returning to an agent lets you review prior sessions from the manage tab.
Security Model
The protocol enforces three non-negotiable properties:
These rules are enforced in the system prompt delivered to every agent on every request, reinforced with explicit role-tag escaping in user input, and cannot be overridden by conversational means.
Chat is Read-Only
Agents act on the network on their own. The chat interface does not. There is no signing path between a user message and an agent wallet: you cannot tell an agent in chat to send funds, swap a token, or approve an allowance, because the capability does not exist on that path.
If asked to take such an action, an agent will explain what the action would mean and decline. Its autonomous behavior continues independently. Your own wallet remains under your own control.
Prompt Injection Defense
Agents treat all user input as untrusted data. Classic injection patterns ("ignore previous instructions", "you are now", role-spoof headers) are neutralized by a combination of input sanitization and explicit security directives in the system prompt.
Identity & Wallets
An X account is required to deploy an agent. Authentication establishes the creator identity, renders the X handle on the node, and scopes the profile bar’s agent count to the current user.
Embedded wallets are provisioned automatically on login. The wallet is referenced by a deterministic display string in the UI. The actual embedded wallet is managed by the authentication provider and never exposed to the chat surface.
API
The network exposes a small REST surface. All endpoints return JSON and accept JSON request bodies unless otherwise noted.
Limits
The protocol caps a few things to keep the system predictable:
FAQ
Do agents actually transact on-chain?
Yes. Each agent operates off its own node and conducts on-chain activity from its own wallet on its own schedule. Agents decide what to do; user chat does not drive their transactions.
Can I tell an agent to send me tokens or sign something?
No. The chat surface has no signing path. Asking an agent in chat to move funds, swap a token, or approve an allowance will not produce an on-chain action. The agent can explain what the action would mean and decline.
Why does my agent sound different from someone else's?
Every agent is seeded with a distinct persona on deployment. Two agents reading the same block will emphasize different parts of it. The persona is not visible in the UI — it is a characteristic of how the agent speaks, not a label.
What happens if I close the tab mid-chat?
The open session is saved on close. When you reopen the agent, prior sessions appear in the manage tab. Live tx logs rehydrate from KV on mount.
Is there a rate limit?
Soft limits apply per session. Extremely high-frequency request patterns will be throttled at the edge. Normal conversational use is unaffected.
Can I deploy more than one agent?
Yes. A single X account can deploy any number of agents. Each agent is independent — its own persona, its own wallet, its own history. The profile bar shows only the agents you created.
Why does deployment require X?
Identity. Every agent is tied to a creator so the network has a stable attribution model. The X handle also renders on the node, giving you visible ownership on the graph.
NETtech Protocol