← Index
Source: docs/tasks/jul-01-rabbit-design.md (auto-generated by scripts/generate-docs-html.mjs — edit the .md, not this file)

Rabbit — Jul 01 Task

Full content of current-plan.md, included for reference.

New First

✅ DONE — C4 관찰자 대시보드 + C2 서처(번들 제출)를 /xyz에 구현. 설계·구현: ../features/xyz-demo.md · ../features/c2-searcher.md

Feature description — PBS consumer track (relay/builder 소비자)

좋은 방향 전환이야 — relay·builder를 직접 만드는 대신 *이미 돌아가는 relay/builder 인프라를 소비하는 쪽. 이게 사실 현실 개발자가 PBS와 만나는 진짜 접점이야. 어디서 실제로 테스트 가능한지(테스트넷 relay 가용성) 먼저 확인하고 정리할게.

좋아, "이미 있는 relay를 쓴다" = **네가 인프라를 만드는 게 아니라 소비자가 되는 것**이야. 그럼 relay/builder를 만들 필요도, validator를 빌릴 필요도 없어 — 이미 돌아가는 Flashbots 인프라에 너의 트랜잭션/번들을 밀어넣거나, 그 데이터를 읽는 쪽이지. 네가 맡을 수 있는 역할이 4가지야:

네가 될 수 있는 4가지 소비자 역할

트랙 역할 뭘 만드나 필요한 것 어디서 테스트
C4 ⭐첫걸음 관찰자 relay Data API 읽어 분석/대시보드 아무것도(키 불필요) 즉시(메인넷/Sepolia)
C2 ⭐핵심 서처(searcher) 번들 만들어 eth_sendBundle로 제출 지갑·RPC Sepolia
C1 일반 발신자 Protect RPC로 프라이빗 tx 지갑 Sepolia
C3 검증자(제안자) mev-boost를 실제 relay에 연결·관찰 validator 운영 테스트넷 validator

"relay를 사용"의 알맹이는 C2(서처) 야 — 네 번들을 진짜 relay/builder에 넣어서 실제 블록에 포함시키는 것. C4로 감을 잡고 → C2로 직접 써보는 순서를 추천해.

테스트넷 상황 (중요)

C4 — 관찰자 (지금 당장, 키도 필요 없음)

공개 relay Data API를 때려서 "누가 블록을 만들었나, 입찰가는 얼마였나"를 읽어:

# 최근 제안된 블록들(어느 builder/relay가 이겼는지, value 포함)
curl "https://boost-relay.flashbots.net/relay/v1/data/bidtraces/proposer_payload_delivered?limit=20"
# 특정 슬롯에 들어온 모든 입찰(경매 경쟁 관찰)
curl "https://boost-relay.flashbots.net/relay/v1/data/bidtraces/builder_blocks_received?slot=SLOT"

샘플 프로그램: 여러 relay(flashbots, bloxroute, agnostic…)를 동시에 폴링해서 builder 시장점유율·입찰가 분포·relay별 지연을 집계하는 작은 대시보드. relayscan(flashbots/relayscan)이 정확히 이걸 하는 오픈소스라 참고용으로 좋아. PBS "경매"가 실제로 어떻게 도는지 데이터로 체감돼.

C2 — 서처: 번들을 기존 relay에 제출 (핵심)

Sepolia에서 flashbots/ethers-provider-flashbots-bundle로 번들 한 개 보내보기:

import { FlashbotsBundleProvider } from "@flashbots/ethers-provider-bundle";
import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(SEPOLIA_RPC);
const auth = ethers.Wallet.createRandom();          // 서명자(평판용 키)
const fb = await FlashbotsBundleProvider.create(
  provider, auth, "https://relay-sepolia.flashbots.net", "sepolia");

const wallet = new ethers.Wallet(PRIVKEY, provider);
const target = await provider.getBlockNumber() + 1;

// 번들 = 순서 정해진 tx 묶음 (원자적: 다 들어가거나 다 빠지거나)
const bundle = [{ signer: wallet, transaction: {
  chainId: 11155111, to: "0x...", value: 0n, gasLimit: 21000,
  maxFeePerGas: ethers.parseUnits("30","gwei"),
  maxPriorityFeePerGas: ethers.parseUnits("2","gwei"),
}}];

