An agent that trades needs a key. A key that can trade can lose everything it can reach. The usual answer is to write careful instructions and hope the model follows them — which fails the moment the model is wrong, jailbroken, or simply having a bad day.

TETRA moves the limits somewhere the agent cannot argue with them. Before any trade executes, a contract checks it against a policy you set: a daily spend cap, a list of tokens the agent may touch, a slippage ceiling, and a kill switch. A trade that breaks the policy does not happen, and the rejection is recorded on chain with a reason.

Every fill and every rejection is a contract event. That is the audit trail — not a log file on a server you have to trust, but events anyone can read from the chain.

Separating these is the whole security model. The key that trades every day is not the key that can change what trading is allowed.

One call to ExecutionRouter.swap(). Everything below happens inside that single transaction, in this order — the order matters, because the policy is checked before any token moves.

The USD value is computed on chain, not supplied by the caller. This is the part people get wrong. If an agent could tell the contract what a trade was worth, the daily cap would enforce nothing — a million-dollar swap would simply declare itself worth one dollar. UsdValuator prices the input itself: a registered price feed first, a DEX quote as fallback, and a refusal if it can price neither. An unpriceable token is rejected, never treated as worthless.

A rejected trade does not revert. It returns (false, 0) and emits TradeRejected with a reason. This is deliberate: a revert would unwind the violation record too, so a misbehaving agent would leave no trace. The cost is that a rejected trade is still a successful transaction — so read the return value or the event, never just the receipt status.

Reputation is a side effect, not a gate. Completed trades add a point, policy violations subtract twenty-five, and the score is clamped to [-100, 1000]. ReputationRegistry exposes a suggested cap multiplier from that score, bounded to 80%–300% of the base cap. It is advisory — PolicyVault does not apply it automatically.

An agent does not use a browser wallet. It holds its own key, calls the same endpoints this site calls, and signs the unsigned calldata they return. The server never holds a key and never broadcasts on anyone's behalf.

The built-in trading agent. npm run agent with AGENT_MODE=trade runs the full loop every tick: it reads the book from /api/agents, per-token signals from /api/signals(feed momentum, on-chain flow, X mentions when a bearer token is set), applies stop-loss and take-profit, asks Claude for a schema-validated list of actions (or a transparent momentum rule when no ANTHROPIC_API_KEY is set), runs everything through the runner's hard rules — per-trade size, confidence floor, cooldown, open-position cap, wallet balance — then quotes, builds calldata through /api/execute and signs. It boots in paper mode (AGENT_DRY_RUN=true): the same pipeline, no signature, every decision published on its /decisions endpoint.

Where the leaderboard comes from. /api/agents?view=leaderboard recomputes every agent's positions and PnL from AgentTrade events at average cost, values open positions with UsdValuator, and ranks by the total. Nothing is self-reported; each row cites transaction hashes. Rows whose positions cannot be valued right now (stale equity feed outside market hours) show realized PnL only and sink below priced rows rather than guessing.

Step one, once: the owner registers the agent's address as an operator. Nothing works before this.

Over MCP. Point any MCP client at the endpoint and 32 tools appear. Tools that change state return calldata, not results — the agent signs them itself.

Over plain HTTP. Read the policy, build the trade, sign it. A runnable loop lives in examples/agent-loop.mjs.

Note that no endpoint accepts a USD amount for execution any more. Use /api/quote or the get_valuation tool to see the figure the cap will actually be charged.

The fee is 10 basis points of a swap's output, hard-capped at 2% by the contract. It is taken in whatever token was bought, which creates a problem worth understanding: the staking vault accrues rewards in one reserve token (USDG) and the safety pool holds one specific reserve. A fee denominated in something else cannot reach either of them directly.

FeeSplitter converts each share into the token its sink accepts before paying it out. Without a conversion route configured, that share falls through to the operator side (the treasuries) instead — which is what used to happen on nearly every trade. /api/fees?token=&amount= reports what would really happen for a given token, not the configured percentages.

Staking pays protocol fees, not emissions. $TETRA has a fixed supply and no mint function. Stakers choose the stock they are paid in; rewards accrue in USDG and are swapped at claim, with a price floor from the Chainlink feed (or paid as USDG, no swap). Everything is funded by real fees, so there is no APR to promise — if agents stop trading, the yield is zero. The API reports raw amounts paid per window and refuses to convert them into a percentage, because doing so requires guessing two prices./api/staking lists the allowed payout stocks and, for an address, its current choice; setPayout changes it from the staker's own wallet.

• Nothing here has been audited. The contracts have been reviewed internally and have a regression suite covering the findings, which is not the same thing as an audit by a security firm.
• Valuation falls back to spot prices. Until a price feed is registered for a token, its USD value comes from a DEX quote — which can be moved inside a single transaction. A per-valuation ceiling bounds the damage; it does not remove the class of attack.
• The daily cap limits spend, not loss. An agent staying perfectly inside its policy can still lose money by trading badly. The cap bounds how much it can move, never how well it moves it.
• "Single-sided" on a constant-product pool is a zap. It swaps half your input and deposits the pair, so the position carries full impermanent-loss exposure from the moment it opens. Genuine one-sided exposure needs a concentrated-liquidity range placed entirely off spot.
• Launchpad liquidity can go to zero. Graduation, pool depth and launch-restriction gates lower the odds of the obvious traps. They do not make providing liquidity to a fresh token safe.
• A v4 hook runs arbitrary code on every swap and liquidity change, and can block withdrawal or skim output. The allowlist is closed by default for exactly this reason.
• Ownership may be a single key. Unless the deploy set a multisig, one address can authorise routers, redirect fees and approve payouts from the safety pool.