Docs

CROW is an on-chain investment platform on Solana. Capital sits in program-owned vaults, not in an operator's wallet. Two primitives cover everything: funds, which a manager trades, and indices, which follow a basket of tokens by rule.

Deposits are always made in SOL. What happens to that SOL next is the only real difference between the two primitives.

Almost nothing here is a record this site keeps. A vault, its holdings, who created it, the shares you own, the weights an index tracks, the basket a unique index rebuilt last night, and whether a creator’s X account has been verified — all of it lives in accounts on Solana, written by the program and readable by anyone with an explorer. This interface reads that state and shows it. It cannot invent a holding, a share balance or a badge, and if it disappeared tomorrow every vault would still be there and every holder could still redeem.

Two things are deliberately not on-chain, because they cannot be. Valuations come from a pricing service, since a program has no way to know what a token is worth — so a deposit carries a signed valuation the program verifies before it mints anything. And the daily rebalance is triggered by a keeper service, because nothing on Solana runs on a timer. The program checks both: it will not accept a valuation from the wrong key, and it refuses a rebalance from anyone but the keeper it was told about, or before the schedule is due.

A fund is user-managed. You deposit SOL and receive shares of the vault. The manager trades the vault's assets; your shares are redeemable for SOL at the vault's current value per share (NAV).

• ·No starting allocation is required — a fund can launch empty and deploy over time.
• ·The manager can trade any supported token; positions are visible on the product page.
• ·Shares are pro-rata: your claim scales with vault performance, up or down.

shares_minted = deposit_sol * total_shares / vault_value_sol
redeem_sol    = shares_burned * vault_value_sol / total_shares

An index is a basket of tokens with target weights. Deposited SOL is split into the basket at the next rebalance, so an index holds the underlying tokens rather than a discretionary book.

• ·Weights are declared at creation and sum to 100%.
• ·Deposits queue until the rebalance tick, then buy in at target weights.
• ·Drift is corrected each rebalance — winners are trimmed, laggards are topped up.

Unique indices are platform-created and rule-driven: the basket rebuilds itself on a cadence from live market data, e.g. Solana Top 10 Volume 24H. Nobody picks the constituents — the rule does, every tick.

Users can create funds and standard indices. Unique indices stay platform-only so the rules and data feeds behind them remain auditable. See Unique → Indices.

• ·Deposit — send SOL, receive shares. Funds price immediately; indices price at the next rebalance.
• ·Redeem — burn shares, receive SOL, in two parts. Whatever cash the vault is holding is paid out in the same transaction you sign. Everything else is recorded on chain as a claim, and the keeper turns those tokens into SOL over the following seconds without you signing anything more. Anything that cannot be sold, you can withdraw as the token itself.
• ·History — every mint, burn, trade and rebalance is emitted as an event and shows up in the global feed.

Go to Create, pick fund or index, then fill in details. Required fields are validated inline and a confirmation summary is shown before deployment.

• ·Name, ticker and description are required.
• ·An optional square image is cropped and stored with the product.
• ·Indices require weights summing to 100%; funds require no starting allocation.
• ·Optionally link an X account to verify who is behind the vault.

A linked X account earns a blue check next to the product name across Explore, feeds, portfolio and manage views. It attests to identity only — never to performance, custody quality or safety.

A handle typed into a form would prove nothing, so the badge is not one. Three separate things have to be true before it appears, and a verification service checks all three before anything is written:

• ·The wallet signs a challenge naming that specific vault, so a signature collected for one product cannot be replayed against another.
• ·That address must equal the vault’s creator on-chain. Nobody can verify a product they did not create.
• ·X itself confirms the account, through an OAuth exchange that happens server-side. The handle comes from X’s own API, never from anything the browser sent.

The result is written to the vault account by a verification authority the program checks — a key that exists for this and nothing else, and which cannot move funds, trade, or change any other setting. So the badge is a fact recorded on Solana, readable by anyone, not a row in a database this site controls.

A 5% deposit fee and 1% of AUM weekly to whoever runs the vault, plus 1% of AUM weekly to the platform. Nothing else — no performance fee, no exit fee, no lockup. The platform never takes a cut of the deposit fee.

Fund — managed by a person.

• ·5% deposit fee — manager. Taken from incoming SOL. 95% of your deposit mints shares at NAV.
• ·1% of AUM, weekly — manager. A manager who loses value earns less — the incentive is performance.
• ·1% of AUM, weekly — platform. The same platform rate on every vault on CROW.