const signed = await fb.signBundle(bundle);
const sim = await fb.simulate(signed, target);      // ← 먼저 시뮬(중요)
console.log("sim:", sim);
const res = await fb.sendRawBundle(signed, target); // ← 기존 relay에 제출
console.log("bundleHash:", res.bundleHash);
// res.wait() 로 포함 여부 확인

샘플 프로그램 아이디어(진짜 "PBS를 쓴다"에 가까운 것):

  1. 원자적 멀티-tx: "approve → swap"을 한 번에(둘 다 되거나 둘 다 안 되거나) — 번들의 원자성 체감.
  2. backrun 봇: 특정 pending tx 뒤에 내 tx를 붙이는 번들(mev_sendBundle + MEV-Share 힌트) — 서처의 본질.
  3. 프론트런 방지 실증: 같은 스왑을 (a) 공개 mempool, (b) Protect RPC로 각각 보내 결과(샌드위치 유무) 비교 — 우리가 며칠 얘기한 그 지점.

C1 — 일반 발신자 (제일 간단)

번들도 필요 없이, RPC만 바꿔 프라이빗 발송:

// RPC를 Protect로 바꾸면 그 지갑의 tx가 기존 builder로 프라이빗 전달
const provider = new ethers.JsonRpcProvider("https://rpc-sepolia.flashbots.net");
// 이후 일반 sendTransaction — mempool 안 거침

C3 — 검증자 쪽에서 기존 relay 쓰기 (무겁지만 "제안자 체험")

Hoodi(개방형 validator)에 검증자 하나 세우고 mev-boost를 여러 실제 relay에 연결:

mev-boost -mainnet=false \
  -relay https://0x...@boost-relay.flashbots.net \
  -relay https://0x...@bloxroute.relay... \
  -addr :18550
# CL 검증자 클라이언트의 --builder=http://localhost:18550

→ 네 블록이 실제 builder들의 경매로 채워지는 걸 mev-boost 로그로 관찰. "relay를 소비하는 제안자" 경험.

추천 경로

C4(데이터로 이해) → C2(번들로 직접 사용, Sepolia) → 필요하면 C3. C1은 C2 하다 보면 자연히 익혀져.

원하면 C4+C2 스타터 레포를 스캐폴딩해줄게 — pbs-consumer/에 (1) relaywatch/ 여러 relay Data API 폴링→builder 점유율 집계(Node/TS), (2) bundler/ Sepolia 번들 제출 3시나리오(원자 멀티-tx·backrun·공개vs프라이빗 비교), (3) .env.example·README(Sepolia 세팅·faucet 링크). 만들어줄까? 이건 도커도 validator도 필요 없어서 바로 npm run으로 굴러가.

Sources: Flashbots Protect Quick Start · Sending Tx & Bundles · Relay API 스펙 · ethers-provider-flashbots-bundle · Hoodi/Holesky 상태

New Second

Task description

alt text I want to have this kind of 쩌는 app in ETC category. Just similar web app that don't need to particular features.

Claude design

What jay wants (my read): a visually striking, "쩌는" live-trading dashboard like the Gravia screenshot — a showcase piece under JayVerse (the renamed ETC menu). Not a real trading bot: no profit logic, no live capital. We reproduce the look and motion with mock (optionally real-public) data. The screenshot itself is labeled SIMULATED, so we stay honest and do the same.

Reality check on the source: the tweet's "$68 → $750,000 across 50 markets" is unverified marketing. We copy the aesthetic + UX, not the claim. Label the page SIMULATED / DEMO clearly.

Concept

A single, self-contained page at /etc/gravia (working name) — pure client-side, dark cyberpunk terminal aesthetic: neon magenta/green on near-black, monospace, a tight grid of glowing panels, subtle scanline/CRT glow, everything animating in real time off one mock feed.

Panels (mirror the screenshot)

  1. Top ticker bar — model tag, market name, BTC/ETH prices, trade count, uptime clock.
  2. Wallet panel — balance, win-rate, trade count (animated counters).
  3. Live candlestick chart — BTC 5m, streaming candles.
  4. Order book ladder — bids/asks with size bars.
  5. #1 Trader · Live Streak — multiplier + sparkline.
  6. Market force-graph — the signature centerpiece: bear/bull/median/catalyst/cluster nodes on a physics-driven network, pulsing. (Hardest panel.)
  7. P&L cumulative curve — the "up and to the right" line.
  8. Recent trades table — streaming rows.
  9. Analytics bars — volume/heat mini bar charts.
  10. Execution log — bottom terminal log, new lines appended live.

