Store Bluechip creator-pool contract, Got rid of Pyth Oracle

Proposal Discussion DApps / Tooling
1

This proposal stores the CREATOR-POOL contract of the Bluechip creator-token launchpad — the second and final StoreCode for the protocol’s native-threshold rebuild. The companion factory proposal (#1043) passed on 2026-09-20 and is stored as code 1904; the router needs no new store (its reproducible build is byte-identical to code 1903, approved in #1040, and is reused as-is). Codes 1901/1902 from #1037/#1038 are superseded and will remain unused.

What this contract is

The creator-pool is the per-creator contract the factory (code 1904) instantiates. It holds the commit ledger while a pool is funding; executes the atomic threshold crossing (mints the fixed 1.2M-token TokenFactory supply, seeds a native GAMM balancer pool from the committed OSMO, queues the pro-rata committer airdrop); and post-threshold routes swaps through x/poolmanager. Third-party liquidity uses ordinary MsgJoinPool/MsgExitPool on the native pool — the contract is not in the LP path.

Why a re-store: moving off the Pyth oracle

The previously approved build (#1038, code 1902) valued every commit in USD against a $25,000 threshold using the Pyth OSMO/USD feed. After approval, Pyth discontinued its CosmWasm integration and the on-chain Osmosis feed froze (price updates fail guardian verification), with no path to recovery and no viable replacement: no maintained external feed exists for Osmosis, and on-chain OSMO/USD liquidity is thin enough that a TWAP securing a threshold-sized decision would be cheap to manipulate. Rather than substitute a fragile oracle, the rebuild removes the concept the oracle served. Concretely, in this contract:

  • The USD valuation path is deleted end to end: no oracle contract calls, no price structs, no staleness/confidence gates, no off-chain price keeper. The string ‘pyth’ does not appear in the proposed binary.
  • The commit threshold is now denominated in OSMO itself (500,000 OSMO at launch): a commit’s value toward the threshold IS its attached OSMO. No conversion happens anywhere.
  • Minimum commits moved from USD amounts to 115 OSMO (pre-threshold) / 25 OSMO (post-threshold).
  • The single remaining price read is chain-native: an x/twap query over a configured OSMO/USDC pool, used SOLELY to budget the ~20 alloyed-USDC pool-creation fee that x/gamm charges at threshold crossing. It never values a commit and cannot affect whether or when a pool crosses.
  • Commit fees at the threshold crossing are charged on the THRESHOLD PORTION only: a commit that overshoots the remaining gap pays the 1% + 5% fees on the gap it actually fills, and the gross excess is refunded fee-free in the same transaction (with one bounded exception: while the pool-creation-fee reserve is still short, at most 1% of the excess is retained toward it — never bank-sent, and zero once the reserve is full).
  • The threshold number is expected to be retuned over time (so its real-world size stays sensible as the OSMO price moves) through the factory’s standard 48-hour timelocked config process — publicly watchable on-chain via the factory’s PendingChanges query, expiring if unapplied within 7 days, and applying only to pools created after the change.

Security advantages

  • No oracle to manipulate. Under the old design, whoever could influence the price feed could influence when pools cross — the event that 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 external trust or liveness dependency. Committers no longer rely on Pyth publishers, a guardian set, or the team’s operation of a price-pushing keeper — infrastructure whose failure (as Pyth just demonstrated) can be permanent.
  • The remaining TWAP is fee-sized and fenced. It budgets only the ~$20 fee swap; it is fail-closed on any anomaly (query error, zero price, prices beyond a hard plausibility ceiling), and the swap’s maximum spend is hard-clamped to the protocol’s own 1% commit-fee retention — so even a fully manipulated pricing pool can at worst touch protocol revenue on a ~$20 operation, never committed funds. The crossing also tracks the chain’s LIVE x/poolmanager fee, so an Osmosis governance change to the fee cannot strand pools.
  • The crossing’s fund split is hard-checked: the threshold portion, the refund, and any reserve retention must reconstruct the attached commit exactly, or the whole transaction reverts.
  • The liquidity circuit breaker is a per-transaction revert: if either side of a live pool falls below 25% of its seeded liquidity, the affected swap reverts and the sender’s funds return by normal transaction failure — protecting each trade without wedging commits or the committer airdrop behind a latched pause.
  • Committer entitlements survive worst cases: airdrop mints are ledger-bounded, failed mints are individually claimable, and those claims remain available even after an emergency drain (they never touch swept funds).
  • Validated: 302 unit tests plus an 8-scenario end-to-end suite executing the real Osmosis modules (tokenfactory, gamm, poolmanager, twap) — full lifecycle, a mainnet-shape crossing paying the 20-USDC fee through a live pricing pool, atomic revert of a mid-crossing module failure, and fail-closed handling of fee changes — plus two rounds of adversarial security review focused on whether removing the oracle opened any new path to user funds. The reviews’ hardenings are in these bytes.

Artifacts

Reproducible from the repository default branch with cosmwasm/optimizer 0.16.0 (git clone, make optimize-all, sha256sum artifacts/*.wasm; commit e2d6811d932003f97f80f6bde9abea0890445254):

  • creator_pool.wasm (THIS proposal): sha256 85300cbd2f7c513b8504da569ffe4218c73ffcac791390b2bb8c98eb0a507242
  • factory.wasm: sha256 b2d5e5014f08e67a8ed6eca3f0b396f3702ac744f6c66c2978dfa2d53aeb03e6 = stored code 1904 (proposal #1043, passed) — the same commit reproduces it byte-identically
  • router.wasm: sha256 ea5c69bb716932c0b879780f904437c6606a4c38a25a1d1f0d2bf654207a64ac = stored code 1903 (reused)

Instantiate permission is Everybody: the factory instantiates this code at runtime, and the factory’s address could not be allowlisted before it existed. Third-party instantiations are inert — a pool only trusts the factory that instantiated it, and the factory’s registry only recognizes pools it created itself.

This proposal only stores code. It instantiates nothing, changes no chain parameters, and grants no module access. Pools only ever hold OSMO, their own TokenFactory denom, and the gamm/pool LP shares of the pool they seeded — no privileged mint of OSMO, no bridged-asset exposure. Every admin mutation sits behind a 48-hour on-chain timelock and the admin/migrate authority is a multisig.

2

Good to see a way forward after the Pyth issue. Counting everything in OSMO is easier to follow as a user, too. Since the target will be adjusted over time, showing a rough dollar value next to the OSMO amount on the pool page could help people understand what they’re committing. Looking forward to seeing the first creator pools go live.

1 Like
3

(post deleted by author)

4

Thank you for the rebuild. Removing the oracle from the crossing path is the right call, and I’d keep it exactly as is. A crossing condition that is a plain sum of OSMO is the strongest property of this design. My suggestion is a follow-up that builds on it rather than replacing it.

The remaining issue. A fixed 500,000 OSMO threshold makes the real-world size of each launch drift with the OSMO price. If OSMO doubles, the threshold costs committers twice as much in USD terms. If it halves, pools seed with half the intended depth. Both hurt TVL: the first raises the barrier to launching, the second creates thinner pools that are easier to move.

Suggestion: a bounded, USD-guided threshold, set at pool creation only.

  1. Keep the crossing oracle-free. Each pool’s threshold is a fixed OSMO number, snapshotted when the pool is created. Committers always know the exact target, and it never moves mid-funding. The price never touches commits, fees, or the crossing itself.
  2. Use the price only to guide retuning. The target would be roughly $25,000 / reference price, computed off-chain or by a keeper and proposed through the existing 48-hour timelock and multisig flow (visible in PendingChanges). Governance stays the final gate, so nothing is automatic or unreviewable.
  3. Use a robust reference price. Take a time-weighted median across several independent, sufficiently liquid markets, with minimum liquidity and freshness checks. If those conditions can’t be met, no retune is proposed.
  4. Hard-bound every change. Set an absolute floor and ceiling in OSMO and a maximum step per epoch (for example ±10–15%). Even a fully manipulated price can then only mis-size a future threshold slightly. It can never touch committed funds or an in-flight pool.
  5. Fail static, not closed. If the price source is unavailable, the last threshold simply stays in force. Launches continue and nothing stalls, which also avoids a Pyth-style permanent dependency.
  6. Make it transparent. The UI should show the USD goal, the current OSMO target, the reference price used, live progress, and the atomic fee-free refund of any excess.

Why this helps TVL. Launch size stays predictable in dollar terms, so seeded pools have consistent depth, and the barrier to entry doesn’t spike when OSMO rallies. That makes launches more attractive to creators and committers and keeps pool quality steady across market cycles.

Honest trade-off. The price still matters, but only as advisory input to a timelocked, bounded parameter change. The worst case is a slightly mis-sized future threshold. Unlike the Pyth design, there is no fund-loss path and no liveness dependency. I’d treat this as a v2 parameter-governance improvement, not a blocker for storing this code.