CRYPTO-ONE is a research-oriented crypto trading repository centered on a paired buy/sell transformer stack for 15-minute SOL market structure. The current active model work lives in crypto_one_ft/features/models_september, while the rest of the repository preserves earlier collector, database, wallet, and analytics experiments that fed into the current system design.

python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install -r requirements.txt
python3 start.py

That command path is the fastest clean run from a fresh clone. It executes the built-in configuration check plus the buy-side and sell-side transformer sanity tests that ship with the active model stack.

The active system is organized around a buy model and a sell model that share the same general workflow:

1. Raw 15-minute candles are normalized and enriched with engineered market-structure features.
2. The buy-side builder and sell-side builder convert those candles into hierarchical sequences with auxiliary targets and attention weights.
3. Transformer models score those sequences for timing, expected return, ranking, hazard behavior, and confidence.
4. The realtime loop combines market data, model outputs, and threshold logic to drive live decision support.

The design focus in the active stack is consistency between offline preparation and online inference. The same feature-engineering concepts appear across the builders, evaluators, and live scoring path so the model sees a stable representation of the market in every mode.

crypto_one_ft/features/models_september/transformer_model.py defines the buy-side hierarchical model. Its built-in sanity test shows the intended structure clearly:

• input shape: [batch, minutes, sub_steps, features]
• test configuration: 10 periods x 60 sub-steps x 5 features
• prediction surface: ranking, returns, hazard timing, entry confidence, expected ROI, risk probability, and ROI quantiles

This model is designed for denser intraperiod sequences where the network first learns within-period structure and then reasons across longer history.

crypto_one_ft/features/models_september/transformer_sell.py defines the paired sell model:

• input shape: [batch, periods, feature_groups, features]
• test configuration: 60 bars x 1 feature-group step x 76 features
• prediction surface: setup bins, setup continuous values, ranking, returns, hazard timing, exit confidence, expected ROI, risk probability, and ROI quantiles

This side of the stack places more weight on bar-level context and explicit setup descriptors used to manage exits and post-entry trade behavior.

test_model_performance_both.py is the main junction point between the two models. It loads the paired outputs into one evaluator so thresholding, ranking behavior, and timing signals can be inspected together instead of in isolation.

trading.py is the realtime orchestration layer. It pulls in market data, applies the same general feature-preparation concepts, runs the buy and sell bundles, and then applies decision logic, thresholds, and execution-oriented helpers around those predictions.

The active builders expect a 15-minute aggregated candle dataset with exchange-style OHLCV columns. From there, the stack moves through four layers:

1. Candle normalization prepare_new_kline_dataframe(...) standardizes timestamps, numeric columns, and market-structure fields.
2. Engineered features The builders attach recent-low distance, support/resistance context, linear-fit trend features, directional-volume ratios, and predictive prior columns.
3. Sequence extraction The dataset is converted into attention-weighted temporal windows with auxiliary metadata for training and evaluation.
4. Model scoring The transformer heads produce ranking, return, hazard, confidence, and ROI-oriented outputs that are consumed by evaluation and live logic.

This flow is why the repository is script-heavy: each stage is exposed directly so the data path can be inspected, rerun, or replaced without having to unpack a large framework layer first.

This is the root quick-start path:

python3 start.py

It runs:

• quick_config_test.py
• transformer_model.py
• transformer_sell.py

Use a 15-minute aggregated candle file with the schema expected by the active builders:

python3 crypto_one_ft/features/models_september/feature_builder_15m_buy.py \
  --src /path/to/your_15m_candles.csv \
  --out /path/to/output/buy

python3 crypto_one_ft/features/models_september/feature_builder_15m_sell.py \
  --src /path/to/your_15m_candles.csv \
  --out /path/to/output/sell

The builders expect columns such as:

• open_time
• open
• high
• low
• close
• volume
• quote_asset_volume
• number_of_trades
• taker_buy_base_asset_volume
• taker_buy_quote_asset_volume

python3 crypto_one_ft/features/models_september/train_model.py
python3 crypto_one_ft/features/models_september/train_model_sell.py

These scripts orchestrate the buy and sell training flows for the hierarchical transformer architecture.

python3 crypto_one_ft/features/models_september/test_model_performance_both.py

This evaluator combines the two model paths and is the main entry point for measuring ranking, return, and timing behavior together.

python3 crypto_one_ft/features/models_september/trading.py

The live path is designed around external market data, runtime configuration, and environment-provided credentials. Use .env.example as the starting point for local configuration.

The repository uses environment variables for RPC access, data services, collector infrastructure, and wallet-aware integrations. Start with:

cp .env.example .env

Key groups:

.
├── crypto_one_ft/
│   ├── features/models_september/   # active transformer stack
│   └── legacy/                      # earlier runtime and deployment work
├── legacy/                          # collectors, SQL, analytics, crawler pipeline
├── .env.example
├── requirements.txt
└── start.py

• The active stack is Python-first and organized around explicit scripts rather than a packaged library.
• The repository contains both current model work and preserved historical experiments, so reading by subsystem is more effective than reading by date.
• The quickest way to understand the current architecture is to start with start.py, then open the files in the Active Code Paths table above.