Grid trading on Robinhood Chain

Recommendation: build a noncustodial grid executor using existing liquidity first. Put balances, permissions, execution bounds, grid state transitions, and withdrawals onchain. Run discovery, simulation, routing, scheduling, and optimization offchain. Develop a Uniswap v4 maker-grid hook as a separate experiment once observed order flow supports supplying liquidity.

The referenced thread 01a09dd7-3a02-70b0-841d-c009b185186d is collecting stock-token history and investigating robust grids across the 100 most liquid assets, including the interval between the US close and open. This document connects that research to deployable execution semantics. It does not import the earlier meme-token LP thesis as evidence about stock-token pools.

The saved stock-token dataset covers 334 contracts, including 194 matched to the official registry. It reports some price history for 276 products; the main hourly collection covers 274. Those are mostly provider reference-price samples, sometimes spanning other chains, rather than executable Robinhood Chain trades. The distinction determines what a backtest can establish.

The chain and execution infrastructure exist. Robinhood documents a live Ethereum L2 built with Arbitrum technology, chain ID 4663. Uniswap announced v2, v3, v4, and UniswapX support on July 1, 2026. This research verified documentation, not deployed bytecode or successful stock-token executions. Robinhood network documentation, Uniswap chain launch.

Before implementation, pin chain-specific contracts from the v4 deployment table, verify runtime code and source versions at a recorded block, and test the intended token/pool combinations. Do not copy addresses from another network or mistake PositionDescriptor for PoolManager in flattened deployment tables.

Two different products can be called a grid. A taker grid buys and sells through existing venues after its levels become executable. A maker grid deposits inventory at levels and lets incoming traders consume it. The former pays execution costs and depends on a keeper or filler; the latter must attract order flow and bears market-making inventory risk. The same sampled price path cannot be used as an identical fill simulation for both.

What v4 changes. It retains v3's concentrated-liquidity model while changing how pools are implemented and extended. v4 versus v3.

Sources: hooks, flash accounting, dynamic fees, v4 whitepaper.

Flash accounting is an intratransaction optimization; it does not fund an overnight position. Gas still includes our hooks, storage, oracle checks and data costs. Dynamic LP fees must be distinguished from hook charges and protocol fees. A higher fee may compensate inventory risk but also drive traders to another venue; it cannot guarantee positive maker returns.

A pool's hook address is part of its immutable PoolKey. We cannot attach a grid hook to an existing unrelated pool. A new pool needs its own liquidity and incoming flow; Uniswap explicitly does not guarantee frontend routing to every hook. Keep a v4 trading adapter separate from a custom hook product. Hook integration constraints.

Recommended onchain boundary. Initially use isolated per-user, per-pair strategy accounts with a funded base/quote budget. Avoid pooled share pricing until there is a reason to share ownership. The account stores or commits to the authorized grid: pair, bounds, spacing, rung size, expiry, execution sessions, fee caps and inventory limits. It also tracks consumed amounts and policy nonces. Arithmetic or geometric grids can be encoded compactly without storing every price as an independent order.

Every execution must satisfy the contract's own constraints, even when its caller is malicious:

• Correct strategy, version, pair, direction and eligible rung; no replay or duplicated fill.
• Actual input/output balances satisfy the user's limit after all applicable deductions.
• Input amount, cumulative inventory and keeper compensation stay inside the funded mandate.
• Output and remaining principal belong to the strategy account; callers cannot choose arbitrary recipients or targets.
• Deadline, session and applicable oracle checks pass; route data cannot weaken those checks.
• A filled quantity creates only the corresponding funded opposite-side quantity. Partial fills do not rearm a full rung or reuse committed capital.

Model each rung's remaining quantity and associated inventory explicitly. For example: armed buy → partial/complete buy → funded sell → partial/complete sell → funded buy. A price jumping across three levels is not three fills unless three executable transactions or actual maker fills occurred. Different rungs cannot each assume access to the same quote reserve.

