Skip to content
VENDOR
initialising foundry
LiveAgent teams for pons on Robinhood Chain

One objective.
A specialised
agent team.

Describe what you want to know about a launch, a creator or a pool. VENDOR decomposes the objective, recommends the agents built for it, manufactures them, and deploys them across launch events, pool state, swap flow and holder structure.

Describe the mission. Assemble the agents. Deploy.

Press enter, or start from an example

Example objectives
System starting.
01How a mission runs

One objective. A specialised agent team.

Most research tools ask you to know which tool you need before you start. VENDOR inverts that: you describe the outcome, and the system decides what has to be true to get there.
01

Describe

State the objective in your own words. No filters, no query syntax, no tool selection.

02

Decompose

The objective is split into three to five subtasks, each with its own source categories.

03

Assemble & manufacture

One to three agents are recommended and built. You decide the coverage-versus-speed trade-off.

04

Deploy & synthesise

Agents work separate corridors, exchange findings, and return one reconciled brief.

02Objective decomposition

An objective is not a query. It is a plan.

Decomposition is where a sentence becomes work. Each subtask carries the source categories it needs, which is what makes agent recommendation a routing decision rather than a label match.

Objective

Track new pons launches climbing toward graduation.

  1. Sweep the factory for new launches

    Read TokenLaunched from the active factory, resolve each token's self-described metadata, and drop relaunches of the same name and image.

    Launch EventsToken MetadataChain State
  2. Measure paired-ETH velocity against the threshold

    Track ETH entering each locked pool and express progress as a rate toward the 4.2 ETH graduation threshold rather than a raw balance.

    Pool StateSwap Flow
  3. Separate broad buying from single-wallet accumulation

    Cluster swaps by wallet and block. A pool filled by four wallets behaves nothing like one filled by four hundred.

    Swap FlowChain State
  4. Verify supply and lock state

    Confirm fixed supply on the token contract and the liquidity position held by the locker before any launch is promoted to the shortlist.

    Chain StatePool StateProtocol Reference
03Team assembly

One, two or three agents, and the trade-off is stated.

Team size is a coverage decision, not a speed setting. Whatever you choose, the resulting brief reports its own confidence honestly and names the lines of enquiry it did not cover.
1 agent

Focused

One corridor, one perspective. Fastest route to an answer, with the narrowest coverage and no cross-checking.

Source coverage42%
Corroboration30%
Turnaround95%
2 agents

Balanced

Two corridors with a single exchange. Enough for a finding and a check on it.

Source coverage70%
Corroboration66%
Turnaround72%
3 agentsWidest

Coordinated

Three corridors with full exchange. Widest source coverage and the strongest corroboration.

Source coverage95%
Corroboration92%
Turnaround50%
04Agent archetypes

Seven specialists, each with a narrow job.

An archetype is a role, a capability list and a source scope. Narrow roles are what make coordination legible: you can tell which agent produced a claim and what it was allowed to look at.

SCOUT

Launch Discovery

Live

Opens the search space. Reads TokenLaunched from the pons factory and surfaces the launches worth looking at before anything is narrowed.

Capabilities

  • Continuous sweep of factory launch events
  • New pool detection against the WETH pair
  • Deduplication of relaunches and copycat metadata
  • Relevance triage before deeper analysis begins

Planned source categories

  • Launch Eventsin development
  • Token Metadatain development
  • Community Channelsplanned
  • Chain Statein development

Machine compartment

Slot
01-01
Silhouette
orb
Accent
acid
Source scope
4 categories
05Agent coordination

Agents that work together, not merely at the same time.

Running several agents in parallel is easy. Making their outputs add up is the actual problem: overlap has to be merged, disagreement has to survive, and the reader has to be able to tell which agent said what.
  • Shared mission context

    Intermediate findings are written to one place, so a later agent extends earlier work instead of repeating it.

  • Disagreement is preserved

    When two agents conflict, the brief records the conflict rather than averaging it into a bland middle.

  • Attribution all the way down

    Every finding, every evidence item and every downgrade carries the agent that produced it.

SHAREDCONTEXTSCOUTANALYSTVERIFIERSYNTHMISSION BRIEF
Agents write into one shared mission context. SYNTH reconciles it into a single brief, including the places where two agents disagree.
06Mission results

One brief, with its confidence on the outside.

A mission returns a single organised document: executive summary, findings with evidence, a source-category map, an ecosystem graph, per-agent contributions and suggested next actions, each carrying a confidence you can argue with.
Excerpt / example mission brief

Executive summary

Raw pool balance is the wrong ranking. Measured as a rate toward the 4.2 ETH graduation threshold and weighted by how many distinct wallets supplied it, the ordering of the window changes at the top: the pool nearest to graduating is also the narrowest, filled by four wallets inside two blocks of the launch window open

Key finding

The pool nearest graduation is the narrowest in the window

One launch sits closest to the 4.2 ETH threshold on balance alone, but four wallets account for most of the paired ETH and all four entered within two blocks of launch. Depth without breadth reverses quickly, b

Confidence86%
Run a full mission
07Capability matrix

What is live, what is being wired, what is next.

Every capability carries its real status and the phase it belongs to. Read surfaces on pons are wired one at a time and disclosed individually.

Mission Interface

