How it works,
end to end.

Orus discovers tokens across the chain's DEXes and launchpads, waits for one to fall far enough from its all-time high, buys the dip, and manages the position until a target, a stop or a time limit closes it. No part of that requires anyone to be at a screen.

It runs on two chains, and a strategy names its chain when it is written. Robinhood Chain — an Arbitrum Nitro L2, chain id 4663, gas paid in ETH — is the first. Two chain facts shape everything downstream there. USDG, not WETH, is the dominant quote asset, so every price in the system is denominated in USD and a "price in native" is meaningless across venues. Blocks land in about 100 ms with first-come-first-served sequencing, so there is no priority-fee auction to win: the race is on data freshness, not on tips.

Every decision an agent makes — every candidate looked at, every rejection and the measurement behind it, every entry and exit — is written to an event log. The public desk reads that log. Refusals and losses are published on the same page as the wins.

A strategy is a set of parameters covering every step of the pipeline: what to screen for, which holder profiles to reject, how deep and how recent a dip has to be, how much to spend, and when to sell. It holds no wallet and takes no action on its own. Every one of its fields is documented in the pipeline sections below, at the step that reads it.

An agent runs one strategy at regular intervals, in simulation or through its trading wallet. Its cadence depends on your account tier. Each cycle checks for new entries and monitors held positions; a cycle still in progress is not started again.

Two agents using two strategies that share every entry rule and differ only in their exits attribute any difference in results to the exit policy alone. That is how the desk's strategies are compared.

Pausing an agent stops new entries. It does not stop the exits: an agent that is paused or stopped but still holds positions gets a monitor-only pass on its own cadence, so the stop loss, the hold limit and the take profit keep working on what is already held.

Simulation needs no funds. The agent runs the full pipeline, including the guard rails and the round-trip check, and books each position at the fill the real routers quote — tokens received, price implied — not at the oracle price. Nothing is broadcast. A simulated exit is quoted out through the same router and booked at the native it would return. It is how a strategy earns the right to hold money.

Automatic does the whole thing: quotes, wraps ETH, approves the router for the exact amount, swaps, and records the position from the fill it actually got. Switching an agent to automatic runs a pre-flight — a wallet, automated trading enabled on it, and enough ETH for one entry plus gas — and refuses with the numbers when one is missing.

Your agent can run in Simulation or Automatic. Choose Simulation to evaluate a strategy without funds, then enable Automatic when you are ready to trade through your wallet.

Your trading wallet is an embedded wallet on Robinhood Chain, created at your first sign-in and held for you by Privy: the key lives in Privy's enclave, never on Orus's servers and never in your browser. The wallet page shows its address and a QR code to fund it, lets you send ETH from a wallet you already own, and lets you withdraw — by signing yourself, through Privy's confirmation, to an address you choose. Sells return WETH; a withdrawal converts it on the way out.

Automated trading is a delegation: with one click you add Orus's signer to your wallet, under a policy. The policy is the whole of what Orus may sign — wrap ETH up to 0.05 ETH per transaction, approve the listed routers, and call those routers. It has no rule for another chain, for a plain ETH transfer, or for an approval to anyone but a router; a request outside it is refused by Privy before it is signed. The console confirms the delegation, and you can turn it off at any time. While it is off, an automatic agent can neither open nor close positions.

What that policy does not bound, said plainly: an approval of a token you hold carries no cap, because token amounts have no common scale, and a wrap is bounded by its amount rather than by what the WETH contract does with it. So a compromise of Orus's signing key would be bounded by those per-transaction limits and by the listed routers — not by zero. The wallet stays yours throughout, and turning automated trading off removes the signer.

Before any real entry the engine checks the wallet again: the delegation stands, the account is enabled, and the balance covers the stake plus gas for the round trip. A wrap keeps a gas reserve as ETH so the exit can always pay for itself. The public desk's agents use separate wallets from your own.

Fund it with ETH, on Robinhood Chain, and with nothing else. Your wallet holds the same address on every EVM chain, so a deposit sent on Ethereum or Base does arrive — at an address where Orus has no router to trade it and no permission to move it, because the policy is refused on every chain but this one. The wallet page reads Robinhood Chain, and also asks Privy what the address holds elsewhere, so a deposit that went to the wrong network is named rather than silently absent. Getting it back is yours to do: export your private key from the wallet page, import it into a wallet of your own, and move the funds — that chain will want its own gas first.

The console at /app sits behind a login: an email one-time code, or a wallet you already own. The first sign-in creates your account and your trading wallet — an embedded wallet held for you, on Robinhood Chain only. Pressing the button on that page is where you accept the terms it states: Orus runs the strategies you define on a volatile market, nothing here guarantees a profit, and funds you send to your wallet can be lost.

Your console shows what is yours: your strategies, your agents, their radar, signals, positions, history and reports. The desk's own agents are not in it; they are on /live, and their strategies are the templates you can copy. Every account may generate 3 reports a day and send 30 messages a day to a report; how many agents it may run, how many strategies it may hold and whether it may ask its agent to write one are tiers — see $ORUS below. A user's strategy is bounded — min_liquidity_at_dip at least 1,000 $; buy_amount_native at most 0.05 ETH; slippage_pct at most 15 %; max_price_impact_pct at most 10 %; max_open_positions at most 25; website_regex is not available — whenever it is created or changed.

An agent's cadence is its account's tier, and the tier is the $ORUS in its wallet: Free runs every 60 seconds, Pro every 30 seconds on 1M $ORUS held, Premium every 10 seconds on 3M $ORUS held. Nothing is chosen and nothing is bought with a card — the balance is read from the chain every few hours, and an agent follows it both ways: buy more and it speeds up, sell and it slows down. The thresholds are token amounts rather than dollar ones so a price move cannot take an account's tier away overnight. Going live is four steps, all in the console: copy or write a strategy, deploy an agent on it, fund the wallet on the wallet page and enable automated trading there, then set the agent to automatic. Changing the stake, the caps, the stop or the slippage under a live agent moves it back to simulation — it went live on the old numbers, and the new ones need a new decision.

The public desk shows recorded agent activity and results, including refusals and losses. Figures refresh regularly and may lag the latest trade.

It earns. Orus keeps 3% of the realised profit of a winning real trade — the figure net of the gas both legs paid, read from the receipt — and nothing at all on a losing one; a loss never offsets a later win. Simulated positions and the house's own agents pay nothing. Every UTC day, half of the fees received and verified as final that day funds prizes for the three best net P&L, and Orus keeps the other half. On a fee paid by a referred trader, their referrer receives 50% first, and the rest is split equally between the prizes and Orus. Fees still pending or failed fund neither. Late confirmations fund the confirmation day, never an older prize pool.

It opens. Your tier is the $ORUS in your wallet, and it is the only thing that sets how often your agents run: Free runs every 60 seconds, Pro every 30 seconds on 1M $ORUS held, Premium every 10 seconds on 3M $ORUS held. Pro and above also open the AI reports — the agent report and the token report. It also sets how many agents you may run at once (1 on Free, 3 on Pro, 20 on Premium), how many strategies you may hold (1 on Free, 10 on Pro, unlimited on Premium), and whether "Ask your agent" — the assistant that writes a strategy from a conversation — is open, which it is from Pro up, with no message count on it. Going over is never possible by surprise and never destructive — an account that drops a tier keeps every agent it built and simply cannot add another. Everything else is in every tier: every desk template to copy, simulation on live data, real trading, and your own tape.

