Rabbit ⇄ Verex — Cross-repo Plan (rolling)

Active track: J2 — the mandated trader. An agent that runs unattended in rabbit, forms its own view of a verex prediction market, trades on it, and settles — where the worst it can ever cost is a number the owner set in advance and the chain enforces, not a number the agent's own code promises.

What this file owns: only what crosses the two repos — the scenario, the seam, the build order, and the dependencies between them. What it does not own: per-repo detail. Rabbit's feature status lives in ../features/README.md; verex's lives in its own current-plan.md and features README. One fact, one home — this doc links, it does not copy.

Iterating (jay, 2026-08-21). This plan is written and rewritten in conversation. The four architectural forks below are answered; the open questions are not. How this plan was arrived at — including the two findings that reordered it — is in 2026-08-21.

Table of contents

• §0 — Summary
• The scenario
• A second scenario — nested-market arbitrage (not built)
• Architecture — where each bound actually lives
• Repo status
• Implementation matrix — who builds what
• Build order
• Built so far — and how to check it
• Open questions
• What this will not prove
• Ownership rules

0. Summary

_{↑ TOC}

Rabbit has the agent-payments machinery (ERC-7715/7710 session keys, a mandate grant/revoke demo, LLM plumbing) and no autonomous loop. Verex has a working Sepolia CLOB prediction market and no way for a stranger to trade on it — every order today is signed by a server-held demo wallet (accountIndex 1..9, keys in Secret Manager). J2 is the one project that needs both, and it is worth doing precisely because it forces each repo past the thing it has been avoiding: rabbit has to let an agent act unattended, and verex has to accept a counterparty it does not custody.

Four forks, answered (jay, 2026-08-21):

Consequence of the fourth answer: the full loop needs a market resolved on live Sepolia, which is verex's W1. W1's fresh seed deletes staging's Trade/PricePoint/Outcome/Market rows, so re-seeding after the agent has traded on staging would leave its journal citing deleted rows.

Where W1 sits, revised (jay, 2026-08-25). That constraint says W1 before the first staging run — not W1 before everything. Locally it never applies: ./scripts/reset.sh wipes and re-seeds on demand, and the mock oracle resolves instantly, so Phases 1–4 including redemption are fully testable on anvil. W1 therefore moved to Phase 6, immediately before the first staging use. One piece is pulled forward: a smoke probe against the live adapter, because W1 is the only thing in this plan that has never worked and it should not be discovered at the end.

Where it stands (2026-09-04): the milestone happened. On 2026-09-02 the loop produced its first fully scheduled, wallet-granted, on-chain-drawn trade — a server tick nobody triggered drew MockUSDC through a mandate granted by MetaMask's own ERC-7715 popup and bought 4.81 Yes (draw tx 0x5e765a3b…; the mandate read 7.50/10 after). Phases 1–2 (V-A…V-D, R-A…R-E, R-I) remain done with on-chain cap/expiry (details); R-F is built (Phase 3). Two changes made the milestone possible, both bigger than they look:

• The local chain is now an anvil fork of Sepolia (chain id 11155111, pinned block, state file, default port 8545 — startup line in docs/memo.md). MetaMask therefore grants real 7715 permissions against its own canonical DelegationManager, which the fork inherits — answering O9 early: no local framework deployment, no raw typed-data blob.
• A bearish view is expressed as BUY of the opposite outcome on binary markets (SELL survives only on non-binary ones). Two holes close by construction: insufficient Yes balance is unreachable, and every trade now passes through the mandate draw — the cap bounds all of it.

What remains for the closed loop: R-G/R-H (Phase 4), the MCP wrapper (Phase 5), W1 and the first staging run (Phase 6). R-F's own bar — a full unattended day — has not been soaked yet; the scheduler has only run attended sessions so far. History note: this stretch is recorded in the merge commits (rabbit aa193cf and after, verex 934be01), not in docs/history — the daily file is written on request only.

A second scenario is written down but not built — nested-market arbitrage, added 2026-08-27 so the design is not read as "an LLM that trades on news". The mandate, the tick and the journal are indifferent to where the signal comes from, and that section shows one that needs no LLM at all. It carries a hand-test procedure; nothing in it is in the build order.

