Rosetta is what you build after you’ve had the same realization a few too many times: moving meaningful capital onchain is easy to start and hard to run. While working on @parabolfi, we learned that a single yield source is never enough. Treating yield as a one-time choice leads to drift. Treating it as a surface you continuously navigate is the only way it works at scale. The hardest part isn’t pressing "deposit" but everything that comes after. Where should the money sit right now? Under what rules? For how long? What risk is acceptable? What happens when the best opportunity changes two hours later, or two blocks later, or when a protocol parameter shifts and an apparently safe position becomes a bad one? Onchain finance is incredibly good at creating markets. It’s still strangely primitive at operating capital across those markets. Most people experience this as tab fatigue and anxiety. A dozen vaults and money markets, a blur of APRs, incentives, point programs, and risk disclaimers. You set something up, you feel good for an afternoon, and then reality catches up: yields move, conditions change, and your "strategy" quietly decays into a static position you no longer believe in. Teams experience it differently, but the underlying problem is the same. If you run a treasury, a stablecoin balance sheet, a fintech wallet program, an exchange, or a DeFi allocator, you're really searching for a policy-compliant, risk-bounded way to deploy capital that can keep up with a market that never sleeps. Rosetta exists because we think the right mental model for onchain capital is not "pick a vault" but "program the rules." And once you do that, allocation stops being a manual workflow and starts becoming an execution layer.
A simple idea: if capital is going to be onchain, it should be programmable
This can sound grand until you strip it down to the thing we’re actually building: a system that lets you define how capital is allowed to behave, and then continuously routes and re-routes that capital across onchain opportunities within those constraints. Not a spreadsheet. Not a dashboard you stare at. Not a set of reminders to "rebalance on Fridays." Rosetta is closer to an autopilot, but one you can audit and constrain. You set policy. Rosetta executes. This matters because yield isn’t one thing. It’s not even a stable concept. Yield today is a surface made up of many moving variables: rate curves, utilization, incentives, liquidity depth, borrow demand, protocol upgrades, pool composition, bridge friction, gas costs, and sometimes the weird social physics of attention and points. If you treat yield as a single number, you get whiplash. If you treat it as a search problem, you can build something robust. Rosetta treats it as a search problem.
The gap Rosetta is trying to close
In traditional finance, allocation is a combination of policy and plumbing. There are investment mandates, risk limits, counterparty lists, and there are systems that enforce them. The enforcement is not a human clicking around in a browser. It’s software. Onchain, we have astonishing plumbing: Permissionless markets, composable contracts, real-time settlement. But we don’t have widely adopted, policy-first operating systems that sit between capital and protocols and enforce a mandate automatically. So the world improvises. People run playbooks using spreadsheets. They build internal scripts that break the moment an API changes. They rely on a single operator who just knows what to do. Or they accept the worst outcome, which is drift: capital stays where it was last placed, not where it should be. Rosetta is built for the teams who don’t want drift.
What Rosetta feels like
The experience we’re aiming for is simple to describe. You define a yield profile. That profile contains constraints and preferences. It might include things like which assets you’re willing to hold, the protocols you’re comfortable with, the maximum exposure you want to any single market, the minimum liquidity you require, or how you want to trade off return versus conservatism.
Then Rosetta does the busy work. It monitors the opportunity set, computes allocation candidates, and executes reallocations when the expected improvement is worth it, all while staying inside your rules. If this sounds like something that should already exist, we agree. The reason it doesn’t is that doing it properly requires respecting two realities at the same time. The first reality is that onchain markets move quickly and can’t be summarized into a weekly report. The second reality is that capital at scale needs guardrails, auditability, and a system that doesn’t turn optimization into a euphemism for taking hidden risk. Rosetta tries to hold those two truths together.
Non-custodial by default, because trust should be optional
We’re building Rosetta as non-custodial infrastructure using @privy_io. It’s a design constraint that shapes everything. If Rosetta is going to sit close to the money, it can’t require you to hand the money over. The system needs to work with your existing custody setup, your existing control, and your existing security posture. Non-custodial also forces clarity. It means the rules have to be explicit, the executor has to be transparent, and the outcomes have to be verifiable. The point is not to create a black box alpha engine. The point is to create a reliable operating layer that allocators can actually use in production.
Hyperliquid
Every ambitious system needs a place to start where the feedback loop is fast and the environment is demanding.
We’re starting with Hyperliquid because it’s the most interesting place to deploy onchain capital right now: high velocity, deep liquidity, a rapidly evolving ecosystem, and a culture that rewards execution. It’s also a place where the difference between static and responsive allocation shows up immediately. Rosetta is being built to be Hyperliquid-native from day one, with the goal of making it effortless for allocators to participate in the ecosystem’s yield opportunities without becoming full-time operators. Starting focused doesn’t mean staying narrow. The architecture is meant to generalize. But the product has to earn its right to expand by working exceptionally well in one demanding environment first.
How Rosetta works, without the hand-waving
At a high level, Rosetta has three jobs: First, it needs to understand the yield landscape. Not just headline rates, but the mechanics underneath them. Incentives, utilization, liquidity conditions, and the practical costs of moving. A yield that looks great but can’t absorb size without slippage is not a yield; it’s a mirage. A yield that depends on a transient incentive that ends next week is a different product than a sustainable rate.
Second, it needs to translate policy into executable decisions. This is the part most tools avoid. It’s easy to show a chart. It’s harder to encode "we want this return profile, but never at the cost of breaking these constraints" in a way that a machine can enforce consistently.
Third, it needs to execute. Execution is not only sending transactions. It’s doing so safely, deterministically, and in a way that can be audited after the fact. It’s also knowing when not to move. Constant rebalancing can be as harmful as never rebalancing. The system has to be opinionated about thresholds and about the difference between noise and signal.
We think of Rosetta as an offchain solver paired with an onchain executor. The solver explores the space of feasible allocations under your rules. The executor carries out the chosen moves onchain. Keeping the "search" and the "settlement" distinct is part of how we balance flexibility with verifiability.
Yield profiles, not one-size-fits-all vaults
A useful way to think about Rosetta is that it lets you create yield profiles the way you might create payment profiles or routing rules in a payments stack. Different pools of capital want different behavior. A stablecoin treasury might prioritize capital preservation and liquidity. A DeFi allocator might tolerate more variance for a higher expected return. A wallet program might need daily liquidity with strict asset constraints. A protocol might have governance-imposed mandates about where it can deploy. Rosetta doesn’t force these into a single "best vault." It gives you a way to define them and then runs them as living policies. That’s the core shift. Instead of treating allocation as a series of one-off decisions, you treat it as a system.
Why now
Onchain markets have crossed a threshold. There’s enough liquidity, enough variety of yield sources, and enough real balance sheet activity that manual allocation is no longer merely inconvenient. It becomes a structural disadvantage. At the same time, the industry has learned some painful lessons about risk. "Chase the highest APR" is not a strategy. It’s a way to eventually discover a flaw, usually the hard way. Mature allocators want tools that encode discipline. The moment those two conditions become true at the same time, the need for a policy-first operating system becomes obvious. We’re building Rosetta because we think the next decade of onchain finance will not be won by whoever can invent the most exotic new yield source. It will be won by whoever can operate capital safely, continuously, and at scale across an increasingly complex landscape.
What we believe
We believe allocation should be software. We believe policy should be first-class We believe the best yield is the yield you can actually hold, at size, within a mandate, through time. And we believe non-custodial systems are not a niche preference. They’re the only sustainable foundation for an operating layer that sits between users and markets.
Where we’re headed
This post is an introduction, not a launch announcement carved in stone. Rosetta is being built iteratively, with real users, real capital constraints, and real market conditions. We have generated significant volume in the few days after our closed beta launch last week
If you want early access codes, or you want to talk through a specific use case, reach out. We’re happiest when Rosetta is being stress-tested by people with real constraints and real standards.
