How VENDOR works, in detail.

VENDOR turns a stated objective into a small team of specialised agents, deploys them against pons on Robinhood Chain, and returns one reconciled brief. You describe what you want to know; the system produces the plan, assembles the team and organises the result.

It is built for one launchpad on one chain rather than for everything. pons launches fixed-supply tokens into Uniswap V3 pools paired against WETH, with liquidity held by a locker and a published graduation threshold. That is a narrow, well-specified surface, and a tool shaped around it can say things a general crawler cannot.

Robinhood Chain

An EVM Layer 2 built on the Arbitrum Orbit stack, settling to Ethereum with blob data availability. Gas is paid in ETH and there is no separate chain token. Mainnet runs at chain ID 4663.

pons

A token launch and trading platform on Robinhood Chain. Launches are non-custodial: every launch and trade is a transaction the creator or trader signs themselves.

Fixed supply

Every pons launch mints exactly one billion tokens with no further mint path, which makes supply a constant rather than a variable to track.

Launch window

A two-block protection window at launch restricts each wallet to 5.5% of supply, which shapes how the earliest cohort can form.

Graduation

A launch graduates once 4.2 ETH is paired in its locked pool. Distance to that threshold is the single most useful progress measure on the chain.

Fees and burns

A 1% pool fee splits 70/30 between creator and protocol on current launches. The protocol routes the large majority of its share into TWAP purchases of PONS that are permanently burned.

Community takeover

A mechanism by which a community can assume an abandoned launch's creator fees and social presence, which changes who a creator-based signal is actually tracking.

Objective

What you want to know, in your own words. The primary object in the system, and everything else hangs off it.

Subtask

One unit of work produced by decomposition, carrying the read surfaces it needs and the agent it is assigned to.

Archetype

A specialised agent defined by a role, a capability list and a source scope. Seven exist in the current model.

Mission plan

The reviewable artefact produced before anything runs: objective, decomposition, team, assignments, read surfaces and deliverables.

Mission brief

The single organised result: executive summary, findings with evidence, coverage map, patterns, graph, contributions, timeline and next actions.

1. 01Define: state the objective in natural language, or start from an example.
2. 02Analyze: the objective is parsed and decomposed into three to five subtasks.
3. 03Assemble: one to three agents are recommended; you confirm or change the team.
4. 04Manufacture: the selected compartments lock and the agents are built and released.
5. 05Plan: the full mission plan is shown for review. Nothing runs until you authorise it.
6. 06Deploy: agents enter separate corridors, work their subtasks and transmit progress.
7. 07Result: findings are reconciled into one brief with confidence and attribution.

The Plan stage is a deliberate checkpoint. It costs one screen and it is the only place where a misread objective can be caught before work is done against the wrong plan.

Decomposition produces three to five subtasks. Each carries a statement of what must be established, a note on what would count as establishing it, and the chain surfaces it needs.

Those surfaces are the important part. They convert agent recommendation from a name match into a routing decision: an archetype is proposed because its declared scope covers what a subtask has to read.

• Fewer than three subtasks usually means the objective was restated rather than analysed.
• More than five turns the plan into task management that you have to supervise.
• Subtasks are shown before team assembly, so the plan can be rejected early.

A recommended team is proposed from the decomposition. You can accept it, change it, or build your own from the archetypes relevant to the objective. The team is capped at three.

• One agent: fastest, narrowest coverage, no independent corroboration.
• Two agents: one finding and one check on it, with a single exchange.
• Three agents: widest surface coverage and full cross-agent exchange.

The brief reflects the choice. Overall confidence is scaled by team size, and any line of enquiry the chosen team could not cover is listed explicitly in the result rather than omitted.

Specialisation is enforced by scope rather than by instruction. Each archetype declares the read surfaces it may draw on, which is what makes its output auditable and its attribution meaningful.