The scenario

_{↑ TOC}

One tick, running on a schedule with no browser open:

Skips are the point. A demo that only shows trades shows capability. A journal where most rows read "book 0.31, model 0.29, edge 0.02 < 0.05 → no action" is what makes a decision visible as a decision. Expiry is the money shot — leave the agent running past the deadline: it keeps ticking, keeps wanting to top up, and the chain keeps refusing. Nobody revoked anything; the window simply closed.

A second scenario — nested-market arbitrage

_{↑ TOC}

Not built, and not scheduled. This section is an illustration of a second shape the same machinery could take, written at jay's request (2026-08-27) so the agent's design is not read as "an LLM that trades on news" when the mandate, the tick and the journal are indifferent to where the signal comes from. Nothing below is in the build order. It is here to be argued with.

The signal is arithmetic, not a forecast. Verex already seeds two markets that are logically nested:

Closing above $10,000 implies closing above $6,000. So P(≥10k) ≤ P(≥6k) must hold at all times, and the tradeable form of a violation is:

best BID on eth-above-10k  >  best ASK on uma-eth-above-6k

When that happens the agent sells the 10k YES at the bid and buys the 6k YES at the ask, taking a net credit for a position that can never lose: the leg it bought pays out in every world where the leg it sold does.

Why this scenario is worth writing down. It removes the LLM entirely. The news scenario's journal rows say "the model thought 0.58" — a claim a reader has to take on trust. These rows would say "0.64 > 0.63, and the first implies the second" — a claim a reader can check. Same mandate, same tick, same journal; a different estimate step and a two-leg act step.

The honest caveat, which belongs in the demo rather than under it. The two markets resolve through different oracles — eth-above-10k-2026 is operator-resolved, uma-eth-above-6k-2026 goes through the UMA adapter. They can disagree about the same underlying fact, so the position is not actually riskless; it carries basis risk between two settlement processes. A demo that claims "risk-free" without saying this is selling something.

Testing it by hand

The agent side is not built, so this procedure only creates and observes the condition. It is worth running anyway: it answers "could this ever fire?" before anyone writes the code.

First, the finding that makes the naive version fail. The seeded LMSR ladders are five levels deep, ±5¢ around each mid — so the reachable price ranges do not overlap:

eth-above-10k-2026      0.39 ─── 0.44 ─── 0.49      (bids 0.43..0.39, asks 0.45..0.49)
uma-eth-above-6k-2026            0.57 ─── 0.62 ─── 0.67

Buying the 10k market until its ask is exhausted stops at 0.49; selling the 6k market to its floor stops at 0.57. Eating the ladders can never make them cross. The violation has to be posted, not walked to — a resting limit order priced past the whole ladder.

Steps. Verex API on :4000, anvil up, demo wallets seeded (wallet 1 holds 7,000 USDC).

On the ≈991 USDC. That is not a fee. Roughly 927 of it buys 2,000 YES tokens at an average 0.46 — a position, not a loss — and the remaining ~64 is escrow behind the resting bid, released by step 7. The only real cost of the round trip is the spread on selling those tokens back. Wallet 1 holds 7,000 USDC and is the only demo wallet with room; the others hold 1,000.

Two things this procedure does not prove. It does not show the agent finding the violation — step 2 is a human posting it. And step 5 is two separate orders that can partially fill independently; a real implementation needs the legs to be atomic or the position bounded, which is work this plan has not scoped.

The other candidates, and why this one

Architecture — where each bound actually lives

_{↑ TOC}

This section is the design. Two parts of it changed while building: the mandate is not granted through ERC-7715, and the delegator is not the owner's EOA. For the system as it actually runs, see autonomous-trading-agent.md; the reasons are in The mandate is enforced on chain.

  Owner wallet (MetaMask)
      │  ERC-7715 delegation — cap: N MockUSDC, expiry: T
      │  ◀── the ONLY on-chain enforcement point
      ▼  redeem ≤ cap
  Agent EOA            key on RABBIT's server (testnet-grade, labelled on the page)
      │                holds ONLY what was released — that is the whole safety claim
      │  signs CTF EIP-712 orders
      ▼
  Verex API  ──▶ CTF Exchange (Sepolia)   ◀── operator sends matchOrders

