The mechanism, not the pitch.

A finch is not a chatbot with a personality. It is a finch.json document — identity, model, memory, tools, permissions, wallet, triggers, budget — and a runtime that executes it. The document is the agent: you can read it, diff it, fork it, publish it, and run it somewhere else. Nothing about a finch requires this website to exist.

{
  "schema": "finch.manifest/0.1",
  "identity": { "name": "Network Scout", "handle": "network-scout",
                "instructions": "Report live chain figures…" },
  "model":    { "provider": "hyperbolic", "model": "meta-llama/Llama-3.3-70B-Instruct" },
  "memory":   { "kind": "none" },
  "tools":    { "flightpath": ["network_status"], "services": [] },
  "permissions": { "allowWrites": false, "rwaApprovedOnly": true },
  "wallet":   { "mode": "observer", "allowances": [], "allowedContracts": [] },
  "budget":   { "maxToolStepsPerRun": 5, "killSwitch": { "maxConsecutiveFailures": 3 } },
  "supportedChains": [4663]
}

Hatching resolves that document against live infrastructure and returns a bound runtime. The loop is deliberately small: recall memory, call the model with the declared tools, execute any tool calls, feed observations back, repeat until the model stops calling tools or the step budget runs out.

narrow by design

One finch does one thing. Specialization is what makes composition legible — you can reason about what a Network Scout will do.

permissions can't self-widen

Write tools are stripped at hatch unless the wallet grants operator mode. A manifest cannot grant itself authority it wasn't given.

provider-abstracted

The model is a reference, not a dependency. Hyperbolic today; any OpenAI-compatible endpoint by changing two fields.

bounded

Step caps, daily action and credit budgets, and a kill switch that stops the finch after N consecutive tool failures.

A nest is the coordinated swarm — many finches aligned to one objective. What aligns them is not a conversation; it is a directed acyclic graph. Each task names the finch that performs it, the tasks it depends on, and the typed channel it publishes on. A task's instruction can reference upstream channels with {{channel}}, and the coordinator substitutes the producing task's real output before the finch ever sees it.

{
  "schema": "nest.manifest/0.1",
  "identity": { "id": "chain-intelligence",
                "objective": "Assess the state of Robinhood Chain for agents executing there." },
  "coordinator": { "model": {…}, "synthesize": true },
  "finches": [ { "handle": "network-scout", "manifest": { …a full finch.json… } }, … ],
  "tasks": [
    { "id": "t1", "finch": "network-scout", "dependsOn": [],
      "instruction": "Report the current live status of Robinhood Chain.",
      "outputChannel": "chain.status" },
    { "id": "t4", "finch": "risk-finch", "dependsOn": ["t2", "t3"],
      "instruction": "Chain status:\n{{chain.status}}\n\nBlock profile:\n{{block.profile}}…",
      "outputChannel": "risk.assessment" }
  ],
  "executionPolicy": { "mode": "preview", "maxParallel": 3, "maxTaskFailures": 2 }
}

The scheduler is plain topological execution: validate the graph (unknown finch, unknown dependency, duplicate channel, cycle — all rejected before anything runs), then repeatedly execute the wave of tasks whose dependencies have all published. Waves are bounded by maxParallel; the run halts on the failure or token limits in the execution policy.

typed channels, not shared memory

Tasks communicate through named channels with one producer each. That's what makes a nest's data flow auditable after the fact.

failure propagates honestly

If a task fails, its channel is never published and downstream tasks are marked skipped — not fed a plausible substitute.

synthesis reads terminals

The coordinator summarizes only from channels that actually exist, and is instructed to say when the outputs are insufficient.

portable

A nest.json carries its members' full finch manifests. Export it, run it yourself with runNest() from @finch/sdk.

You can watch this happen: run a nest and every task shows its resolved input, its output, its token cost, its duration, and which tools it called.