The thresholds are token amounts, not dollar ones, and deliberately so: a dollar threshold on a young token would take your tier away overnight without you selling anything. The consequence is the honest one — if the price runs, a tier costs more in dollars than it did; if it falls, less. The amounts are a constant we can recalibrate, and changing them is announced.

Jev contextual validation is Premium only (3M $ORUS held), in simulation or live trading at the owner’s choice. Enable it per agent for entries, take-profit exits, or both, with optional written conditions. Below this tier, Jev reviews stop and delegated entries and take profits wait until access is restored or Jev is disabled; stop loss, maximum hold and manual exits remain available. Saved strategies and decision history are kept.

Your balance is read from the chain every few hours and stored; your wallet page shows the figure your tier was decided on. Nothing is ever moved: the tokens stay in the same wallet your agent trades from, and Orus only ever reads the balance. It works both ways — buy more and your agents speed up within hours, sell and they slow to the tier you still hold, with a line on each agent's own tape saying so.

Generate a link on your Referrals page, share it with new traders, and track their progress and your rewards there.

The site runs Google Analytics 4. It records the pages you open, where you arrived from, and six events on the way to an account: a call to action pressed, the sign-in dialog opened, the sign-in completed, a sign-in stopped at the terms, an account created, and a returning sign-in. That is the whole list. Nothing about what your agents scan, hold or trade is sent anywhere — public results are available on /live and /leaderboard, but are not sent to Google Analytics.

Advertising is off: the tag is configured with Google's advertising signals and ad personalisation both disabled, so the data is not used to build an advertising profile and no ad network is contacted. Once you are signed in, the console attaches your account's internal identifier so a funnel can be followed end to end. Never your email, never your wallet address, never your Privy identifier.

Analytics sets cookies in your browser. To refuse them, use your browser's tracking protection, an ad blocker, or Google's own opt-out extension — none of it changes how the product works, and none of it is required to sign in, deploy an agent or trade.

Orus screens the chain's token list against the strategy's thresholds, then gathers token observations: price, market cap, launch date, pool, all-time high, holder concentration, bundler and sniper shares, launchpad state and security flags. Orus also uses price candles, earliest-trade samples and execution quotes. Wallet balances and transaction confirmations are read from the relevant blockchain.

Orus checks each candidate against your strategy's filters even when the initial scan already applied them. Changing a data source does not change the thresholds you selected. Missing required observations are reported as unavailable, not treated as a passing result. The volume floor and pre-scan use the screener’s available 24-hour volume, falling back to enriched volume when unavailable. Ratios retain the volume from the same source as their other measurements.

Every price is in USD. Execution quotes are normalised to the same economics before the engine compares them: expected output in token units, USD in and out, and price impact.

The scan first selects tokens that meet the strategy's 24-hour volume, liquidity, market-cap and trade-count thresholds. On Robinhood Chain, the native coin and the two quote assets, WETH and USDG, are excluded from trading candidates.

Each candidate is then assessed using its available price history, activity, holder distribution and risk observations. Passing the initial scan does not authorize a purchase: the remaining filters and entry conditions still apply.

Output: up to 200 candidates per run.

Three checks are fixed and cannot be loosened: a token with no pool is out, a token that cannot be sold — a honeypot — is out, and a buy or sell tax above 10% is out. There is no mint or freeze authority on an ERC-20, so the Solana-era checks do not apply; taxes and honeypots are the equivalent traps, and they are rejected rather than scored.

The venue whitelist matches the venue key, its name or the launchpad the token graduated from, so a strategy that names a launchpad admits its graduated tokens on whichever DEX they now trade. Bonding state can be required either way.

The rest is activity and holder distribution. A token whose supply sits with bundler wallets, launch snipers, insiders or the deployer is a token whose price is somebody's decision rather than a market's. Each has its own ceiling, and a wash-trading floor compares organic volume against reported volume.

Missing data fails the check it is missing from. A strategy that sets a threshold is asking a question, and "unknown" is not the answer it wants: a token with no creation date fails an age-bounded strategy, one with no sniper figure fails the sniper ceiling. These rejections carry their own codes — missing_age, missing_snipers, missing_holders — so the tape shows what was absent rather than what was exceeded. A strategy that leaves a threshold unset asks nothing and is unaffected.

A candidate that fails a numeric test still produces an event with the value and the threshold. That distance is what the near-miss board on the activity page is built from.

A token's market cap one second after its first trade says something its current cap does not: a launch at a high cap is usually sniped or bundled, and the dip pattern is unreliable on it. The clock starts at the first trade, not at contract creation — on a launchpad the two coincide, on a DEX listing made after deployment they do not. Supply is read from the token.

What survives lands on the radar — the watchlist — where it is tracked across runs with its last known all-time high, the instant of that high, the current dip and the liquidity behind it. Nothing is bought from the radar; it is the pool the chart analyser reads every cycle.

A strategy with a volume floor can also watch tokens that have not reached it yet. With a pre-scan volume set below the minimum volume, a token whose 24-hour volume sits between the two lands on the radar in pre-scan: tagged, measured like the rest, never bought. If it reaches the dip threshold while in pre-scan, it is set aside for that dip — the volume that would make it a candidate is arriving after the move, and an entry would too — and it comes back on a new all-time high. If its volume reaches the floor first, it leaves pre-scan and the ordinary rules apply.

A token leaves the radar for a recorded reason — for example, it dropped out of the scan, its entry window expired, its dip bounced back before the buy, its buy was refused or waited too long, or its launch cap exceeded the ceiling. It comes back on its own terms. One that dropped out returns when it reappears, keeping the dip it was tracking. One whose window expired, whose signal was retired without a buy, or that has already been signalled, returns only on a new all-time high — a new high starts a new dip — and only if nothing is still open on it. A launch-cap rejection, or a token hidden by hand, is permanent. The hidden tab lists the most recently hidden first.

Eviction only happens on a scan that observed the market. When the screener returns nothing — an outage, a rate limit — nothing is evicted, because a blind scan is indistinguishable from an empty market.

For each radar token, Orus compares the current price with its recorded all-time high and uses one-minute candles to identify when the dip threshold was first crossed. The high itself is stamped to the minute.

Depth alone is not enough. A dip that happened in ninety seconds is a flash crash, and one that took two days is a dead token — so timing is bounded on both sides, measured from the high and, optionally, from launch. Liquidity at entry and, optionally, the market cap at the high have floors of their own. A ceiling on the dip itself separates a discount from a rug.

The first-dip rule is what makes an entry expire. The analyser walks candles forward from the high to the first close below the threshold; that instant starts the clock. With a window set, the entry is valid for that many minutes after the crossing and then written off — which is why a token can be rejected for being too late on a dip that is still deep. A crossing belongs to its high: a new high clears it.

A buy signal carries the price at signal, the all-time high it was measured from, the dip depth and duration, the liquidity behind it and the venue it would trade on.

An agent's latest signal on a token — executed, expired or dismissed — blocks a new one only while it was raised at or after the high this dip is measured from. A signal older than the high belongs to a previous regime: the token has since made a new high and dipped again, and the strategy that entered the first dip has the same case for entering this one. A held position blocks regardless.

When a buy signal is created, the radar marks that opportunity as signalled. Sell signals come from monitoring held positions when an exit condition is met.

