BlueChip update: re-storing two contracts — the price oracle is gone, and that’s a good thing
Repository: GitHub - Bluechip23/bluechip-osmosis-contract · GitHub
What’s being asked: 2 new StoreCode proposals (factory + creator-pool). The router stored by proposal #1040 (code 1903) is reused unchanged.
FIRST — AN APOLOGY, AND WHY WE’RE BACK
A few weeks ago you approved three StoreCode proposals for BlueChip (#1037 factory, #1038 creator-pool, #1040 router). I have to ask you to store two of them again, and I’m sorry for the repeat ask. Here’s exactly what happened.
The approved contracts valued commits against a USD-denominated threshold using the Pyth OSMO/USD price feed. Between approval and launch, that dependency died out from under us:
- Pyth discontinued its CosmWasm/Osmosis integration in favor of its new Pyth Pro product, which has no on-chain deployment agreement with Osmosis.
- The existing Pyth contract on Osmosis is now effectively frozen — price updates fail verification (GuardianSetExpired), and there is no path to fix that from our side.
- We surveyed the alternatives (Band, other oracle providers, on-chain TWAPs). Nothing on Osmosis today can safely secure a USD threshold: the OSMO/USD pool substrate is thin enough that manipulating an on-chain price for a threshold-sized decision is cheap, and no maintained external feed exists.
Launching the approved bytes would have meant launching a protocol whose commits fail closed forever — the fail-safe design working as intended, but against a dependency that will never come back. So rather than bolt on a fragile replacement oracle, we removed the concept the oracle existed to serve.
WHAT CHANGED: EVERYTHING IS PRICED IN OSMO NOW
The commit threshold is now denominated in OSMO itself:
- Threshold: 500,000 OSMO (~$20k at recent prices). A commit’s value toward the threshold is its attached OSMO — no conversion of any kind happens.
- Minimum commits: 115 OSMO pre-threshold / 25 OSMO post-threshold.
- Everything else you approved is unchanged in design: TokenFactory creator denoms, the fixed 1.2M supply and its split, native GAMM pool seeding at crossing, pro-rata committer airdrop, 48h timelocks on every admin action, multisig admin.
The one place a price is still read: at threshold crossing, Osmosis itself charges a pool-creation fee denominated in alloyed USDC (~$20). The contract budgets that single ~$20 swap using the chain’s own x/twap module — and that swap’s spend is hard-capped to the protocol’s own fee revenue, so it can never touch committed funds.
WHY THIS MAKES THE CONTRACT SAFER, NOT JUST SIMPLER
Removing the USD conversion removes the attack surface that came with it. Concretely:
- No oracle to manipulate. Under the old design, whoever could move the price feed could move when pools cross — the single most valuable event in the protocol (it mints the supply and seeds the pool). Now the crossing condition is a plain sum of OSMO received. There is nothing to spoof, stale-date, or manipulate.
- No oracle to trust. Committers no longer have to trust Pyth’s publishers, a guardian set, or our operation of a price-pushing keeper. The keeper is gone entirely — one less standing piece of infrastructure whose failure would halt the protocol.
- No liveness dependency on anyone. The old design failed closed (safely) whenever the feed went stale — which, as Pyth just demonstrated, can mean failing closed permanently. The new design has no external dependency that can take the protocol down.
- The one remaining price read is fee-sized and fenced. The ~$20 fee swap’s TWAP is bounded by a hard sanity ceiling, fails closed on any anomaly, and its spend is clamped to protocol fee retention — a worst-case exposure of protocol revenue on a ~$20 operation, never user funds. It cannot affect whether or when a pool crosses.
The net effect: the questions a security reviewer has to ask shrank from “can anyone influence the price feed, the keeper, or the TWAP that values every commit?” to “can anyone miscount OSMO?” — and counting attached coins is the one thing a chain does natively.
ABOUT THE THRESHOLD NUMBER
A fixed 500,000 OSMO threshold is honest but not immortal: if the OSMO price moves a lot, the equivalent raise size moves with it. So, plainly stated up front: we expect to adjust the threshold over time to keep it economically sensible — if OSMO doubles, a lower OSMO threshold keeps the raise size similar; if it halves, the reverse.
That adjustment is not a backdoor:
- It rides the factory’s standard 48-hour timelocked config process — every pending change is publicly visible on-chain (the factory exposes a PendingChanges query precisely so anyone can watch), and a pending change that isn’t applied within 7 days expires and must be re-proposed.
- A threshold change applies to pools created after the change. A pool that is already funding keeps the threshold it was created with — nobody’s in-progress raise gets moved.
Two StoreCode proposals (they cannot share a transaction due to per-tx gas limits):
factory sha256: b2d5e5014f08e67a8ed6eca3f0b396f3702ac744f6c66c2978dfa2d53aeb03e6
creator_pool sha256: 517ac0daf1b6345b7308d0d29eed2b9448e80b0cf4908ce9b7f0488ebea82b70
The router does not need re-storing: it never touched the oracle, and its reproducible build is byte-for-byte identical to code 1903 (ea5c69bb…) that you already approved in #1040 — we simply reuse it. Codes 1901/1902 from the earlier proposals will remain unused on chain.