Tech (all client-side, no backend → matches "no particular features")

Optional "make it real" tie-ins (later, not MVP)

This same doc already carries real public feeds — we can swap mock → real for two panels:

Scope / recommendation

Open questions for jay

  1. Route name — /etc/gravia, or a neutral one like /etc/trading-terminal?
  2. MVP fully mock, or wire the real Hyperliquid book from day one?
  3. Is the force-graph centerpiece a must-have for MVP (it's the most work), or defer to v2?

New Third

✅ DONE

Done (2026-07-01):

New Fourth

✅ DONE

Done (2026-07-01): Added an EN/KO language toggle button next to the theme toggle in app/Nav.tsx. New app/LangContext.tsx (client, localStorage-persisted), app/LangToggle.tsx (the button), app/NavLinks.tsx (menu labels switch ko/en); app/layout.tsx wraps the app in LangProvider and sets <html lang> before paint (no flash). First cut translates the top-menu labels; page content can follow incrementally. Committed separately.

0. Summary

Designs for the Jun 30 tasks: split Portfolio & Market into two categories + reorder the menu, refine auth / LLM gating, build the Market page (Hyperliquid orderbook + indices), fix the Knowledge page (serve know.html), add KB-over-MCP/RAG to AI Chat, an AP2 Stripe settlement example, and an ETC ERC-7702 / 7715 demo.

1. Split "Portfolio & Market" → Portfolio + Market

✅ DONE Now: one item Portfolio & Market (/portfolio, stub). Target: two categories.

New menu order: Knowledge · Portfolio · AI Chat · Game · Market · AP2 · XYZ · JayVerse. Decided (jay): Home = / (logo/profile entry, leads the bar) and Verex = trailing external link after JayVerse. Full bar: Home · Knowledge · Portfolio · AI Chat · Game · Market · AP2 · XYZ · JayVerse · Verex ↗. Work: edit app/Nav.tsx MENU; create /market; move market widgets out of /summary; keep /portfolio for holdings. ✅ Done (2026-06-30): Nav.tsx split + reordered; /market page added (stub — indices/orderbook content is §3 / task 3); /market public + /portfolio still login-only in middleware.ts. Verified on build + server (/market 200, /portfolio 302→/login). (2026-06-30 update: Knowledge category later removed from the menu — see §4; current bar omits 지식.)

2. Auth + LLM gating

🔲 TODO

3. Market page — Hyperliquid orderbook + indices

🔲 TODO

4. Knowledge page — serve know.html (Fix: No content)

✅ DONE ↺ Superseded (2026-06-30) — Knowledge category removed (restore when needed). Per jay: the Knowledge menu item + /knowledge route were removed from the app; its content now lives in docs/ for local file:// browsing (not web-served → no public exposure): docs/know.html (index, opened via file:///Users/jay/work/task/docs/know.html) + docs/knowledge/ (e.g. management.md). The web-iframe approach below is on hold. Open: know.html links to ai//eng//nostra/ (in archive/, 881 MB) + docs/* — not relocated; left for the restore step.

5. AI Chat — KB via MCP + RAG

🔲 TODO

6. AP2 — Stripe settlement example (educational)

🔲 TODO

7. ETC — ERC-7702 / 7715 demo (educational)

🔲 TODO Standards (jay confirmed): EIP-7702 (an EOA temporarily runs smart-account code = a delegatable smart account) + ERC-7715 (wallet_grantPermissions — grant a scoped session key) / ERC-7710 (delegation).

8. Cross-cutting — IA update

🔲 TODO

9. Decisions & remaining open questions

Resolved (jay):

Still open:

10. Suggested sequence

  1. Menu split + reorder + Market page (indices first, orderbook next).
  2. Knowledge content move + serve know.html.
  3. AI Chat gating (BYO key / jay's stored key; local disabled).
  4. KB RAG + MCP.
  5. AP2 Stripe example; ETC ERC-7702/7715 demo.