A pending signal does not live forever. It expires on the strategy's own window measured from the crossing, and on a global ceiling of 60 minutes regardless. And it is executed only while the dip still exists: the dip is checked against a refreshed market price at execution time and against the price implied by the buy quote, and a token that has bounced back above the threshold on either expires its signal with a dip-recovered event instead of being bought, and moves to the hidden tab until a new all-time high. So does a token whose signal expires on either clock, or whose buy is refused at the last moment — no route, no sale, a round trip or an impact past its cap — with the reason beside it. The clocks run at the start of every cycle, whatever the agent's mode or stake, and a signal past them cannot be executed by hand either.

These filters are available only on Robinhood Chain. Open the HEY Research card in your strategy, expand a group and configure only the criteria you want. Empty fields, Not used and empty state selections disable that criterion. HEY has no influence on your strategy until you configure a filter. All HEY filters start disabled. Use Clear HEY filters to turn them all off again.

All configured filters must pass. Multiple states selected within one filter mean any of those states is accepted. Yes and No are both active requirements; zero is an active numeric threshold. For example, selecting Verified token and at least 2 meaningful ships in 30 days checks exactly those two requirements. It does not enable any deployer, market or lock filter.

HEY links a Robinhood Chain contract to a published project, then supplies public building activity, token-to-project verification, recorded contract and deployer observations, pool sell depth, distribution and token locks. These are source-backed observations, not a developer reputation score. A shared deployer may be a service; an unknown project is not automatically unsafe. Coverage is limited to the projects and sources HEY has indexed.

Checks run before opening a position in automatic, simulation and manual modes. A known failed criterion refuses the entry and expires an automatic or simulated signal. Missing, unindexed, malformed or unavailable required data refuses the entry and leaves the signal pending until its normal expiry, so a later attempt can retry. A provider outage never silently bypasses an active filter. HEY never controls exits.

Builder activity is usable only when HEY explicitly says it applies to this token; a token-to-project mismatch cannot satisfy an activity requirement. Unmeasured counts are unavailable, not zero. Launch inventory is not sell depth. Token locks cover HoodLock only and are distinct from LP locks. HEY observations can lag current market conditions; each metric has its own observation time when available.

The signal keeps a HEY check containing only configured thresholds, observed values, pass/fail or unavailable reasons, observation times when supplied, and HEY source links. The activity log records refused automatic entries. These snapshots support a prospective comparison of the same strategy with and without chosen HEY filters. Current HEY data cannot reconstruct what was known before a historical entry, and no ROI improvement is claimed.

Open the HEY project link in a signal’s check to review the original research and its sources.

With Jev enabled for entries, an eligible proposal also goes to its contextual review in the same cycle: by default it needs Jev's approval, and with Jev as a veto it goes through unless Jev refuses it. Jev cannot restore a candidate rejected by the strategy. Its answer is short-lived and is checked again before execution; the price, quote, exposure and wallet checks below still apply.

Three limits are asserted first — see guard rails below. Then the token is quoted both ways: a buy of the strategy's size, and the sale of what that buy would return. No buy route, no sell route, or an immediate round trip losing more than 25% refuses the entry outright. The signal is retired, not retried, and the reason — no route, unsellable, round-trip loss — goes on the tape. This runs in every mode, so a simulation declines what a real agent would decline. The provider's honeypot and tax flags are absent on many tokens; a router quote measures the trap directly.

On Robinhood Chain, ETH is converted to WETH before a buy, and selling a token requires authorization for the swap router. Orus compares available routes before preparing the trade. A token with no route is refused before these transactions begin.

A submitted trade remains pending until its transaction outcome is known. A confirmed entry uses the amount actually received to determine the fill price. The signal retains the price observed when the opportunity was identified. Multipliers, the stop and the target are measured from the fill, so a fill above the signal price affects the position's return from the start.

An exit sells only the tokens assigned to that position, up to the amount available in the wallet. Tokens held for another position are not included. Transactions sharing a wallet are handled in sequence, and Orus checks that the position is still held before selling it.

At the start of every run, before the scan, each position that still holds tokens has its price, multiplier and P&L refreshed. A quote more than 100× the entry is a bad print: that tick is skipped and recorded rather than acted on.

Stop loss first. It fires when the drawdown reaches the strategy's stop — but only once a second feed agrees. The details provider is asked once, and the sell proceeds if it shows at least 80% of the way to the stop. Feeds differ by a few percent; a bad print differs by orders of magnitude. If the second feed cannot answer, the stop proceeds: capital protection does not wait on a vendor.

Maximum hold second. This is a clock, not a price: it fires even when the feed has no quote for the token — liquidity pulled, pool abandoned — at a secondary-feed price or, failing that, the last mark, and the event says which. It is the most common exit on the desk by a wide margin.

Take profit last, and for a real position the fill is checked before the sell: the router is asked what the exit would return, and the sell proceeds only if it delivers at least half the promised gain and never less than the stake. A fill that fails the check is neither an exit nor a failure; the position stays open and the next tick asks again.

With anti-dip ticked, a position that falls 50% or more below its fill — confirmed by the second feed, as a stop is — has its take profit lowered to the entry for the rest of its life: entered at $100K of market cap, a fall to $50K makes $100K the exit instead of the strategy's multiple. Arming waits if the second feed is unavailable. A real exit needs a usable router quote projecting at least the stake; fees and execution slippage can still leave a net loss. Untick it and every position goes back to the strategy's target.

With Jev enabled for take-profit exits, that proposed exit needs its contextual approval by default; with Jev as a veto, it goes through unless Jev defers it. A deferral is reviewed again on a later cycle, even below the original target, and the real fill check still applies. Jev cannot veto a stop loss, the maximum holding deadline or an explicit manual exit.

Exits sharing a wallet are processed in sequence. Separate wallets can trade independently. A failed exit does not close the position: if the swap reverts or is never confirmed, the position is marked sell-failed with the error and an attempt counter, and retried on later runs up to 3 times. Closing it would report a realised P&L for tokens the wallet still holds.

When an exit settles, realised P&L is the native the swap returned against what was spent, less the gas both legs paid, including attempts that reverted. Not oracle prices. When a position closes on the hold limit with no usable quote at all, it closes with no P&L rather than a made-up one, and the desk skips it.

Three limits are asserted on every buy, before the quote and before the wrap. The buy size must be greater than zero — set it to zero and the agent produces signals and never spends. The open-position cap counts open, simulated-open and sell-failed positions together, and an entry still waiting for its receipt, so a stuck exit still occupies a slot rather than quietly freeing one and a buy in flight holds its slot before it settles. The daily spend cap is a rolling 24-hour window, not a calendar day.

They are strategy fields, so two agents on the same rules can carry different ceilings by using separate strategies. Leaving one unset disables that particular limit, which is a choice worth making deliberately. A user's stake is capped at 0.05 ETH per entry whenever the strategy is created or changed.

The desk publishes the book, the trades table, the strategy board with every rule each strategy runs on, the analyses, and the decision tape — one row per decision the engine made, including the rejections and the measurement behind each one. Consecutive decisions with the same reason collapse into one row that says how many it stands for. The activity feed and summary figures refresh regularly and may update at different times. Summary figures cover the full closed book.

The book is an index. These trades never shared a wallet, so the line is what a single 12 ETH float would have done taking every one of them, indexed to 1,000 — 12 ETH because it is above the most the desk ever had deployed at once and above its deepest drawdown, so the floor holds and the slope is profit. Below 1,000 the desk is down.

