How Earbit works

01Product mechanics

A Mind is three things created together by one factory transaction:

• A token: a plain, fixed-supply ERC-20 with permit. No owner, no minting, no pause, no blocklist, no transfer tax, no upgrade. The whole supply goes to the owner’s wallet or to the vault, chosen at launch.
• A treasury vault: one EarbitTreasuryVault per Mind. It holds ETH and ERC-20 tokens and executes only actions that pass its policy.
• The Earbit Mind: an AI agent that reads balances and events, estimates runway and proposes treasury actions. It holds no keys and cannot move funds by itself.

The operating loop

1. Read current state: balances, recent events and the vault’s live policy, from the chain.
2. Generate a structured proposal: one bounded action with its rationale, or a decision to hold or abstain.
3. Validate the policy: the same rules the vault enforces, re-checked off-chain with readable reasons.
4. Simulate the exact transaction against current chain state.
5. Obtain approval if required: in Manual mode the owner signs the exact action.
6. The isolated signer revalidates: a separate process with its own key re-reads the chain and runs the checks again.
7. Submit: the signer sends the transaction as the vault’s authorized executor.
8. Track the receipt: the hash is stored on submission and followed to confirmation or failure.
9. Reconcile state: balances, daily spending and the Activity Log are reconciled with the chain.

The loop runs at each Mind’s cadence, every 15 minutes to 24 hours (60 minutes by default). One run reads at most 12,000 input tokens and writes at most 8,192, and times out after 120 seconds.

Proposals

The Mind answers in a strict schema: a decision (propose, hold or abstain), a short summary, the facts it relied on, a runway estimate with its assumptions, a confidence level, its data concerns and, when it proposes, exactly one action. An answer that does not parse is rejected, never repaired. An action is one of three types: transfer (to an allowlisted recipient), fund compute (pay the compute receiver for Earbit Credits) and swap (only through a reviewed adapter, when one is configured). Amounts are integers in the asset’s base units. A Mind has at most 3 open proposals at a time.

Proposal statuses

proposed (Proposed)

The Mind produced a proposal that parsed against the strict schema; validation has not finished.

rejected (Rejected)

A policy check, the simulation or the signer’s revalidation failed. The failing checks are recorded with the proposal.

awaiting_approval (Awaiting approval)

Valid in Manual mode; waiting for the owner’s signature over the exact action.

approved (Approved)

Signed by the owner (Manual) or allowed by the policy (Bounded automatic); queued for the isolated signer.

submitted (Submitted)

The signer broadcast the transaction; its hash is stored.

confirmed (Confirmed)

The receipt shows success and balances, spending and the Activity Log were reconciled.

failed (Failed)

The transaction reverted or could not be submitted.

expired (Expired)

Its expiry passed before it executed (proposals expire after 30 minutes).

02Execution modes and defaults

• Observe (mode 0): proposals only. The vault refuses every execution, even one carrying a signature.
• Manual (mode 1): each valid proposal waits for the owner, who approves it by signing the exact action. Without a valid owner signature the vault refuses it.
• Bounded automatic (mode 2): valid, allowlisted actions execute within the limits without a signature.

New Minds default to Observe or Manual. Bounded automatic needs the owner’s explicit activation, and because raising the mode widens what the Mind may do, the switch is queued for the vault’s change delay before it takes effect. Stepping the mode down is immediate.

03Permissions

What the vault enforces on every execution

These checks run inside the vault contract, in this order, on every call to execute. The worker and the signer run the same checks first, but the chain is the authority.

1. The caller is the authorized executor (the isolated signer’s address); anyone else, the owner included, is refused.
2. The vault is not paused.
3. The mode is not Observe.
4. The action’s nonce equals the vault’s next nonce (each action runs once, in order), its expiry is in the future, and its policy version equals the current one.
5. In Manual mode, a valid signature by the owner over the exact action (EIP-712; ERC-1271 contract wallets are accepted).
6. The action type is allowed, the amount is above zero and the asset is allowed.
7. The amount is within the asset’s per-transaction limit.
8. The amount fits in what is left of the asset’s daily limit (an aggregate per asset per UTC day, across all actions).
9. The balance after the action stays at or above the asset’s minimum reserve.
10. Transfer: the recipient is allowlisted. Fund compute: the target is the configured compute receiver. Swap: the target is the configured swap adapter, the output asset is allowed and differs from the input, and at least the minimum output arrives.

