Sentinel turns a failed memecoin trading bot into a lesson about exits

The difficult part is not always finding a signal

Trading-bot projects often focus on entry logic: detect a new token, score it, decide whether to buy, then automate the trade. Sentinel documents a more uncomfortable builder problem. An exit rule can look sound in code and still fail in the market it is meant to protect.

Sentinel is a complete automated trading system for pump.fun memecoins, but its stated purpose is educational research rather than deploying a profitable strategy. The project was run on live data in paper mode, meaning simulated execution rather than trades with real capital. Its README reports 93 real trades and says every tested configuration had negative expectancy, or a negative average outcome over repeated trades.

That makes this repository useful to developers building market-data systems, simulation tools, and risk controls. It is also useful to anyone tempted to treat a stop-loss as a guaranteed floor. Sentinel's post-mortem argues that, for the tokens it studied, that assumption was the central failure.

A stop price is not necessarily an executable price

The repository highlights one result in particular. Sentinel set a hard stop at a loss of 18%, then logged the on-chain price path for each exit. The reported median actual fill was a loss of 84%.

The distinction matters. A stop-loss trigger tells a system when to attempt a sale. It does not ensure that buyers exist at that price. According to the project, pump.fun coins could gap from above the trigger to 80% down or worse in a single tick. With no liquidity at the stop price, an order cannot fill where the rule expected.

Sentinel frames this as structural rather than a parameter-tuning issue. The README says a tighter filter, a tighter stop, and a take-profit ladder each failed to change the negative outcome in the observed data. That is a practical research lesson: before optimizing thresholds or adding a more elaborate model, test whether the market mechanics can honor the assumptions behind the strategy.

The project does not claim to offer financial advice, and it explicitly warns readers not to use it with a funded wallet. No real capital was traded by this code, according to the README.

A pipeline designed to reject most opportunities

Sentinel is organized as a decoupled event-bus pipeline. In this pattern, a component emits an event when work is ready and other components subscribe to it. The design separates ingestion, filtering, decision-making, risk approval, execution, and position management instead of putting the entire trading loop in one service.

A raw token begins at a PumpPortal WebSocket feed, then enters a nursery period. A local, ring-buffer-based cheap filter evaluates signals before the system requests paid enrichment data. The repository says this free pre-filter rejected more than 99% of launches before a paid API call.

Tokens that pass can be enriched using Helius data, including holder information, concentration, and developer behavior. A full filter then applies the rules with paid data available. Claude is used for a structured BUY or SKIP decision, with an hourly ceiling on calls. The next step is not execution, but risk.approve, a hard approval gate that can reduce position size but cannot increase it.

From there, Sentinel uses a paper fill engine and a mechanical positions module. Its exits are rules-driven: the README says no model can hold a position or override a sale. That boundary is a notable implementation choice. It limits the scope of an AI-assisted decision component and keeps position exits deterministic.

Safety constraints are part of the architecture

The repository treats live execution as deliberately difficult to activate. It describes a human-edited LIVE_TRADING constant, a runtime confirmation flag, and a user-provided SOLANA_PRIVATE_KEY as separate requirements. The risk layer also includes hard guards and a database-backed kill switch. In paper mode, the README says the system never signs transactions and does not need a wallet key.

These controls do not make an automated strategy economically sound. Sentinel's own result is that this strategy was not. But they demonstrate a useful separation between evaluating a system and granting it authority to act. For builders working on high-consequence automation, explicit gates, a kill switch, and one-way limits on approval are concrete guardrail patterns.

The project also keeps external-data dependencies behind module boundaries. Helius enrichment is described as sitting behind a seam, while the rest of the pipeline handles the event flow and filtering. That can make it easier to replace a provider or test logic without turning a provider integration into the whole application.

A TypeScript application with a dashboard and database

The main application is TypeScript using ESM and NodeNext, with Node 20 or later required by its package manifest. Express 5 and ws provide the REST and realtime API layer. PostgreSQL is accessed through pg, and the README identifies Supabase as the database deployment option.

The manifest also confirms the Anthropic SDK, Solana's @solana/web3.js, and bs58. The latter two support the gated live-path code described in the README, while the former supports the structured decision step. Vitest is the test runner; the README reports about 330 tests covering pure logic and some live-database tests that are skipped without DATABASE_URL.

There is also a separate Next.js 15 and React 19 dashboard in ui/, intended to show realtime system activity. The supplied repository evidence identifies a report site at https://report.cogdb.xyz/ and points readers to a post-mortem with charts in the repository.

Sentinel's strongest contribution is not a promised edge. It is a candid example of preserving a negative result, exposing the operational assumptions behind it, and leaving behind a system others can inspect. Builders who want to examine that tradeoff can start with the verified repository: MuLIAICHI/sentinel.