Verifiable on-chain, not on our word.
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.
- Return since start
- +24.8%
- Closed positions
- 260
- Profitable positions
- 69.2%
- Trading days
- 64 / 64
- Live since
- 13 Jul 2026
time-weighted · deposits excluded · after fees and funding
flat-to-flat, counted from 23 Jul
share of closed positions above zero
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 changes how the system can work: below $2,000 it cannot spread across instruments and both execution accounts. The stages differ in length, so the last column normalises each one to 30 days — without it the shorter stage looks worse than it is.
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.
This is the record of the trading account linked above, not of the pool. The pool has no history of its own yet, and what a participant receives differs from it: fees and the sharing of losses between participants change the result.
Last updated 15 Sep 2026
One trading book, on a contract you can check.
Participants deposit USDC on Hyperliquid into a smart contract. The bot trades the combined capital. Each trade's result is split among the participants whose money was in the pool when it opened, and a performance fee is taken only on profit.
Deposits are open up to a size limit set in the contract. The contract has not been audited; read the risks before you send anything.
-
1 · Deposit
Send USDC from your Hyperliquid spot balance to the pool's address (the pool page signs the transfer), from the address that should receive your payouts. It needs no gas, and the minimum is 10 USDC. Other kinds of transfer are not credited and can get stuck.
-
2 · The bot trades
Your money trades as part of one book, on two separate trading accounts that start once participants' capital reaches 1,000 USDC; until then deposits wait in the vault. A new deposit joins new trades only; it has no claim on trades already open.
-
3 · Weekly settlement
Results are settled once a week. The fee is charged only on net profit above your own high-water mark, and is zero in a week that ends below it. The rate is fixed in the contract, the same for everyone, and will be published with the terms.
-
4 · Automatic payout
Request a withdrawal at any time; the request is a HyperEVM transaction and needs a little HYPE for gas. Requests are paid in order: first the part not tied up in open trades, then the rest as those trades close, up to 24 days in the worst case for a complete exit. Payouts are sent automatically, only to the address your deposit came from, and cost you nothing. The minimum payout is 10 USDC; smaller amounts accumulate.
What to know first.
-
You can lose everything you put in
The pool trades leveraged perpetual futures. Prices can move through a protective stop, and in the worst case a deposit is lost entirely.
-
A loss can be shared
If a trade loses more than one participant's money, the other participants of that same trade pay the excess. That participant repays them only from later profit in the pool. The operator does not cover losses.
-
The keys are the operator's
The operator runs the keeper that credits deposits and reports prices and results, and holds the admin key. A faulty or dishonest keeper could credit a deposit to the wrong address, report wrong prices, or report results that are not real and so move pool money, up to the whole pool; technically, the operator can take the pool's money. The contract pays out only to a participant's own address. It has not been audited.
A system of constraints, not a single algorithm.
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.
-
Judged in context
A new position is evaluated against the existing portfolio, available capital and current exposure — never on its own merits alone.
-
Portfolio outranks signal
Portfolio-level constraints take precedence. The system will decline new exposure even when an analytical layer finds the entry attractive.
-
Independent veto
Microstructure control can shrink or block an entry outright, and the main trading logic may not override it.
A venue where the track record cannot be edited.
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.
-
Nothing to take on trust
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.
-
Custody stays where it belongs
There is no broker holding client money in the middle. In a Private Instance, funds sit in an account their owner controls. In the pool, they sit in the contract's own Hyperliquid account, and its code pays out only to a participant's own address. Either way, trading permission is separate from the power to move money.
-
More than crypto
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.
Six gates between an idea and a fill.
- 1
Blockchain & market data
On-chain state and live market conditions enter the system.
- 2
Analytical layers
Several independent contours form a trading initiative.
- 3
Portfolio control
Can this exposure fit inside current capital and risk?
- 4
Microstructure check
A final independent review of the initial entry.
- 5
Risk & protection
System limits and execution-layer health are verified.
- 6
Execution
Only a permitted action reaches Hyperliquid.
Two execution planes, one portfolio.
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.
Left
Independent risk budget · own trading account
- Closed positions
- 260
- Win rate
- 69.2%
- Trading days
- 64 / 64
Right
Independent risk budget · own trading account
- Closed positions
- 50
- Win rate
- 66.0%
- Trading days
- 9 / 9
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.
The layer that can say no.
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.
- ALLOW
Permit the original size of the initial order.
- REDUCE
Cut the size of the initial position.
- BLOCK
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.
Defense in depth.
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.
-
Capacity & exposure
A gross exposure ceiling per execution instance. Increase requests are cut or refused when they exceed the available risk budget.
-
Concentration
Per-instrument limits that cap how much of the book any single market may occupy.
-
Liquidation safety
A preflight check before adding risk: the intended protective structure must remain valid against the venue's real liquidation boundary.
-
Protection & reconciliation
Open positions carry protective orders, and their presence is verified against actual exchange state — not against an internal note saying they should exist.
-
Data integrity
Stale upstream state, lost connectivity or unconfirmed venue state can close the path to new entries.
-
Emergency control
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. In the pool, the contract holds the funds; the bot's trading keys cannot withdraw them.
Planning rates, not promises.
Modelled monthly rates by account size. These are planning inputs, not results.
How to read this table
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.
The table describes the strategy at different account sizes. It is not a promise about what a pool participant receives: fees, the sharing of losses between participants and the size of the pool all change the result.
| 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% |
- Stress and Base are the rows to plan against.
The questions that come up first.
Is the pool open?
Yes, in beta and under a size limit that is set in the contract. The pool page shows live whether it is accepting deposits and how much room is left. The contract has not been audited.
How do I verify the track record myself?
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.
Who holds the keys?
In the pool, funds sit in the contract's own Hyperliquid account. The operator runs the keeper that credits deposits and reports prices and results, and holds the admin key; trading keys cannot withdraw, and the contract pays out only to a participant's own address. The contract does not cross-check the results the keeper reports, so the pool rests on trust in the operator: the size limit caps only new deposits, and the risks are listed on the pool page. In a Private Instance, you hold the keys: Rubik receives trading permission for your account and nothing else; it cannot withdraw funds to any address.
What is the minimum?
In the pool, the minimum deposit is 10 USDC and the minimum payout is 10 USDC; smaller payouts accumulate until they reach it. For a Private Instance it is discussed individually: the strategy behaves differently at different account sizes.
What are the fees?
Performance-based: a share of net profit above your own high-water mark, and nothing in a week that ends below it. In the pool the rate is fixed in the contract and the same for every participant; it will be published with the participant terms, which are pending legal review. For a Private Instance the payment model is agreed individually.
How do I exit?
In a Private Instance, you withdraw yourself — it is your account. In the pool, you can request a withdrawal at any time: the part of your capital not tied up in open trades is paid first and the rest as those trades close, strictly in order of request, so that one participant leaving does not close positions at a bad moment for everyone else. A complete exit can take up to 24 days in the worst case. Payouts are sent automatically, only to the address your deposit came from.
What if a trade loses more than my money?
Trades carry protective stops, but a price can gap through one. If the loss exceeds one participant's money, the other participants of that same trade pay the excess — each no more than their own share and their own money. Whatever does not fit there is shared across the pool. The participant who caused it repays them from future profit in the pool. The operator does not cover losses.
Who cannot participate?
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.
What happens if something breaks?
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.
Brokers, IBs and introducers.
If you bring flow to Hyperliquid, there is a straightforward way to work together.
-
Builder codes
Integration goes through Hyperliquid builder codes — attribution is handled by the venue, not by a spreadsheet between us.
-
Revenue share
Terms are agreed per partner and depend on volume and the model your clients use.
-
Listing and introductions
We are open to listing conversations and to introducing the desk to allocators through partners who already have the relationship.
Who runs this.
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.
-
Iulii Maksenkov
Founder · Research and engineering
Builds the system end to end: signal research, the execution engine and the risk controls around it.
-
Andrius Grizitskas
Founder · Business and operations
Everything outside the code: partners, capital relations and the company's legal setup.
Start a conversation.
No forms and no sign-up. Write to us directly and we will take it from there.