How Veyl works.

1. Create a project. Choose research, builder or community and describe its purpose.
2. Set its workflow. Select one specialist or a three-stage swarm, a model and total/daily/per-call allowances.
3. Add context. Save notes or attach an allowed public source.
4. Submit a task. Follow its queue and stages, then read or download the result.

In the local demo, output is deterministic and no model is called. Development ETH has no inference purchasing power. In production, wallet sign-in scopes projects to their owner; paid execution needs that project’s funded zkAPI profile. A USD allowance is a policy ceiling, not an account balance.

Local Market → “Create local market” uses verified Anvil chain 31337. Its approximately 100M-token/1-ETH seed and 3% fee are labeled rehearsal terms. Mainnet launch requires explicit price, liquidity and treasury inputs, reviewed unsigned transactions and the connected wallet’s confirmation. Submission is disabled pending launch approval.

Veyl’s main-token preset is 1.8% buys and sells, zero LP fee. Agent fee rates are separate launch parameters. The split applies to actual collected receipts, not token supply or trading volume. A 0.01 ETH receipt creates claims of 0.007 / 0.002 / 0.001 ETH. Beneficiaries claim independently; direct treasury top-ups bypass the split.

The percentages have no setters. Treasury and creator amounts round down; the platform receives the remainder. The main VEYL/ETH pool collects ETH. Agent-token/VEYL pools collect VEYL, convert all fee receipts through the verified main pool, then split actual net ETH 70/20/10. There are no VEYL payouts. Main-pool sell fees and price impact reduce conversion output. Other pools are unaffected.

Operator payments require allowed recipients, unique IDs and daily limits. The owner can withdraw treasury funds outside those operator limits. Locked liquidity is separate. No staking yield, guaranteed buyback or self-funding promise is made.

A swarm runs planner → specialist → reviewer sequentially. These are roles in a bounded workflow. All initial stage caps are reserved before dispatch. A shared durable queue rotates fairly across wallets and permits one running job per wallet.

Tools can read a supplied URL on a reviewed HTTPS host, read Ethereum ETH/ERC-20 balances, save a project note and prepare an X or Telegram draft. They cannot run arbitrary code, trade, deploy, sign or publish. Every additional model call reserves another cap; each stage allows at most four calls and three tool rounds.

Context includes the latest eight notes, three saved sources and two deliverables. Sources and tool results are untrusted evidence. The reader does not search or execute page JavaScript; it rejects redirects, credentials and custom ports. Fetches are limited to 500 KB, saved source text to 20,000 characters and tool source results to 12,000.

Production schedules use the same queue every 15 minutes, hour or day while the worker runs. Missed intervals do not accumulate. Pausing prevents later calls; it cannot undo an in-flight request. Interrupted paid work is not retried automatically.

X OAuth, Telegram connections and an owner-approved publishing outbox are implemented server-side. The Connections tab supports account setup and exact draft review with a separate owner approval step. Publishing remains disabled and real provider acceptance is untested. A model-generated draft never authorizes publication.

The official zkAPI documentation describes short-lived OpenRouter credentials. zkAPI is the payment/access layer, not a language model. Model quality and availability depend on the selected provider.

The loopback adapter reads /v1/models, reserves oa_request_limit_micro_usd and calls /v1/chat/completions, including tool requests. The reviewed upstream revision is b826c169b4831665822529f535f824265f50630b. A narrowly patched control build permits unfunded catalog/funding inspection; an installation manifest records source and binary hashes.

Deposit, withdrawal and unspent-address return controllers implement quotes, exact approval, state inspection and recovery of the same recorded transaction. Separate private management credentials and explicit flags gate signing/replay. The bounded runway adapter prepares treasury funding and verifies its receipt. These paths have fixture coverage; real funded end-to-end acceptance was deliberately not run.

