AI-скоринг токенів та проектів у мобільних додатках
Кожного тижня запускаються десятки нових токенів. Більшість мають низьку якість, деякі — це чисті афери, а небагато є легітимними проектами. Система скорингу допомагає швидко відфільтрувати очевидних претендентів і розставити пріоритети для аналізу решти.
Параметри скорингу: що ми оцінюємо
Надійна система скорингу охоплює кілька вимірів:
Технологія та розробка:
- GitHub активність: коміти за останні 30/90 днів, кількість контрибюторів, відкриті проблеми
- Якість коду: наявність тестів, звіти про аудит
- Технологічний стек: використовувані блокчейни, стандарти токенів
Команда:
- Перевірені особистості проти анонімних розробників (фактор ризику)
- LinkedIn профілі, публічна історія
- Попередні проекти та їх результати
Токеноміка:
- Розподіл токенів: відсоток, який утримується командою, інвесторами та публікою
- Розпис вестингу: наявність періодів блокування
- Інфляційна/дефляційна модель
- Співвідношення обігового до загального пропозиції
Ринкові метрики:
- Ринкова капіталізація / FDV коефіцієнт (Fully Diluted Valuation)
- Глибина ліквідності: обсяг у DEX пулах
- Розподіл власників: топ-10 власників та їх відсоток пропозиції
Спільнота:
- Послідовники на Twitter та справжня частота залучення
- Активність у Telegram/Discord щодо розміру
Джерела даних
class TokenDataAggregator:
def get_github_metrics(self, repo_url: str) -> dict:
# GitHub API v3
import requests
owner, repo = self._parse_repo_url(repo_url)
headers = {"Authorization": f"token {GITHUB_TOKEN}"}
commits_30d = requests.get(
f"https://api.github.com/repos/{owner}/{repo}/commits",
params={"since": (datetime.now() - timedelta(days=30)).isoformat()},
headers=headers
).json()
contributors = requests.get(
f"https://api.github.com/repos/{owner}/{repo}/contributors",
headers=headers
).json()
return {
"commits_30d": len(commits_30d) if isinstance(commits_30d, list) else 0,
"contributors_count": len(contributors) if isinstance(contributors, list) else 0,
"stars": self._get_repo_stars(owner, repo, headers)
}
def get_onchain_metrics(self, contract_address: str, chain: str) -> dict:
# Moralis API — підтримує ETH, BSC, Polygon та інші
response = requests.get(
f"https://deep-index.moralis.io/api/v2.2/erc20/{contract_address}/owners",
params={"chain": chain, "limit": 10},
headers={"X-API-Key": MORALIS_API_KEY}
)
holders = response.json()
top10_concentration = sum(h["percentage_relative_to_total_supply"]
for h in holders.get("result", [])[:10])
return {"top10_holder_concentration": top10_concentration}
Moralis API агрегує on-chain дані мережі, сумісні з EVM. Covalent API — альтернатива з історичними даними. Для Solana використовуйте Helius або прямо Solana RPC.
Модель скорингу
Rule-Based скоринг як основа
Почніть зі зваженої системи правил. Цей підхід прозорий і пояснюваний — важливо для користувачів, які хочуть розуміти оцінки:
class TokenScorer:
WEIGHTS = {
"github_activity": 0.15,
"team_transparency": 0.20,
"tokenomics_health": 0.25,
"liquidity_score": 0.20,
"community_quality": 0.10,
"audit_status": 0.10,
}
def score_github(self, metrics: dict) -> float:
score = 0.0
if metrics["commits_30d"] > 50:
score += 0.4
elif metrics["commits_30d"] > 10:
score += 0.2
if metrics["contributors_count"] > 5:
score += 0.3
elif metrics["contributors_count"] > 2:
score += 0.15
return min(score, 1.0)
def score_tokenomics(self, data: dict) -> float:
score = 1.0
# Штраф за високе розподіленням команді
if data["team_allocation_pct"] > 30:
score -= 0.3
# Штраф за відсутність вестингу
if not data["has_vesting"]:
score -= 0.25
# Штраф за низький коефіцієнт обігу (багато токенів ще буде випущено)
if data["circulating_ratio"] < 0.2:
score -= 0.2
return max(score, 0.0)
ML поверх правил: виявлення аномалій та rug pull паттернів
ML компонент виявляє паттерни, характерні для афер. Навчайте на історичних даних: токени, які виконали rug pull, та легітимні проекти.
Індикатори rug pull у даних:
- Автор контракту видалив пул ліквідності протягом 30 днів
- Honeypot: токен неможливо продати (функція sell заблокована в контракті)
- Proxy контракт без timelock для змін логіки
- 90%+ пропозиції утримується однією адресою
from sklearn.ensemble import GradientBoostingClassifier
# Rug pull детектор
features = [
"top1_holder_pct",
"lp_lock_days",
"is_proxy_contract",
"sell_function_exists",
"owner_renounced",
"audit_score",
"github_commits_30d",
"holder_count"
]
model = GradientBoostingClassifier(n_estimators=100, max_depth=4)
model.fit(X_train, y_train) # y: 1 = rug pull, 0 = легітимний
Набір даних: підтверджені rug pull токени з DeFiLlama Hacks dashboard, Token Sniffer історичні дані.
Honeypot детекція
Окрема критична перевірка: чи можна фактично продати токен? Використовуйте симуляцію транзакції go-ethereum / ethers.js перед взаємодією з контрактом:
from web3 import Web3
def check_honeypot(contract_address: str, router_address: str) -> bool:
w3 = Web3(Web3.HTTPProvider(RPC_URL))
# Симулюємо продаж мінімальної кількості
try:
router = w3.eth.contract(address=router_address, abi=ROUTER_ABI)
router.functions.swapExactTokensForETHSupportingFeeOnTransferTokens(
1, # 1 wei еквівалент токена
0,
[contract_address, WETH_ADDRESS],
ZERO_ADDRESS,
int(time.time()) + 60
).call({"from": TEST_WALLET})
return False # продаж вдався = не honeypot
except Exception:
return True # revert = honeypot
Це виклик, не відправлення — газ не витрачається, транзакція не записується в блокчейн.
Мобільний інтерфейс
Остаточна оцінка — це число від 0 до 100 з кольоровим кодуванням (червоний < 40, жовтий 40–70, зелений > 70). Але оцінка без пояснення — чорна скринька. Відображайте розбір разом з цим: які фактори знизили оцінку.
struct TokenScore: Codable {
let overallScore: Double // 0-100
let riskLevel: RiskLevel // .low, .medium, .high, .critical
let breakdown: ScoreBreakdown
let warnings: [String] // ["Honeypot detected", "No audit report"]
let lastUpdated: Date
}
struct ScoreBreakdown: Codable {
let technology: Double
let team: Double
let tokenomics: Double
let liquidity: Double
let community: Double
}
Пріоритизуйте попередження: виявлення honeypot отримує червоний баннер негайно, низька ліквідність з'являється як жовте попередження нижче на сторінці.
Огляд процесу
Визначте параметри скорингу з клієнтом. Побудуйте дата-конвеєр (GitHub API, on-chain дані, соціальні метрики). Розробіть rule-based скоринговий механізм. Навчайте ML модель для виявлення rug pull/honeypot. Розгорніть REST API з кешуванням (дані токена оновлюються щогодини). Побудуйте мобільний інтерфейс: карточка токена з оцінкою та розбором за категоріями.
Оцінки часових рамок
Rule-based скоринг з основними метриками: 1–2 тижні. Повна система з ML rug pull детектором, honeypot перевіркою та мобільним інтерфейсом: 3–5 тижнів.