deposit         10.0000 SOL
deposit fee 5%   0.5000 SOL -> manager
minting          9.5000 SOL at NAV

weekly on AUM    1% manager
                 1% platform

Index — run by a rule, no manager.

• ·5% deposit fee — creator. Taken from incoming SOL and paid to whoever published the index. 95% mints shares at NAV.
• ·1% of AUM, weekly — creator. Paid to whoever published the index for maintaining it.
• ·1% of AUM, weekly — platform. The same platform rate on every vault on CROW.

deposit         10.0000 SOL
deposit fee 5%   0.5000 SOL -> creator
minting          9.5000 SOL at NAV

weekly on AUM    1% creator
                 1% platform

AUM is the total value the vault holds. NAV is the value of one share — AUM divided by shares outstanding. Both are shown on every vault page.

CROW never picks a trade route. It is handed one as opaque bytes and then checks the outcome — which means a bad or hostile route costs a failed transaction rather than funds.

• ·Every trade is bracketed. The vault may not spend more than the amount declared, and must receive at least the minimum it was promised. The minimum is computed from the quote and enforced on chain, not taken on trust from the router.
• ·No account the vault owns may lose value. Before a route runs, every vault-owned token account it touches is measured; afterwards, none may hold less than it started with. Only the declared input leg is allowed to fall. This covers drains nobody enumerated in advance, including a route closing an account to skim its rent.
• ·Redemption never depends on a price. Burning shares entitles you to a proportional slice of every token the vault holds, worked out from its balances at that moment. No oracle, no route, no counterparty. The instruction that moves each token is permissionless and pays only to the address written into the claim, so if every service here stopped you could call it yourself and still be paid.
• ·Nothing is given authority over your wallet. An earlier design paid the tokens to you and then took an approval over each of your token accounts so they could be sold for you. That is gone. Claimed tokens sit in a program-derived account of your own, are sold through one instruction that pays to an address the program fixes rather than one a route supplies, and can be withdrawn by you as tokens at any time. An approval spanning ten accounts in someone's wallet is the shape of a drainer whatever the intent behind it.
• ·Anyone may settle a claim; nobody may redirect one. The instruction that moves a claimed token can be called by anyone, because there is nothing in it a caller chooses. The destination is derived from the redeemer written into the claim, the source must be the vault's own account, and the amount is capped by what the claim records. Calling it on someone else's claim pays their tokens to them and costs you the fee. It is open precisely so a redemption never depends on our keeper being awake — you can always push your own through. Selling those tokens is a different matter and is not open: a sale takes a minimum price from whoever calls it, so that one is limited to the keeper or to you.
• ·A redemption fits in one plain transaction. Paying every holding out at once named more accounts than Solana allows in a single transaction, and the only way to fit was an address lookup table — a shorthand list stored elsewhere that a wallet cannot read without fetching it. Wallets warn about that, reasonably. Splitting the payout removed the table: a ten-token redemption is now 943 bytes of the 1,232 available, with nothing hidden from the wallet showing it to you.
• ·Deposits are priced by a signed valuation. The pricer signs what a vault is worth; the program verifies that signature on chain before minting shares. It refuses to value a vault whose holdings it cannot price, rather than valuing them at zero and handing out shares too cheaply.
• ·One admin power, bounded and on the record. If a token becomes impossible to transfer — frozen, or its transfer hook starts refusing — the claim against it can never be paid, and the vault would hold those tokens aside forever and never trade that mint again. An admin can write off one such claim, for one mint, no sooner than thirty days after it was made, and doing so emits an event naming who was owed and how much. It does not move the tokens; it releases the vault's obligation to keep holding them.
• ·Both Solana token programs are supported. Classic SPL and Token-2022, which matters more than it sounds — a majority of the most-traded tokens on Solana use the newer one.

Keys are separated by what they can do. The service that signs valuations and the service that runs rebalances each hold their own key, with no authority over anything else. The administrative key — which can upgrade the program — is held separately and is never placed on a server.

Worth being specific, because “on-chain” is a word people use loosely. Four kinds of account hold everything the platform knows about a product, and every one of them is public.

The vault holds what it is and who owns it: kind, name, ticker, description, creator, manager, when it was created, whether it is paused. Its money: the share mint, the cash mint, and held — the list of every token it currently owns, which the program updates itself on each trade. Its schedule: cadence, when it next rebalances, when fees last accrued. And its verification: whether an X account was proven, and which one.

