17 · Sources
Vendor facts are checked against primary documentation; Market Bender decisions remain labeled as decisions. Conditional and unclear claims stay visible until implementation evidence resolves them.
Claims, consequences and follow-up
| ID / claim | Status | Primary source | Implementation consequence | Follow-up |
|---|---|---|---|---|
| CLM-001 t3code is the upstream interface/runtime foundation and Market Bender should integrate through additive packages and adapters. Checked 2026-07-16 | Project decision | Primary source | Pin an upstream revision; keep a compatibility ledger and isolate product code. | Prove the selected tool/auth extension points against the pinned revision. |
| CLM-002 Current t3code is a React/Vite client with Node WebSocket orchestration and provider adapters; it supports more than Claude. Checked 2026-07-16 | Verified | Primary source | Claude-first is a Market Bender default, not an upstream limitation. Integrate behind the provider boundary. | Record exact upstream commit and package/API touchpoints in Prompt 02. |
| CLM-003 Market Bender can keep t3code substantially unmodified while exposing product tools. Checked 2026-07-16 | Conditional | Primary source | Prefer the existing provider/MCP/tool session seam; any core patch requires a compatibility-ledger entry. | Prototype tool injection and Privy auth adapter before declaring zero upstream changes. |
| CLM-004 A Privy access-token `sub` is the user's wallet address. Checked 2026-07-16 | Outdated | Primary source | Use the Privy DID as identity and persist an explicit user-to-master-wallet mapping. | Remove wallet-address-as-sub assumptions from authentication code and tests. |
| CLM-005 Hyperliquid agent/API wallets sign trading actions for a master account and should be isolated by trading process. Checked 2026-07-16 | Verified | Primary source | Use a fresh signer per process/account scope, an atomic nonce sequencer, expiry, rotation, and revocation. | Test registration, expiry, deregistration, and replay resistance on testnet. |
| CLM-006 An agent wallet can be treated as incapable of every sensitive account action. Checked 2026-07-16 | Conditional | Primary source | Enforce a strict allowlist in the signing service and Privy policies; keep master-only operations on a separate authorization path. | Build an action-by-action permission matrix and negative tests. |
| CLM-007 HIP-3 perps use the unified exchange API but require per-DEX discovery and encoded asset IDs. Checked 2026-07-16 | Verified | Primary source | Never hardcode IDs; cache network-scoped metadata and resolve `{dex}:{coin}` from current info responses. | Record mainnet/testnet discovery fixtures and stale-metadata behavior. |
| CLM-008 `@nktkas/hyperliquid` is the selected TypeScript boundary and supports shared HTTP/WebSocket transports and typed clients. Checked 2026-07-16 | Project decision | Primary source | Pin the package version, wrap it behind Market Bender interfaces, and do not leak SDK shapes into domain contracts. | Reverify constructors/methods at implementation time; current research found 0.33.2. |
| CLM-009 Hyperliquid WebSocket reconnect snapshots are sufficient without reconciliation. Checked 2026-07-16 | Unclear | Primary source | Treat streams as acceleration, not sole truth; reconcile orders, fills, positions, funding, and equity through info endpoints. | Define cursor/deduplication rules and outage test fixtures. |
| CLM-010 A Durable Object is appropriate for authoritative per-match coordination. Checked 2026-07-16 | Verified | Primary source | Route one match ID to one object; persist every critical transition and use timestamp truth rather than in-memory timers. | Test restart, migration, alarm delay, duplicate message, and split-client scenarios. |
| CLM-011 Cloudflare Queues consumers may receive a message more than once. Checked 2026-07-16 | Verified | Primary source | All consumers require stable idempotency keys and a dead-letter path. | Add replay tests and DLQ operations runbook. |
| CLM-012 Workers KV is suitable for authoritative financial or match state. Checked 2026-07-16 | Outdated | Primary source | Use KV only for non-authoritative cached configuration; it is eventually consistent. | Add architecture test/lint rule forbidding authoritative repositories from binding KV. |
| CLM-013 D1 may be used as the transactional authority for an active match. Checked 2026-07-16 | Conditional | Primary source | Keep active-match authority in the Durable Object; use D1 for relational indexes/records and session bookmarks where read replication is enabled. | Specify which tables are derived versus authoritative. |
| CLM-014 The approved settlement model is winner-takes-all from a frozen deadline equity snapshot, with deterministic custody/accounting in the additive layer. Checked 2026-07-16 | Project decision | Primary source | Harden formula, timestamps, evidence, idempotency, refund/tie rules, and administrative constraints without substituting a different custody model. | Obtain legal/operational review before real-money production. |
| CLM-015 The current elemental market list is live and reproducibly refreshed. Checked 2026-07-16 | Unclear | Primary source | Treat dated market commentary as research, not runtime configuration; discover markets from the exchange. | Build a retrieval script with timestamps and raw response evidence. |
Curated by system
t3code
t3code repository
Upstream topology, provider adapters, WebSocket runtime, compatibility baseline
t3code architecture overview
Client/server split, provider services and HTTP/WebSocket connection model
Privy
Hyperliquid agent wallets
Master and agent wallet creation/registration recipe
Hyperliquid policies and offline actions
User-signed/L1 action distinction, policies, authorization keys
Access tokens
Token verification and subject identity semantics
Wallet policy and controls
Signer/quorum and policy controls
Hyperliquid
Nonces and API wallets
Signer-scoped nonce rules, pruning, per-process isolation
Asset IDs
Native, HIP-3, spot and network-specific identifiers
Info endpoint
Metadata, account state, fills, orders and reconciliation
Exchange endpoint
Order and account actions
Account abstraction modes
Current unified-account terminology and mode behavior
WebSocket and subscriptions
Market/user streams, snapshots and reconnect handling
Fees
Fee treatment and tier behavior
HIP-3
HIP-3 builder-deployed perpetuals
Builder-deployed perp responsibilities and unified trading path
TypeScript SDK
@nktkas/hyperliquid repository
Selected typed SDK, clients, transports and version pinning
Cloudflare
Durable Objects overview
Strongly consistent per-entity coordination
Durable Objects rules
Persistent state, concurrency and in-memory reset constraints
Durable Objects WebSockets
Hibernation and connection ownership
Queues delivery guarantees
At-least-once delivery and idempotency
Workflows overview
Durable multi-step execution and retries
D1 read replication
Primary/replica behavior and Sessions API consistency
Workers KV consistency
Eventually consistent cache constraints
R2 overview
Replay artifacts and large append-only records
Workers secrets
Protected deployment values
Security
OWASP API Security Top 10
API authorization and abuse-review baseline
Legal / operational review
Specialist review required
Custody, wagering, derivatives, sanctions, jurisdiction and dispute operations; not vendor-verified
Primary facts, project choices, specialist review
Reverify implementation-sensitive claims at the affected prompt stage and pin versions/commits. Market data requires raw responses and capture timestamps. Legal/operational requirements for wagering, custody, derivatives, sanctions, KYC, disputes and jurisdiction must be reviewed by qualified specialists and are never presented as vendor-verified.