Keystone × Jupiter: Wrong the First Time, Right This Time
Type: Ecosystem alignment & technical collaboration
Submitted by: Keystone Finance
Treasury request: None
TL;DR: Keystone issues ksUSD, a carry-backed dollar. Jupiter V6 is its execution layer: every mint, redeem, rebalance, and mode flip routes its spot leg through Jupiter. No treasury ask. This is our second, deliberately narrower approach: routing review, execution-quality feedback, and ecosystem alignment.
What is ksUSD?
ksUSD is a carry-backed dollar issued by Keystone Finance.
Users deposit USDC and mint ksUSD. The protocol then coordinates market-generated carry from three sources Solana already produces:
- Funding from SOL perps
- Staking yield from jitoSOL
- Lending yield from Kamino
The goal is simple: give users dollar-denominated exposure to Solana carry without requiring them to hold SOL price risk.
The strategy runs on-chain and remains delta-neutral. In its primary mode, the vault holds jitoSOL and shorts SOL-PERP to hedge price exposure. Holders get exposure to staking yield and funding carry, while the protocol manages the position inside one coordinated system.
Those three carry legs are not separate products. They are one machine.
That machine needs execution.
Jupiter V6 is the execution layer. It is not a fourth yield source. It is the router that makes the strategy work: every spot conversion the system makes routes through Jupiter.
Keystone is not asking Jupiter DAO for treasury capital. We are asking for routing review, execution-quality feedback, and a conversation around long-term alignment.
Why this is our second approach
We first approached Jupiter with a broader DAO integrator treasury mandate.
That was the wrong ask.
It asked the treasury for capital, and it also tried to run the perp leg through Jupiter Perps. That was not the right integration for this product.
Jupiter Perps uses a borrow-fee model. For Keystone, which needs a delta-neutral short to receive funding when funding is positive, that structure does not work. The short pays a fee instead of receiving two-sided funding.
So the perp leg moved to Drift, where Keystone can access a two-sided funding market.
Jupiter’s role is now narrower and stronger:
Jupiter is the swap router.
That is the correct integration.
How ksUSD works
ksUSD runs in three modes, based on SOL-PERP funding.
Normal mode
When funding is positive, the vault swaps USDC into jitoSOL through Jupiter, then shorts SOL-PERP on Drift.
The user holds a dollar-denominated asset.
The protocol holds staked SOL.
The hedge removes SOL price exposure.
Yield comes from jitoSOL staking yield plus funding received on the short.
Reverse mode
When funding is deeply negative, the vault can borrow jitoSOL on Kamino, sell it for USDC through Jupiter, and go long SOL-PERP.
This lets the system earn from negative funding regimes instead of only earning when funding is positive.
Idle mode
When funding is near zero, the vault parks capital in Kamino lending.
When the system rotates back into Normal or Reverse mode, the spot leg routes through Jupiter again.
Why execution is yield
A basis strategy earns a real but thin spread.
If each rebalance leaks too much to slippage, that leak comes directly out of holder yield.
That makes execution quality a core part of the product, not a back-office concern.
The main spot path is USDC ↔ jitoSOL. Liquidity for that pair lives across multiple pools. Keystone needs best execution through one CPI-callable route.
That is Jupiter’s role.
Funding, staking, and lending are active in different market regimes. Jupiter is active across all of them.
Every mint, redeem, rebalance, and mode flip needs execution.
Why Jupiter matters structurally
Keystone needs four things to exist in the same environment:
- A liquid LST
- A money market for borrowing and lending
- A perp venue with real funding
- A router for efficient spot execution
Solana is the only environment where these pieces sit close enough together to be composed by one on-chain program.
Jupiter makes the on-chain version executable.
An off-chain desk can route swaps through centralized venues, but it does not settle those legs atomically against the hedge.
A cross-chain system cannot coordinate the legs cleanly.
Keystone’s edge is that the system can coordinate staking, funding, lending, and execution inside one Solana-native strategy.
Without Jupiter routing, the carry generated by the other legs leaks before holders ever see it.
On jupUSD and ksUSD
jupUSD and ksUSD are different products.
They are not competing for the same job.
jupUSD is a settlement dollar. It is designed to be a stable unit of account across the Jupiter ecosystem.
ksUSD is a carry instrument. It is designed to earn from Solana market structure.
jupUSD earns from off-chain RWA yield.
ksUSD earns from on-chain carry:
- Drift funding
- jitoSOL staking
- Kamino lending
A Solana treasury could hold both.
jupUSD is the dollar it settles in.
ksUSD is the dollar it earns in.
Keystone has no ambition to replace jupUSD as a unit of account for the Superapp. That lane belongs to jupUSD.
What Keystone needs from Jupiter is routing.
Regardless of which dollar wins shelf space, ksUSD’s spot leg routes through Jupiter.
What Jupiter gets
Recurring swap volume
Every USDC ↔ jitoSOL conversion routes through Jupiter.
That means minting, redemption, rebalancing, and mode changes create mechanical router volume tied to product usage.
This flow scales with TVL.
Legible flow
Keystone flow is delta-neutral and condition-driven.
It is not speculative directional flow trying to pick off LPs.
For a router and its liquidity network, predictable uninformed flow is the good kind.
Strategic pair depth
Keystone concentrates activity around USDC ↔ jitoSOL, a key stablecoin/LST pair.
That helps reinforce one of the most important intersections in Solana DeFi: dollars moving into productive staking assets.
A cleaner reference integration
Keystone’s first approach over-integrated Jupiter.
This version uses Jupiter for what it does best: execution.
That is the integration we want to get right.
Risks
No Keystone risk lands on Jupiter DAO.
Execution and slippage risk
Poor execution leaks directly into yield.
Keystone will size launch TVL conservatively and monitor execution quality as a first-class metric.
MEV and sandwich exposure
Predictable rebalance flow can be targeted.
Keystone will use slippage bounds, careful transaction construction, and routing parameters to reduce exposure. This is an area where Jupiter’s guidance would be valuable.
Routing dependency
Jupiter is the sole router in v1 by design.
We will size flow conservatively and coordinate as volume grows.
Smart-contract risk
Keystone composes with Jupiter, Drift, Kamino, and jitoSOL. The Keystone vault will be audited before mainnet launch.
What we are asking for
- Routing review of the Jupiter V6 integration, including swap construction, slippage bounds, routing parameters, and CPI patterns.
- MEV and execution-quality guidance for protecting predictable rebalance flow.
- Liquidity guidance around USDC ↔ jitoSOL depth and how to size flow responsibly as TVL grows.
- Feedback on whether the integration should be even narrower, given that our first approach over-integrated Jupiter.
Keystone is a user of Jupiter’s router, not a claim on Jupiter’s treasury.
We welcome the community’s scrutiny and look forward to the discussion.
We are building in public at @Keystone_Fi. A follow this early, as the community forms, means a lot.
— Keystone Finance