# SOON — a short-video feed where every video is a coin, with the video stored on-chain
Been building this for a while and it’s live on mainnet: https://soonlaunchpad.fun
A TikTok-style feed where each clip *is* a market. Free to post, free to watch, and the MP4 lives in a canister — not IPFS, not S3.
Yes, ICP has seen a short-video app before. Hot or Not raised past a 1M ICP soft cap in its SNS and later came back to the DAO for another 75K. This one had no sale, no SNS, no treasury and no token — it was built and shipped, and it pays its own hosting out of trading fees. Judge it on that.
## The idea
A full ICRC-1 ledger costs ~5.3T cycles to deploy. At a million videos that’s millions of dollars, so a token-per-video is dead on arrival.
Instead every reel is a row in one shared canister with a bonding curve already running — posting costs nothing and the curve is live within seconds of upload. Holdings are a single map keyed "reelId|principal", so an untraded reel costs the bytes it occupies and nothing more.
That’s the whole reason posting can be free.
## Two different cycle burns
This is the part I’d most like scrutiny on, because the two get conflated everywhere:
- Every trade sets aside 20 of the 100 bps fee, converts it through the CMC, and destroys the cycles with
ic0.cycles_burn128. Not spent on compute — destroyed. - Every watch consumes cycles directly. There’s no server: the canister serves the bytes, records the play, reads the price, and the network consumes cycles it never gives back. That one is measured by sampling the canister’s own balance and counting each decrease — a *rise* is a top-up, not negative consumption. Currently 323.8B cycles consumed serving the feed.
Both are on a public analytics page. The fee-funded burn currently reads zero and I’ve left it reading zero: sub-1-ICP sweeps cost more in CMC and ledger fees than they destroy, so it moves in steps rather than continuously.
## Graduation
At 36.63 ICP of backing, a reel stops being a row and becomes a real token. It deploys its own ICRC-1 ledger, buys tokens for existing holders out of the reel’s own reserve, and seeds an ICPSwap pool. Holders claim their exact share — nobody is diluted relative to anybody else.
The LP position is minted to aaaaa-aa. Not “locked”, not “we promise” — there is no key.
And nobody triggers it. The buy that crosses the threshold schedules the graduation itself, with a sweep every ten minutes catching anything a transient failure missed.
## Self-funding canisters
The cycles leg fuels the fleet *before* it burns. Every hour the burner reads each canister’s balance and tops up anything below 6T.
Balances are self-reported through a cyclesBalance query rather than canister_status — making the burner a controller of every canister it funds would grant it standing power to stop and overwrite them, in exchange for reading one number.
Burning cycles while the canister holding the videos starves would be destroying the platform to make a counter go up.
That’s the whole model: no raise to burn through, no treasury to come back to. If the fees don’t cover the cycles, the thing shrinks. That constraint is the design, not a limitation of it.
## In-browser editing
Trim, captions with drag positioning and per-caption in/out points, seven looks, speed 0.5–2×. The preview canvas and the exporter call the same draw function, so what you place is what ships — no class of bug where the export differs from the preview.
Encoding is real-time via canvas + MediaRecorder. WebCodecs would be faster but needs a muxer and a demuxer on top, which is two dependencies to save seconds on a clip capped at thirty.
## Verify it yourself
reels us2jo-dqaaa-aaaah-av4oq-cai
factory jk7sm-yqaaa-aaaah-avzxa-cai
burner jw3i5-pqaaa-aaaah-avzva-cai
Live right now: 9 reels, 44.5 MB of video on-chain, 0.67 ICP volume. Small numbers — it’s new.
