Building Trisara (Colosseum hackathon): session-aware pricing infra for RWA markets: a real clock for equity prices onchain.
The BONER/HIMS case is the exhibit: one meme cornered ~42% of HIMS on-chain float and pushed the wrapped token to $132 against a $28 real close over a weekend with the NYSE closed. No arb window fast enough to hold the two together. Uniswap routes >99% of tracked stock-token DeFi deposits on Robinhood Chain, so this lands on your pools first.
I verified the root cause live (Chainlink equity feeds frozen 37.7h over weekends). Trisara’s PoolTwapAdapter + GuardedSwapRouter collars flow when the reference market is closed: a plug-in, not a fork.
Is session-aware pricing something v4 hooks on RH Chain should standardize? Keen for the community’s take.
Session awareness and price correctness are different problems: a feed can be accurate at Friday close and still be unusable as a routing or liquidation reference while the underlying venue is shut. If this becomes a v4 hook standard on Robinhood Chain, would you have the hook fail closed once the reference session is stale, or allow swaps inside a bounded collar around the last live price?
Exactly the right distinction, and it’s why the policy is per action class, not per feed.
A liquidation reference should fail closed (HALT). Liquidations are irreversible; there is no Monday reprice. We logged NVDA’s Friday print sitting about 0.5% below Monday’s first live price — a venue liquidating off the stale print would have wrongfully liquidated borrowers it had no business touching.
A swap router is different: the user is present, the trade is consenting, and blocking all weekend flow is its own cost. There a bounded collar around the last live print is the honest middle. Flow continues inside a band the venue chose before the weekend; everything outside reverts with a reason code.
So the hook doesn’t impose one answer. It enforces the venue’s pre-published rule for each action class, with every trigger carrying a reason code and an expiry. The failure mode being removed isn’t “picked the wrong policy.” It’s “decided it mid-crisis.”
The 0.5% NVDA gap is a useful concrete case. Was the collar width calibrated from a distribution of weekend-to-reopen gaps, or was that 0.5% observation used more as a sanity check? I’m curious what evidence you’d use to set the boundary without making the collar so wide that the stale-price protection loses meaning.
Honest answer: sanity check, not calibration. One weekend and three assets isn’t a distribution. It’s a single observation proving the stale-print error is real and measurable.
What I’d actually calibrate from: the distribution of historical weekend-to-reopen gaps across many weekends and assets. That gives you the normal band — the reopen noise a collar must tolerate without false-tripping. Then the dated dislocations (HIMS at +360% over a weekend, JELLY-style squeezes) mark the tail the collar has to catch. The boundary lives between those two: wide enough that ordinary Monday gaps don’t trip it, tight enough that a real dislocation can’t hide inside it. We’re logging a second weekend Oct 10-11 to start building that distribution for real.
Two more things matter. First, the boundary isn’t global. It’s venue-set and pre-published, because a lender and a swap router have different costs of being wrong. Second, it’s revisable with evidence: every trip is logged with a reason code, so the venue sees its own false-trip rate and adjusts on a schedule, never mid-crisis.
The failure mode you’re pointing at is real: a collar so wide it never binds is decoration. That’s why the calibration has to be public and the trips have to be counted.
From the wallet support side, I think the part users will notice most is what happens when a swap gets blocked over the weekend. If someone just sees “swap failed,” they’ll assume something is broken. A plain message like “stock market closed, price limited until reopen” would save a lot of confusion. Would the reason codes be simple enough for wallets to show something like that?
Yes, that’s exactly the job the reason codes do. They’re small typed codes rather than revert strings, so a wallet can map each one to a message like the one you wrote without parsing text.
Two things make them wallet-friendly. First, the code names the situation, not the mechanism: a closed market, a dislocated price, and a stale feed produce different messages, because “market closed” and “price looks manipulated” deserve different user reactions. Second, the code travels with the resume condition. The wallet doesn’t just say “until reopen,” it can say “reopens Monday 9:30 AM ET,” or offer “retry at reopen” as a one-tap action instead of a dead end.
You’re pointing at the real UX risk here: a silent or cryptic revert trains users to think the app is broken, and then they route around the protection entirely. The whole point of returning a reason instead of just reverting is that the wallet gets to tell the truth about what happened.
1 Like
Update since the original post: core contracts are now live on all three testnets (Robinhood 46630, HyperEVM 998, Tempo 42431), and I ran a live guarded swap on 46630 tonight, 100 rUSDG for 0.258 TSLA at the session-aware price.
The weekend-freeze problem this post describes now has a running reference implementation. Happy to answer questions on the design.