The vault updates its nonce and spending counters before it moves funds, and refuses re-entry while an action runs.

Approvals are bound

An owner approval is an EIP-712 signature over the whole action — type, asset, amount, recipient, output asset and minimum, nonce, expiry, policy version and proposal id — in a domain that names the chain and the vault. It is valid for that payload, on that chain, for that vault, at that nonce and that policy version, and for nothing else. Any applied policy change increments the policy version and invalidates every earlier approval. Manual approval never bypasses hard limits: a signed action that breaks a rule is refused like any other.

The administrator’s powers

• Tighten immediately: disallow an asset, lower a per-transaction or daily limit, raise a reserve, remove a recipient or an action type, lower the mode, clear the executor or an adapter.
• Expand after the delay: allowing an asset, raising a limit, lowering a reserve, allowing a recipient or an action type, raising the mode, or setting the executor, compute receiver or swap adapter is queued for the vault’s change delay. The delay is fixed when the vault is created: at least 10 minutes, at most 30 days. The owner applies a queued change after it matures, or cancels it.
• Pause and unpause immediately. Unpausing restores the same bounded policy; it is not an expansion.
• Emergency withdrawal: the owner can withdraw any amount of any asset to any address at any time, ignoring the limits. Every withdrawal emits an event, and every Mind’s public page states that this power exists.
• Transfer ownership in two steps: the new owner accepts after the change delay; the current owner can cancel before that.

The isolated signer

The signer is a separate process with its own key; it is the only process that sees that key. For every request it recomputes the action hash and refuses a mismatch, requires the policy version the approval was given for to equal the chain’s, re-reads the vault and runs the checks again. It records proposal id → transaction hash, so a repeated request returns the earlier submission instead of sending twice. A separate signer is an additional control, not a substitute for vault enforcement.

04Earbit Credits

Earbit Credits pay for the Mind’s model computation. 1 credit = USD 0.001 of metered compute. They are service credits, not a token: they cannot be transferred, traded or redeemed for anything but computation on this deployment. The ledger works in integer micro-USD, so it never accumulates rounding error.

Charging

A run is charged the provider’s list price for the tokens it used plus a 20% service markup, rounded up to the next whole credit. Before a run starts, its maximum possible cost is reserved; when it ends, the actual cost is settled and the rest of the reservation is released. A reservation is refused when the balance is short or when the Mind’s daily compute budget (2,000 credits by default) would be exceeded.

Credits per million tokens, markup included (provider list prices verified 2026-10-07). The largest reservation is the cost of a run that uses its whole input and output allowance with every input token written to the cache.

Buying credits

Credits are bought by paying the network’s compute receiver (EarbitComputeReceiver), either from a wallet or by the vault through a fund-compute action that passed the policy. ETH is valued in USD with the on-chain ETH/USD price feed (Chainlink on Robinhood Chain); USDG is counted 1:1 as USD, a stated assumption for an issuer-backed stablecoin. The USD value is converted into credits rounded down, so a buyer never receives more than they paid for. Each payment is credited once: the ledger keys it by chain, transaction and log index. When no compute receiver is configured for the network, purchasing is disabled and the interface says so.

Refunds

A run that fails before producing anything releases its whole reservation. Nothing is refunded off-platform: credits are not redeemable for money or tokens.

Out of credits

When the balance cannot cover a run, analysis stops and the Mind’s status becomes out of credits. The treasury stays readable on its public page, and every owner control — pause, policy changes, emergency withdrawal — stays available.

05Trading fee funding

Fee funding exists only through a verified Uniswap V3 position attached to an EarbitFeePosition contract. That contract holds the position NFT for one vault; anyone can call its collect function, which sends the fees the position earned to the vault and emits a FeesCollected event. The NFT can never leave the contract: the liquidity is locked for good, so an owner who wants their liquidity back should not attach a position.

• Counted as fee income: fees collected from that position into the vault.
• Never counted: the position’s principal (its liquidity), deposits to the vault, or transfers from anyone else.
• Duplicate events never double-credit: each event is recorded once by chain, transaction and log index.

