Store Bluechip protocol CosmWasm contracts
Type: StoreCode (3 × MsgStoreCode in one proposal) Deposit: 6,000 OSMO (confirmed against the live min_deposit on osmosis-1; 14-day deposit period) Repository: GitHub - Bluechip23/bluechip-osmosis-contract · GitHub Commit: 91cc5633bbc1d0120cd15fe0de2b5db6fca9d0a0 Mainnet Submission: August 5th 2026
TLDR
Posting this a final time to get any feed back prior to getting main net approval.
Bluechip is a creator-token launchpad built using the Osmosis-native modules TokenFactory, GAMM, and poolmanager. A creator launches a token with no upfront liquidity or cost (cost is taken on by the protocol, explained later). Supporters commit OSMO toward a USD-denominated threshold, and when it’s crossed the contract mints a fixed 1.2M supply of the creators token, seeds a real GAMM balancer pool from the committed OSMO, and airdrops creator tokens to committers pro-rata.
This proposal only stores three contracts. It does not instantiate anything, does not touch chain parameters, and grants no privileged access to any chain module.
Every new pool becomes tradeable through poolmanager, LP-able via ordinary MsgJoinPool/MsgExitPool, and routable by any aggregator on day one.
What it does
- Create — a creator registers a pool. The creator token is a TokenFactory denom (
factory/{pool}/{symbol}) with the pool contract as denom admin. - Commit — supporters send OSMO. Each commit is valued in USD via the Pyth OSMO/USD feed and recorded on a ledger.
- Cross — when cumulative committed value reaches the threshold ($25k), the pool atomically mints the fixed supply, seeds a GAMM balancer pool with the committed OSMO plus the pool-seed token allocation, and queues the committer airdrop.
- Trade — post-threshold the pool is a standard Osmosis GAMM market. Swaps route through
MsgSwapExactAmountIn. Third-party LPs use native join/exit. The protocol has no in-house AMM.
Fixed supply, 1,200,000 tokens (6 decimals), split at crossing:
| Allocation of Creator Token | Amount |
|---|---|
| Committer airdrop | 500,000 |
| Pool seed (into the GAMM pool) | 350,000 |
| Creator | 325,000 |
| Protocol | 25,000 |
The commit threshold is USD-denominated but paid in OSMO. The crossing commit is capped at the amount needed to reach the threshold. Any overshoot is refunded in the same transaction.
What’s being stored
Built reproducibly with cosmwasm/optimizer:0.16.0 from commit 91cc5633bbc1d0120cd15fe0de2b5db6fca9d0a0:
| Contract | Size (bytes) | sha256 |
|---|---|---|
factory.wasm |
474,687 | 99de8ac76503b0188711ce03ab7075b1809f5d0cffd9d45a61231c673181828b |
creator_pool.wasm |
584,874 | bd7f1833186e909c75b24ecc21455ec1bf37b9ed2fca5a97e42b10d8dcc583a4 |
router.wasm |
288,931 | ea5c69bb716932c0b879780f904437c6606a4c38a25a1d1f0d2bf654207a64ac |
Reproduce it yourself:
bash
git clone https://github.com/Bluechip23/bluechip-osmosis-contract
cd bluechip-osmosis-contract
git checkout 91cc5633bbc1d0120cd15fe0de2b5db6fca9d0a0
make optimize-all
sha256sum artifacts/factory.wasm artifacts/creator_pool.wasm artifacts/router.wasm
We verified this ourselves: an independent rebuild from this commit produces byte-identical artifacts (cmp, not just matching hashes). All three pass cosmwasm-check 3.0.9.
instantiate_permission is Everybody on all three. The factory instantiates the creator-pool code at runtime, and the factory’s own address does not exist until after this proposal passes, so it cannot be allowlisted here. The factory’s registry only recognizes pools it created itself through its own reply chain, and unregistered pools are rejected by the router and every cross-contract path.
Security model
Fixed supply, enforced structurally. The four allocations are constants validated at instantiate and re-checked at crossing. The crossing is a single minting event behind four independent gates plus a factory-side idempotency flag. Total minted can never exceed 1.2M creator tokens (per pool). We proved the three sub-invariants and confirmed it live by creating five testnet pools with different committer counts, each distributed exactly 500,000 tokens.
Solvency. Every coin-outflow path was traced against an explicit invariant (bank balance ≥ committer obligations + creator escrow + failed-mint claims + reserved fee). No over-send, double-pay, wrong-recipient, or escrow-sweep path was found. Airdrops are satisfied by fresh mints rather than held balances, and the emergency-withdraw sweep explicitly excludes the creator’s escrowed excess.
Slippage / MEV. Post-threshold buys require an explicit belief_price. The resulting floor is enforced by poolmanager against the realized swap output (token_out_min_amount). Max spread is hard-capped at 5%. A shared reentrancy lock covers commit and swap. The creator token is a native denom with no receive hook, so there is no callback surface.
Governance. Every privileged factory entry point is admin-gated, and all config/pool-config/code-upgrade flows are 48-hour propose. Emergency withdrawal is two-phase with a configurable delay (6h floor, 24h default) and pauses the pool on initiation.
Admin authority is a multisig. The wasmd migrate admin and the in-contract admin are both set to a cw3-flex multisig at instantiate. There is no window where a single EOA holds authority. Our deploy tooling refuses to run against osmosis-1 without a multisig address configured.
Audit status
The codebase has been through multiple adversarial review rounds, most recently a final pre-mainnet pass focused on the least-tested surfaces. Findings were fixed and the whole suite re-verified.
Verified sound (with concrete evidence, not assertion): Pyth wire deserialization against the live on-chain contract; the GAMM pool_id reply decode; the 1.2M supply invariant; end-to-end solvency across all outflow paths; belief-price enforcement against realized output; reentrancy coverage.
Fixed during review (highlights):
- Tightened the price plausibility band from $10,000 to $100/OSMO — the loose ceiling would not have caught a feed id mis-pointed at a higher-priced asset (ETH, SOL), which could have let a threshold be crossed cheaply. Admin-gated and 48h-observable, but the guard now actually does what it claims.
- Added
serdedefaults on the Pyth config fields — an in-place migration from a pre-Pyth config would otherwise have bricked every config load, including the admin check, unrecoverably. - Made a non-canonical Pyth response (a bare price with no feed id to verify) fail closed instead of being trusted.
- Rejected a 100% total commit fee, raised the emergency-withdraw delay floor from 60s to 6h, added a
pool_id != 0guard on the create-pool reply, and widened the cross-denom fee-swap margin from 5% to 20% (a thin margin risked stalling crossings during normal volatility). - Decoupled the oracle probe from unrelated admin actions, so a lapsed price keeper can no longer block an emergency wallet rotation.
Open items, disclosed:
- The circuit breaker latches on trip and requires a manual admin unpause. Because the underlying GAMM pool is public, someone could push a pool below the breaker floor via a direct trade and leave it paused until an admin intervenes (~1.8% of seed value + transient capital, no fund loss, offer coin refunded). We plan to make this self-healing.
- Emergency withdrawal, if invoked mid-distribution, forfeits not-yet-flushed airdrops. It is a last-resort control and documented as such.
Test suite: 320 unit/property tests plus 11 end-to-end tests against a real in-process Osmosis chain (osmosis-test-tube), all passing at the proposed commit.
Testnet validation
The full lifecycle was exercised on osmo-test-5 against a mock Pyth oracle serving a fixed $10.00/OSMO.
Why we used a mock:
- The testnet Pyth OSMO/USD feed is not kept fresh by anyone. When we measured it during this review it was 53 hours stale against a 300-second staleness gate.
- At the real testnet price ($0.03175/OSMO), even a heavily reduced USD threshold requires far more OSMO than testnet faucets dispense.
The mock serves a controlled price in the exact Pyth wire format, so the deserialization and gating code under test is the production path.
These are the exact bytes in this proposal. The contracts were stored on osmo-test-5 and the reported data_hash for each matches the hashes above byte-for-byte.
bash
osmosisd query wasm code-info 13291 --node https://rpc.testnet.osmosis.zone:443 # factory -> 99de8ac7…
osmosisd query wasm code-info 13290 --node https://rpc.testnet.osmosis.zone:443 # creator_pool -> bd7f1833…
osmosisd query wasm code-info 13292 --node https://rpc.testnet.osmosis.zone:443 # router -> ea5c69bb…
The factory and router were instantiated with a cw3 multisig as both migrate and in-contract admin from block one. This is the same structure as a mainnet launch.
Deployed contracts (osmo-test-5) — each is inspectable with osmosisd query wasm contract <address>:
| Contract | Details | Address |
|---|---|---|
| Factory | code 13291, admin = cw3 | osmo1atalwvm4fhxlwk523dz3dhlxj9440xtxxyxsca9uk579wu9q9z3qy6kdq7 |
| Router | code 13292, admin = cw3 | osmo1v2m093ltc7qvfmw3z3g497alwr0mrz6weeltaxkk5cuqtz6a7dhql8c99c |
| cw3 multisig | 3-of-4, 48h voting period | osmo19hu4nhna9yk9ma4nz5wnsj99sgn687ccyk7l04p2w0d6f3se4w7qjfmw79 |
Each pool below is code 13290 with the factory contract as its admin, so the registry chain of custody is verifiable on-chain rather than asserted.
Each pool used a distinct creator, since the production build enforces a 1-hour per-address creation cooldown:
| Pool | Committers | Split | Distribution | GAMM pool |
|---|---|---|---|---|
| PRONE | 1 | 100% | 500,000 — $30 overshoot refunded | 1351 |
| PRTWO | 2 | 25 / 75 | 125,000 / 375,000 | 1352 |
| PRTRE | 3 | ⅓ each | 166,666.7 / 166,666.65 / 166,666.65 | 1353 |
| PRFOR | 4 | 10 / 30 / 20 / 40 | 50,000 / 150,000 / 100,000 / 200,000 | 1354 |
| PRFIV | 5 | 20% each | 100,000 ×5 — $20 overshoot refunded | 1355 |
Pool contract addresses (all code 13290, admin = factory):
| Pool | Address |
|---|---|
| PRONE | osmo1n9v0rferg2e2dy2q3jgrav6yuxmfahhp2ec0g0f0dwxr7d8g06eqazmpzz |
| PRTWO | osmo16q5md48vhksacddfuehvu9ftcwgf5uvukscpjj4c23n5uughyyls4ld5hc |
| PRTRE | osmo1mzfxtj2jfq5vsdju0wvp42zr0a2uvahgkr6vm7790r5aajrkza9qfdfytu |
| PRFOR | osmo1czmfdcawn9wk5u7ve8kxgmak8pqvdmq0qsvhm54ep8fpetcu9krsgus7rw |
| PRFIV | osmo1x5fmjhrwzdwqe55nsued3er43m6aqervjtdahh7lpcphglklzxnqct4n4m |
Every pool’s committer shares sum to exactly 500,000 creator tokens — including the ⅓-each case, which is where floor-division dust would show up if the residual settlement were wrong.
Also exercised on these bytes: creator-excess escrow claimed on all five pools, third-party LP join → swap volume → exit (126,517,571,884,984,025,500 shares minted then burned to zero, with the constant-product invariant growing at constant shares i.e. fees accrued), and the safety gates — null-belief swap refused, belief-priced swap accepted, a $200/OSMO price refused at the plausibility ceiling, a backdated price refused as stale, a sub-minimum commit refused, and a post-threshold commit correctly behaving as a swap with no second crossing.
Representative transactions (all code=0, osmo-test-5):
| Action | Tx |
|---|---|
| Pool creation | B7096ED9249A4F0046104AD5A8E0DCD31585757A08D20772850F041A89C0B057 |
| Crossing w/ overshoot refund | 3983614F5A0429E5A00AAA4B7E1C58D878EA6688E358C326F88E2E576E390DB3 |
| Five-committer crossing | AEDB353B1081B2239B99E42F20276FB2B0B8F54AAE12D18782CBD96DAE0A6E92 |
| Creator-excess claim | 8BD358579E59885C637AC5C8619D3E603E3A3842885058D8695F54BF484B4E41 |
| LP join | AC16A3BECB5CEE70A67C6F1ED4DFE3A3B487F9244B80CB0D43C3409D67D9C18B |
| LP exit (shares → 0) | 9E5F7502D8DB633558A2375C06AB5868E73AD2E79DC14EDBE27AE5B88D5863E8 |
| Belief-priced swap accepted | 4366354B8BAD8CF326559CC84580480393038D4DF4AC5FC2DAE89FB2055F6160 |
| Post-threshold commit (no re-cross) | 10E78A406D6E0323F582DDBE4BA6594CA52B2693E3CF456752CC707A60B3831C |
Two flows are not in the list above, for an unavoidable reason: the router registration timelock is 48 hours and the emergency-withdraw delay has a 6-hour floor on the production build. Verifying those on-chain takes 48h and 6h of real elapsed time respectively. Both are covered by the end-to-end suite against a real chain binary, and both were previously exercised on-chain against a time-shortened build of the same code. We will publish the mainnet transactions for both once the stack is live.
How the real Pyth path is verified despite the mock:
- Wire format checked against the live contract — the real testnet Pyth contract’s
PriceFeedresponse matches our type definitions field-for-field, including Pyth’s asymmetric JSON encoding (price/confas strings,expo/publish_timeas numbers). This is where a deserialization bug would hide, and it’s the mock’s shape too. - Live probe against the real Pyth contract — instantiate/propose/apply run the complete read-and-gate pipeline against the configured contract and refuse a misconfigured or unreadable route.
- Every gate boundary is unit-tested — staleness 300 vs 301s, minimum age 10 vs 9s, future skew 5 vs 6s, confidence threshold ±1bp, exponent range, feed-id mismatch and case-insensitive match, plausibility band.
- End-to-end against a real chain binary — the factory performs genuine cross-contract queries to a deployed mock-pyth contract, including the fail-closed stale path.
- The gates were tripped on-chain — feeding out-of-band values, a $200/OSMO price was rejected at the plausibility ceiling and a backdated publish time was rejected by the staleness gate. The rejection logic ran on a real chain, not only in unit tests.
Not yet proven end-to-end: a threshold crossing priced by the live mainnet Pyth feed. That requires the mainnet feed plus a running price keeper, and it is the first thing we will validate after deployment.
Operational dependencies
Pricing uses Pyth, and that requires a keeper. We chose Pyth over an on-chain pool TWAP because the OSMO/USD pool substrate is thin. A few thousand dollars of depth per venue makes a pool-TWAP oracle manipulable for roughly $1–3k, which is unacceptable for a threshold that gates minting. Pyth aggregates many venues, so moving it is orders of magnitude more expensive.
Pyth on Osmosis is push-based and nobody currently keeps OSMO/USD fresh there, so we run a standing keeper that pushes signed Hermes updates on-chain. If that keeper lapses, the staleness gate makes commits fail, ensuring no funds are at risk, but new commits stop until it resumes.
A second keeper is used to send the allotted creator tokens to the pre threshold committers. This is purely to avoid massive gas spikes on crossings, especially as the ecosystem grows.
No chain-level dependencies beyond standard modules. The contracts hold only OSMO, their own TokenFactory denoms, and the GAMM LP shares of the pool they seeded. There is no privileged mint of OSMO, no bridged-asset exposure, and no chain parameter change requested.
Risks
| Risk | Mitigation |
|---|---|
| Price keeper lapses | Commits fail closed (no mispricing). Supervised process with alerting. |
| Oracle reports a bad price | Eight independent gates; anything out of band reverts the commit. |
| Circuit breaker griefed into a paused state | No fund loss (offer refunded); admin unpause. Self-healing fix planned. |
| Admin key compromise | cw3 multisig holds both migrate and in-contract authority; all config changes are 48h-timelocked and publicly observable. |
| Bug in a deployed pool | Pool code upgrades are 48h-timelocked; two-phase emergency withdrawals as a last resort. |
What happens if this passes
- The three code IDs are created. Nothing is instantiated by the proposal itself.
- We deploy the cw3 multisig, then instantiate the factory and router with the multisig as both migrate and in-contract admin from block one.
- The price keeper starts before instantiate (instantiate live-probes the feed and refuses a stale one).
- We validate a first crossing against the live mainnet Pyth feed and publish the transactions.
- Creators can begin launching pools.
Links
- Repository: GitHub - Bluechip23/bluechip-osmosis-contract · GitHub (commit
91cc5633bbc1d0120cd15fe0de2b5db6fca9d0a0) - Proposal JSON:
gov/storecode_proposal.jsonin the repository - Architecture & security notes:
README.md - Operational runbook:
RUNBOOK.md - Forum discussion: (this thread)
Happy to answer questions here and to make changes before submitting on-chain. We would specifically welcome scrutiny of the oracle gating and the threshold-crossing atomicity, which are the two places where a bug would matter most.