Target weights hold the basket — every mint and its share in basis points. For a unique index this is what the keeper submits each night, and every purchase is checked against it: a leg cannot buy something the basket does not name.

Index params hold the rules a unique index must obey — the selection rule, how many members, the maximum weight, any liquidity floor, the weighting method, excluded mints and the churn cap. These are enforced when a basket is submitted, so an index cannot quietly stop following its own rules.

A claim is written when you redeem and lists what the vault still owes you, mint by mint. It is emptied as each token is paid out and closed when nothing is left, refunding the rent you put up for it.

An owed record is the same debt seen from the vault's side: everything it owes across all unpaid redemptions. It exists so a rebalance cannot sell tokens that already belong to someone who has burned their shares for them. The vault's balance and what the vault may spend are different numbers, and this is the difference.

A sweep permission holds the tokens claimed for you until they are sold, and says which mints it covers. It belongs to you and can be emptied by you at any time.

Your shares are not in any of them. They are an ordinary SPL token in your own wallet, minted by the program — which is why redemption works even if every service here is down. Burn the shares, receive your slice.

Three things are deliberately absent. There is no price anywhere: the program knows what a vault holds, never what it is worth, which is why a deposit must carry a signed valuation. There is no history — past NAV, trades and performance come from events the program emits, which are permanent and public but are logs rather than account state. And there is no list of who holds what, because share ownership is simply who holds the token.

The program cannot do anything on its own. It has no clock, no prices, and no way to reach a market — a Solana program only ever runs because somebody sent it a transaction. So four services run continuously on a dedicated server and send those transactions. They are the moving parts of the platform, and it is worth saying plainly what each one does and what it is unable to do.

• ·The pricer answers what a vault is worth. There is no oracle for the kind of token these vaults hold, so it asks the router what the whole position would actually sell for right now, adds up the answers, and signs the total. The program verifies that signature on chain before it will mint shares. It refuses to price a vault whose holdings it cannot value, rather than treating the missing ones as worthless.
• ·The keeper does the work that has to happen on time. It rebalances each index on its cadence, computes and submits a unique index’s basket each night, converts redeemed tokens back to SOL, and cranks the weekly fees. It pays for its own transactions.
• ·The indexer reads the events the program emits into a history — the activity feed, the charts, and what each vault paid for what it holds. It also samples NAV every few minutes, because a vault’s value moves constantly while events only appear when somebody acts.
• ·The verifier proves a creator owns the X account they claim, and writes the handle on chain once they have signed both a challenge with their wallet and an OAuth flow with X.

A dedicated server rather than shared or serverless hosting, for two reasons. The first is keys: three of these services sign, and a signing key has to sit on a disk somewhere. That disk should be one machine, under one account, with a known address — not a pool of containers whose filesystem and neighbours nobody controls. The second is time. A daily rebalance at midnight is a promise, and a process that has to be woken up, that may start cold, or that may be scheduled a few minutes late is a poor way to keep it.

Each service holds its own key and can do exactly one thing with it. The pricer signs valuations and nothing else. The keeper may rebalance and sweep, and cannot trade a fund, change a fee, or move a vault’s money anywhere except where the program already allows. The verifier may write a sixteen-byte handle onto a vault, so the worst a break-in there buys is a false badge. The key that can upgrade the program is not on the server at all.

None of them custody anything. Vault assets sit in accounts owned by the program, and every restriction that matters — that a trade cannot leave a vault poorer, that a redemption pays the person redeeming — is enforced on chain when the transaction runs, not by the service that sent it. A compromised service can waste money on bad trades within the bounds the program allows. It cannot take any.

Which is why redemption does not go through any of them. Burning shares pays out a proportional slice of everything a vault holds, directly, with no price and no counterparty. If all four services are switched off, deposits stop, rebalances stop, and the charts go flat — and every holder can still take their money out.

One program serves every vault. Its address is the same on every cluster, because it comes from the deploy key rather than the deployment.

program   CroxwitANzaciVuxw7MDCd5bGGtij9JHuKLmzULtWCqW
cluster   mainnet-beta
cash      So11111111111111111111111111111111111111112  (wrapped SOL)
router    JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4  (Jupiter v6)

Every vault, its share mint, its target weights and its rebalance schedule are accounts derived from that program — all of them public and readable without going through this site. Each row in the activity feed links to the transaction that produced it.