autonomous trading: the deploy-and-run layer for strategies on anything

Author a strategy, backtest it, deploy it, and let an agent run it across any venue. Think Vercel, but for trading strategies instead of web apps. The end goal: autonomous agents that trade and make money for you, with none of the casino.

the one-sentence thesis

Most people who could make money in markets never do, because the gap between having a strategy idea and running it live, safely, across venues is enormous: infra, custody, risk controls, execution plumbing, backtesting, monitoring. We collapse that gap to a deploy step. You bring the strategy. The platform handles backtest, execution, custody, policy, and the agent that runs it while you sleep.

why now, why us

This is two halves of one machine, and each of us already owns a half.

Half A without Half B is infrastructure nobody can use. Half B without Half A is a backtest tool with no safe way to go live. Together it's the whole thing. That's the synergy.

what's already built (Half A, concretely)

• Steward , an open-source, self-hostable identity + wallet + policy rail. Every auth account gets its own wallet. The agent never holds the key: it requests a signature, a policy engine evaluates it against hard limits (per-trade, daily, venue allowlists, rate limits), and a vault signs or refuses. Default-deny, fail-closed, full audit log, and a kill-switch that freezes all signing instantly. Think Privy, but open, self-hostable, policy-native, and built for agents instead of retrofitted for them.
• Venue execution , live adapters for Hyperliquid (perps) and Polymarket (prediction markets), with per-venue allowlists and a pre-trade order gate. Venue-scoped trade sessions so an agent self-manages a capped, revocable, reduce-only-capable session. New venues are an adapter, not a rebuild.
• A live reference agent , an autonomous agent already trades real positions on these rails under a constrained policy. It is the working proof that "agent + wallet + policy + venue" is not a slide, it's running.
• Self-custody + ownership , the whole rail is self-hostable and open-source. Users own their keys and data. No per-transaction toll skimming every move.

what we tried, and what didn't work (the honest part)

I came at this from a different angle first: a launchpad for tokenized agents. The infrastructure underneath, the wallets, policy, agent execution rails, turned out to be the genuinely valuable thing. The packaging was the mistake.

• The token was the wrong container. We wrapped the agent in a tradeable token on a memecoin-style launchpad. That bent every design decision toward speculation instead of utility. The market-making and launch mechanics added complexity that served the casino, not the user.
• The casino crowds out the product. When a token is the surface, the incentive is extraction, not building something people actually use to make money. We're sunsetting that token and that framing deliberately, and keeping the engine.
• Lesson: the valuable core was always "an autonomous agent that can safely trade and grow value for you." Strip the token, the launchpad, the speculation, and that core is what's left, and it's built. This project is that core, done honestly.

what needs to work (the gap to close together)

• Strategy authoring , a clean way for a user to express a strategy (config, code, or a DSL) that the agent can execute. The interface between "human's edge" and "agent's actions."
• Backtesting , run a strategy against historical data, get honest performance, iterate. This is the collaborator's core strength and the piece I haven't built.
• Strategy to live deploy , the "Vercel moment." One step from a backtested strategy to a live, policy-gated, agent-run deployment. The rails make this safe; the product makes it one click.
• Multi-venue abstraction , a common strategy interface that runs on crypto first (Hyperliquid, Polymarket, easy lift, already wired), then expands to CEX spot, equities, and beyond. Crypto is the beachhead, not the ceiling.
• Monitoring + trust , live P&L, risk dashboards, the kill-switch surfaced to the user, audit trail. The reasons a user trusts an autonomous thing with their money.

the roadmap shape

• Phase 1 , crypto, end to end. Strategy authoring + backtest + one-click deploy to an agent that runs it on Hyperliquid/Polymarket via the existing rails. The full loop on the easy-lift venues. A real user runs a real backtested strategy live.
• Phase 2 , widen the venues. CEX spot, more crypto venues, prediction markets, via new adapters on the same rail. Strategies become portable across venues.
• Phase 3 , beyond crypto. Equities and "all things." Same authoring + backtest + deploy loop, new execution backends. The platform becomes venue-agnostic.

the division of labor

• I bring: the rails. Steward (identity, wallets, policy, custody), the venue execution layer, the live agent runtime, the production infrastructure. The safe, ownable execution substrate.
• The collaborator brings: the user's path to success. Strategy authoring, backtesting frameworks, the deploy experience, the product that makes the rails usable by someone with an edge but not an infra team.
• Shared: the end goal, autonomous agents that trade and make money for the user, honestly, without the casino. And the operating discipline: this is a tool for users to succeed, not a vehicle to extract from them.

open questions for alignment

• Naming. We are not married to any prior name. Clean slate.
• Where the strategy/backtest layer lives relative to the rails: separate service, or integrated into the agent runtime?
• Strategy expression: config-driven, full code, a constrained DSL, or all three by tier?
• Custody model for non-crypto venues (equities/CEX), where the Steward-style policy gate maps onto venues that have their own custody.
• Go-to-market: power users first (bring-your-own-strategy), or curated strategies for people who just want returns?
• Time + ownership: I'm focusing my primary hours elsewhere, so this needs a collaborator who can own the build day to day. What's the working split and the stake?

This brief states my half and the shared goal so we can find the overlap. The collaborator is writing his own from the user-tools side. We compare, we align, we decide if the two halves are actually one machine. I'm convinced they are.