Why "funding, not trading". ERC-7710 enforcers inspect a call; a CTF order is a signature. So a session key signing an order does not pass through any enforcer. Bounding the funding instead gives a claim that is weaker in scope but completely honest, and it is true arithmetic rather than trust: the agent cannot lose what it never had. The stronger version — per-market and per-price limits enforced by contract — needs an EIP-1271 smart account with a custom validator, and is recorded as a later milestone rather than built (O4).

Two gas facts, verified in verex's code on 2026-08-21, and they are not symmetric:

• Trading costs the agent nothing. book.ts:694 settles via chain.exchangeAs(0).matchOrders(...) — the operator sends the match transaction. An external maker only ever signs. So the agent needs no Sepolia ETH to trade, which is a genuinely nice property for an unattended process.
• Redeeming does. CTF redeemPositions must come from the position holder, so the agent EOA needs a little Sepolia ETH — only for the redemption leg. Budget it once, at Phase 4.

Verex is closer to this than it looks. model Order already stores maker (a real address), signedOrder (Json) and a unique orderHash. buildSignedOrder then signs on the client's behalf with account(index). Accepting an external order is mostly deleting that step, not adding one. What genuinely has to change is makerIndex, funding, and the index-scoped read endpoints — Phase 1.

Repo status

_{↑ TOC}

Summary only — each repo's own plan is authoritative.

Implementation matrix — who builds what

_{↑ TOC}

The build order below has the reasoning and the done-when gates. This is the same work as a table, so you can see at a glance which repo owes what and where the two actually touch.

At a glance

Full matrix

The # prefix names the repo — V, W0 and W1 are verex, R is rabbit. Rows marked ⇄ come in pairs and are the only genuinely two-sided work: V-A ⇄ R-B (one signs an order, the other accepts it) and V-D ⇄ R-G (one exposes redeem, the other calls it). They are placed adjacent so the seam is visible in the table rather than inferred from the dependency column — which means this table is not a work queue; the build order below is.

Reading the dependency column: the only hard cross-repo blocks are the two ⇄ pairs — V-A…V-D → R-B and V-D → R-G. Everything in R-A, and all of P0/V-A/V-B/V-C, can proceed in parallel, so the two repos are not serialised on each other except at those two points.

Build order

_{↑ TOC}

Ordered as jay described it: verex opens up, rabbit's agent arrives, the loop closes, and only then does any of it touch a real testnet. Phases 1–4 run entirely on the local Foundry chain — anvil + the mock oracle, which resolves instantly — so nothing here waits on Sepolia. [V] = verex repo, [R] = rabbit repo. Estimates are focused-work days.

Run early, in parallel — W0, the live-oracle smoke probe [V] · minutes

Not a phase and not on anyone's critical path. W1 is the only thing in this plan that has never worked, and everything it depends on belongs to a contract verex did not write — UMA's collateral whitelist, its final fee, a real liveness window. Deferring the single riskiest unknown to the very end is how you find out too late.

The probe is one call: initialize on the staging adapter with Sepolia WETH as the reward token. If the live oracle accepts the request, the rest of W1 is waiting and configuration and can safely sit at the end. If it reverts, you learn it now.

Do not use MockUSDC. UmaCtfAdapter's own docblock says it: the reward token must be on UMA's AddressWhitelist, MockUSDC is not, and Sepolia WETH 0x7b79995e5f793A07Bc00c21412e50Ecae098E7f9 is — self-service via deposit(). This is the trap that passes locally and reverts on Sepolia.

Phase 1 — verex accepts a counterparty it does not custody [V] · ~2–3d

The interesting half of this phase is that verex stops being a custodian, which is a product claim for verex on its own — not a favour to rabbit.

Done when: a wallet verex has never heard of funds itself, signs an order, gets filled against the operator's LMSR ladder, and reads its own position back — with no accountIndex required in the external-maker path.