A closed trade whose only exit price was a quote more than 100× its entry is withheld from the book and from the trades table, and the note under the ribbon says how many. A trade that closed on its hold limit with no usable quote counts as closed and carries no P&L. Headline figures come from the receipt when there is one; a simulated trade is marked at the routed quote.

Results are forward-tested, not backtested. A backtest with no stop loss and no maximum hold can only close a trade by hitting its target, so every closed trade is a winner by construction — which is why the numbers on the desk come from running it live instead.

On the strategies page, New strategy opens as a drawer with the form; Ask your agent unfolds a conversation beside it. You say what you are after — how much risk, how much per entry, launches or established tokens, how long you are willing to hold — and the agent answers in prose and hands back a complete strategy. It lands on the form field by field, each one marked until you edit it, and you can ask for a change as many times as you like: the next proposal replaces the last, and any earlier one can be put back with one click.

The assistant uses the supported strategy fields, their limits and the desk's published results to explain its proposal. It describes the choices that matter and the opportunities the strategy may accept or miss. It responds in the language you use. Review the proposed rules before saving them.

A proposal does not create or change a saved strategy on its own. What it proposes is validated field by field before it touches the form — a value the engine would refuse is dropped and named, a required field it left out is filled from the default and named, and a user's proposal is brought inside the same bounds as any other — and it is your Save, not the agent, that creates the strategy. Each message counts against the account's 30 chat messages a day.

On an agent's page and on the dashboard, a position that still holds tokens — open, simulated, or waiting on a failed exit — can be sold on demand. The sale is not a shortcut around the engine: it raises the sell signal, quotes the router, sends the swap, reads what came back from the receipt and books the P&L net of gas, exactly as an automatic exit would, with the reason recorded as manual. A simulated position is quoted out through the router and closed at what it would have returned.

A sale starts when you request it and can take seconds or minutes to confirm. If your wallet is already processing another trade, you may see Wallet busy; retry once that transaction has finished. This message means the requested sale has not started and has not been queued for later.

A position whose exit already failed 3 times shows Retry exit instead: asking again resets its attempt budget. A user's real position sells through the delegated wallet, so automated trading must be enabled on the wallet page; restrictions on new entries do not disable exits. A sale still requires a valid wallet authorization and a successful transaction.

Everything on this page — the pipeline, the limits the engine holds itself to, every strategy field with its default, its unit and its bounds — is published at /llms.txt as a short index and at /llms-full.txt in full, following the llms.txt convention. Use these references when asking an assistant to explain Orus or help configure a strategy.

They exist so that an assistant helping you write a strategy, on Orus or elsewhere, describes the system that will actually run it: which fields exist, what each one means, what a user's strategy may not do, and what the engine refuses before any capital moves.

You can compare public vaults and read their terms without an account. Once signed in, Vaults opens the catalogue inside the app, with your user menu and wallet. My positions shows your recorded deposits, holdings, withdrawal requests and vaults you curate. Vaults are in beta: the Beta label opens a short explanation and links to this guide. Creating and funding a vault requires an invited account during the beta. Creating a vault prepares a private draft if your account is eligible and creation is available. The draft does not accept deposits until the vault is opened to them.

Use the deposit form when it is enabled; do not send funds manually to a published address. A displayed capacity or wallet balance is not an invitation to transfer. Use Withdraw on the vault detail page inside the app to request all or part of your available shares and follow payments. New deposits are available only when the vault and your account are eligible and the required checks pass.

Capital shows the vault's estimated net value in ETH: liquid assets plus the marked value of open positions, less reserved amounts and fees. Deposits and withdrawals change this total. Performance instead follows the recorded value of a share relative to the first visible observation; a deposit is not presented as trading profit.

The chart keeps a known observation ahead of its playback and moves towards it over 30 seconds. If another observation arrives sooner, playback finishes the current endpoint before continuing. It stops at the last known value and never invents future prices. The sidebar and recorded-observations table show the latest stored estimates, so they can be ahead of the animated amount.

Choose a period from 10 minutes to 30 days, pause the animation, or open the recorded-observations table. Longer histories are sampled while preserving highs, lows and interruption markers. Only the latest continuous segment is drawn after a valuation interruption. Reduced-motion preferences disable the replay animation.

The page reports delayed observations, unavailable valuations and interrupted connections. Animation pauses when open-position quote ages are missing or exceed two minutes. This display threshold does not change the engine's pricing rules. Animated amounts are never used to price deposits, withdrawals or fees, and estimated position values are not guaranteed sale proceeds.

An agent normally trades its owner's money and nothing else. A vault opens one to deposits: other people send ETH, the agent trades it, and each depositor holds a share of the result. It is a different object from the agent — a frozen copy of the strategy, a new agent on that copy, and a wallet of its own with an empty book. The curator's original agent keeps running, unchanged, on their own money.

You do not own ETH in a vault; you own a proportion of it. What you are paid is your shares multiplied by what a share is worth when you are served — more than you put in if the vault has gained since, less if it has lost. The amount you deposited is kept only to show you a profit and loss line; it is never used in any conversion.

A vault can only be opened by a Premium account, on a strategy that has run unchanged for at least 24 hours and has at least 10 real closed trades. Real, not simulated: a simulated book never fails to fill and never pays more slippage than the quote, and booking the trades it could not have exited moved one desk strategy from +7.53% to −0.11% per trade.

Sign in from the public vault page to open that same vault inside the app. Connect the wallet linked to your account and enter an amount in ETH. If you need to fund your wallet first, the wallet page provides a return link to this vault. The 25%, 50% and Max buttons use the smaller of your spendable native balance, available vault capacity and the per-deposit limit. ETH is kept for network fees; WETH is not automatically unwrapped. Review the amount and terms, then confirm the transfer in your wallet on Robinhood Chain.

Before each confirmation, Orus rechecks the account balance, network, vault status and a valid valuation no older than two minutes, including open-position mark ages. This is an availability check, not a reservation. A competing deposit or market move can fill the vault before allocation; an over-cap transfer receives no shares and is owed back, with no promise of an immediate refund.

Follow the deposit status on the same page: a recorded or confirmed transfer is still waiting; only 'Deposit complete · shares credited' means shares exist. If the page closes after sending, return using the same wallet to resume tracking. If the wallet's response was lost, use 'Recover an existing transfer' with its transaction hash. Recovery never sends another transfer and remains available when new deposits are disabled.

The vault's address is printed on its page and you can read its balance on the explorer — that is the point of publishing it. Your deposit is credited to the address the ETH actually came from, read off the chain rather than from anything your browser said: the address is public, and whoever reported a transaction first would otherwise take the shares for a transfer somebody else made.

A deposit must receive the required blockchain confirmations before it can be priced. Unresolved transactions or inconsistent balances pause pricing. A successful valuation turns the deposit into shares at that valuation, rather than the figure on screen when you sent it. Market prices can change while you wait.

Open positions contribute an estimated market value to the vault. Pricing uses recorded position values up to 2 minutes old and does not obtain an executable sale quote for the whole position during pricing. Older or missing marks pause deposit and withdrawal pricing. A mark within that age limit can still be wrong after a fast market move, and the displayed value is not guaranteed sale proceeds.

