Subway

AMM liquidity provision on Robinhood Chain (chain id 4663), hedged or not, as two fungible tokens.

A pooled vault (xAMC) LPs a Robinhood Stock Token against USDG on Uniswap. A second vault (hAMC) holds xAMC and hedges its delta with a short on Lighter's Robinhood Chain perp instance, whose settlement contract lives on the same chain and is owned by that vault. Holding xAMC is equity beta plus fees; holding hAMC is roughly dollar-stable with an on-chain NAV floor other protocols can price. Any ratio in between is a mix of the two.

Status: pre-launch research and contracts. Nothing is deployed, and no pair has been shown to be profitable. The evidence gate in research/ rejected the three pairs this project started from and has not yet cleared any replacement. Read the verdict before assuming the strategy works.

---

Why this shape

Shares are the product. A pooled vault mints a fungible token that can be posted as collateral, LP'd, or wrapped by other protocols. Per-user vaults cannot produce that.

The hedge is a second vault, not a flag. Holders want both modes. A per-holder hedged/unhedged flag inside one vault would make its shares non-fungible, which destroys the collateral use that is the whole reason for pooling. So the modes are two tokens, and "toggle hedge" is wrapping xAMC into hAMC or unwrapping it — no LP position is closed or reopened.

The unhedged vault ships first. xAMC has no keeper trading risk, no rollup dependency, no epochs and no redemption queue, and it measures fees against toxic-flow loss with real capital. That measurement decides whether either mode is worth running. hAMC is then a second contract rather than a rewrite.

Same-chain custody root. Lighter RH is an app-specific rollup whose L1 is Robinhood Chain, so the vault contract can be the L1 owner of the pair's Lighter account. Lighter's own rules then do the custody work: secure withdrawals land only at the L1 owner, L2 transfers and fast withdrawals need the L1 owner's signature, and API keys carry no withdrawal scope. The keeper's key is trade-only by construction, not by policy.

Hedge netting. One Lighter account per pair. Opposite flows across depositors cancel before touching the perp book; one key to rotate, one margin balance to bound.

The hard problem: what is a share worth?

xAMC has a much smaller version of this problem. Everything the base vault owns is on this chain: LP value at the Chainlink feed price, plus fees the range has earned, plus idle balances. Nothing is hidden inside a rollup, so nothing has to be haircut to zero, and withdrawals come straight out of the range.

What it is not is independent of the pool. The two legs are priced at the feed, but how much of each a range is holding is decided by the pool's current price — so moving the pool inside the range moves convertToAssets even with the feed still. The feed bounds the damage, because the inventory is always marked at an honest price rather than at a tick an attacker chose. It does not eliminate it. How deposits should be priced in the face of that is still open; see docs/a1-deposit-pricing.md.

The problem belongs to hAMC. Everything it owns is priceable — it holds xAMC, which prices itself — except the hedge equity, which lives inside Lighter's rollup and cannot be read from this chain. So navFloor() is a deliberate undervaluation built only from things the contract can verify:

floor = idle balances + xAMC value at the FEED price + margin × (1 − haircut)

with unsettled hedge PnL counted as zero. The error is one-directional: the floor can be too low, never too high. A lender reading it is safe; a depositor is paid slightly less than fair, which is the side to be wrong on.

Two consequences that look like bugs and are not:

• Depositors mint at the floor. Note which way that cuts: shares are value × supply / floor, so a lower denominator mints more shares. A depositor entering at a floor below true NAV is therefore mildly overpaid, at the expense of the holders already in. An earlier version of this file claimed the opposite and drew a security argument from it; the argument does not hold, and pricing an hAMC mint is an open Track B problem rather than something the floor solves for free.
• The price uses the Chainlink feed, never the pool tick. A pool tick is something an attacker can move with capital; a share price built on one is a share price they can print.

xAMC redeems synchronously; hAMC cannot

xAMC is not a compliant ERC-4626, and deliberately so. A slice of a Uniswap range is stock and USDG, so redeem returns two amounts; the single-asset ERC-4626 exits revert pointing at it, and mint/previewMint/ maxDeposit/maxMint/previewWithdraw are absent. What is implemented is ERC-20 plus the ERC-4626 accounting views (asset, totalAssets, convertTo*, previewDeposit, previewRedeem), because that is the part an oracle or a lending market actually reads. Implementing the 4626 exit signature and quietly paying two tokens would break every integrator that trusted the return value.

A redeemer is paid their pro-rata slice of the position, and nobody else's claim changes. Fees take an extra step to make that true: Uniswap v4 pays a position's entire accrued fee balance to whoever changes its liquidity, no matter how small the change, so the vault sweeps fees into itself before it divides anything and then splits them like any other idle balance. Without that step a one-share redeemer would leave with every other holder's fees. There is no cash buffer, because none is needed.

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