Draft · not in force

How the pool works, and what can go wrong.

This page explains the rules of the Rubik pool in plain words and lists the risks you would take. It is a draft: it is not an agreement or an offer, the legal parts are not written, and the pool is in a beta under a size limit. Some rules below are decided but not yet built into the contract; each of those is marked.

Not yet in the contract — the rule is decided, but the contract code does not enforce it yet. Until it does, read it as a plan, not as a feature.

01 In short

Six lines to read if you read nothing else.

What the pool is: A shared trading book. You send USDC from your own Hyperliquid account to the pool's address. A contract on HyperEVM keeps the books, and a bot trades leveraged perpetual futures with the pooled money on Hyperliquid, through two trading accounts.
What you can lose: All of it. A loss can even be larger than your money in the pool; the difference is then paid by other participants of the same trades, and your money can be used the same way for theirs. See Risks.
What it costs: A fee on profit above your own high-water mark, settled weekly, and nothing in a week that ends below it. The rate is 50 %.
How you get out: Request a withdrawal at any time. The part not needed as collateral for open trades is paid first, the rest as those trades close. Worst case for a complete exit: up to 17 days for the bot to close every position, plus up to 7 days until the next settlement.
Who holds the keys: The operator, alone. The admin, keeper and guardian keys all belong to the operator, and the contract does not check the results the keeper reports: technically, the operator can take the pool's money. See Keys, the keeper and what you trust.
What is not final: Legal entity and jurisdiction, fee and referral rates, and several safety mechanisms, which are marked where they appear.

02 Risks

Read this before anything else.

These are the risks we can name today. The list is not complete: no list of risks can be.

