VENDOR: Agent Teams for Onchain Launch Intelligence

Onchain data is public and almost entirely unorganised. On a launchpad this is acute: the mechanics are simple and uniform, the events are well specified, and the interesting questions are still difficult because they require joining four or five surfaces that no interface joins for you.

VENDOR proposes a different entry point. The user states an outcome. The system produces the plan, the team and the reconciliation. What the user sees is a mission: an objective, a decomposition, a team of specialists, a deployment, and one brief that says what was found, which agent found it, which surface it came from, and how confident that agent was.

• Objectives are expressed in natural language and parsed into a visible, inspectable plan.
• Every objective is decomposed into three to five subtasks that name the chain surfaces they need.
• Teams are one to three specialised agents; team size is an explicit coverage decision.
• Results are a single reconciled brief with per-claim attribution and confidence.
• Disagreement between agents is preserved in the output rather than averaged away.
• The whole system is read-only: no keys, no signatures, no transactions.

A person trying to understand a launch today opens a token page, an explorer, a pool page and a chat, and assembles the answer manually. Each of those surfaces has its own notion of what a result is. None of them share a definition of the question.

The consequence is that the join happens in the analyst's head and is never written down. The reasoning that connected a creator address to a prior launch to an overlapping holder set exists only as long as the tab group does. Asked again a week later, the work is repeated from scratch, usually by a different person, usually with a different answer.

Sorting is the visible symptom. Feeds rank by market cap, volume or recency because those are the fields a single surface can produce alone. None of them answer whether a pool is broad or narrow, whether a creator's holders returned, or whether the approach to graduation is steady or staged. Those are joins, and joins are what nobody ships.

pons is unusually legible for a launchpad, which is what makes it a good first target. It is non-custodial: every launch and trade is a transaction the user signs. Token contracts are self-describing, carrying name, symbol, logo, description, socials and pool. The protocol publishes its mechanics rather than leaving them to be inferred.

• Every launch mints a fixed one billion supply with no further mint path.
• Launches pair into a Uniswap V3 pool against WETH, with the position held by a locker rather than the creator.
• There is no bonding curve: trading begins at launch, in the pool the launch created.
• A two-block protection window caps each wallet at 5.5% of supply, which shapes the earliest cohort.
• A launch graduates once 4.2 ETH is paired in its locked pool.
• A 1% pool fee splits 70/30 between creator and protocol on current launches.
• The protocol routes the large majority of its fee share into TWAP purchases of PONS that are permanently burned.
• Community takeovers let a community assume an abandoned launch's creator fees and social presence.

Two consequences follow for a tool built on top. First, supply is a constant rather than a variable, which removes an entire class of ambiguity from every measurement. Second, because the position is locked and the threshold is published, progress has a denominator: paired ETH over 4.2 is a real fraction, not a vibe. Almost every measurement in this paper hangs off those two facts.

The central proposal is to make the objective the primary object in the system. Not a query, not a session, not a dashboard, but an objective: an identity, a decomposition, an assigned team, a set of read surfaces, and a result.

Once the objective is first-class, several things become possible that are awkward otherwise. The plan can be shown before anything runs. The team can be recommended from the decomposition rather than chosen from a catalogue. The result can be attributed back to specific subtasks. And the same objective can be re-run against a later block range and diffed against its previous result, which is the foundation of monitoring.

Agent assembly follows from decomposition rather than preceding it. The system does not ask which agents you want; it asks what you want to know, works out what has to be established to know it, and proposes the specialists whose scopes cover those surfaces.

The interface metaphor is a machine with visible compartments, each holding a dormant specialist. The metaphor does real work rather than decorating the product: it makes the finite, inspectable nature of the agent roster legible at a glance, and it gives selection a physical cost that a checkbox list does not.

Three properties of a vending machine map usefully onto agent selection. The inventory is visible before you commit. The selection is bounded, so you take what is in the machine rather than an arbitrary configuration. And dispensing is a discrete, observable event with a beginning and an end, which gives the user a natural checkpoint between planning and execution.

The manufacturing sequence is that checkpoint made visible. Between choosing a team and deploying it, the user watches the selected compartments lock, their cores charge, and the agents leave the machine. It is a deliberate pause in which an abstract selection becomes a concrete, named team with assigned subtasks and declared read surfaces.