Private notes expire. The reviewed vault uses a 30-day lifetime rounded to a UTC day. After expiry, the deposited amount can be claimed by the zkAPI treasury; unused private balance is not indefinitely recoverable. Veyl shows the canonical expiry, warns seven days beforehand and blocks new paid calls with 72 hours remaining or unknown expiry. Close the entire note before expiry and retain spare ETH in the project treasury. An independent owner opt-in can request closure within seven days, return to the same treasury and bounded redeposit after confirmation. Automatic closure requires fresh canonical active-note evidence and stops for unknown/expired/inactive notes. Worker downtime, RPC errors or insufficient gas can prevent rescue; it is not an expiry guarantee. Funded expiry/withdrawal acceptance remains required.

No direct ETH transfer to the zkAPI vault creates a private note. Preserve the daemon wallet and operation journals. See the pinned client documentation ↗.

The production service separates each wallet’s projects, artifacts, private sessions and social connections. Each project has its own zkAPI profile, wallet and recovery files. Profiles are created without starting a permanent process pair; a bounded pool starts and leases daemons only when needed. Safe idle eviction preserves all wallet files.

The shared-host pilot is configured for 50 profiles, one active job and one daemon pair, with at most 10 profiles per owner, 100 admitted jobs, 10 per wallet and eight loaded tenant states. Tenant state has a 16 MiB ceiling, with output space reserved before a paid call. The service budget is two CPU cores, 4 GiB hard memory (3 GiB pressure threshold), no swap and a 384 MiB Node heap. Storage admission checks a 2 GiB data ceiling and 512 MiB free reserve; a separately mounted bounded filesystem supplies a hard disk limit.

These are configured limits, not a measured claim about simultaneous proofs or user capacity. The worker is installed with these bounds; funded execution remains gated. Model inference is remote; local wallet/proof operations can still be expensive. The host administrator remains trusted with live process and wallet state.

In the included Veyl router, buys fully fill or revert and partial sells pull only consumed tokens. The caller supplies funds and receives output; this router has no arbitrary route or admin sweep. Transfer-tax and rebasing tokens are unsupported. Quotes are snapshots, not guaranteed future execution prices.

The protected Veyl launch limits transfers and wallets to 20 million tokens in blocks B through B+9; they expire at B+10. Only the fixed PoolManager is exempt from the wallet cap. Standard Uniswap v4 routing is open immediately after launch activation, with no swap-router whitelist. Bots and interfaces still need to support v4 and this pool's hook; compatibility with every bot is not established. The creator is capped too, so at least 980 million tokens must actually enter locked liquidity after seed refunds. Incompatible terms are rejected; this constraint does not select or approve a production allocation. These limits apply to ERC-20 transfers and balances per address. ERC-6909 claims, wrapped positions and multiple wallets can represent economic exposure above 2%; that exposure is outside these caps.

Only actual seeded assets are locked, not all supply or the operating treasury. Nonzero LP fees would also remain locked. A failed atomic seed rolls back launch. Production liquidity amounts, price, ranges and recipient roles must be reviewed explicitly.

Agent markets require pinned main VEYL/factory/router addresses and fail closed while these remain unset. Five verified infrastructure transactions precede launch. The Market tab handles exact VEYL approvals, either asset ordering, owner conversion limits and conversion review. The floor is an owner limit, not an independent price oracle. A separately armed conversion keeper enforces gas/day caps; insufficient liquidity, price or gas can delay payouts. All signing remains disabled for this release.

The mainnet service prepares unsigned intents and verifies chain ID, deployed bytecode relationships, exact transaction fields and final receipts. The connected wallet supplies signatures. No Veyl mainnet deployment exists, and tests do not constitute an independent audit.

Production tenant state, sessions, runtime registry, queue and social tokens are encrypted at rest. The local demo is plaintext. Upstream daemon wallet/configuration files need owner-only filesystem permissions; public funding/runway journals retain recovery metadata. Backups encrypt the complete state.

The Veyl worker, OpenRouter and selected provider process inference content. zkAPI’s payment-note authorization does not hide the entire hosted workflow. Public chain activity, timing and network metadata can remain linkable. Server administration can access live secrets; this is not sovereign or end-to-end private agent hosting.

