750SC, the price of every single chip in the shop
Shop and Slate Credits
Every chip in the catalogue costs the same: 750 SC, paid once, owned forever. There is no subscription, no per-slate fee and no tier above the one you bought. SC is the unit that makes that work, and this page is about where it comes from and where it goes.
The Peg
One thousand SC is one dollar. That ratio is not a marketing rounding, it is a configuration property read by the commission code, and it is identical in the development, CI and production property files. Everything priced in SC can be divided by a thousand to get the honest number.
Three Names for One Thing
The currency is called SC in the code and on the balance line, SlateCoins in the purchase popup, and Slate Credits on the home page. Three names for one number, none of them wrong, none of them agreed on. It is the kind of drift that happens when a currency gets named three times by the same person in three different months.
5 dollars
5,000 SC
10 dollars
12,000 SC
30 dollars
60,000 SC
60 dollars
150,000 SC
The four packages are a hardcoded list in the Stripe service, not a database table. The rate improves with size: a dollar buys 1,000 SC at the bottom and 2,500 SC at the top.
Seven Item Types, Five of Them Real
CHIP_TYPE, 20 seeded rows, gates which chips your account may use
PACK, 7 rows, expands into its contents on purchase
STORAGE_BOOST, 2 rows, the only stackable items in the catalogue
WIZARD, upserted from code on every boot, priced by the wizard itself
FEATURE_UNLOCK, 2 rows, exactly one of which has a side effect implemented
THEME, declared in the enum, zero rows, zero references anywhere
BADGE, declared in the enum, zero rows, zero references anywhere
Two Constants Nobody Kept
The shop screen has a label ready for Themes and a label ready for Badges. Neither tab ever appears, because the grid filters out groups with no items and there have never been any items. They are two lines in an enum and nothing else. Naming a thing is not building it, and leaving the name in place for a year is how you end up documenting the difference.
How the Wallet Is Built
A balance is a single mutable row per user, locked pessimistically on write and created lazily at zero if it does not exist. Alongside it, every credit and debit appends a transaction row carrying the signed amount, the resulting balance and a free-form metadata blob. The ledger is append-only and complete. It is also never read back by anything: no endpoint exposes it, no screen renders it. It exists so that when a number is wrong there is a record of how it got that way.
Four Transaction Types Out of Seven
PURCHASE fires on the Stripe webhook. SPEND fires on a shop purchase. EARN fires exactly once per account, for the 100 SC signup bonus. ADMIN_ADJUSTMENT fires when a human decides so. REDEMPTION, REFUND and COMMISSION have never been written by any code path. There is no refund flow, and commissions do not touch the wallet at all.
The Signup Bonus Is Not Enough for Anything
A new account is credited 100 SC, which is ten cents, against a catalogue whose cheapest paid item is 500 SC. That is deliberate to the extent that nothing about it is accidental, and honest to the extent that it buys a number on the balance line rather than an item. The free tier is the Playground, not the bonus.
How Credits Actually Enter an Account
Three ways, exhaustively: a Stripe purchase, the 100 SC signup bonus, and a manual admin adjustment. That is the whole list. The Earn SC page describes a fourth, paying between 500 and 5,000 SC for a reel that clears a view threshold, and it is entirely real. It is also entirely manual: you email a link, view counts are checked after thirty days, and an admin credits the balance by hand. Static page, no API calls, no automation.
commission.rate.default=50
commission.minimum.cashout.usd.cents=10000
commission.sc.to.usd.rate=1000
Where Commissions Come From
A creator issues a discount code. Someone redeems it, which writes a discount row stamped with the creator's identifier. When that person later buys that specific item, half of what they actually paid becomes a commission for the creator. Note the order: the split is taken from the discounted price, not the list price, so a generous code earns its creator less. That trade-off is real and it is not signposted anywhere in the product.
A discount row is never consumed. For the two stackable storage items a buyer can repurchase at the same discount indefinitely, minting a fresh commission every time.
The Part That Does Not Pay Out
The payout API is complete on paper: request, approve, reject, mark paid, with a hundred dollar minimum and one pending request at a time. It has no frontend. Not a thin one, none: no hook, no type, no screen. Worse, marking a request paid does not settle anything. The balance is recomputed as the sum of every commission row ever written, so after a payout it reads exactly the same and the creator can request it again. The accounting is correct and the settlement was never built.
"Buy once, own forever. The hard part was never the buying.
"