• SCOUT reads factory launch events and token metadata to open the search space.
• ANALYST reads swap flow and pool state for trade structure.
• VERIFIER re-reads chain state to confirm or downgrade every claim.
• SIGNAL measures pairing velocity and buy pressure against the graduation threshold.
• CHAIN resolves the contract surface: factory, pool, locker and creator.
• MAPPER builds the creator, token and holder graph.
• SYNTH reconciles the team's output into one brief.

• Shared mission context: an append-only record of intermediate findings that every agent writes to during execution.
• Handoffs: transfers between agents that carry the reason for the transfer, so the trace is readable afterwards.
• Preserved disagreement: when two agents conflict, the brief reports the conflict instead of averaging it away.

SYNTH performs reconciliation. It deliberately has almost no independent read scope: giving the synthesiser collection powers would let it quietly become the only agent whose output matters.

• Executive summary: the structural answer, not a restatement of the objective.
• Key findings: each attributed to an agent, with expandable evidence and a confidence value.
• Coverage map: which read surfaces the mission actually drew on, and in what proportion.
• Emerging patterns: movement indicators with direction and magnitude.
• Relationship graph: entities and typed, weighted connections between them.
• Agent contributions: what each agent did, how much it reviewed, and how confident it was.
• Timeline: the order in which the mission's conclusions were reached.
• Suggested next actions: concrete follow-ups implied by the findings.

Confidence appears next to the claim, not in a methodology footnote. A finding that could not be matched to chain state is retained at reduced confidence and marked, rather than being silently dropped.

Live

Shipped and usable in the current release.

In Development

Actively being built and rolling out. Named in the roadmap with a phase attached.

Planned

Committed to a named phase with a defined scope. Design work may be underway; implementation has not started.

Research

An open design question. The direction is described honestly, with no delivery commitment attached.

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.

• Launch Events: TokenLaunched emissions from the pons factory.
• Pool State: pool configuration, slot0 pricing, paired ETH and locked position.
• Swap Flow: swap direction, size, wallet and block ordering.
• Token Metadata: name, symbol, logo, description, socials and pool, read from the token contract.
• Creator History: a creator address across its launches and fee claims.
• Holder Graph: distribution derived from transfers, and overlap between launches.
• Chain State: balances, code, storage and block ordering read from the node.
• Protocol Reference: the published pons launch, graduation and fee mechanics.

Failure is a first-class output. When a surface cannot be reached, the mission records the gap and the brief reports reduced coverage. Silent partial collection is the most dangerous failure mode a research tool can have.

• No key custody. VENDOR holds no keys and signs nothing.
• No wallet connection is required or requested for any capability.
• No transaction is ever constructed, simulated for submission, or broadcast.
• Agent scope is enforced per archetype: an agent cannot reach a surface it does not declare.
• No secrets are embedded in the client, and the mission experience makes no authenticated third-party requests.

Read-only is the design, not a stage. VENDOR reports on the chain; it never touches it.

Every surface VENDOR reads is public. Public chain state, public contracts, public events and published protocol reference. There is no privileged access to request and nothing to grant.

• Nothing acts on your behalf. VENDOR reports; you decide.
• Account features in later phases scope to your own missions and monitors.
• Any grant you give can be revoked, and revocation takes effect for in-flight missions.

• Public sources only. Nothing is collected from behind an access barrier.
• Provenance travels with the finding and is never stripped during summarisation.
• Addresses are analysed as onchain entities, not as attempts to identify a person.
• Collected material is scoped to the mission that collected it.
• You can see what was reached, what was skipped, and why.

1. 01A claim is proposed by the agent that found it, with the surface it came from.
2. 02VERIFIER re-reads the underlying chain state rather than trusting the first read.
3. 03Claims confirmed against state are retained at full confidence with the read recorded.
4. 04Claims that cannot be confirmed are retained at reduced confidence and marked.
5. 05Contradicted claims are retained together with the contradiction, not deleted.
6. 06Every downgrade appears in the brief with its reason.

A research tool that silently discards what it could not verify is indistinguishable from one that never checked.