Reading Robinhood Chain is unremarkable — balances, tokens, contracts, blocks. Writing is where agent systems usually get dishonest, so Finch has exactly one write path and no way around it. An intent is constructed, checked against policy, simulated, optionally gated on a human, submitted, and only then — after a receipt — reported as confirmed.

three modes, always stated

PREVIEW: no wallet, read-only. SIMULATE: build the real transaction and simulate it against current state, no broadcast. LIVE: broadcast, receipt-gated.

simulation is not optional

estimateGas plus an eth_call, before signing. A revert surfaces its reason and the intent stops there.

idempotent

Every execution carries an id with a unique index behind it. Replaying returns the stored record instead of sending a second transaction.

EVM-native

Robinhood Chain is an Arbitrum Nitro L2 (id 4663). One intent, one transaction — no bundling exotica borrowed from other ecosystems.

What is live today: chain reads run against Robinhood mainnet right now — that is where the block height on the home page comes from. Write modes (simulate, live) are implemented in the execution layer but stay closed in the product until the audit checklist is signed off; nests run read-only, and the UI says so rather than showing a button that would lie.

The uncomfortable question about autonomous agents is what happens when one is wrong. Finch answers it structurally: an agent's authority is a bounded float, not a wallet. A human owner funds OperatorBudget.sol with a small amount and sets per-operator, per-token, per-epoch caps onchain. The agent operates a restricted wallet that can only spend inside those caps, and the owner can pause, revoke or sweep at any moment.

Offchain, the PolicyEngine mirrors the same limits and adds the ones a contract can't express: recipient and contract allowlists, per-transaction caps, and an approval threshold above which a spend pauses at awaiting_approval until a human signs off. Approvals count against allowances, because an approval is spendable authority. RWA interactions are hard-limited to an explicitly approved registry, and that gate cannot be waived from a manifest.

A finch or a nest registers on Robinhood Chain through FinchRegistry.sol: an id, an owner, a manifest hash, a manifest URI, a version and a status — all event-emitting, all permissionless. The manifest body lives offchain where large data belongs; the hash onchain is what makes it verifiable.

MongoDB indexes those events so the Aviary can search quickly. It is a cache, not an authority: if this site disappeared, another developer could rebuild the registry from chain 4663 events alone. That is the difference between a network and a database with a website in front of it.

Proof of Flight extends the same idea to actions: a meaningful live execution produces a receipt binding the finch id, nest id, task id, action, chain, transaction, block, status and execution policy — so what an agent did is checkable by someone who doesn't trust the operator.

$FINCH launches through Pons on Robinhood Chain with a 3% creator tax to the Finch fee wallet. That single stream funds infrastructure, compute, hosting, RPC, indexing and development. Pons' own protocol fees are separate and are never counted as Finch revenue.

The token is deliberately not a tollbooth. The SDK, manifests, self-hosting, Aviary browsing, Flight School previews and public chain reads stay free — a network nobody can use without paying first is not a network. Metered consumption (hosted finches, sustained nest workloads, premium data) and publisher earnings are designed, accounted for in the data layer, and switched off until the contracts exist.

Launch signing is currently blocked by a guard: it will not sign until it can verify onchain that the deployed Pons version permits 300 bps to our fee recipient. If it can't verify, it refuses and shows why — it never silently falls back to a different rate.

Most of the engineering in Finch is refusal. These are enforced in code, not in a style guide:

never fake a confirmation

An HTTP 200 is not a transaction receipt. Confirmed state renders only from a receipt with a block number.

never invent metrics

The network page shows the registry's real counts. If the network holds sixteen finches, it says sixteen.

never hide provenance

Seed and demo data carry a badge everywhere they appear, and every task in a nest run shows exactly what its finch was given.

never a dead button

A control works, is visibly disabled, or states that it is not available yet — with the reason.

never leak a key

The fee-wallet key exists only as a server secret read by one module. Providers and Flightpath throw if constructed in a browser.

never widen its own authority

Manifests cannot grant themselves permissions; the RWA gate and mandatory simulation cannot be switched off from configuration.