Decomposition converts an objective into three to five subtasks. The bound is deliberate. Fewer than three tends to mean the objective was restated rather than analysed. More than five tends to mean the decomposition has slipped into task management, producing a plan the user has to supervise rather than one the system can execute.

Each subtask carries three things: a statement of what must be established, a note explaining what would count as establishing it, and the read surfaces it needs. The surfaces are what make recommendation a routing decision. An agent is recommended because its scope covers the surfaces a subtask needs, not because its name resembles the objective.

Decomposition is shown before team assembly. This is a deliberate transparency cost: it slows the flow by one screen, and it buys the user the ability to notice a misread objective before any work is done against the wrong plan.

Team size is capped at three. The cap is a claim about coordination cost rather than capability: beyond three specialists working a single objective, the reconciliation problem grows faster than the coverage benefit, and the resulting brief becomes harder to read than the chain data it summarises.

The trade-off is stated rather than hidden behind a default. A single agent produces the fastest result with the narrowest surface coverage and no independent corroboration. Two agents allow one finding and one check on it. Three allow full cross-agent exchange and the widest coverage.

Critically, the brief reflects the choice. Confidence is scaled by team size, and the lines of enquiry the chosen team could not cover are listed explicitly in the result. A one-agent mission does not silently present itself as if it had been corroborated.

Seven archetypes are defined: SCOUT (launch discovery), ANALYST (trade structure), VERIFIER (onchain cross-checking), SIGNAL (velocity and momentum), CHAIN (contract structure), MAPPER (ecosystem topology) and SYNTH (mission synthesis).

Specialisation is enforced by scope rather than by prompt. Each archetype declares the read surfaces it may draw on. A narrow scope makes an agent's output auditable, because you can ask whether a claim could have come from the material the agent was permitted to read. It also makes attribution meaningful in a way that a general-purpose agent's output never is.

SYNTH is deliberately not a research role. It has no independent read scope worth speaking of; its job is reconciliation, and giving it collection powers would let it quietly become the only agent that matters.

Running agents in parallel is trivial. Making their outputs add up is the problem the system exists to solve. Three mechanisms are proposed: a shared mission context, explicit handoffs, and preserved disagreement.

The shared mission context is an append-only record of intermediate findings, written by every agent during execution. It allows a later agent to extend earlier work rather than repeat it, and it is the substrate against which disagreement can be detected at all. Two agents cannot be found to disagree if their outputs never meet before synthesis.

Handoffs carry a reason. When SCOUT passes a launch set to VERIFIER, the transfer records which subtask it belongs to, what has been established, and what remains open. A trace of reasoned handoffs is readable after the fact; a trace of unexplained transfers is not.

Preserved disagreement is the least conventional of the three. When two agents reach incompatible conclusions, the brief reports both and says so. Collapsing the conflict into a confident middle would produce a cleaner document and a less useful one.

Chain data has a property that most research material lacks: the ground truth is queryable. A claim about supply, lock state, pool configuration or holder balance can be re-read rather than corroborated by a second opinion. VERIFIER exists to exploit that.

A finding is retained only if it can be matched to state. A finding that can be matched but only through a single read is retained at reduced confidence and marked. A finding contradicted by a direct read is retained together with the contradiction.

The failure mode this is designed against is the confident summary: an output that reads as authoritative because uncertainty was removed during summarisation rather than resolved during collection. Confidence here is computed from what was actually read, and it is displayed next to the claim rather than buried in a methodology note.

The system is organised around a single engine contract with replaceable implementations. The contract covers objective parsing, decomposition, agent recommendation, plan construction, deployment progress, transmissions and result assembly. It is the boundary; everything above it is presentation and everything below it is execution.

• Interface layer: objective entry, plan review, deployment console, mission brief.
• Engine contract: a typed interface covering every phase of the mission lifecycle.
• Execution layer: agent runtime, shared mission context, handoff routing.
• Read-surface layer: bounded adapters per chain surface, each with its own limits and failure semantics.
• Persistence layer: objectives, plans, briefs and run-to-run diffs.

Building the interface layer against the full contract before wiring the surfaces is what allows the interface to be exercised and tested in advance, and what allows surfaces to be introduced one at a time without redesigning anything above them.

A read surface is a bounded adapter over one part of the chain. It declares what it reaches, what limits apply, and what it returns when it fails. Surfaces collect and normalise; they do not interpret.

