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 Robinhood Chain — an Arbitrum Nitro L2, chain id 4663, gas paid in ETH. Two chain facts shape everything downstream. 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 row 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 binds one strategy to a cadence, an execution mode and, optionally, a wallet. The cron fires every minute and ticks every thirty seconds inside it; an agent only runs when its own frequency has elapsed, and each run is claimed before it starts — the last-run timestamp is bumped under an optimistic lock — so a run that overruns its interval is never started twice by two concurrent ticks.

Two agents on two strategy rows 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.

Manual, where a signal waits for a human to execute it, is the desk operator's mode. A user's agent is either simulating or automatic.

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 for an exact amount, and call those routers. It has no rule for a transfer, for another chain, or for an approval to anyone else; a request outside it is refused by Privy before it is signed. The console records the delegation only after asking Privy that the signer is really there, and you can turn it off at any time. While it is off, an automatic agent can neither open nor close positions.

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 house desk's own agents trade from a key the operator holds; a user's agent never touches it.

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 — by the same rules in the API and in a database check.

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.

Nothing on the desk is a mock. What you read is the same database the engine writes to, on the same fifteen-second poll the operator sees.

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 that day's fees is paid out as prizes to the three best net P&L, and the rest buys back $ORUS.

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, the two features that spend a model call rather than a database row. 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.

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 — it lives in the database, and the parts of it that are public are on /live and /leaderboard because we chose to publish them.

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. The market layer also supplies candles, earliest-trade samples and execution quotes. Chain reads and transaction broadcasting use the chain RPC.

Every provider sits behind one market module. The engine imports that module and nothing else, so replacing a provider means reimplementing one function, and every filter is re-checked locally even when the screener already applied it — a provider change can never silently weaken a rule.

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 Orus screener narrows the chain's token list under the thresholds it can enforce server-side — 24-hour volume, liquidity, market cap, trade count. That is the cheap pass, and it exists to keep the expensive one small. The native sentinel and the two quote assets, WETH and USDG, are dropped here: the screener lists them as tokens, but they are not candidates.

Each survivor gets one token-details read, which returns the observations the filter and chart analyser need in a single response. Details are shared across the agents running in one process, so nine agents screening the same chain cost one call per token, not nine.

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. The value is cached, so the check costs one request per token, once.

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 token leaves the radar for one of three reasons, and each is recorded: it dropped out of the scan, its entry window expired, 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, 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.

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 the analyser takes the all-time high from the details it already has, pulls five-minute candles only when that high moved or no crossing is stored yet, and measures the current price against it.

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. The lookups are batched, two per run rather than two per candidate.

Once the signal row exists the radar entry moves to signal-generated and the desk operator is notified on Telegram. Sell signals are not produced here; they come from the position monitor when an exit condition fires.

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: every entry in a batch is re-priced from one refresh at execution time, then once more on the price the router's own buy quote implies, and a token that has bounced back above the threshold on either expires its signal with a dip-recovered event instead of being bought.

With Jev enabled for entries, an eligible proposal also needs its contextual approval in the same cycle. Jev cannot restore a candidate rejected by the strategy. Its approval 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.

ETH is wrapped before a buy, because the router quotes ERC-20 legs only and rejects the native address. Selling an ERC-20 needs an approval first. The Orus execution layer compares available swap routes, signs the selected transaction and broadcasts it to the chain. The quote is taken before the wrap, so a pair with no route costs nothing.

The position row is written before the transaction is broadcast, so a confirmed swap can never end up untracked; if the swap fails, the placeholder is deleted. The amount received is read from the transaction's transfer logs, not from the quote, and the entry price is the fill price in every mode — what was spent over what was received. The oracle price the signal was raised on stays on the signal. Multipliers, the stop and the target are all measured from the fill, so a fill a few percent above the oracle is drawdown the position carries from the start.

An exit sells what the position holds, capped at the wallet balance for fee-on-transfer shortfalls — never the wallet's whole balance, which may hold the same token for another agent or for the operator. Every signed sequence on a wallet — a buy's wrap, approve and swap; a sell's approve, swap and unwrap — runs under a lease on that wallet held in the database, so two processes never sign against one nonce, and a position is re-read under the lease before it is sold.

At the end of every run, 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 Jev enabled for take-profit exits, that proposed exit needs its contextual approval. 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 run one at a time per wallet — they share a nonce, so concurrent swaps would collide. Agents on different wallets run concurrently. 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, so a stuck exit still occupies a slot rather than quietly freeing one. 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 running two strategy rows. 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 by the same rule in the API and in the database.

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 tape polls every eight seconds; the aggregates are computed over the whole closed book and cached for forty-five seconds.

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 agent is briefed on exactly what this page describes: the pipeline and what each step refuses, the limits the engine holds itself to, every field with its meaning and its bounds, and the desk's own strategies with the results they have produced — as evidence, not as instructions. It is told to explain the three to five choices that matter, to say what the strategy will and will not catch, and to refuse a wish the engine cannot grant rather than invent a field for it. It answers in the language you write in.

Nothing the agent says reaches the database 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.

It is immediate — the request stays open while the swap confirms, which is seconds on a good day and a couple of minutes on a slow one — and it is safe alongside the cron because of the wallet lease: the sale takes the lease on the wallet, re-reads the position under it, and never signs against a nonce a running cycle is using nor sells tokens a cycle has just sold. A wallet that is still busy after forty-five seconds answers wallet busy, and the button offers a retry rather than a promise to sell 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; the global kill switch does not stop an exit, and neither does the account's trading switch — a way out is never switched off.

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. Both are generated from the same table and the same constants as this page, in the same build, so they cannot say something this page does not.

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.

Jev is an evaluation model from TypeSafe AI, available through Vercel AI Gateway. 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. Only an approval can continue to execution, where 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 operator's Manual mode leaves entry execution by hand and can review proposed take-profit exits.

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.

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. 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. A condition that cannot be established may leave an entry waiting until its window expires.

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. Missing or contradictory evidence does not authorize the delegated exit.

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 missing data, a timeout, unavailable service or a cycle's time budget, it never grants approval by default. Delegated entries wait within their existing window; delegated take profits remain open for a later review. 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.

Orus supplies a recent sequence of buys and sells with times, amounts and pseudonymous participant identifiers, a sample of participants' holdings and cumulative purchases and sales, 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.