You can lose everything: The pool trades leveraged perpetual futures, a high-risk product. Prices can move fast and far, and you can lose your entire deposit. Nothing on this site, including the track record and the modelled scenarios, is a forecast or a promise of any result.
A loss can exceed your money, and reach other people's: Every position has a protective stop, but on cross margin the price can jump through it (a flash crash, a gap, a delisting), or several stops can hit at once. Then one participant's share of the loss can be larger than the money they have in the pool. That excess is paid first by the other participants of the same trades, each at most their own share and their own money, then by the whole pool. So your money can cover a loss you did not cause. You are repaid only if the participant who caused it later earns it back in the pool. The operator does not pay losses. See section 09.
No independent audit: The contract has not been audited by an independent firm. It has been tested and reviewed by the operator's own team and tools, which can miss things. A bug could freeze funds, split them wrongly or lose them. The source is published and verified on explorers so anyone can read it, but reading is not an audit.
You trust the keeper: The contract cannot see the market, and it cannot see who sent a transfer on HyperCore. A keeper service run by the operator credits deposits, reports the prices of open positions, files each trade's result and runs the weekly settlement. The contract does not cross-check the results the keeper files against the trading accounts. A faulty or dishonest keeper could credit a deposit to the wrong address, report wrong prices, or file results that are not real and so move pool money to itself or to others, up to the whole pool. In effect the operator can technically take the pool's money. The size limit only caps how much can be deposited: it does not limit what a keeper could take from what is already in the pool. The only brake is the guardian's power to revoke the keeper, and the guardian is the operator's key too.
Control sits with one party: The admin key is a single-signature wallet held by the operator, and the guardian key and the keeper key are the operator's too. There is no second signer and no outside party who can stop a misuse of them. Role changes wait for a public delay so you could see one coming and leave, but that only helps if the exit works (section 11). The admin can change the pool's size limit at once, without any delay.
Hyperliquid risk: Everything happens on Hyperliquid. Outages, order-book or oracle problems, automatic deleveraging, delistings, changes to its rules, fees or limits, bugs, or a failure of its bridge or validators can lock or destroy value, or stop a position from being closed. We do not control Hyperliquid and cannot make you whole for what it does.
A trading account's mode can change for good: Hyperliquid lets a trading key switch a trading account into its unified account mode, and that cannot be undone: the trading key cannot switch it back, and the contract has no way to. In that mode the contract's checks of that account's balance read differently. The keeper checks the mode of both trading accounts at every step and, if it changes, stops its money operations until the operator resolves it, so crediting, payouts and settlements can be delayed. The trading keys are fresh keys held only by the operator's bot, and the guardian can revoke them.
Payouts can be late: A withdrawal is not instant. Part of your money stays as collateral while your trades are open, and in a heavily loaded pool that part can be most of it. The rest is paid as those trades close. Worst case for a complete exit: up to 17 days (the operator's bot is required to close every position within that time; this is a rule for the bot, not for the contract) plus up to 7 days until the next settlement. Requests are paid in strict order, so a large earlier request can hold up those behind it. Payouts also wait while a weekly settlement runs, and while prices are stale. If the bot does not keep to its rule, a request unserved for 28 days lets anyone freeze the pool (section 11).
A refused deposit: the return has not yet been used on mainnet: The contract refuses deposits in some situations (section 05). The contract has a return function: the keeper sends a refused transfer back to the address it came from, and the contract makes sure the same transfer is never both credited and returned, or returned twice. The keeper runs this return automatically, but it has not yet been used with a real refusal on mainnet, and some cases (another token, a perp-side transfer) are returned by hand. Until it has been used, a transfer the pool refuses may stay on the contract's account for a while. The website checks the pool's state before you sign, but that is a snapshot and can change before your deposit is credited.
Early stage: The pool is new, and mainnet has little history so far. The beta started on the operator's own funds, and outside deposits are now open under a size limit and a limited number of participant addresses; an address that has left still counts toward that number. The first phase trades through two trading accounts once participants' capital reaches 1,000 USDC. Parts of the design are not built yet, as marked on this page.
Your results will differ from the track record: The track record is the operator's own account. The pool runs the same trading system, but on its own account, with a narrower choice of instruments (the pool does not trade instruments that allow only isolated margin), with weekly fee settlement, deposit and withdrawal timing and a size limit. Your results can differ, possibly by a lot.
Conflicts of interest: The operator earns the fee, runs the bot and the keeper, and may hold its own money in the pool as an ordinary participant. Other accounts run by the operator may hold the same positions at the same time.
No legal structure yet; taxes are yours: There is no legal wrapper yet: company registration is in preparation, and the legal terms are not written. Rules or authorities may restrict the pool, or you, in ways we cannot predict. You are responsible for your own taxes.

03 Operator

Who runs the pool.

Who: Rubik Capital, operated by Andrius Grizitskas. Company registration is in preparation.
What the operator does: Runs the trading bot, the keeper and the watchdog; holds the admin, guardian and keeper keys; receives the performance fee.
Where your money is: Deposits go to the pool's own Hyperliquid account, controlled by the contract, not to a personal wallet of the operator. Payouts go only to your own address (section 08).
What the operator does not do: Pay losses. A loss beyond a participant's money is paid by other participants (section 09); if even that is not enough, the pool records a shortfall. The operator's fee and the operator's own pocket are not a safety net.

Legal entity: TBD — pending legal review
Registered address: TBD — pending legal review
Jurisdiction and governing law: TBD — pending legal review
Licences and regulatory status: TBD — pending legal review
Contact for notices: TBD — pending legal review

04 Eligibility

Who may take part.

Who is excluded: US persons are not accepted. You confirm your own status; no identity checks are made.
One address, one participant: A participant is a Hyperliquid address. You send from an address whose key you hold, and every payout and refund returns to that same address.
A limited number of addresses: The number of participant addresses is limited. The limit is set when the contract is deployed (10 in the beta), and the contract never allows more than 43, a bound set by the gas cost of the weekly settlement. An address keeps its place even after it has left. If the places are used up, no new address can join.
Raising the address limit: The admin can raise the limit, never lower it and never above 43, and only through a public delay of 48 hours; the change shows up first as a Proposed event.

Excluded jurisdictions beyond the US: TBD — pending legal review
Age and legal capacity: TBD — pending legal review
Number of participant addresses in the first phase: 10

05 Deposits

What you send, and when it is refused.

What you send: USDC only, as a transfer from your own Hyperliquid spot balance to the pool's spot balance on HyperCore (the Pool page signs it as a Send), to the pool's HyperCore address shown on the Pool page and checked as described there, and from the address that should receive your payouts. It is a Hyperliquid transfer, not a contract call, and needs no gas. These are not accepted and can get stuck: a transfer from HyperEVM or through a bridge, a transfer to the pool's perp balance (usdSend, or a Send whose destination is the perp side), a transfer to a HIP-3 dex, and any other token. Do not send anything else.
Send from an account you control: Payouts and refunds go back only to the address the money came from. A transfer from an account you cannot sign for, such as a sub-account, a vault or a custodial account, may be impossible to return or pay out.
Minimum: 10 USDC, for every deposit, including top-ups. A smaller transfer is not credited. The contract has a return function that sends it back to the sender, and the keeper runs it automatically; it has not yet been used with a real refusal on mainnet, so such a transfer may stay on the pool's account for a while.
How it is credited: The contract cannot see who sent a HyperCore transfer. The keeper reads the public ledger and credits the address that sent it, usually within minutes, but not instantly. If it does not arrive, do not send again; write to us.
When a deposit is refused: The contract refuses deposits below the minimum, above the pool's size limit, over the address limit, while the pool carries a shortfall, while at current prices some participant would end below zero, while a weekly settlement runs, and while deposits are paused. The reason for the shortfall rules is fairness: a newcomer must not pay for a trade they were not part of. A refused transfer is returned to the sending address by the keeper, through the contract's return function. The keeper runs that return automatically, but it has not yet been used with a real refusal on mainnet; do not send while the pool is closed.
Pause: The guardian key can pause new deposits at any time, without notice. Withdrawals and payouts are not affected by a pause. Only the admin can lift it.
Size limit: The pool has a size limit, shown live on the Pool page. It is set by the operator, who can change it at any time. In the first phase it starts at 1,000 USDC and is raised in steps (to 3,000, then 10,000), each step only after two clean weekly settlements in a row: no keeper incident, the books reconciled, all payouts confirmed. The limit is small on purpose.
How the limit is measured: The contract applies the limit to the capital of the participants plus the new deposit (totalStake() on the ledger), so profit alone cannot close the pool to deposits and the order in which two transfers arrive does not matter. Profit counts toward the limit only after a weekly settlement turns it into capital; a withdrawal frees room at once. The room shown on the Pool page is the limit minus that capital.

06 Shares and results

No units, no price per unit.

How a trade is shared: There is nothing like fund units bought at a price. Each trade belongs to the participants whose capital was in the pool when the size of its order was calculated, and its result is split among them in proportion to their weight at that moment. A deposit joins new trades only; an order calculated before your deposit stays with the earlier group, even if it is filled afterwards.
Two trading accounts: The pool trades through two separate Hyperliquid trading accounts. Every transfer of money to trading is split between them 50 % / 50 %; the split is set in the contract and can be changed by the admin only through the public delay (section 10). Both accounts trade the same system, and each trade still belongs to the participants who were in the pool when it was sized.
When trading starts: Until participants' capital reaches 1,000 USDC, deposits wait in the vault and do not trade. When it does, the keeper splits the money between the two trading accounts in one step and both start trading at once. If withdrawals later take capital below that amount, trading does not stop. This is a rule of the operator's keeper, not of the contract.
How much is in positions: Each trading account keeps at most 60 % of its own capital in open positions; the rest stays free. This is a rule of the operator's bot, not of the contract.
Your weight: Weight is your capital after counting losses at current prices: a loss on an open position lowers it at once, a gain raises it only at the next weekly settlement. This is on purpose, so nobody can claim a larger part of a new trade on gains that may still disappear. The cost is that your part of a new trade can be a little smaller than your balance suggests.
Weekly settlement: Scheduled for Mondays at 04:00 UTC; the day and hour are the keeper's schedule. The contract allows at most one regular settlement per calendar week, a week starting on Monday 00:00 UTC. It also allows an extra settlement inside a week, but only under conditions it checks itself: when the book has grown past a limit set in the contract since the last settlement, or when some participant is below zero at current prices. An extra settlement credits results and takes the fee like a regular one; it does not start a new week. At every settlement results are credited to capital, the fee is taken, referral rewards are credited, and any loss beyond a participant's money is split (section 09).
During a settlement: While a settlement is running, new deposits are not credited and withdrawal requests are not processed. Requests stay in the queue and are served after the settlement ends.
Prices come from the keeper: The prices of open positions are reported by the keeper, which refreshes them before every deposit, withdrawal and settlement. If prices are stale, withdrawals are refused until they are refreshed.
Rounding: Amounts are rounded against the participant, and dust goes to the pool's fee account.

07 Fees and referrals

What the pool charges.

Performance fee: A fee on net profit above your own high-water mark, settled weekly. The mark is the highest level on which a fee has already been charged for you; it does not depend on anyone else. A week that ends below it costs nothing. The rate is fixed when the contract is deployed, for good: no function changes it. It is the same for every participant.
Cautious base: The fee base is closed profit minus any open loss. Open profit is not counted until the trade closes, so you are not charged on gains that later vanish.
Only on a trade's final result: Part of a trade closed in profit does not enter the fee base until the whole order is closed.
A fee already taken is not refunded: If a fee was charged on a gain and a later loss wipes that gain out, the fee is not returned. The high-water mark stops you paying twice on the same profit; it cannot undo a payment made on profit you no longer have.
When you leave: Open profit is not paid out when you leave, and no fee is taken on it. Your share stays in the open trades until they close; the profit then becomes closed, the fee is taken at the next settlement, and the rest is paid to you as a final payout.
Costs paid by the operator: The fee goes to the operator's wallet after each settlement. The network gas for payouts is paid by the operator's bot out of that fee. Your own contract actions (registration, withdrawal requests) are paid by you in HYPE during the beta; signed requests without gas are planned for the public launch and are not available now.
Referrals: Two levels. A partner, approved by the operator, earns a share of the profit of the people they bring, for a limited period; any participant with an open link earns a smaller share, with no limit of time. There are no chains of referrals. Every reward is paid out of the operator's share of the fee: it never reduces what the referred participant keeps and never adds to what they pay. The shares are fixed when the contract is deployed, like the fee.
What referral rewards cannot do: They do not repay a participant's own debt (section 09) and they are not used to cover anyone's loss. A reward for an address that has never sent money to the pool builds up and is paid once that address is active.
Registered once: Referral and payout settings are registered by a separate contract call before the first deposit. They are set once. After the first deposit that call changes nothing: the referrer can never be set later, and the payout mode can be changed only with a separate call, setPayoutMode. Both are HyperEVM transactions and need a little HYPE for gas.

Performance fee rate: 50 %
Referral reward rates and partner period: TBD — pending legal review

08 Withdrawals

Getting your money out.

How to ask: Request a withdrawal at any time, either an exact amount or everything; one request per address can be open at a time. The request is a transaction on HyperEVM sent from your own address, so you pay its gas in HYPE, unlike a deposit; in a complex state of the pool's book it can need a large-block transaction, an account setting on HyperEVM. The Pool page sends the request from your connected wallet; it does not change that account setting, and says so if the request needs it.
Order: Strictly first in, first out. The part of your capital not needed as collateral for open trades is paid first; the rest is paid as those trades close. A request that cannot be paid in full waits, and later requests wait behind it.
What is held back: While your trades are open, part of your money stays in the pool as collateral and as cover for a possible top-up on those trades (section 09). How much depends on how heavily the pool is loaded; in busy periods almost nothing can be paid at once. Asking for everything pays the free part; the held part is released as your trades close. The worst case for a complete exit is up to 17 days, the time the operator's bot may keep a position open before it must close it (a rule for the bot, not for the contract), plus up to 7 days until the settlement that pays out the released share.
We do not close trades early for you: A trade belongs to everyone in it. Closing a winning trade early for one participant would take from the others, so a leaving participant waits for the bot's normal exits. If many participants leave at once, the bot takes fewer new trades so the queue can clear.
Payouts go back where the money came from: Payouts are sent automatically to the Hyperliquid address that made the deposit. There is no other destination, for anyone, the operator included. If you lose access to that address, you lose access to the payout.
Small amounts: Payouts under 10 USDC accumulate until they reach it. A participant who has fully left and has no share in open trades receives a smaller remainder as it is.
Waiting and refusals: While a weekly settlement runs, the queue is not processed and your request waits. If prices are stale, withdrawals are refused until the keeper refreshes them; send the request again afterwards. If a request stays unserved for 28 days, anyone can freeze the pool (section 11).

09 Losses

When a loss exceeds your money.

The rule most likely to surprise you. It is written into the contract code, which has not been audited.

When it happens: Not in a normal week. It happens when a position closes worse than its protective stop, for example in a flash crash, a gap or a delisting, or when several stops hit together. Then a participant's share of the loss can be larger than their money in the pool.
Who pays, in order: First, the participant's own money in the pool. Second, the other participants of the same trade, in proportion to their weight, each at most their own share of that trade and at most their own money. Third, if still short, the whole pool: holders of capital, in proportion to their capital, never more than what is needed and never more than they have. Fourth, if still short, a pool shortfall is recorded and charged to no one. Only money standing as collateral can be used (capital and requested but unpaid withdrawals). Money already waiting for payout and referral rewards cannot.
The operator does not pay: Neither the operator nor the operator's fee covers this.
Repayment: The participant who could not cover their share owes it to those who paid. It is repaid only out of that participant's own future profit from pool trades, before any fee on that profit and in proportion to what each payer is owed. New deposits and referral rewards do not repay it, so nobody is asked to top up from outside. If the participant never earns it back, the payers are not repaid.
If you leave while trades are open: Your share of risk stays in your open trades. If one closes worse than its stop, the shortfall on your share is paid by those still in it, and your later profit in the pool repays them. A part of your money is kept back until your trades close, to cover this.
Deposits are closed meanwhile: While there is a shortfall, or some participant is below zero at current prices, new deposits are refused, so a newcomer never pays for a trade they were not part of.
Trades closed in parts: A trade can be closed in several parts. When the parts fall on either side of a weekly settlement, a participant who joined after that settlement can end up paying for part of a trade closed earlier. This is a known cost, accepted by the operator.
In an emergency stop the rule changes: See section 11.

10 Keys and trust

Who can do what.

Every value below can be read from the chain; the Pool page shows how.

Admin: A single-signature Safe wallet held by the operator. It can replace the keeper, the guardian and itself, add trading-only keys to the pool's trading accounts, set the pool's size limit at once, lift a deposit pause, restore a keeper or trading key the guardian revoked and manage partners. It can also change how money sent to trading is split between the two trading accounts. Role changes and a change of that split take effect only after a public delay, planned at 48 hours, so they can be seen before they apply. The delay is set when the contract is deployed and can be read on chain; every role change shows up first as a Proposed event on the vault.
Guardian: A separate hot key of the operator. It can only take away: pause deposits, revoke the keeper and the trading keys, cancel pending role changes (all but its own replacement) and cancel a trading account's open orders, which also removes that account's protective stops. It cannot move money. Revoking the keeper stops prices, settlement and payouts until the admin restores it. A watchdog run by the operator may pause deposits on its own.
Keeper Not yet in the contract: Credits deposits, reports prices, processes withdrawals in order, files trade results, runs the weekly settlement. In the contract code, payouts go only to a participant's own address (the return of a refused transfer is the one exception: the keeper names its recipient), and the trading accounts send money only back to the vault. What the keeper may credit is limited to genuine incoming transfers not yet credited. What the contract does not check is the results the keeper files, so in effect the keeper can move the pool's money: a dishonest keeper could record results that are not real, up to the whole pool. Checks on this are planned and are not in the contract.
Trading keys: A trading key can place and cancel orders. It cannot withdraw. It can still lose money, and it can switch its trading account into Hyperliquid's unified mode, which cannot be undone (section 02).
No upgrade: The contract has no upgrade function and no proxy: its rules cannot be swapped under you; only its roles can be changed.
The operator's own money: If the operator holds money in the pool, it sits under the same rules as everyone's, with no priority and no exemption from losses.
Source code: Published at https://github.com/Jointkeeper/rubik-pool-contracts (commit fd7f60078c26889d1f8ff19d8b7f00e9d21c6d9d) and verified on Sourcify and HyperEVMScan, with a manifest and a how-to-verify guide on the Pool page. The licence is Business Source License 1.1, which converts to GPL-2.0-or-later on a change date set when the source is published (decided: two years); the libraries it uses stay under MIT. It is source-available, not open source. Public source is not an audit.
What you still trust: That the keeper reports honestly and competently, that the operator does not misuse its keys, that Hyperliquid works, and that our code is correct.

Operator liability for keeper and operator errors: TBD — pending legal review
Licence of the source code: Business Source License 1.1; the change date to GPL-2.0-or-later is set at publication (decided: two years)

11 Emergency exit

Built, not yet proven live.

The freeze is in the contract code. It is not audited and has not run on mainnet. A freeze is irreversible, and what happens to open positions depends on the operator's bot.

What it is for: To get money out when the normal route is stuck: the settlement hangs, the keeper goes silent, or withdrawal requests stop being served.
When it starts: Anyone can freeze the pool once one condition holds: no keeper operation for 4 days; a withdrawal request unprocessed for 4 days; a settlement open for 4 days; no settlement for 15 days; the oldest request in the queue older than 28 days; or an announcement by the admin, 48 hours after it is made (the guardian can cancel it only before then). The first four count only after the first credited deposit.
What a freeze does: A freeze cannot be undone. From then on the keeper and the admin can do nothing, and deposits and withdrawal requests are rejected. Each participant can claim their share, and anyone can trigger a claim for anyone; the money goes only to that participant's own address, which must be active on Hyperliquid.
What is divided: The money in the vault and the free margin of the trading accounts, which anyone can collect to the vault. The contract does not close open positions: only the operator's bot can, and their value reaches participants only after they are closed and collected. Money that arrives later is divided too.
Transfers around the freeze: A transfer sent after the freeze goes to the holders. A transfer sent before it but not yet credited stays stuck: the return function does not work after a freeze.
How the result is split: For the week of an emergency stop, the result is split in proportion to capital at the start of the week, not trade by trade, so the rule of section 09 does not apply that week. No performance fee is taken for that week. A fee already accrued to the operator and not yet paid out is paid before participants' shares, except for the amount of a recognised pool shortfall, on which it ranks equally with everyone.
What it costs: Positions left open keep carrying market risk until the bot closes them, and a hurried close costs slippage, borne by the participants.
What it does not cover: A halt of Hyperliquid itself, or a fault in the emergency mechanism. The mechanism is in the contract code, but it is not audited and has not run on mainnet.

12 Taxes, disputes, changes

Still to be written.

These parts are for legal review. Nothing here binds anyone yet.

Taxes: You are responsible for your own taxes. The operator gives no tax advice.
Data: This website collects no personal data. Wallet addresses and transfers are public on chain by their nature.
Changes: The rules built into the contract change only through the contract's own role changes (section 10). How changes to this page are announced is still to be written.

Dispute resolution: TBD — pending legal review
Notice of changes to these terms: TBD — pending legal review
Which prevails if this page and the verified contract differ: TBD — pending legal review
Limitation of liability: TBD — pending legal review
Taxes: wording: TBD — pending legal review