Not "no accountIndex anywhere" (jay, 2026-08-25). Index 0 is the operator's LMSR maker — the counterparty an external order fills against — so it cannot leave. And Order.makerIndex becomes nullable, not removed: the demo wallets on the web page keep trading exactly as today. Phase 1 is additive. Retiring the user-facing index path later is O8.

Milestone before Phase 2 — the MetaMask-signed order. After V-A…V-C, place an order from rabbit's /live/agent page signed by MetaMask, not by an agent key. Same wire format, same endpoints; the only thing that changes later is who holds the key. It proves this whole gate from a browser and needs neither R-B nor the O1 decision.

Phase 2 — the agent exists, driven by hand [R] · ~3–4d

Done when: curl-ing the tick twice produces exactly one trade, one journal row per call including the skip, and a budget figure that matches the chain — and an estimate's row names the NewsItem rows it cited, which still resolve after the input box is cleared.

Phase 3 — actually unattended [R] · ~0.5d

R-F. Wire the scheduler (O2). This is the milestone that earns the word "agentic" — Phases 1–2 without it are still a button. Done when: the loop runs for a day with no browser and no terminal, and the journal shows ticks nobody triggered.

✅ Built 2026-09-02. An in-process server timer — lib/agent-scheduler.ts, a globalThis singleton so dev HMR keeps it; minimum interval 5s; a tick in flight is never overlapped — driven by POST /api/agent/scheduler and a console panel. Settings are captured at Start; changing a dial mid-run does nothing until Stop → Start. The tick body moved verbatim to lib/agent-tick.ts so the route and the scheduler run the same function, and the manual "Run one tick" button is gone — the scheduler is the only trigger. The journal already shows ticks nobody triggered; the full unattended day has not been soaked, so the bar above still stands.

Phase 4 — the loop closes [R] · ~1–2d

Done when: one round trip — estimate, trade, resolution, redeem — appears as a connected set of journal rows, and a second mandate is allowed to expire on camera.

Phase 5 — MCP wrapper [V] · ~1–2d

V-E. packages/mcp-server — a thin wrapper over Phase 1's REST endpoints (list_markets, get_book, place_order, get_position, redeem). Not a rewrite: MCP calls the same API the agent already uses, so this is a second front door, not a second implementation. Closes verex's S3 gap and makes any MCP client — not just rabbit's agent — able to trade. Done when: rabbit's agent runs unchanged against the MCP transport, and a generic MCP client can place one order without reading verex's source.

Phase 6 — go to Sepolia: W1 and the first staging run [V] · ~1–2d

Why last (jay, 2026-08-25). The re-seed rule says W1 before the first staging run, and this is that moment. Everything before it ran on anvil against the mock, so there was never staging history to protect. Testing on a testnet gets redone at the end regardless, so doing it early would be doing it twice. What makes this safe rather than reckless is W0, run early.