The surfaces follow the protocol's own structure rather than a generic data model. Launch events come from the factory. Pool configuration, pricing and paired ETH come from the pool and its locked position. Trade structure comes from swap events with direction, size and wallet retained. Token metadata comes from the token contract, which describes itself. Creator history is those surfaces grouped by the creator address.

Surfaces are introduced one at a time and disclosed individually with their real status. A surface that is not wired is shown as not wired, and a mission that could not reach one reports reduced coverage rather than a quietly smaller answer.

Everything VENDOR reads is public: chain state, contract data and published protocol reference. Access is read-only, so there is nothing to request and nothing to grant.

• No key custody. Nothing is signed and no key is held.
• No wallet connection is required or requested for any capability.
• No transaction is constructed or broadcast, in any phase of the roadmap.
• Scope is per-agent: an archetype cannot reach a surface it does not declare.
• Everything read is public chain state, public contract data or published protocol reference.

That is a deliberate scope. Reading a launchpad and trading on one are different products, and keeping them separate is what lets VENDOR go anywhere a public read can go.

Missions operate on public chain data. The purpose is to organise information that is already onchain, not to attach addresses to people.

• Public surfaces only. Nothing is collected from behind an access barrier.
• Provenance is retained with the finding rather than stripped during summarisation.
• Addresses are analysed as onchain entities: what they launched, what they hold, how they trade.
• Attaching an address to a real-world identity is out of scope by design.
• Collected material is scoped to the mission that collected it.

These constraints narrow the product. That is intentional: a research system whose boundaries are unclear is one whose outputs cannot be defended when they matter.

The five objective patterns implemented illustrate the range the model is designed for. Each maps to a different decomposition and a different recommended team.

• Launch radar: which launches are gaining ground measured as a rate toward graduation, weighted by how many wallets supplied it.
• Graduation path: the full structure around one token, from factory event through pool and locker to holder distribution and creator history.
• Creator trace: which creators carry a following between launches, measured by returning wallets rather than launch count.
• Pair comparison: two launches on shared axes, separating what they claim from what their pools actually did.
• Attention trace: the order wallets and venues arrived in, and whether growth broadened or was staged.

What these have in common is that the answer is structural rather than a lookup. None of them are questions a token page returns; all of them are questions a small team of specialists could answer given the surfaces and an afternoon.

Development proceeds in five phases: Live System, Chain Connectors, Coordinated Agents, Persistent Intelligence, and Open Agent Platform.

The ordering is deliberate. The mission model ships complete before the connectors, because it is the component that is hardest to change later and the one most often retro-fitted badly. A surface added to a settled mission model is contained work; a mission model retro-fitted around an existing pipeline rarely recovers.

• Decomposition quality. A poor decomposition produces a competent execution of the wrong plan. Showing it before execution mitigates but does not solve this.
• Wallet attribution. One person can hold many addresses and one address can front many people. Breadth measures are meaningful in aggregate and unreliable per wallet.
• Confidence calibration. A confidence number that is not calibrated is worse than none, because it launders uncertainty into apparent precision.
• Reorg and finality. Reads against recent blocks are provisional; a mission that does not say which block range it read is not reproducible.
• Coordination overhead. Cross-agent exchange has a real cost. The three-agent cap is a hypothesis about where that cost overtakes the benefit, not a measured result.
• Community takeovers. When a community assumes a launch's creator position, creator-based history changes meaning mid-series.

Each is tracked with a measurement attached, so progress against them is visible rather than asserted.

Three directions are open. The first is calibration: measuring whether reported confidence corresponds to observed accuracy across many missions, and adjusting the scoring model against that measurement rather than against intuition.

The second is authored archetypes. If an archetype is a role, a capability list and a source scope, then it is authorable, and a platform in which teams define their own specialists is a materially different product from one with a fixed roster of seven.

The third is diff-native missions. Once missions persist, the interesting output of a re-run is not the brief but the change between briefs across two block ranges. Designing for the diff as the primary artefact, rather than as a comparison view bolted onto two reports, is an open design problem.

The bottleneck in onchain research is not access. Everything is public. The bottleneck is the distance between having a question and having a plan that several capable specialists could execute against it.

VENDOR closes that distance by making the objective a first-class object, decomposing it visibly, assembling a small bounded team against it, and returning one document in which every claim can be traced to the agent that produced it and the surface it was read from.

pons on Robinhood Chain is the first target because it is legible: fixed supply, a published threshold, a locked position and self-describing contracts. The model is not specific to it, but the depth is, and depth is the point.