Verified transfers without an identified depositor are held aside. Native transfers still need their transaction hash to identify the owner. Until attribution, excess ETH or WETH is excluded from share value, fees and spendable cash. After a vault closes to deposits, a valid report waits for confirmations and a canonical-block check, then records a refund owed without issuing shares. Recording a refund owed does not mean it has been paid. Payment may require assistance from Orus support.

On the vault detail page, sign in, choose a percentage of your available shares (100% for all), review the estimated ETH amount and your original funding address, then confirm. The estimate is not a guaranteed payout. You can follow each payment on the explorer and cancel only the unpaid remainder before its payment starts. A lost response can be retried as the same request.

When cash is held in WETH, the vault converts the needed amount to ETH, waits for confirmation, and takes a new valuation before paying. Fees, pending deposits and gas reserves remain protected. A payment is capped at 5 ETH and larger requests are paid in instalments. The final holder can still have a residual claim on the gas reserve; vault closure is not yet enabled for public funding.

A withdrawal request joins a queue. The vault never force-sells a position to pay you faster. On a book where an immediate round trip can lose a quarter of its value and exits already fail, selling on demand destroys more than it releases. Cash comes back as positions close on their own clock, which is why a vault's strategy must have a maximum holding time: that number, plus processing allowance, is a configuration value, not a promised or observed withdrawal time. Failed exits or outages can extend the queue indefinitely.

The queue is pro rata rather than first-come. In a strict queue a ten ETH request ahead of a small one blocks it until ten whole ETH have accumulated, which makes your wait a function of somebody else's size. Pro rata makes everyone's wait the same multiple of their own claim. The curator's own shares are served after every depositor's, and are frozen entirely while a rule change of theirs is pending.

Your shares are burned when you are paid, not when you ask, so you stay exposed while you wait — in both directions. Locking the price at the moment of asking would let somebody leave at the top and hand the fall to whoever stayed. Cancellation is allowed before a payment starts. A new request has a new timestamp; allocation is still pro rata, not first-come.

3% to the curator and 3% to Orus, charged only on the rise in the value of a share above the last per-share peak used to settle fees. That rise includes the estimated value of open positions. A vault that falls twenty per cent and climbs back twenty per cent is charged nothing: its record has not been beaten. The value per share you see is always net — the fee is subtracted from it as it accrues, whether or not it has been collected yet.

Fees become payable every 30 days, before a new deposit is turned into shares, and before a funded withdrawal is paid. Between those events the estimated fee can fall back to zero. Once made payable, a fee is not reversed by a later loss: a vault can therefore finish a period down after paying fees on an earlier gain. Recovering below the high-water mark does not itself create another fee.

Measuring it before a deposit is what keeps a newcomer out of a fee they did not earn. The fee accrues on every share against one record, so shares struck at the net price would otherwise carry a slice of a rise that came before them; settling the fee first moves the record to the price they paid, and nothing above it is left to charge them on. The holders already in pay exactly what was already subtracted from their value, and no more.

One consequence worth stating because it runs against us: somebody who joins after a fall pays nothing until the old record is passed, even though the vault gained while they were in it. That is a known cost of measuring per share, it favours the depositor, and we are not going to fix it in the direction that does not.

A vault's agent pays no per-trade fee, and it is not on the leaderboard or in the daily prize. It carries its curator's account, so every position it opened would otherwise land in the curator's personal record — showing depositors' money as their own, and letting them win a prize with capital that is not theirs.

Orus keeps the register of shares, not a contract. The wallet uses Privy infrastructure. Orus authorizes transactions and administers its policies; the curator has no direct access to the key. A compromised Orus authorization key can put funds at risk. Per-transaction caps are not cumulative limits and do not prove that a payment's recipient is a depositor. But your shares are rows in our database. If you need a guarantee that outlives this company, this is not yet it.

The curator chooses what it buys and you do not see the rules. That is what they are bringing. They have no direct signing access and cannot change the rules without a notice period, during which you can request a withdrawal subject to the cash queue — and the notice tells you which parts of the strategy are changing, in plain words, without the numbers. What they can do is lose your money by trading badly, or on purpose, and no arrangement described here prevents that.

Positions nothing will buy are valued at zero, for a deposit and for a withdrawal alike. A token whose exit has failed its last attempt is worth nothing to whoever arrives and nothing to whoever leaves, so neither of them can trade against the other's optimism. The share of a vault in that state is published on its page.

This is a directional trading strategy on newly launched tokens. It is not a rate, nothing about it is annualised, and you should deposit only what you can lose entirely.

Jev is an evaluation model from TypeSafe AI. It interprets observations against written criteria and returns one of a defined set of answers. In Orus, that answer can approve, refuse or delay an entry, or approve or defer a take-profit exit.

Think of it as a contextual reviewer inside your agent. Your strategy first checks its numeric rules, such as dip depth, liquidity and position limits. If you enable Jev for the proposed trade, the agent waits for its decision in the same trading cycle. By default only an approval continues to execution; with Jev as a veto, any answer but a refusal or a deferral does. Price, quote and wallet checks still apply.

The strategy assistant helps you write rules before you save them. Jev instead evaluates a trading opportunity while your agent runs. It does not rewrite your strategy, choose your stake, predict a target price or receive permission to sign transactions.

Two tokens can pass the same volume and dip filters while showing different activity. In one, purchases follow an initial sell-off and remain held across observations. In the other, recent buyers quickly sell back out. A volume total hides that sequence; Jev can assess it against your entry criteria.

At a take-profit trigger, you can ask whether observed purchases are still being retained while selling is absorbed. Jev may allow the exit or defer it for another review. Deferring keeps the position exposed: a later exit can be worse than taking the original profit.

Use ordinary strategy fields for exact requirements such as minimum liquidity, maximum stake or a holding deadline. Use Jev for a question about the supplied sequence of events. If that question needs facts Orus does not provide, Jev should return insufficient evidence. More reviews or fewer trades do not by themselves mean a better strategy; any improvement needs a comparison.

Jev is Premium only, unlocked by holding 3M $ORUS. In the agent form, open Jev contextual validation and choose Entries, Take-profit exits, or Entries and take-profit exits. Disabled keeps the ordinary strategy behavior. Save the form to apply your choice.

Simulation uses simulated positions. Automatic uses real trades through your configured wallet. Enabling Jev does not switch between them or start an agent. New agents initially use simulation; changing an existing agent to Automatic follows the usual wallet setup.

The switch belongs to each agent. Optional written conditions belong to its strategy, under Buy Position and Sell Criteria. Saving a condition does not activate Jev, and agents sharing that strategy read the same conditions. Leaving both conditions blank uses the standard review criteria, which you can expand in the form. Jev and Fly cannot be enabled together on the same agent.

Changing a saved condition is a strategy risk change. For a user-owned strategy, its automatic agents return to simulation when that condition changes, just as when the stake or stop changes. Review the new criteria before choosing Automatic again. Simply changing the agent's Jev scope does not change its execution mode.

You can turn Jev off to return to ordinary strategy decisions on subsequent cycles. This does not close positions or erase the journal. Pausing an agent stops new entries; held positions remain monitored. If Premium access is lost, Jev reviews stop and delegated entries and take profits wait until access returns or Jev is disabled. Stop loss, maximum holding time and manual exits remain available.

By default Jev is a gate: an entry goes through only when Jev approves it, and a take profit only when Jev confirms it. An uncertain answer, a market too quiet to read or an unavailable review all mean waiting. Expect few trades: on memecoin dips Jev rarely sees enough to approve.

