Five things
- Self-custody Vault: real funds sit in your own on-chain Vault and only your wallet can withdraw. Claiming, closing and withdrawing still work even if the platform is paused.
- Restricted destinations: the program only lets funds move to DLMM pools, swaps, your own accounts and the fee account (only when fees are claimed); the platform’s execution key has no recipient parameter.
- Multisig and timelock: the upgrade authority sits in a Squads multisig; an audit and verifiable builds are planned before public launch. Fee and cap changes go through a 48-hour timelock.
- Simulated first: every transaction is simulated before sending, and isn’t sent if the simulation fails.
- Public performance: every trade by the official paper Agents is public; see Public performance pages.
Separation of duties
The system splits “judgment”, “authorization”, “signing”, and “reconciliation” into separate processes. Each process has only the database permissions and keys it needs. This isolation is enforced by processes and database roles, not by any piece of code behaving itself.
| Stage | What it can do | What it cannot get |
|---|---|---|
| AI (judgment) | Read data, call market tools, pick a pool from the candidates actually queried this round or do nothing, give management suggestions | Database write access, the authorization key, any private key |
| Rule engine and safety checks | Narrow candidates per the strategy, synthesize ranges, run hard triggers such as stop-loss, check whether pools and tokens are safe | Private keys |
| Authorization (Policy) | Check limits such as amount, number of positions, number of actions, and slippage, and issue single-use execution authorizations; for Vault agents, also issue an on-chain co-signature | Private keys; cannot send transactions itself |
| Execution (keeper) | Execute only authorized actions | The authorization key, so it cannot create its own authorizations; on-chain it cannot move funds anywhere other than the Vault, your wallet, and the fee account |
| Observation | Read the chain only, recording balances and positions | Signing ability |
| Reconciliation | Determine a transaction’s final outcome (confirmed, dropped, reverted) | Signing ability; it can never send transactions |
| Web | Display data; build unsigned transactions for actions you initiate, and after you sign, check them item by item before forwarding | The authorization key, any private key |
What the AI can and cannot do
Each round the AI queries the market and picks from the candidates actually queried that round, or does nothing; within your limits it decides the range shape, width and side (the platform synthesizes the exact price bins); while a position is held it decides whether to keep holding, exit early, reset the range or compound; and it writes a reason for each decision.
It cannot: pick a pool outside this round’s query results or loosen your hard boundaries; deploy beyond the total budget, per-position or position-count limits, or exceed the authorized slippage; write price bins or send transactions directly; block or delay protective exits (stop loss, max hold, a token becoming unsafe, inventory intake over the limit, a close you requested).
When the AI is missing, times out, trips its circuit breaker or produces invalid output, no action is taken that round, and it does not fall back to the top-ranked pool. Protective exits don’t depend on the AI and trigger as usual. The full process is in How it decides.
Boundaries the platform hard-enforces
Most rules of a prompt agent are judged by the agent from your own words, but the following are enforced by a deterministic engine and cannot be changed by the AI:
| Boundary | Notes |
|---|---|
| Total budget | Total deployment across all positions does not exceed it |
| Quote token, named token allowlist / blocklist | Candidates can only come from within this scope |
| Platform safety floor | Excludes honeypots, freezable tokens, tokens with high transfer tax, and so on; if a token becomes unsafe while held, the position is exited immediately |
| Position structure | The layered / banded structure you wrote |
| Maximum range width | At most 60% on one side (widened to match if your own words say wider) |
| Stop-loss and max hold | If you wrote them, they are checked every minute and the position is exited once met; the AI can only exit earlier, not cancel them |
| Backstop stop-loss | If the prompt doesn’t specify a stop-loss, the platform force-exits at a 30% loss; writing your own stop-loss line in the prompt replaces it, and it is not enabled when your own words explicitly say “no stop loss” |
| General settings | Check frequency, max slippage for opens / range resets, swap back, retry count for failed opens, daily action limit |
The authorization layer and safety checks have the final veto over every action. Legacy rule-based strategies still work as “rules execute; the AI only picks pools, holds, or exits early”.
Every transaction is simulated first
Every transaction that moves funds is simulated before sending and isn’t sent if the simulation fails:
- with real funds, the Agent’s transactions are simulated before and after signing;
- Vault deposits and withdrawals, and opening, claiming, exiting and resetting the range on positions in your wallet, are built by the server and simulated before your wallet signs. Before signing, check that what your wallet shows matches what you started on the page.
When a transaction’s outcome is uncertain
After a transaction is sent on-chain, a clear result may not come back. The system’s principle is: a failed send does not mean it was not sent.
- The same signed transaction is rebroadcast repeatedly while it is valid. Its signature does not change, so it lands on-chain at most once; this is not a retry;
- Whether a transaction was dropped by the network, or landed and then reverted in full, is determined only by the reconciliation process, which has no signing ability. Only after confirming there was no change to any funds is it treated as a failure with no side effects, and the next round decides afresh;
- If the outcome still cannot be proven, the action moves to manual review. The system will not blindly resend or re-sign.
While an action is in manual review:
- The timeline and Telegram receive the alert “An on-chain action needs a manual review”, and the top of the agent page states the reason;
- Until the review is complete, this agent opens no new positions, and the positions involved in that action pause automatic actions;
- Other open positions are managed as usual, including stop-loss;
- You can close positions or withdraw yourself at any time in the Funds tab.
When a real-funds agent hasn’t completed a check round for more than 15 minutes, you get an “Agent stopped checking positions” alert stating how long it has been stopped and how many open positions are not being managed automatically. After recovery, another alert says “Agent is running again”. There is also a daily report (“Daily report MM-DD: …”).
Emergency stop and pausing
| Action | Where | Effect |
|---|---|---|
| Emergency stop | Settings → Danger zone → Emergency stop | Immediately stops pool scanning and opening new positions for all agents under the account; stop-loss and exits for existing positions run as usual; execution cannot be turned on in the meantime. Click Lift emergency stop to resume |
| Pause agent | Pause in the top-right corner of the agent page | This agent stops running automatically; click Resume to resume |
| Close all positions | More → Close all positions on the agent page | Exits all positions at the next check, keeps the tokens, opens no new positions, then pauses automatically |
| Pause Vault | “Pause” on the Vault card in the “Funds” tab | Takes effect on-chain: the platform cannot open positions, add liquidity, or swap; closing positions and your withdrawals are unaffected |
| Disable platform keeper | Emergency exit (no platform needed) in the Funds tab | The platform can do nothing with this Vault, including closing positions; only you can act |
Vault security properties
The following are constraints in the Vault program’s code (not externally audited):
- Exits are always available: the owner’s fee claims, position closes, position account closes, and withdrawals do not read any pause flag, and can run when the platform is globally paused, the Vault is paused, or the keeper is disabled or removed.
- Restricted fund destinations: the Vault’s tokens can only flow to DLMM pools (adding liquidity), swap escrow accounts that are emptied within the same instruction, the owner’s own accounts, and the fee account (only when fees are claimed). Keeper instructions have no recipient address parameter at all.
- Two keys: with only the keeper key, an attacker can only close positions, claim fees, and close position accounts; funds stay in the Vault, and no new positions or swaps are possible. If both the keeper key and the platform risk-control key leak, unfavorable opens or swaps within the limits are possible (economic loss), but funds still cannot be moved out.
- Fees only from the balance difference before and after a claim: no amount parameter is accepted and principal is never involved; the rate applied is the lowest of the rate you agreed to when creating the Vault, the platform’s global rate, and the pool’s tier rate, so the platform cannot exceed the cap you agreed to.
- Token admission: platform opens and swaps accept only tokens without a freeze authority (except the issuers’ freeze authority on USDC / USDT), and reject Token-2022 tokens with extensions such as permanent delegate or transfer hooks. Your own exit paths do no token checks.
- Platform governance has a timelock: changes to the fee rate, fee tiers, the fee reimbursement cap, and the reserve cap all go through a 48-hour timelock.
Known limitations:
- The program is upgradeable, and the upgrade authority is the ultimate point of trust. It sits in a Squads multisig. The config admin (fee changes, keeper changes) has been in the same multisig since 2026-10-09. A separate guardian key can only switch on the global pause (which blocks opens, adds and swaps, never exits).
- Meteora DLMM itself is upgradeable. If it changes its interface or disables a pool, closing positions may fail; this is an external dependency.
- Earlier instructions in the same transaction can manipulate the active bin price, so the on-chain per-position limit is only a coarse defense; the main defense is the on-chain co-signature from platform risk control.
Public performance pages
For an executing Agent (paper funds or real funds), the owner can turn on a public performance page from the Agent page (off by default, revocable any time). The three official paper Agents are always public:
| Level | Public performance page |
|---|---|
| Steady | /p/gT2PVfc4N1SBpXQr |
| Balanced | /p/6RZ6Q10MNDzeP_fs |
| Aggressive | /p/Cr2f0Sqm7Tz5q1Zt |
These are the Agents running each level’s current version. When a level is revised, a new official Agent starts and the old page stays up, marked as replaced.
No sign-in needed: net result, realized PnL, fees, win rate, the curve and PnL calendar, every closed and open position (pool, opened at, hold time, principal, PnL, exit reason), and the rules and hard limits in plain words. Real-funds Agents also show the funds address and the signature of every open and close, so you can check them on Solscan yourself. The prompt itself is public only if the owner ticks it; real-funds Agents never show their funds value. The official Agents run on paper funds: fees and fills are estimates, not real returns.
Compliance and current status
- Real-funds execution has been opened by decision of the platform owner, with no per-user amount cap and no manual review: agents activate automatically after a deposit, and withdrawals are executed directly with your wallet’s signature. Each agent runs within the limits written in its own strategy.
- The control attestation required for activation is currently a single global waiver record issued by the platform owner (valid until 2027-09-27). It is not the result of an independent third-party review. After it expires, activation and execution will stop.
- Custody licensing, KYC/AML, client asset segregation, and sanctions list screening are not yet resolved.
- The Vault program has not been externally audited; an external audit and verifiable builds are planned before public launch.
Never send your private key, seed phrase, or sign-in credentials to anyone. Before signing in your wallet, check that the action your wallet shows matches the one you started on the page.