Rubik Capital
Blockchain intelligence, dual execution, and defense-in-depth risk control — built as a system of constraints rather than a single algorithm firing orders at the exchange.
Every position below was opened and closed on Hyperliquid by the account linked here. Open the address and check the numbers yourself — that is the point of publishing them.
net of deposits
flat-to-flat, since 23 Jul
of closed positions
no missed days
first real order
| Stage | Capital | Return | Per month |
|---|---|---|---|
| Test budget · under $2k · 13 Jul – 21 Aug | $495 → $1,106 | +13.1% | +10.2% · 38d |
| Since $2k · 21 Aug – to date | $1,106 → $6,556 | +10.7% | +13.3% · 24d |
Split by account size rather than by calendar month, because size is what changes the way the system can work: below $2,000 it cannot spread across instruments and both execution accounts. The stages are of different length, so the last column normalises each one to 30 days — without it the shorter stage looks worse than it is. Capital reached its current size on 11 Sep 2026; that window is still too short to judge on its own.
A closed position is one flat-to-flat cycle, not a single fill — a cycle usually closes in several partial reductions. Return is time-weighted, so capital added along the way does not inflate it. Drawdown, holding time and every individual fill are not restated here: the account is public, so they can be read from the chain itself.
Last updated 15 Sep 2026
A signal in Rubik is a proposal to act, not an order to execute.
Rubik reads on-chain and market-state data through several independent analytical layers. A trading initiative never reaches the exchange directly: it passes through capital allocation, portfolio-level limits, a separate microstructure control layer, and protective execution machinery.
A new position is evaluated against the existing portfolio, available capital and current exposure — never on its own merits alone.
Portfolio-level constraints take precedence. The system will decline new exposure even when an analytical layer finds the entry attractive.
Microstructure control can shrink or block an entry outright, and the main trading logic may not override it.
Hyperliquid settles perpetual futures on-chain. Every fill, every position and every transfer is written to a public ledger the moment it happens — by the exchange, not by us.
Our results are not a PDF we compiled. They are the account history above, readable by anyone, including the parts we would rather not show.
There is no broker holding client money in the middle. Funds sit in the account their owner controls, and trading permission is a separate thing from the power to move them.
HIP-3 builder markets extend the instrument set beyond crypto pairs, which widens where the strategy can look for an edge without leaving one venue.
The same transparency cuts both ways, and we accept that: a bad month is as public as a good one.
On-chain state and live market conditions enter the system.
Several independent contours form a trading initiative.
Can this exposure fit inside current capital and risk?
A final independent review of the initial entry.
System limits and execution-layer health are verified.
Only a permitted action reaches Hyperliquid.
Rubik runs as two independent execution instances on separate trading accounts, held together by a single portfolio-level control. The split distributes trading load, exposure and strategy capacity across two planes.
Under certain conditions the instances can hold opposite directions on the same instrument — long on one, short on the other — used as a controlled element of portfolio hedging.
Correctly read: controlled opposing exposure, not a mandatory symmetric hedge. Positions need not open together, match in size, or hold a fixed ratio. The conditions that trigger this configuration are part of internal logic and are not disclosed.
Independent risk budget · own trading account
Independent risk budget · own trading account
Both wings run the same rules and the same code; they differ only in which account they execute on. The right wing started later, so its history is shorter.
Above the core decision logic sits a separate layer reading market microstructure. It does not look for opportunity — it judges whether an initial entry is admissible in current conditions, and it holds an independent right of veto.
Permit the original size of the initial order.
Cut the size of the initial position.
Decline to open the position at all.
This layer governs the creation of a new position. Once open, add / hold / reduce / exit decisions belong to the main analytics and position management. The features, combinations and thresholds behind the verdict are closed.
Rubik is not built around a single stop mechanism. Between a trading idea and real risk stand several independent layers, each able to limit, shrink or halt the action.
A gross exposure ceiling per execution instance. Increase requests are cut or refused when they exceed the available risk budget.
Per-instrument limits that cap how much of the book any single market may occupy.
A preflight check before adding risk: the intended protective structure must remain valid against the venue's real liquidation boundary.
Open positions carry protective orders, and their presence is verified against actual exchange state — not against an internal note saying they should exist.
Stale upstream state, lost connectivity or unconfirmed venue state can close the path to new entries.
A critical-drawdown kill mechanism can stop trading and close positions. Its threshold is internal and not disclosed.
Reducing existing risk always outranks creating new risk. When state cannot be trusted, the system shuts the door on new entries while leaving the existing book free to exit safely.
Trading authority ≠ withdrawal authority.
Rubik separates the power to trade from the power to move money. The system manages positions within its permitted execution access and holds no ability to withdraw funds. Control of capital stays outside the trading agent.
Participants pool capital into a single trading book. Each holds an economic share; performance is measured against a personal high-water mark.
A dedicated instance of Rubik on managed infrastructure, trading the client's own account. The client keeps custody; Rubik keeps the canonical trading state.
A non-custodial vault contract on HyperEVM. The contract owns its own trading account; funds are never handed to us.
Fee rates, legal structure and service terms are settled individually and are not published here.
Modelled monthly rates by account size. These are planning inputs, not results.
These are modelled planning rates, not results and not a forecast.
Rubik needs enough capital to run at full capacity — spread across instruments and both execution accounts. It started on a $495 test budget, passed $2,000 on 21 Aug 2026 and reached its current size on 11 Sep, so the columns beyond the first describe accounts we have not run yet.
What we have actually done is broken out by capital stage in the track record above, normalised to a monthly rate so the stages can be compared. Read the table as a plan and the track as the evidence.
| Monthly rate | Entry | Core | Extended | Large |
|---|---|---|---|---|
| Stress edge degrades | 3.6% | 4.0% | 4.4% | 4.5% |
| Base realistic | 9.0% | 16% | 18% | 19% |
| Optimistic top of sample | 18% | 20% | 24% | 25% |
Open the account address in the Hyperliquid explorer — the link is in the track record section above. You will see every fill and every transfer, with timestamps. Nothing we publish is outside that history.
In a Private Instance, you do. Rubik receives trading permission for your account and nothing else; it cannot withdraw funds to any address. Deposits and withdrawals stay under your control at all times.
Discussed individually. The strategy behaves differently at different account sizes, so the sensible entry point depends on which participation model fits you.
Performance-based and agreed individually. We do not publish a rate card, because the terms differ between the shared book and a dedicated instance.
In a Private Instance, you withdraw yourself — it is your account. In the shared book, a redemption request is settled within available liquidity, deferred rather than forced, so that one participant leaving does not close positions at a bad moment for everyone else.
We do not onboard US persons. This is not a venue restriction — Hyperliquid does not ask who you are. It is about us: managing someone else's capital for a US person brings the arrangement under US regulation no matter where the trades settle, and we are not registered there. Your status is something you confirm when we start talking. We do not run identity checks, and we would rather say that plainly than imply a control we do not perform.
Open positions carry protective orders that are verified against exchange state rather than an internal note. A critical-drawdown mechanism can stop trading and close the book. The thresholds behind it are internal.
If you bring flow to Hyperliquid, there is a straightforward way to work together.
Integration goes through Hyperliquid builder codes — attribution is handled by the venue, not by a spreadsheet between us.
Terms are agreed per partner and depend on volume and the model your clients use.
We are open to listing conversations and to introducing the desk to allocators through partners who already have the relationship.
Two founders, no layer in between. The person who writes the trading logic and the person who handles everything around it are both named here, and the account the system trades is the one linked above.
Founder · Research and engineering
Builds the system end to end: signal research, the execution engine and the risk controls around it.
Founder · Business and operations
Everything outside the code: partners, capital relations and the company's legal setup.
No forms and no sign-up. Write to us directly and we will take it from there.