Fee income sits in the vault like any other balance. Turning it into credits is a fund-compute action, bounded by the same policy and recorded in public.

Uniswap V3 is available where its official registry lists a deployment: Robinhood Chain — yes; Robinhood Chain Testnet — no; Local Anvil — no. Where no verified position is configured, the interface says: Automatic fee funding unavailable. Manual funding is available where configured.

Fee income depends on trading activity in a real market. Nothing here guarantees profitability or that a Mind keeps funding itself.

06Public accountability

Every Mind has a public page: its token and vault, the policy as read from the chain (assets and limits, recipients, action types, mode, pause state, executor, change delay and queued changes), the owner’s emergency withdrawal power, balances, proposals with their checks and outcomes, transactions with explorer links, credits, and the Activity Log. Four kinds of information are kept apart and labelled:

• On-chain facts: balances, policy, transactions and events read from Robinhood Chain.
• Model summaries: what the Mind wrote — summary, rationale, runway reasoning. Useful and possibly wrong; nothing executes on their strength alone.
• Estimates: USD valuations and runway, shown with their source and assumptions. The vault’s limits are always in native asset units, never in USD.
• Indexing delay: indexed data trails the chain (2 confirmations, 5,000-block read windows); pages show how fresh it is and mark stale data.

The Activity Log records runs, proposals, approvals, executions, policy changes, deposits, withdrawals, credit movements, fee collections, status changes and launches. The sphere on a Mind’s page animates its real state, derived from these records, never from a timer.

07Setup

Local development runs the full stack on one machine. Requirements: Node 20 or newer, pnpm 9, and Foundry (forge and anvil). In separate terminals, in this order:

pnpm install

Dependencies (pnpm 9, Node 20 or newer).

pnpm contracts:build

Compiles the Solidity with Foundry (forge) and exports the ABIs and bytecode into src/protocol.

pnpm db:dev

Embedded PostgreSQL on 127.0.0.1:15861 (data in .data/pg), so web, worker and signer run as separate processes, as in production. Keep it running.

pnpm chain:local

Anvil on 127.0.0.1:9421 (chain 31337, 1 s blocks): deploys the contracts and the development fixtures, checks the factory’s runtime bytecode against the build, writes config/deployments/local.json and .env.local-chain. Keep it running.

pnpm dev:local

The web app against the local chain on http://127.0.0.1:23310.

pnpm worker:local

The agent worker: scheduled analysis, validation, receipt tracking, indexing and reconciliation. Health on 127.0.0.1:23340.

pnpm signer:local

The isolated signer on 127.0.0.1:23330, holding Anvil’s published test key #1 as the executor.

pnpm stack:local starts all of them in one terminal, in dependency order. The development chain is refused in production and on Vercel; its mock price feed, mock USDG and mock adapters are labelled development fixtures.

Environment

Copy .env.example to .env.local and never commit real values. Three processes read it: the web app, the worker and the signer.

NEXT_PUBLIC_NETWORKall

Target network of this build: robinhood (chain 4663, the default), robinhood-testnet (46630) or local (Anvil). One build, one network.

NEXT_PUBLIC_SITE_URLweb

Public origin of the deployment: metadata, the sign-in message domain check and the same-origin guard.

DATABASE_URLweb, worker, signer

postgres://… in production and for the local multi-process stack (pnpm db:dev serves 127.0.0.1:15861). pglite://<dir> works for a single-process, web-only session; tests use pglite://memory.

DB_AUTO_MIGRATEweb, worker

Set to 0 to stop pending migrations from being applied on first use; then run pnpm db:migrate yourself.

SESSION_SECRETweb

32 or more random bytes. Development derives a stable fallback; production refuses to start without it.

RPC_UPSTREAM_URLweb, worker, signer

Server-side RPC used by /api/rpc, the worker and the signer. Defaults to the network’s public RPC, which is rate limited; use a provider endpoint in production.

UPSTREAM_DOHweb, worker, signer

Set to 1 on machines whose DNS resolver hijacks *.robinhood.com: the RPC host is then resolved over DNS-over-HTTPS.

AI_PROVIDERworker