The steps live in verex's plan, not here — W1 is verex's item and this file only owns the seam. Seven steps with the trap next to each: verex current-plan.md → W1. The short version is: fund Sepolia WETH (not MockUSDC — it is not on UMA's whitelist), fresh seed with a short-dated market, propose, wait out real liveness, settle, redeem, close A5.

Take the undisputed path. The dispute branch is not walkable on Sepolia: a real dispute escalates to UMA's DVM — a ~2-day staked commit/reveal round that testnet does not reliably provide. The mock's jury exists precisely because that half is only demonstrable locally. Do not design the demo around a dispute resolving.

Done when: one market resolved end-to-end through the live adapter, a winner redeemed, A5 closed, and the seed left at least one short-dated market the agent can plausibly see resolve inside a demo. (That last clause is J2's requirement on W1, not W1's own.)

Built so far — and how to check it

_{↑ TOC}

Written 2026-08-25, extended 2026-08-26 with R-A · R-E · R-I and the on-chain mandate. Merged and pushed 2026-08-26 — claude/j2-phase-1-2 is on main in both repos (rabbit 306811b, verex 5154c4f). Nothing is deployed: rabbit has no workflow and verex's is workflow_dispatch only. Both repos have moved on since, so read git log, not this line. Full narrative: 2026-08-26-rabbit-history.md.

2026-08-27 — V-B did not actually run. The row below was true about the code and false about whether it worked: verex's API signed as an operator with no gas on the local chain, so every faucet call died as Insufficient funds for gas * price + value. Because app/api/agent/mandate/prepare/route.ts funds the owner smart account through that faucet, and swallows its failure with .catch(() => null), steps 5–13 of the walkthrough below could not have passed — the mandate would grant with an unfunded smart account and every tick would fail to draw, with nothing on screen saying why. Root cause: scripts/dev-local.sh exports a default VEREX_OPERATOR_KEY that the seed inherits, while a separate terminal running the API picks a different key out of packages/api/.env — dotenv never overrides a shell variable. Fixed on verex branch claude/faucet-operator-and-target.

What landed

Not started: R-G (resolution watch), R-H (expiry run), V-E (MCP), W1. R-F landed 2026-09-02 — see Phase 3.

Since 2026-09-01 — the fork, the scheduler, the first unattended trade

Commits: rabbit aa193cf (the 2026-09-02 console day; fork work merged just before it), verex 934be01. The first scheduled on-chain-drawn trade is quoted in §0.

The mandate is enforced on chain, not by the server

jay chose option (c) on 2026-08-26: deploy MetaMask's delegation framework to the local anvil rather than let the server play at holding the boundary. It worked, and it is cheaper than the plan assumed — @metamask/smart-accounts-kit (already a dependency) ships deploySmartAccountsEnvironment(), which puts DelegationManager, SimpleFactory, the implementations and ~35 caveat enforcers on any chain. 240 ms on anvil.

Two of those enforcers are exactly R-A's two boundaries:

Not via wallet_requestExecutionPermissions (ERC-7715). That call is answered by the MetaMask extension, which supplies the DelegationManager address in its response — the SDK hardcodes none, which is the proof. Our deployment is not CREATE2, so its addresses could not match what the wallet expects even if chainId 31337 were on its list. Instead the mandate is a plain EIP-712 Delegation whose verifyingContract and chainId we pass, so eth_signTypedData_v4 works on any chain. The console has a button that asks the wallet for its real supported-chain list, so the day 31337 appears there, this decision can be revisited from evidence rather than memory.

Consequence to know: the delegator is a Hybrid smart account owned by the MetaMask EOA, because redeemDelegations executes in the delegator's context and therefore needs contract code there. The USDC lives at the smart-account address, not at the EOA. It is funded by V-B's address-scoped faucet — a Phase 1 piece that slotted in unchanged. Upside: no EIP-7702, so anvil never needs the Prague hardfork.

The tick now draws through the delegation before it places an order. Order-first would leave a book entry that cannot settle if the draw is refused — the same failure shape as verex's W6.5.

Three decisions taken while building, not asked

1. External orders are limit-only. A market order needs the client to sign worst-case terms — that is its slippage policy, not verex's. Index-based market orders are untouched.
2. V-D records instead of executing. Verex holds no key for an external holder, so it cannot send redeemPositions. The holder redeems and reports the tx; verex verifies the receipt.
3. The estimate is skipped when there is no news. A pure prior is frozen at the model's training cutoff and competes with a live book — the market wins by construction. Recorded as SKIP_NO_ESTIMATE with a reason rather than silently guessing.

One gap this created, deliberately left open

Funds are checked at placement. An external maker can place a resting order and then withdraw, leaving a book entry that cannot settle — a demo wallet cannot, because verex holds its key. Recorded as W6.5 in verex's plan. Cheap fix: re-check at match time. Thorough fix: W5.

How to check it

Setup — four terminals, and AGENT_PRIVATE_KEY must be set or the agent's address changes on every restart and orphans the mandate.

# 1 — chain
anvil

# 2 — verex: postgres + schema + seed, then the API
cd ~/work/verex && ./scripts/dev-local.sh
pnpm --filter @verex/sdk build          # rabbit's file: link resolves to dist/
pnpm --filter @verex/api dev

# 3 — rabbit
cd ~/work/rabbit
export AGENT_PRIVATE_KEY=0x…            # any test key; must be stable
export VEREX_API_URL=http://127.0.0.1:4000
export AI_API_KEY=…                     # the DashScope key jay-chat already uses
npx prisma db push                      # NewsItem, Mandate, AgentTick
pnpm delegation:deploy                  # DelegationManager + ~35 enforcers → anvil (~0.2s)
pnpm agent:seed-news                    # the demo's evidence — see below
pnpm dev                                # rabbit → :3100  (verex's web already has :3000)

Console: http://localhost:3100/live/agent/console. The system as it actually runs — processes, ports, keys, seams — is autonomous-trading-agent.md.

Prove the boundaries are real before touching the UI. This needs nothing but anvil and the deploy above — no verex, no postgres, no MetaMask:

pnpm delegation:verify

It draws inside the mandate, then over the cap, then past the expiry, and prints what the contracts say. Expect exactly this, and treat any other outcome as the demo being broken:

1. draw 4 of 10 …………………  agent USDC: 4
2. cap exceeded …………………  ERC20TransferAmountEnforcer:allowance-exceeded   (still 4)
3. after expiry ………………… TimestampEnforcer:expired-delegation             (still 4)

Step 3 is the whole argument: nobody revoked anything. The window closed, and the same code with the same key keeps running and keeps being refused.

The demo case, seeded

The news store starts empty, so until 2026-08-27 the only way to see the scenario was to type a headline and hope. pnpm agent:seed-news (rabbit, scripts/seed-agent-news.mjs) fills it with two cases on purpose — jay's decision, because the demo has to show both halves:

The second row is the more important one. This plan's claim is not "the agent trades", it is "a decision is legible as a decision" — and a skip carrying its reasoning and its cited headline is what proves that. A demo where everything trades has quietly dropped the argument.

Expected is not guaranteed. The verdict depends on where the LLM puts p, which can differ run to run. Do not tune edgeThreshold until it says what you want — the moment the threshold is chosen to produce a verdict, the journal stops being evidence and becomes staging. Read what comes out.

The public page at /live/agent tells this same story as a hand-written script (AgentJournalMock.tsx, rewritten 2026-08-27) — same columns, same verdict names and colours as the console's JournalPanel, so a visitor with no local chain and an operator with one are looking at the same agent. It walks all seven verdicts and ends on two consecutive SKIP_EXPIRED rows.

The checks, in order. Each one either passes or names what broke.

Automated checks that already pass:

cd ~/work/verex && pnpm --filter @verex/api exec tsc --noEmit   # clean
pnpm --filter @verex/sdk test                                    # 6/6, incl. tampered-amount
cd ~/work/rabbit && npx tsc --noEmit                             # clean
npx next build                                                   # clean
pnpm delegation:verify                                           # 3/3 on a live chain

What a failure most likely means. A valid signature that the exchange rejects is almost always a stale exchange address — reset.sh deploys a fresh backbone, and a cached verifyingContract produces a perfectly valid signature of the wrong message. Re-read /config — the preflight strip puts that address on screen for exactly this reason.

A mandate failure reads differently: if the signature is refused, the delegator is usually the EOA rather than the smart account, and if redeemDelegations reverts with no enforcer name, the smart account is probably not deployed yet.

Open questions

_{↑ TOC}

What this will not prove

_{↑ TOC}

Written up front so it does not get quietly dropped, and it belongs on the page itself.

• Not autonomous goal-setting. A human writes the rule and grants the mandate. The agent chooses when and whether, not what for.
• Not production custody. A server-held key is a demo compromise, labelled as one.
• Not a trading strategy. An LLM's probability estimate is a plausible trigger, not an edge. The demo is about the bound, not the trade — and it should be honest about losing money.
• Not a full mandate. The bound is on funding, not on each trade (O4). Inside its budget the agent may do something stupid; it simply cannot do something large.
• Not an agent that discovers news. R-I's store is filled by hand, so the agent reads a world curated by whoever runs the demo. Entering a headline supplies evidence and is fair; entering a stance would steer the conclusion and is not. This version tests the mechanism. A real feed (origin: feed) is what would remove this line.
• Expiry is block time, not wall clock, and nothing notifies the owner when a mandate lapses — the agent has to notice its own refusal.

Ownership rules

_{↑ TOC}

Rule of thumb: if it can be finished inside one repo, it belongs to that repo's plan. Only what needs both ends moving belongs here.