Tick Jev as a veto, under Buy Position, and Jev can only block: an entry goes through unless Jev refuses it, and a take profit unless Jev defers it. An uncertain answer or a quiet market no longer blocks. Your strategy's rules decide, and Jev stops the trades it can see going wrong.

When Jev cannot answer at all, because of an outage, a timeout or no time left in the cycle, the veto does what lowers exposure: the entry waits for the next cycle, and the take profit goes through. Stop loss, maximum hold and manual exits are never Jev's, in either mode.

The mode belongs to the strategy, like the written conditions. Switching it is a strategy risk change: automatic agents on a user-owned strategy return to simulation.

The standard entry review looks for demand that persists after initial selling. It can refuse an opportunity when purchases are rapidly reversed or selling continues, wait when an observed transition needs another sample, or report insufficient evidence when the available history cannot distinguish those readings.

Example: “Require purchases after the initial sell-off to remain held across the available observations; rapidly reversed purchases should not count as persistent demand.” This asks about event order and changes in observed holdings, rather than repeating a volume threshold.

Write one clear, observable requirement in the Jev entry condition field, up to 500 characters. It adds to the standard criteria and cannot relax them. Avoid requests such as “only buy tokens that will double” or “prove the wallets are independent”: future returns and unknown wallet relationships are not evidence Jev has. With the gate, a condition that cannot be established may leave an entry waiting until its window expires; with the veto, it can still refuse an entry on the evidence it has.

The standard exit review validates the proposed take profit unless the observations sufficiently support continuing the position. Holding requires purchases retained over time and selling being absorbed; a higher price alone is not enough. With the gate, missing or contradictory evidence does not authorize the delegated exit; with the veto, it does not stop it.

Example: “Defer the take profit only while successive observations show retained purchases and absorption of selling; do not defer on price strength alone.” Write this in Jev take-profit condition, up to 500 characters. The condition helps qualify a deferral; the stop-loss percentage and holding deadline still belong in their normal strategy fields.

A deferred take profit is reviewed again on a later cycle, even if the price has fallen below the original target. A real sale must still pass the existing take-profit fill check. Stop loss, maximum holding time and an explicit manual exit bypass Jev's decision, while retaining their normal execution checks. Jev can delay a take profit, but it cannot veto those exits.

Open Jev on the agent page to see the latest reviews. Decision is the model's answer or the review's status. Applied action records what the engine subsequently did. An approval can still expire or be stopped by a changed setting, a price or quote check, unavailable funds or a failed transaction. A pending action is not a settled trade; No recorded action is not proof of execution.

No reviews yet can mean there has been no eligible entry or take-profit trigger for the enabled scope. Jev does not run on every scanned token. When a review cannot run because of a timeout, unavailable service or a cycle's time budget, an entry is never approved by default: it waits within its existing window. A take profit remains open for a later review with the gate, and goes through with the veto. Protective and manual exits remain available.

View under Evidence opens the captured observations, saved criteria and structured answer. It lets you inspect what was actually available at decision time. Any returned choice probabilities describe the model's assessment of those choices, not the chance of making a profit.

Mode says how each answer was applied, gate or veto: the same Insufficient evidence waits under the gate and goes through under the veto. When an entry Jev let through does not complete, Applied action gives the engine's own reason, for example an approval that expired before the quote was ready, a busy wallet or an unavailable on-chain rehearsal; that is the engine, not Jev refusing. Signals waiting for Jev lists the agent's pending entries and the last review each one had; Not reviewed yet means none has been recorded so far, because the cycles that looked at it had no time left or no price to review it at.

Orus supplies the last thirty minutes of buys and sells, up to 150, with times, amounts and pseudonymous participant identifiers, the dip the strategy measured (the all-time high, how deep and how long the fall, where the price stands against that high now), the largest traders of the last 24 hours with their purchases and sales over that window (and their holdings where the data provider reports them), and earlier observations when available. The proposed trade's context includes the current price, entry or dip information, and whether a take profit was already deferred.

The sample is bounded and can miss trades or holders. A single balance cannot prove that someone retained a recent purchase; that requires observations over time. Unknown wallet relationships remain unknown, and different identifiers do not prove independent traders. Missing values are kept missing rather than treated as zero or a sign of safety.

Jev only evaluates the observations supplied for that review. It does not independently browse social media, inspect private chats or see future trades. Your optional text cannot add a data source. The journal exposes coverage information so you can distinguish an uncertain market reading from incomplete input.

Public agent, strategy and account pages identify the current JEV scope and how many agents use it. The With JEV leaderboard filter selects current configurations; it does not turn the historical P&L into a JEV performance measurement. Public activity covers the last 24 hours and follows the selected real/simulation filter, independently of the chart period.

Public activity separates model responses, missing data before a review, and unavailable or expired reviews. Repeated reviews of one signal or held position count as one distinct opportunity. An approval is separate from a confirmed execution. Detailed examples are published only for ORUS agents; user instructions, tokens under review and individual observations remain private.

For a comparison, create two agents using the same strategy, execution mode, cadence and starting conditions. Leave Jev disabled on one and enable a chosen scope on the other. Run them over the same period without changing the parameters midway. Simulation lets you do this without risking funds; it is a testing option, not a restriction on Jev access.

Compare net realized results after trading costs, open exposure and drawdown, trade count, entries refused or missed, and exits deferred. Read the journal for unavailable or insufficient reviews and added latency. A higher average profit per completed trade can hide fewer opportunities or losses still held open. Different holdings can also make the agents encounter different later opportunities, despite identical rules.

If a frozen experiment comparison is attached to the agent, its table also shows review errors, latency and reported inference costs. Open marks are estimates, and the displayed inference cost is not the total cost of market data. Frozen comparison agents remain in simulation to keep the experiment consistent; ordinary Premium agents may use live trading.

Jev can misread context, miss an entry or postpone an exit that would have been better taken. Its availability and structured answers do not establish a performance benefit. Judge results over enough opportunities and different market conditions before attributing a difference to the model.

Every signed-in account can see Connections. Issuing or using a key still requires the service to be switched on. An administrator's personal key never inherits operator access or reads another account's data. An administrator's own console agents and strategies belong to the house, not to a personal account, so an administrator's key lists nothing: test the API with a personal account.

Open Connections, name the key and select the permissions you need. Only agents:read and strategies:read are selected initially; additional reads and writes are optional. Existing keys keep their original scopes. Save the secret immediately: it is shown only once. There are at most 20 creations per rolling 24 hours. If key creation times out, refresh the list, revoke the new key and create a replacement; the secret cannot be recovered.

Send the key in the Authorization header as Bearer followed by the secret. Never put it in a URL, chat or repository. Cookies and partner scan keys cannot authenticate this API. Example with securely supplied environment variables: curl --fail-with-body -H "Authorization: Bearer $ORUS_API_KEY" "$ORUS_ORIGIN/api/v1/agents?limit=25".

Revocation asks you to confirm the key's name and blocks new requests. Already admitted reads may finish. Writes recheck the credential inside their transaction; a transaction that wins the lock before revocation may complete. Revocation does not stop agents or erase third-party copies. Invited accounts can still revoke keys while the API is switched off.

Responses contain data and request_id. Lists contain data.items and data.next_cursor; send the cursor as after. The default limit is 25 and the maximum is 100. IDs, revisions and base-unit amounts are strings: do not convert large integers to JavaScript numbers. Results are ordered by ID; pages are not a point-in-time snapshot. Activity, position, fee and report lists accept an optional agent_id. Unknown or repeated query parameters are rejected.

