Introducing Luminary.
We are the first to pursue scheduled sealed auctions for tokenized stocks.
At the open, close, and midnight UTC, orders meet privately and clear at one fair, reference-anchored price.
No one gets picked off. @robinhoodapp
$LUMI is not first in the rollout.
The roadmap starts with daily auctions, treasury settlement, and solvency.
Then comes RFQ blocks and NAV auctions.
$LUMI and the calendar API arrive after the market has real events to measure.
Soon on @RobinhoodCrypto
An auction engine should not be the first system deciding what it can trade.
Luminaries starts with an RWA only registry, Reg S coherence with Stock Tokens, and non US jurisdiction gates.
Eligibility is resolved before the matching rule gets involved.
Every completed call is designed to leave a traceable record.
id
asset
kind
callBlock
pStar
crossedQty
proofTx
That last entry matters.
The price on the tape can point back to the transaction that verified the auction.
One proof settles the call.
That is the target in Luminary's design. AuctionClearProof covers the complete result: p*, crossed quantity, limit compliance, reference band, and conservation.
The proof matches the unit of the market event.
Built on @RobinhoodCrypto
Before an asset reaches an auction, Luminary puts it through an RWA only registry.
The base tracks raw units, two price views, the treasury quote, corporate actions, solvency, and a tape.
The auction engine inherits that foundation. It does not replace the asset system beneath it.
Solvency and clearing proof solve different jobs.
Solvency sits in the RWA base.
AuctionClearProof checks the call itself: the price band, order limits, volume condition, and conservation.
A market has to show it can settle.
It also has to show how it selected the result.
Built on @RobinhoodCrypto Chain.
The spec treats a successful auction as a list of observable results.
A closing call clears crossable NVDA orders at one p* inside the band.
A fund call anchors to NAV.
An RFQ cross settles privately at reference.
An ex date pauses the schedule.
That is the actual acceptance bar.
Net asset value appears twice in Luminaries, for two different reasons.
Treasury quote notes accrue NAV while an order waits.
A fund auction can also use NAV as its reference anchor.
One keeps the quote asset productive.
The other sets the basis for the call.
Creating @RobinhoodCrypto next gen infrastructure.
AuctionPool extends RwaDarkPool.
That matters because Luminary is not treating privacy as a bolt on after matching.
The RWA pool is the base.
The auction layer adds a scheduled call, uniform clearing, verification, and a public print on top of it.
Building privacy on @RobinhoodCrypto
Each contract has one job.
AuctionPool holds auction state.
AuctionVerifier accepts the result.
PrintRegistry writes the record.
FeeVault handles fee flow.
Foundry is in the stack because settlement, verification, reporting, and fees are distinct contract responsibilities.
The proof layer starts from a shipped privacy core.
AuctionClearProof is a BatchCrossProof variant with auction checks for the reference band, limits, matched quantity, and conservation.
The circuit's job is simple: show that the published clearing result followed the rules.
Built on @RobinhoodCrypto
The reference path changes with the asset.
For stock auctions, Luminary is designed around a Chainlink based reference band.
The multiplier and cap set the permitted range.
For funds, an issuer can request an auction anchored to NAV.
One clearing engine. Two reference models. Different assets get the right starting point.
Soon on @ponsdotfamily
Luminary’s test plan treats time as a source of risk.
The fixtures cover daylight saving changes, holidays, ex dates, and NAV anchored calls.
Before an auction calendar becomes a product surface, it has to survive the dates that break ordinary scheduling code.
Soon on @RobinhoodApp
Every auction record carries a kind.
OPEN
CLOSE
MIDNIGHT
NAV
That field lets the same settlement path handle an underlying market open, a close, the 00:00 UTC call, or an issuer requested fund event.
Matching and proving are separate jobs.
The clearing engine selects p*. The Noir based AuctionClearProof checks whether that result respected the band, order limits, crossed volume rule, and conservation.
The proof is not the auctioneer. It is the evidence trail.
The Bun and TypeScript engine has a narrow job: run the schedule and calculate the auction.
Golden fixtures feed it known orders, references, and limits.
The expected p* is already defined.
That turns a market rule into software that can be tested case by case.
Luminaries gives every auction a hard boundary.
AuctionCalendar opens the collection window.
Orders enter sealed. Then the call block is pinned before clearing begins.
The match belongs to a defined event on the chain, not an arbitrary moment in a rolling book.
Building @RobinhoodApp Rails.
The auction tests are written around outcomes, not interfaces.
Can every crossable order clear at one price?
Does that price remain inside the reference band?
Were all limit instructions respected?
Those are the conditions Luminary has to satisfy before the first closing print matters.
Luminary is built on an existing RWA stack, then changes the matching model.
The base already covers the registry, dual pricing, raw unit notes, treasury quote, corporate action calendar, solvency, and tape.
The auction layer is the new market primitive.
Built on @RobinhoodApp