Use reviewed venue adapters, not arbitrary external calls or delegatecalls. Token balance deltas and fee accounting matter more than trusting a router's return value. Owner cancellation invalidates future fills once the cancellation is included; it cannot undo already included transactions. Allow direct withdrawal of idle assets and recovery of resulting inventory without a keeper, oracle valuation, or mandatory market sale. Removing liquidity and liquidating inventory are separate actions.

Recommended offchain boundary. Run the chain indexer, quotes, route comparison, transaction simulation, keeper submission, calendar generation, strategy search and analytics offchain. Use multiple independent RPC providers and durable reconciliation by block hash and transaction receipt. Offchain workers propose transactions; they cannot expand the onchain mandate.

Anyone should eventually be able to execute a valid fill for a bounded reward. Start operationally with redundant operated keepers and a public execution interface. Pay for verified progress, with no reward for an ineligible attempt. Permissionless keepers improve replacement and censorship resistance but can choose adverse timing inside the authorized price bounds; bounds and expiry still matter. An outage can delay execution despite preserved custody.

Contracts do not wake themselves at 4 p.m. Hooks run when an external transaction invokes the relevant pool operation. Scheduled rearming, recentering and exits still need transactions. Encode finite UTC session windows generated from a versioned market calendar, with owner-authorized scope and automatic expiry if no new valid schedule arrives. Store canonical time in UTC and display America/New_York, respecting DST, holidays and early closes.

How a v4 maker grid could work. Represent individual levels as narrow, one-sided liquidity ranges. Group compatible orders by pool, direction, tick band and generation, with per-user proportional claims. A swap that fully crosses a range can trigger an afterSwap hook that removes that group's completed liquidity and credits the acquired asset. Then rearm the opposite side only under explicit rules.

Do not call a touched range a complete fill. Conversion occurs across a price interval, not at one exact discrete price. Without removal, a converted LP position can convert back on reversal. OpenZeppelin's experimental LimitOrderHook is a useful implementation reference, not a ready-made recurring grid product. Uniswap range orders, OpenZeppelin hook source.

Keep per-swap work independent of user count using grouped accounting and pull-based claims. Tick-crossing work still needs a provable bound. A naive loop over every order or every crossed empty tick can make large swaps unaffordable or revert. Merely postponing completed-range removal can change fill semantics because liquidity remains exposed to reversal; batching therefore needs a correctness design, not just a gas cap. Explicitly test swaps initiated by the hook itself, callback context, partial fills, rounding, fee ownership, cancellations and multi-level crossings.

Dynamic fees and inventory-aware quoting are promising later additions. A custom-accounting discrete grid could provide more exact price semantics, but requires implementing and auditing matching, partial fills, fees and solvency. Begin with the smallest hook that tests atomic maker-fill settlement.

UniswapX is a separate route worth testing. Official docs confirm its Dutch V3 settlement on Robinhood Chain. Competitive fillers may improve net execution and handle transaction submission, but gasless user submission does not mean execution is economically free. The grid still needs durable inventory and recurring-order state. Do not assume an API's short-lived swap orders are a complete persistent grid service, or assume contract-wallet authorization and cancellation support without integration tests. Robinhood UniswapX announcement, reactor architecture, Dutch V3 filling.

The overnight strategy requires distinct market regimes. Robinhood documents 24/7 secondary stock-token trading, restricted primary mint/burn windows and asset-specific underlying trading capabilities. Ordinary applications compose with existing tokens; direct issuance is restricted to authorized participants. Do not assume immediate redemption arbitrage to the underlying throughout the week. Stock-token mechanics.

Stock feeds update 24/5 and may pause during corporate actions. Validate feed age, oraclePaused(), price positivity, decimals and sequencer status, with a recovery grace period. A paused or stale feed must not authorize a new oracle-dependent fill. The onchain feed already includes the corporate-action multiplier; applying it twice misprices a token. Oracle documentation.

