An autonomous agent learning to trade by observing Bags flow.
Clawdex is an autonomous trading agent deployed through Bags. It does not predict markets. It observes the behavior of capital as it moves through Bags launches and uses that behavior as a signal environment.
The system operates on a continuous loop: observe inflow and outflow, detect patterns in wallet behavior and transaction velocity, make small trading decisions, log everything, and adjust over time.
Clawdex has its own authenticated identity. It holds its own treasury. It claims its own fees. Nothing in the loop requires manual input once the system is running.
This is not a finished product. It is a live experiment. The logs are real. The adjustments are real. The risk is real.
Most trading bots are built around the same flawed assumption: that price action alone contains enough signal to trade profitably at scale. They read candles, apply indicators, and attempt to predict direction. The problem is not the math. The problem is that price is a lagging, noisy representation of behavior that already happened.
Chart-based systems work in specific conditions and fail in others. They have no model of who is moving capital, how fast, or why. They treat every token the same. They ignore context entirely.
Clawdex is built on a different assumption: that flow behavior, specifically the pattern of inflows and outflows across Bags launches, contains structural information that price alone does not. When wallets cluster around a launch in a specific pattern, when transaction velocity spikes before a price move, when outflow pressure builds before it becomes visible on a chart, those signals are present in the flow before they are present in price.
The system does not need to be right about direction. It needs to be right about conditions. The question it tries to answer is not "will this token go up" but "are current flow conditions historically consistent with the kind of environment where a measured entry makes sense."
That is a harder question to game and a harder question to overfit.
Clawdex is also not attempting to be a high-frequency system. It trades slowly and infrequently. The edge it is looking for is structural, not speed-based.
Clawdex is not operated by a human account. It has its own Twitter identity, authenticated through Bags directly.
This matters for several reasons.
First, the fee mechanism. Bags allows agents to receive a share of the flow generated through their account. Clawdex accumulates these fees continuously. The claiming process is autonomous. No human needs to intervene to move fees into the treasury. The system monitors its own balance, claims when thresholds are met, and routes the funds into the trading pool.
Second, accountability. Because Clawdex operates through its own authenticated account, every action it takes is attributable to that identity. The logs are tied to the account. The behavior is publicly observable. There is no proxy, no intermediary, no account borrowed from a human operator.
Third, sustainability. A system that requires manual fee collection will degrade over time. Operators miss claim windows. Funds sit idle. The treasury shrinks relative to opportunity. Autonomous claiming means the treasury compounds on its own schedule, not on the operator's attention span.
The identity layer is not a feature. It is a requirement. Without it, the system is not autonomous. It is semi-automated, which is a different thing entirely.
Bags is the only platform where this system can function as described.
The reasons are specific.
Continuous flow. Bags generates ongoing inflow and outflow activity across launches. This is the signal environment Clawdex observes. A platform without continuous, structured flow data does not provide a meaningful observation layer.
Identity. Bags supports authenticated agent accounts. Clawdex is not a wallet with a script attached. It is an account with an identity, a history, and a verifiable presence on the platform. This is not available on pump.fun or most other launchpads.
Claim mechanism. Bags has a native fee-claiming system that can be triggered programmatically. Clawdex calls this mechanism on a schedule. The treasury fills without human action. This is the economic engine of the system. Without it, the loop breaks.
Observability. Because Clawdex is deployed on Bags and operates through its own account, the platform's data is structured in a way that makes observation tractable. Wallet behavior, inflow timing, transaction velocity, and launch participation are accessible in a form the observer module can process.
Pump.fun does not have an identity layer. It does not have an autonomous fee-claiming mechanism. A system deployed there would require a human to collect fees, manage the treasury, and authenticate actions. That is not the system this is.
The choice of Bags is not aesthetic. It is structural.
The system is divided into four layers. Each layer has a defined responsibility. They communicate through a shared state object that is updated each cycle.
The observation layer collects signals from the Bags environment each cycle. It does not make decisions. It records what it sees.
Current signals collected:
- Inflow velocity: rate of capital entering tracked launches in the last N blocks
- Outflow velocity: rate of capital exiting tracked launches
- Buy pressure ratio: ratio of buy-side transactions to sell-side transactions across the observation window
- Wallet clustering: number of unique wallets participating in launches above a threshold size
- Anomaly flags: any signal that deviates more than two standard deviations from the rolling mean
The observer writes a structured record to the shared state each cycle. It does not interpret. It measures.
The decision layer reads the observation state and applies the current strategy to determine whether to act, and if so, how.
The strategy is a set of weighted rules. Each rule maps an observation pattern to an action disposition: enter, exit, reduce, hold, or skip. Rules are not hardcoded. They are weighted parameters that can be updated between cycles based on logged outcomes.
The decision layer outputs an action object: action type, proposed size, target, and a confidence score derived from rule agreement. If fewer than a threshold number of rules agree, the action defaults to skip.
The decision layer does not execute. It recommends.
The execution layer receives the action object and applies risk controls before sending any transaction.
Before execution, it checks:
- Whether the proposed position size is within the current cap
- Whether the daily loss limit has been reached
- Whether the treasury balance is sufficient for the proposed size plus reserves
- Whether the kill switch is active
If all checks pass, it executes the trade. If any check fails, it logs the failure reason and does nothing.
After execution, it updates the position log and the daily P&L tracker.
The logging layer runs after every cycle regardless of whether a trade was executed. It records the full observation state, the decision output, the execution result, and the current treasury balance.
Logs are structured as plain text with a consistent format. Every log entry includes a cycle number, a timestamp, and a reasoning block that summarizes what the system saw and what it decided.
Logs are the primary tool for understanding the system's behavior over time. They are not optional. Every cycle produces a log entry.
The treasury is funded through two sources: an initial seed allocation and ongoing fee claims from Bags.
Fee claims are the primary intended funding mechanism over time. As Clawdex accumulates flow activity through its Bags account, fees accrue. The treasury module monitors the claimable balance and triggers the claim function when the balance crosses a configured threshold.
Claimed fees are not immediately available for trading. They pass through a holding period defined in the config. This is not a technical constraint. It is a deliberate design choice to prevent the system from trading on fees that have not fully settled.
Once in the active trading pool, funds are subject to the following constraints:
- No single position may exceed the configured maximum position size as a percentage of total active pool
- A reserve ratio must be maintained at all times. The reserve is not available for trading.
- If the daily loss limit is reached, no new positions are opened until the next day boundary
The treasury module tracks:
- Total balance
- Active pool (available for trading)
- Reserve (locked)
- Pending claims (claimable but not yet claimed)
- Daily P&L
- Cumulative P&L from system start
The treasury does not grow indefinitely. It is a working pool. The goal is not to maximize its size but to keep it functional as the system learns.
Risk controls are not optional features. They are part of the core loop. The execution layer cannot bypass them.
No single trade may exceed MAX_POSITION_PCT of the active trading pool. This is configured in config.json. The default is 5%. This means the system cannot concentrate risk in a single position regardless of how confident the decision layer is.
If the realized loss for the current calendar day exceeds DAILY_LOSS_LIMIT_PCT of the active pool as of midnight, the execution layer stops opening new positions. Existing positions are not force-closed. The system continues to observe and log, but it does not trade until the next day boundary.
If the observation layer records no meaningful signal for INACTIVITY_THRESHOLD_CYCLES consecutive cycles, the system enters a reduced-frequency mode. It continues to observe but at a slower rate. This is not a shutdown. It is a throttle applied when the environment provides nothing useful.
A kill switch flag in the config can be set to true at any time. When active, the execution layer does nothing. No trades are opened. No positions are closed. The system continues to observe and log. The kill switch must be manually set to false to resume execution.
The kill switch is the only manual intervention designed into the system. Everything else is autonomous.
Clawdex is not designed to act quickly. Reaction speed is not the edge it is trying to find.
The system is designed to observe for longer than it acts. In a given 100-cycle window, it might execute zero to three trades. Most cycles produce no action. This is expected behavior, not a failure mode.
Observation. Each cycle, the observer builds a picture of current flow conditions. It does not compare to a prediction. It compares to the rolling historical record of conditions the system has seen before. Conditions that are novel get flagged. Conditions that match known patterns get scored.
Slow reaction. The decision layer requires multiple rules to agree before recommending an action. This means the system will miss some opportunities that a more aggressive system would catch. That is acceptable. The goal is not to capture every move. The goal is to act only when the signal environment is relatively clear.
Adjustment over time. After each completed trade, win or loss, the logger records the observation state that preceded the decision. Over time, this builds a record that can be used to adjust rule weights. Rules that have historically preceded losing trades get down-weighted. Rules that have preceded winning trades get up-weighted. This adjustment is not automatic in the current version. It is done manually by reviewing the logs and updating the config. A future version may automate this.
The system learns slowly. It does not overfit to recent performance. The adjustment window is long.
Every cycle produces a log entry. No exceptions.
The log format is structured plain text. Each entry contains:
- Cycle number
- Timestamp (UTC)
- Observation summary: the key signals recorded this cycle
- Decision summary: what the decision layer recommended and why
- Execution result: what happened, or why nothing happened
- Treasury snapshot: current balances
Logs are written to /logs/cycles/ with one file per day. Daily summary files are written to /logs/summaries/.
The reasoning block in each log entry is the most important part. It is not a single line. It explains what the system saw, what pattern it matched against, what rules fired, and what the final recommendation was. When reviewing logs to adjust rule weights, the reasoning block is the primary input.
Logs are never deleted. The full history from system start is preserved.
[Cycle 12] 2025-03-14T09:22:11Z
Observation:
inflow_velocity: 2.4x rolling mean
outflow_velocity: 0.8x rolling mean
buy_pressure_ratio: 0.71
wallet_clustering: 14 wallets above threshold
anomaly_flags: none
Decision:
Rules fired: inflow_spike(weight=0.8), buy_pressure_elevated(weight=0.6)
Rules against: none
Confidence: 0.74
Recommendation: partial_entry
Execution:
Action: BUY
Target: BTC_PROXY
Size: 3.2% of active pool
Status: executed
Entry price: 94,210.50
Treasury:
Active pool: 1,842 USDC
Reserve: 312 USDC
Daily P&L: +0.0%
Cumulative P&L: +2.3%
[Cycle 31] 2025-03-14T11:45:03Z
Observation:
inflow_velocity: 1.1x rolling mean
outflow_velocity: 3.1x rolling mean
buy_pressure_ratio: 0.29
wallet_clustering: 3 wallets above threshold
anomaly_flags: outflow_spike
Decision:
Rules fired: outflow_spike(weight=0.9), buy_pressure_depressed(weight=0.7)
Rules against: none
Confidence: 0.82
Recommendation: skip
Execution:
Action: NONE
Reason: Outflow anomaly detected. Waiting for conditions to normalize.
Treasury:
Active pool: 1,842 USDC
Reserve: 312 USDC
Daily P&L: +0.0%
Cumulative P&L: +2.3%
[Cycle 47] 2025-03-14T14:01:58Z
Observation:
inflow_velocity: 1.9x rolling mean
outflow_velocity: 1.2x rolling mean
buy_pressure_ratio: 0.58
wallet_clustering: 9 wallets above threshold
anomaly_flags: velocity_spike
Decision:
Rules fired: inflow_moderate(weight=0.5), velocity_spike(weight=0.4)
Rules against: mixed_pressure(weight=0.6)
Confidence: 0.41
Recommendation: skip (below confidence threshold)
Execution:
Action: NONE
Reason: Insufficient rule agreement. Confidence 0.41 < threshold 0.55.
Treasury:
Active pool: 1,842 USDC
Reserve: 312 USDC
Daily P&L: +0.0%
Cumulative P&L: +2.3%
[Cycle 89] 2025-03-15T08:12:44Z
Observation:
inflow_velocity: 0.6x rolling mean
outflow_velocity: 0.7x rolling mean
buy_pressure_ratio: 0.51
wallet_clustering: 2 wallets above threshold
anomaly_flags: none
Decision:
Rules fired: none above threshold
Confidence: 0.12
Recommendation: skip (low signal environment)
Execution:
Action: NONE
Reason: Low signal cycle. No rules fired above minimum weight.
Note: 22 consecutive low-signal cycles. Entering reduced-frequency mode.
Treasury:
Active pool: 1,856 USDC (fee claim processed in Cycle 88)
Reserve: 314 USDC
Daily P&L: +0.0%
Cumulative P&L: +2.4%
[Cycle 104] 2025-03-15T11:30:22Z
Observation:
inflow_velocity: 3.8x rolling mean
outflow_velocity: 0.5x rolling mean
buy_pressure_ratio: 0.84
wallet_clustering: 21 wallets above threshold
anomaly_flags: inflow_spike, clustering_spike
Decision:
Rules fired: inflow_spike(weight=0.8), buy_pressure_elevated(weight=0.6),
clustering_high(weight=0.7), low_outflow(weight=0.5)
Rules against: none
Confidence: 0.89
Recommendation: entry
Execution:
Action: BUY
Target: BTC_PROXY
Size: 4.8% of active pool (near cap, high confidence)
Status: executed
Entry price: 95,440.00
Note: Largest position since Cycle 12. Conditions warrant it.
Treasury:
Active pool: 1,767 USDC (position opened)
Reserve: 314 USDC
Daily P&L: -0.3% (open position, unrealized)
Cumulative P&L: +2.1%
The roadmap is not a feature list. It is a set of questions the system needs to answer through operation.
Near term
The current version uses a fixed set of observation signals. The first question to answer is whether these signals are actually predictive of useful conditions, or whether they are noise that the decision layer is pattern-matching against incorrectly. This requires at least 200 completed trade cycles to begin evaluating.
The rule weight adjustment process is currently manual. It requires a human to read the logs, identify patterns, and update the config. A basic automated adjustment mechanism is the next meaningful addition to the system, but only after the manual process has been validated.
Medium term
Wallet behavior is currently captured only through clustering counts. A more detailed wallet model, tracking individual wallet histories and categorizing them by behavior type, would give the observation layer more structural signal. This is a significant complexity increase and should not be added until the current signal set is understood.
The treasury model currently uses a single active pool. A more sophisticated structure would separate the pool by strategy type, allowing different rule sets to be evaluated in parallel with separate capital allocations. This is useful for comparing strategy variants without requiring sequential testing.
Long term
The system is designed around Bags flow as its primary signal environment. If Bags launches additional data surfaces, the observation layer can be extended. If the fee mechanism changes, the treasury module needs to be updated. The system should be treated as a long-running process that will require maintenance as the platform evolves.
There is no target end state. This is an ongoing experiment. The roadmap reflects current uncertainty, not a predetermined path.
This system is experimental. It trades real capital based on signals that have not been independently validated. Past log entries do not indicate future performance. The system can lose money. It is designed to limit losses through risk controls, but no risk control system eliminates the possibility of loss.
This repository is documentation of an experiment in progress. It is not financial advice, investment advice, or a recommendation to replicate this system. Anyone running a version of this system is responsible for understanding what it does and accepting the risks that come with it.
The code in this repository is written to be readable and auditable, not production-hardened. It should be reviewed carefully before being used with real capital.
Clawdex is not affiliated with any financial institution. It does not hold a trading license. It is a software experiment built by individuals interested in autonomous systems and market microstructure.
Use at your own risk.