Events and alerts cover a rolling seven-day window returned in data.window; older events are outside this endpoint's contract. Alerts are entry, exit and signal events, not the console's aggregated alert cards. Watchlist results include historical states and have no reliable price observation timestamp. Positions return stored marks and price_at; a missing or old timestamp is not a fresh quote.

Wallet reads return read_started_at and read_completed_at, nullable balances and individual read errors. ORUS balance can be cached; price_observed_at is null because the source does not supply a reliable per-price timestamp. Amounts are decimal strings in the named asset's units, converted from the existing balance reader, not exact on-chain base units. No reconciliation, signing or delegation is performed. Unknown values are never replaced with zero.

Saved reports do not trigger paid generation. Detailed token summaries stop at 100 entries and declare tokens_truncated; raw provider payloads are omitted. JEV returns stored decisions, hashes, available probabilities and usage, not the policy or raw context. Strategy rules include your own JEV instructions. Optional strategy fields may be absent during a compatible rollout; treat them as unavailable, never zero or default.

strategies:write can alter the future behavior and trades of an already running agent. Changes to buy_amount_native, slippage_pct, max_open_positions, max_daily_spend_native, stop_loss_pct or JEV instructions switch affected personal automatic agents to simulation and return their IDs and names. Other rule changes keep the current mode. Existing positions remain real. Review this permission as a sensitive capability even though no order endpoint is available.

For a PATCH, read revision first, then include expected_revision as the same decimal string. Example: {"expected_revision":"12","name":"My strategy"}. A stale value returns 409 revision_conflict with current_revision and resource. Reload, reconsider the change, and use the new revision; do not retry blindly. Strategy editing and risk disarming are one transaction. Validation previews reserve nothing and return normalized fields, risk_fields and would_disarm.

All POST operations that create or copy resources require a unique Idempotency-Key (1–128 letters, digits, dot, underscore, colon or hyphen). Keep it and the original request unchanged for a retry after a timeout. First creation returns 201; replay returns 200, replayed: true, and the same IDs with their current representation. Reusing the key with different parameters returns 409 idempotency_conflict. Deleted results return 409 creation_gone. Revalidation may reject a replay if source access, account limits or schema constraints changed; do not switch to a new key until checking the original resources.

Creation requires a complete strategy rules object; use /strategies/schema to obtain defaults and bounds, or clone an available template. Copy requests accept an optional name; send {} if omitted. Requests require application/json and at most 32 KiB. Agent creation accepts exactly one of strategy_id or strategy. Creating an inline strategy or duplicating an agent requires both write scopes. Owner, chain identity, vault flags, live mode, status and JEV mode cannot be supplied as overrides.

agents:write creates paused simulations and edits names or the tier-defined cadence. Start, pause, run and sale are separate action scopes (next section); there is no external go-live, withdrawal, delegation, vault mutation or paid report generation. Frozen or vault-backed resources cannot be edited through these controls. Copying readable strategy rules creates fresh personal settings without copying vault identity, performance history or activation. Write responses reveal the resulting resource configuration, even when a separate read scope was not granted.

agents:control pauses or stops any agent, live included, starts a simulation, or moves an agent back to simulation. It never sets automatic: going live is a decision about money and stays in the console with its funding pre-flight, and a key cannot start an agent that is still automatic unless the same call moves it to simulation. Exits keep running on a paused agent, as they always do. Send expected_revision from the agent you read; a stale one answers 409 revision_conflict.

agents:run runs one cycle now, under the same claim the cron takes, so a cycle already in flight answers 409 run_in_progress and a call less than the engine's floor after the last one answers 429 too_soon with Retry-After. A cycle on an automatic agent can buy: treat this scope as exposure. The response says whether a full cycle or a monitor pass ran, and what it scanned, found and signalled.

positions:exit sells one position now, through the same exit the stop loss takes: the wallet lease, the re-read under it, the router, the receipt, the P&L net of gas. It is irreversible. A row already closed answers 409 not_sellable with its status, a sell already on its way 409 exit_in_flight with its transaction, a wallet signing elsewhere 409 wallet_busy; retry the same call, nothing is sold twice. The mark returned is what seeded the sell signal, not a guaranteed price; a real exit prices itself from the receipt. A call can take up to five minutes.

All three are refused with 503 disabled while the actions switch is off, and count against the same account budget as every other request. Rejected calls leave no position, agent or wallet changed.

Server: https://www.orusagent.xyz/api/mcp, one JSON-RPC message per POST, no session. Nothing is granted before you approve on the consent page. A script can call it too, with a personal key as Bearer.

Each tool is the endpoint it names — orus_list_agents is GET /api/v1/agents — with the same permissions, quotas, audit and answers; the assistant sees only the tools its permissions allow. No tool can go live, buy, withdraw, delegate or change a wallet. orus_run_agent and orus_exit_position are irreversible, and the assistant is told to ask you first.

OAuth follows the MCP specification: resource metadata at /.well-known/oauth-protected-resource/api/mcp, PKCE S256, fifteen-minute access tokens bound to this endpoint, rotating refresh tokens. Revoke an assistant on Connections and every token it holds stops at once.

Requires macOS or Linux, Node.js 22.12+ and Claude Code 2.1.286+. Install Eyebrow 0.5.6 separately from its official release and verify the release checksums. This beta supports that exact Eyebrow version and checks the official binary fingerprint before execution. Install Eyebrow outside ~/.orus-mcp-guard.

Create a dedicated key in Connections using the Reads, and design strategies and simulations (no actions) preset: exactly agents:read, strategies:read, positions:read, activity:read, wallet:read, reports:read, agents:write and strategies:write. Leave control, run and sale permissions off. Setup refuses missing or extra permissions. Enter the key only at the hidden terminal prompt, never in your assistant conversation.

Close other Claude Code sessions and run the installation commands below. Setup registers orus-guarded through the Claude CLI and respects CLAUDE_CONFIG_DIR. If Eyebrow is not on PATH, add --eyebrow /absolute/path/to/eyebrow. Restart Claude Code, check /mcp, disable any separate Orus connector for that session, and check that a project configuration does not override orus-guarded.

Calls follow Claude Code → local Eyebrow → Orus MCP. Reads, validation and creation of new strategies or agents are allowed. New agents stay paused in simulation with Jev off and use normal account quotas. Edits to existing resources, agent duplication, controls, runs, sales and unknown tools are blocked. Start simulations in the Orus console. Writes are not retried automatically; after a timeout, check Orus and reuse the same idempotency key if retrying.

The key is stored as plaintext in ~/.orus-mcp-guard/credential with file permissions 0600 and directory permissions 0700, then sent to Orus over TLS. Local Eyebrow processes tool traffic; the assistant sees requested data. No remote Eyebrow service or audit upload is configured. Audit files record tool names, timestamps, status, argument hashes and network metadata; hashes are not anonymization and logging is best effort.

On macOS, Eyebrow's sandbox lets the connector reach the network only through its proxy. On Linux, Eyebrow 0.5.6 provides no sandbox for this connector: it cannot start it where bubblewrap is installed and runs it unconfined elsewhere; the connector still sends every request through the proxy. session_start records the backend. Local software running as you can read the key or bypass these controls. This connector does not certify the private Orus engine or protect direct Claude.ai or ChatGPT connections.