Chainlink further specifies that closed sessions and thin overnight windows can retain the last published value and that these feeds have no heartbeat during off-hours. A callable positive price therefore does not establish freshness; session-aware age bounds must be part of the strategy. Chainlink's Robinhood feed specification.

Separate regular-hours, after-hours, overnight, premarket, weekend/holiday and corporate-action behavior. For a first overnight pilot, select assets with observed fresh overnight feeds and depth; use explicit inventory caps and a terminal inventory policy. Exclude stale-feed periods until a separately tested policy supports them. Extending the freshness threshold over a weekend is not new price discovery. A grid around Friday's closing value can be picked off after material news.

Underlying-price movement and token premium/discount are separate potential drivers. Measure token price against a contemporaneous multiplier-adjusted underlying reference when available. Closed-market discounts need not revert before capital or risk limits bind. Retain raw token quantities and historical multipliers; current multipliers cannot retroactively repair all historical observations.

The REST prices API reports raw underlying bid/ask and underlying daily volume. Those values do not prove onchain liquidity. Its capability schema also differs from the simplified example in the overview; use the actual response and detailed API schema, treating missing values as unknown. Stock-token API.

Token transferability does not establish product eligibility: Robinhood's current offering documentation restricts stock-token offers and sales, including to US persons. Product distribution needs to reflect the actual token terms; this is separate from technical ERC-20 compatibility. Issuer restrictions.

Connect implementation research to the backtest. Use the existing hourly data to shortlist candidates and coarse parameter families. Before claiming executable profitability, collect chain-specific pools, swaps, active liquidity, fees, hook identity, quotes at intended size, oracle updates, corporate actions and session labels. Rank by executable depth and observed session volume as well as reported volume. Avoid selecting historical assets using today's winners without labeling that selection bias.

Use separate replay engines for taker fills and maker inventory conversion. Sparse samples do not reveal within-hour crossing order, number of oscillations, available size or fill latency. Do not manufacture extra cycles through interpolation. Freeze parameters before walk-forward evaluation, report the number of configurations searched, and test sensitivity to worse costs, delayed or missing fills, wider spreads and opening gaps.

For a completed taker cycle, approximate:

net cycle return ≈ gross grid spacing − both-leg venue/hook/service fees − slippage − gas and keeper costs / cycle notional

Illustration only: 50 basis points of spacing, 10 bp execution cost on each leg, 8 bp combined slippage and 4 bp combined gas/keeper cost leaves about 18 bp before inventory and terminal-exit losses. A 50 bp service fee on each leg would make that cycle negative. These are hypothetical values, not observed Robinhood fees. Maker economics instead require actual fee entitlement and inventory accounting.

Report ending marked and executable-liquidation NAV, idle cash, base inventory, collected fees, realized P&L, unrealized P&L, costs, drawdown, turnover and unfilled levels. Compare with cash, the same starting inventory held, and a passive liquidity strategy where relevant. Many closed profitable cycles can coexist with a loss on accumulated inventory. Recentring and mandatory closeout costs belong in results.

Suggested build sequence: (1) instrument a few demonstrably liquid stock/stablecoin pairs; (2) shadow a deterministic offchain grid using executable quotes and the intended contract limits; (3) fork-test a minimal isolated strategy account, including malicious keeper, replay, stale feed, sequencer outage, cancellation and withdrawal cases; (4) after review, run a capped operator-funded pilot; (5) benchmark a v4 maker hook against the same capital and market regimes. Pooled deposits and arbitrary custom matching come later if evidence justifies them.

The key open question is whether session-specific spreads and repeated two-sided flow cover execution and inventory costs at useful trade sizes. Neither cheap L2 gas nor v4 hooks establishes that edge. The next evidence should be transaction-level fill and cost measurements connected to the existing strategy lab.