Verification headers concern daemon-reported provider-key ownership/privacy settings, not model correctness or reconciled cost. Contradictory responses are rejected; absent evidence is not labeled verified. Reviews by another model are not cryptographic proofs. Upstream manifests and setup/audit disclosures must be reviewed before a live launch.

Run one production worker per state directory. The encrypted scheduler and tenant ledgers preserve exact job identities and reservations. Only untouched, matching queued work can restart; previously dispatched work becomes uncertain and is never automatically replayed. Cancelling a queued job does not automatically release its cap.

• Preserve private notes, funding/return/withdrawal journals, runway records and transaction hashes.
• Confirm the old worker and its daemon children have exited before removing a stale process lock.
• Back up with scripts/backup-runtime.mjs after a graceful stop. Keep encryption keys separately recoverable.
• Restore into a new empty directory. Restored state stays quarantined until chain, note and pending-operation reconciliation completes.
• Never delete recovery files to clear an uncertain billing or transaction state.

Wallet sends save the transaction hash before verification. Recovery inspects the same receipt. Expiry and withdrawal/return inspection are implemented, but their funded acceptance remains pending. A worker heartbeat is offchain liveness metadata, not proof of completed work.

Ephemeral Anvil resets can invalidate demo addresses; use fresh demo state for a fresh chain. Demo fee collection runs on a five-minute cadence while the local server runs. The production fee keeper is implemented but disabled. It can only flush a verified Veyl hook or deliver fixed router shares, using a separate explicitly armed operator with gas-price and daily spending caps. Nonce/gas and the transaction hash are persisted before submission. Unknown outcomes block further signing; recovery checks the same canonical finalized receipt, without replay.

The wallet-flow fork passed against Ethereum’s deployed PoolManager at block 26,100,949: separate quoter, three helper and factory deployments, protected Veyl launch with oversized-buy rejection, buy, finite approval, sell, hook flush and all three fee claims. It used a disposable local fork, with zero external broadcasts and zero real funds spent.

The agent/VEYL fork passed at block 26,100,945: verified main VEYL/ETH and agent/VEYL markets, finite approvals, trading, full fee conversion and exact ETH 70/20/10 delivery. It made no public transactions, paid inference calls or real-fund transfers.

An automatic-funding fork at block 26,100,799 verified the actual fee keeper, exact 70/20/10 delivery and separately constrained automatic treasury payment. zkAPI activation and the subsequent model response in that check were fixtures, with no paid upstream inference.

On 1 October 2026, the native ARM64 daemon/companion returned 389 models in an unfunded VPS read check. The bounded worker and authenticated gateway are now installed. Live wallet login, tenant isolation, replay/CSRF rejection and logout were checked. These checks did not perform paid inference, proof generation or sustained funded load.

npm test
npm run setup:contracts
forge test --root contracts
node scripts/check-mainnet-wallet-flow.mjs
node scripts/preflight-mainnet.mjs --offline
node scripts/check-web.mjs

Saved evidence: output/mainnet-protected-wallet-fork/report.json and output/daemon-footprint-20261001.json. Fork scripts use disposable local assets; read-only preflight has no signer. A blocked preflight can exit with code 2. No test count is treated as proof of production readiness.

Production uses an Ethereum wallet login challenge, secure session cookie and CSRF token. The Vercel gateway signs each request to the private worker. Project lookup is scoped to the session wallet; supplied addresses cannot change the owner. POST requests require same-origin JSON and x-agent-csrf.

External integrations use separately issued project tokens and the scoped /api/developer/v1 API. See the SDK and local MCP guide. Tokens cannot fund, trade, approve or publish.

The separate local demo binds to loopback and supports Anvil development transactions. Its CSRF boundary is not a substitute for production wallet authentication. Mainnet transaction, daemon approval and social publishing flags remain off by default.