jepeta.
agent api

How do I add a pre-trade risk gate to a Base trading bot?

Put the risk gate before transaction construction or signing: resolve the exact Base token, call a deterministic risk API, validate the schema, and convert the result into explicit stop/review/continue rules. Do not let an LLM free-form its way around missing evidence.

Concept illustration of automated data connections passing through an inspection gate.
Jepeta · Original AI concept illustration; not a product photo or evidence

Key takeaways

  • Gate before signing
  • Exact contract only
  • Schema validation

Where the gate belongs

The gate should run after token identity is known but before funds are committed. That gives it the exact contract address while still allowing a hard stop with no trade side effect.

Keep the gate separate from alpha or price logic. Security screening answers whether execution should proceed under safety policy, not whether the trade is expected to be profitable.

Recommended control flow

Reject malformed addresses, wrong-chain assets, non-200 API responses, and invalid schemas. For V5, require status=VERDICT and a non-null PASS, WARN or BLOCK verdict before applying the risk policy. Treat NO_VERDICT as a stop even when HTTP status is 200. Stop on BLOCK. Send WARN to additional policy checks or human review. Let PASS continue only if slippage, position-size, price, and other trading rules also pass.

Cache cautiously. Token permissions and market conditions can change, so an old verdict should not be treated as durable authorization.

Auditability

Store the token address, decision, key evidence fields, source status, and observation time with the bot's decision log. If a permanent Jepeta evidence page exists, store its canonical URL as an external verification reference.

Keep private execution settings, wallet credentials and raw provider payloads out of public logs. Public snapshot links can document the observation without exposing the bot’s confidential operational data.

Bind the check to the action being considered

A report for token A must not authorize a transaction for token B after a route changes. Immediately before the execution layer proceeds, compare its chain, input/output assets and intended operation with the context that was screened. If that context changed, discard the earlier authorization decision and recheck. The appropriate freshness window depends on the caller’s policy and available evidence; this guide does not invent a universal safe cache lifetime.

AI-assisted review of linked documentation; no independent product benchmark. Screening observations and policy labels do not guarantee token safety.

Practical checklist

  • Gate before signing
  • Exact contract only
  • Schema validation
  • Fail closed
  • Separate risk from alpha
  • Persist timestamped decision evidence

Limitations

This is educational risk-screening content, not investment advice. Token and market conditions can change after any snapshot. A PASS result or negative honeypot signal is not a safety guarantee.

Sources & methodology

Sources reviewed Nov 4, 2026.

Continue reading

Browse all articles