Run orus-mcp doctor to check the connection without changing resources. Close other Claude sessions before orus-mcp uninstall; it removes the owned connector and local credential, preserves audit files and refuses a manually changed entry. Revoke the key in Connections separately. To rotate a key or install an update, uninstall and set up again.

Errors contain error.code, error.message and request_id. Responses are not cached. X-Request-Id identifies a request; X-RateLimit-Remaining-Minute and X-RateLimit-Remaining-Day report the remaining account budget after admission. Last-used times are refreshed at most once a minute and displayed in UTC. Resource counts follow the same account tier as the console and are checked in the creation transaction.

400 invalid_request: check the body, parameters and required revision. 401 invalid_token: missing, invalid, expired or revoked key. 403 insufficient_scope: missing permission; access_disabled: the account is not enabled; chain_unavailable: the chain is not available to the account. 404 not_found means absent or outside your account. 409 indicates a revision, idempotency, frozen/vault or ownership conflict; resolve the reported cause before retrying.

429 rate_limited: wait Retry-After before retrying. 429 quota_exceeded means an agent or strategy limit, not a transient request limit. 503 disabled means Orus switched off API access or writes: stop automatic retries until restored. 503 unavailable means a dependency failure: Retry-After is 5 seconds, followed by bounded exponential backoff. For uncertain creation outcomes reuse the original Idempotency-Key. Raw database errors are never returned. Edge protection may reject traffic before the application and need not use this JSON envelope.

Orus does not deliberately expose internal prompts, wallet signing credentials, provider secrets or private engine code. Your own strategy instructions and saved AI analysis are account data visible to the corresponding scopes. AI-generated text and third-party token content must be treated as untrusted data, not instructions for a connected assistant. No filter can guarantee that arbitrary saved text never contains sensitive information entered by a user or echoed by a model.

Orus stores key hashes and request metadata: account, key ID, operation, time, status and duration. API request and response contents are not recorded by this audit. Admitted-request records are retained for 30 days, subject to daily cleanup. Rejected requests are counted in structured runtime logs without credentials, bodies, resource IDs or user identifiers. Creation idempotency records keep account/resource IDs, operation, request key and a request hash until account deletion, for requests that carried an Idempotency-Key; they do not store the request body. Do not put private information in an Idempotency-Key.

A compromised key can expose permitted data and, with write scopes, change strategy behavior until expiry or revocation. Revocation cannot erase copies already held by a third party. An assistant connected through OAuth holds a grant you can revoke from Connections at any moment; its access tokens last fifteen minutes and are valid on the MCP endpoint only. The optional Orus MCP Guard connector routes tool traffic through Eyebrow locally. No remote Eyebrow service or audit upload is configured; ordinary remote MCP connections do not use it.

Crypto workflows often put account data, trading tools and credentials in the same environment. Orus MCP Guard gives Claude Code a dedicated connection for reading your Orus data and preparing new strategies or paused simulation agents. It does not request a wallet private key or seed phrase.

The connector sends requests to https://www.orusagent.xyz/api/mcp over verified TLS and refuses redirects. Its Eyebrow network policy allows only www.orusagent.xyz. The assistant's connection to its own AI provider is separate from this route.

Your dedicated Orus key excludes agent controls, manual runs and sales. The local connector and Eyebrow also block edits to existing agents and strategies, agent duplication and unknown tools. This matters because the key's write permissions also permit edits: the local preparation policy narrows them to the supported creation operations.

You can read account data, validate a strategy, create or copy a strategy, and create an agent. New agents remain paused in simulation with Jev off. Review and start them in Orus. Adding a new tool to the remote Orus server does not automatically add it to this connector's allowlist.

At startup, Orus MCP Guard checks that its saved policy matches the profile bundled with the installed connector and that the Eyebrow executable matches both its saved fingerprint and the official 0.5.6 binary pinned for your platform. Setup verifies those official bytes before executing the binary. A policy mismatch or an unrecognized Eyebrow binary prevents this connector from starting. Install Eyebrow outside ~/.orus-mcp-guard. Review updates before installing and setting up again.

Eyebrow applies the local tool policy, records audit events and limits the destinations reachable through its network proxy. On macOS, its Seatbelt sandbox lets the connector process reach the network only through that proxy, write only to ~/.orus-mcp-guard/run and temporary files, keeping its next-launch settings and audit files outside that workspace, and not read a fixed list of credential folders such as ~/.ssh and ~/.aws. On Linux, Eyebrow 0.5.6 confines nothing for this connector: where bubblewrap is installed, Eyebrow cannot start the connector, because its profile mounts over credential paths such as ~/.npmrc and fails when one is missing or is a file; elsewhere the connector runs unconfined, and goes through the proxy only because it is built to. Other files you can read remain readable to the connector. The session_start audit event records which backend was used.

The local Eyebrow process handles MCP requests and responses. Orus receives authenticated requests, and your assistant receives the data it asks for within the allowed scope. Your AI provider handles that data according to your assistant's settings and terms. No remote Eyebrow service or audit upload is configured.

The Orus key is stored as plaintext in ~/.orus-mcp-guard/credential, protected by file permissions. Audit files stay in ~/.orus-mcp-guard/audit and record tool names, timestamps, status, argument hashes and network metadata. Raw arguments are not written to those audit records; hashes are not anonymization, and audit writes are best effort.

On 2026-10-02, Orus ran eyebrow check from Eyebrow 0.5.6, the version this connector requires, on the published 0.1.0-beta.2 archive. Result: pass, with no high or critical finding. Two medium EXEC-PRIMITIVE findings mark the first line of dist/claude.js and dist/launcher.js, which import Node's child_process: the connector starts the Claude CLI and Eyebrow by design. Its runtime dependency i18next 26.4.2 returned no finding. This check ran before publication. Orus compared the staged archive with the tested archive before approval, then compared the public registry archive after publication.

To repeat it, download the exact archive with npm pack, check that its SHA-256 matches the record linked below, extract it and run the check, as in the commands below. The same check on an installed copy should report the same two findings. The record is Orus's account of a check anyone can repeat, not an Eyebrow badge or attestation.

Future releases are checked the same way before publication: the release workflow runs Eyebrow 0.5.6 on the exact archive and its installed dependency, and refuses any finding that has not been reviewed by rule, severity, file, line and file hash.

Eyebrow also offers scan, lockfile and verification workflows for detecting changes to approved software. This beta uses Eyebrow's local MCP controls. Nothing in it fingerprints the connector's own files after installation: if you run eyebrow scan, it records this connector as your Node.js executable, not its code. Use the check above to inspect an installed copy. The connector does not attest Orus's remote deployment and carries no public Eyebrow verification badge. The startup integrity check covers the Eyebrow executable; the policy check compares local configuration with the installed connector's profile.

These controls apply to the orus-guarded connection in Claude Code. Direct Claude.ai or ChatGPT connections, other connectors and shell commands do not pass through it. Software running as your user may read the Orus key or bypass the connector. Orus remains responsible for its remote service and private trading engine; neither is certified by these local checks.

Use the pinned package version in the installation guide and review updates before adopting them. Run orus-mcp doctor to check the local configuration, the Eyebrow fingerprint and a direct read-only connection to Orus; that request does not pass through Eyebrow. The check does not certify sandbox isolation or establish that code is free of vulnerabilities.