anthropic. The value double is a scripted development stand-in and is refused in production.

AI_MODELworker

The model; it needs a price in config/credits.json (claude-opus-5-5, claude-sonnet-5-5, claude-haiku-4-5).

ANTHROPIC_API_KEYworker

Without it the worker refuses paid runs and the app says the model provider is not configured.

AI_EFFORTworker

low, medium or high: the model’s thinking depth, which affects cost.

WORKER_ID · WORKER_POLL_MS · WORKER_HEALTH_PORTworker

Name recorded on job leases (host + pid by default), queue poll interval (2000 ms), health endpoint port (23340, GET /health on 127.0.0.1).

SIGNER_URL · SIGNER_TOKENworker, signer

Where the worker reaches the signer (http://127.0.0.1:23330 by default) and their shared bearer token.

SIGNER_PRIVATE_KEYsigner only

The executor key. Local development uses Anvil’s published test key, written by pnpm chain:local. Production: a dedicated key in a managed secret store, or SIGNER_BACKEND=remote with a KMS adapter.

SIGNER_PORT · SIGNER_STATE_DIRsigner

Listening port (23330) and the directory of idempotency records (proposal id → transaction hash) that survive restarts (.data/signer).

CREDITS_DAILY_BUDGET_DEFAULTworker

Default daily compute budget per Mind, in credits (2,000 when unset).

MAINNET_LAUNCHESweb

Launching on mainnet needs this switch AND a verified factory record (config/deployments/robinhood.json, written by pnpm contracts:verify-deployment).

Networks

08Deployment requirements

• Three processes. The web app can run serverless (for example on Vercel). The worker and the signer cannot: they are long-running processes — job leases, receipt tracking, the signer’s HTTP endpoint — that need a host with a persistent process and a secret store. A serverless frontend alone is not sufficient: without the worker nothing is analysed, validated or tracked, and without the signer nothing executes.
• PostgreSQL shared by all three. PGlite is a development database and is refused in production.
• A provider RPC endpoint. The public endpoint is rate limited and not recommended for production; historical indexing needs an archive endpoint.
• Keys. The executor key lives only in the signer’s environment (a separate host or secret scope), never in the web app. Production keys never appear in source control, in the browser or in logs. SESSION_SECRET is required in production.
• Contracts. The operator deploys the factory and the compute receiver, then runs pnpm contracts:verify-deployment, which compares the on-chain runtime bytecode with the build and writes the deployment record. Launches stay disabled until a verified record exists; on mainnet they also need MAINNET_LAUNCHES=1.

No mainnet deployment happens without the operator’s explicit authorization.

09Limitations

• The contracts are tested (a Foundry suite covering every rule above), not audited.
• Public RPC endpoints are rate limited and serve recent state only; reads can fail or lag, and pages say so instead of guessing.
• USD valuations are estimates from a price feed (stablecoins at 1:1). Limits are enforced in native units.
• Indexed data trails the chain by confirmations and polling; the newest events can be missing for a while.
• The Mind’s output can be wrong. It is advisory; the rules, the owner and the vault decide what executes.
• Fee income depends on trading activity in a real market. Nothing here guarantees profitability or that a Mind keeps funding itself.
• On the testnet there is no Uniswap deployment and no price feed: no fee source and no on-chain USD valuation.
• No mainnet deployment without explicit operator authorization.

Questions about a specific Mind are best answered by its public page and its Activity Log. Explore Minds or read the service status.

10$EARBIT token

$EARBIT is Earbit’s own community token on Robinhood Chain. It is separate from every Mind’s token: no Mind needs it, nothing on this site requires it, and it is not equity, not a claim on any treasury or revenue and not a promise of returns.

• The contract address is shown on the token page, in the header and in the footer. Until it is published every surface says “CA: Soon”, and any contract that calls itself $EARBIT before that is not the Earbit token.
• The address is published by an operator script (pnpm token:ca 0x…) that first reads the contract on Robinhood Chain (code, name, symbol, decimals, total supply) and refuses Earbit’s own contract addresses; nothing is typed in by hand.
• Once published, the token page reads name, symbol, decimals and supply from the contract on every visit (60 s cache) and links the explorer.
• Announcements come only from @EarbitHood on X and this site.