How an objective is expressed, decomposed and turned into an agent team.

  • Natural-language objectives

    Describe what you want to know about a launch, creator or pool. No query syntax.

    Phase 01Live
  • Objective decomposition

    Every objective becomes three to five concrete subtasks with their own read surfaces.

    Phase 01Live
  • One-to-three agent teams

    A recommended team you can change, with the trade-off made explicit.

    Phase 01Live
  • Agent manufacturing

    Selected agents are built from their compartments before deployment.

    Phase 01Live
  • Unified mission brief

    One organised result rather than several disconnected outputs.

    Phase 01Live

Chain Coverage

The read surfaces VENDOR works against on pons and Robinhood Chain.

  • Factory launch indexing

    TokenLaunched events resolved to token, creator, pool and self-described metadata.

    Phase 02In Development
  • Pool and pricing reads

    Uniswap V3 pool configuration, slot0 pricing, paired ETH and locked position.

    Phase 02In Development
  • Swap flow indexing

    Swap events with direction, size, wallet and block ordering retained.

    Phase 02In Development
  • Onchain verification

    Fixed supply, lock state and pool configuration re-read before a claim is retained.

    Phase 02In Development
  • Creator history

    A creator address across its launches, fee accrual and claim behaviour.

    Phase 02In Development
  • Holder graph reconstruction

    Holder distribution derived from transfers, and overlap measured between launches.

    Phase 03Planned
  • Channel resolution

    The socials a token publishes on its own contract, resolved and weighted.

    Phase 03Planned
  • Venue coverage

    Trading venues on Robinhood Chain carrying the pair, and how depth is distributed.

    Phase 03Planned

Agent Coordination

How agents share context, hand off work and resolve disagreement.

  • Shared mission context

    Agents read one another's intermediate findings during a mission.

    Phase 03Planned
  • Agent handoffs

    Explicit transfer of a subtask between specialised agents.

    Phase 03Planned
  • Live mission monitoring

    Watch a running mission and redirect it before it finishes.

    Phase 03Planned

Platform

How the system is scheduled, extended and operated by a team.

  • Scheduled missions

    Re-run a mission on a cadence and compare against the last run.

    Phase 04Planned
  • Threshold alerts

    Alerts on graduation distance, wallet breadth or holder concentration crossing a stated line.

    Phase 04Planned
  • Team workspaces

    Shared missions, shared monitors and per-member permissions.

    Phase 04Planned
  • Developer API

    Programmatic mission creation and structured result retrieval.

    Phase 05Research
  • Custom agents

    Define an archetype with your own capabilities and read surfaces.

    Phase 05Research
  • Additional launch venues

    The same mission model pointed at launch venues beyond pons.

    Phase 05Research
08Product roadmap

One chain, read properly. Then coordination. Then scale.

Depth on pons beats shallow coverage of ten venues. The mission model ships complete first, because it is the part that ages worst when it is retro-fitted.
  1. Phase 01Now

    Live System

    The full mission model, running: objective language, decomposition, the one-to-three agent decision, the manufacturing sequence and a reconciled brief, all pointed at pons on Robinhood Chain.

    • Natural-language objectives with an inspectable parse
    • Objective decomposition into assignable subtasks
    • One-to-three agent selection with stated trade-offs
  2. Phase 02

    Chain Connectors

    Wire the read surfaces one at a time: factory launches, pool and pricing state, swap flow, creator history, and the onchain verification pass that gates every claim.

    • Factory launch indexing from TokenLaunched
    • Pool configuration, slot0 pricing and locked position reads
    • Swap flow indexing with direction, size and wallet retained
  3. Phase 03

    Coordinated Agents

    Move from agents that run beside each other to agents that work together on a shared context, plus the derived surfaces that need more than a single read.

    • Shared mission context across a running team
    • Agent handoffs with stated reasons
    • Live mission monitoring and redirection
  4. Phase 04

    Persistent Intelligence

    Turn a one-shot mission into a standing watch that compares block ranges and tells you what moved.

    • Scheduled missions on a block or time cadence
    • Run-to-run diffs as the primary output
    • Threshold alerts on graduation distance and holder concentration
  5. Phase 05

    Open Agent Platform

    Open the model up: programmatic missions, authored archetypes, and the same mission shape pointed at launch venues beyond pons.

    • Developer API for mission creation and retrieval
    • Custom agents with authored capabilities and scopes
    • Additional launch venues on the same mission model
White paper

VENDOR: Agent Teams for Onchain Launch Intelligence

A launchpad publishes almost everything worth knowing and organises almost none of it. pons on Robinhood Chain emits a launch event, exposes self-describing token contracts, pairs into a Uniswap V3 pool with a locked position, and publishes its graduation threshold, yet answering a question as ordinary as which launches are actually gaining ground still means reading four surfaces by hand and holding the result in your head. This paper describes an interaction model in which a user states an objective in plain language, the system decomposes it into assignable subtasks, recommends a team of one to three specialised agents scoped to specific read surfaces, and returns a single reconciled brief in which every claim carries its author, its source and its confidence.

  1. 01Executive summary
  2. 02The launchpad observability problem
  3. 03The pons surface
  4. 04Objective-driven agent assembly
  5. 05The vending-machine interaction model
  6. 06Objective decomposition
  7. 07One-to-three-agent teams
  8. 08Agent specialisation
  9. 09Multi-agent coordination
  10. 10Verification against chain state
  11. 11Proposed architecture
  12. 12Read-surface architecture
  13. 13Permission and safety model
  14. 14Data-handling principles
  15. 15Example use cases
  16. 16Roadmap
  17. 17Known challenges
  18. 18Future research
  19. 19Conclusion
Live

Point an agent team at the chain.

Access opens in cohorts as each read surface is wired. Tell us what you would point a mission at, and it shapes which surface lands first.