Alpha
Market move but We don't
The problem Alpha solves
The problem it solves
If you hold crypto and the price falls, every option available today costs you something permanent:
- Sell — the loss stops, but so does any chance of the rebound. You end up right about the asset and out of the position anyway.
- Hold — you absorb the entire fall, with no floor and no plan, hoping it recovers before you need the money.
- Borrow against it — and risk getting liquidated the moment the market dips, sold at the worst price of the crash, often hours before the price recovers. The bounce lands for someone else.
A financial instrument that solves exactly this — a put option — has existed for decades. It gives the holder the right to sell at a fixed price, so the downside gets a floor while the upside stays fully open, and the maximum possible loss is capped and known in advance. Options are barely used outside professional trading, not because the instrument doesn't work, but because every interface that offers one demands the user understand strike prices, expiries, implied volatility and theta decay before they can even get a quote. The instrument was never the barrier — the interface was.
What Alpha does
Alpha removes that interface barrier. The user describes what they're worried about in plain language — "protect my ETH from falling more than 20%" or "I need at least $2,000 by 1 November" — and the app buys real downside protection on their behalf on the live Thetanuts order book on Base mainnet. No strike price, no expiry, no options terminology ever appears on screen.
Three products, one underlying engine:
| Product | What it does | The mechanism |
|---|---|---|
| Protection | A real on-chain floor under crypto you already hold | Cost, floor and max loss stated in USDC before you confirm — the premium paid is the only number that can go wrong |
| Lending | Borrow USDC against that same protected holding, with no liquidation risk | Credit limit = strike × contracts, minus the loan's own interest — never a loan-to-value ratio. A conventional lender discounts collateral and reserves the right to liquidate because it has no floor; Alpha has a floor, so the credit limit is the floor |
| Vault | A principal-protected deposit | The yield a deposit would normally earn buys a call option instead of being paid out — principal back in full at maturity, plus a share of any rise, computed from the real premium paid, never promised in advance |
Who it's for:
| Audience | What they need |
|---|---|
| Holders who don't want to sell | A known worst case, stated in dollars, before a volatile event |
| Borrowers already liquidated once | Cash without selling — and without handing a lender the right to sell them out again |
| Savers who can't tolerate losing principal | Little or no upside is acceptable; losing the deposit is not |
Why it's real, not a mockup
Every purchase is a fully-collateralised position on Base mainnet, verifiable independently on BaseScan — not a database row backed by a promise. As of submission, eight real transactions are on chain, including a protection purchase, a loan disbursement derived from that exact position's strike, a loan repayment, and a call purchase funding a principal-protected deposit. The one part of the product that is not real is the user's starting balance — this is a custodial prototype with no deposit flow, so demo balances are seeded rather than funded, and the interface discloses that boundary at the point each number appears rather than in a disclaimer nobody reads.
The design rule underneath all three products
The user is always the buyer of the option, never the seller. Option buyers have losses capped at the premium and open-ended upside; sellers have capped gains and losses that scale with the size of the position. For a decade, retail users have been quietly steered onto the seller side by products advertising "stable yield" that are structurally the same as selling insurance without underwriting it properly. Alpha does not offer that trade, at any price — which is what makes it safer than the products it's replacing, not just simpler to use.
Challenges we ran into
Here's the challenges field, same treatment — table for the parallel structure (each is a bug → cause → fix), so it's scannable at a glance:
Challenges we ran into
| Challenge | What happened | How we fixed it |
|---|---|---|
| The order book that looked ideal was the one we couldn't fill | Our quote engine returned deep floors (20%+ below spot) at 27- and 62-day expiries for over a week of development — until we tried to actually fill one and got Panic(0x11), an arithmetic overflow that said nothing about why. We chased the wrong lead (a missing token approval) before finding the real cause: our order filter was inverted, and those "ideal" floors were orders where we'd be the seller, not the buyer. | We started simulating every order against the chain instead of trusting the raw book. The real, fillable market turned out to be ~2–3 day floors around 6% below spot, not 30-day floors at 20% — so we reframed the product around event protection instead of quietly shipping a demo that would fail the moment anyone tried to buy from it. |
| A loan that was under-collateralised the moment it was written | Our lending product's whole claim is that the credit limit comes straight from the option's strike, no haircut. Our first real loan — 4.5977 USDC lent against a 4.5977 floor — came due owing 4.599410, more than its own floor. We were lending 100% of the guarantee and then charging interest on top of it. | We stopped subtracting interest from the floor and instead solved backwards for the principal that, plus its own interest over the loan's term, lands exactly on the floor (principal × (1 + rate × days/365) = floor) — the same technique we already used for the vault's principal-protection split. |
| A payout silently 10¹² too small | The SDK uses 6 decimals for an order's own contract count, but 18 decimals for the same-named argument to the payout-calculation helper. Passing one straight into the other doesn't throw an error — it just returns a number a trillion times too small. We only caught it by computing a payout by hand and comparing against the code's answer. | We wrote one dedicated conversion helper (toPayoutContracts()) so that decimal boundary gets crossed exactly once, in one place, instead of being a trap every future caller could fall into individually. |
Each of these mattered because it changed what we could honestly claim about the product, not just what the code did underneath it.
Tracks Applied (1)
BEST PRODUCT BUILT ON THE THETANUTS SDK
Thetanuts Finance
Technologies used