Экосистема $TRAIL — финальная версия

Двухсетевой роадмап, токеномика и смарт-контракты (TON + Solana)

Рабочее допущение (поправь, если не так). Я трактую $TRAIL как токен экосистемы, а «мод» — как модульный игровой слой («режим»), который встраивается в Telegram-mini-app игры и моддируемые игры. Ядро механики — «тропа» (trail): проверяемая ончейн-запись активности/прогресса/территории игрока, которая накапливается между играми через мод. Эта трактовка нарочно сделана game-agnostic, чтобы подходить и под гоночные, и под кликеры, и под exploration/territory-игры. Таро и старые NFT-проекты сюда не привязаны.

Суть в одном абзаце. Два блокчейна делают разную работу: TON — это парадная дверь (≈1 млрд пользователей Telegram, вход картой через Stars, mini-apps, дешёвые частые действия), Solana — это рынок капитала (глубокая ликвидность, DEX/CEX, зрелые NFT-маркеты, сжатые NFT почти бесплатно, оракулы, DeFi). «Мод» связывает их так: геймплей и онбординг живут на TON, ценность и торговля редкими активами — на Solana, а между ними ходят доказательства, а не деньги (аттестации), плюс отдельный путь для перемещения ценности через аудированные стейбл-роутеры. Это честнее и безопаснее наивного «моста токена».

1. Что отвечает на каждый твой запрос

2. Зачем TON и зачем Solana — честное разделение труда

Главная мысль: не дублировать функции в двух сетях, а отдать каждой то, в чём у неё несправедливое преимущество.

Вывод для смарт-контрактов (см. §5): на TON живут контракты, которые вызываются часто и дёшево (начисление мягкой валюты, энергия, чек-поинты тропы); на Solana — контракты, где важны ликвидность, торговля и капитал (мастер $TRAIL, стейкинг, минт премиум-NFT, оракул). Связку описываем не как «мост токена», а как аттестацию состояния между сетями.

3. Токеномика

3.1. Модель токенов (рекомендуется два уровня, один бренд)

Чтобы «запустить монеты на TON и на SOL» и при этом не убить экономику инфляцией геймплея, разделяем мягкую и твёрдую валюту:

• $TRAIL — твёрдый токен ценности. Каноничный дом — Solana (ликвидность, DEX/CEX, голосование, стейкинг). Фиксированное предложение. Это и есть «SOL-монета».
• $TRAIL (мост) на TON — джеттон-представление, чтобы пользователи Telegram держали и тратили $TRAIL нативно. Это «TON-монета» того же бренда (обеспечена стейбл-роутингом/релеером, см. §5.3).
• STEP — мягкая внутриигровая валюта (нативный TON-джеттон). Без жёсткого капа, минтится геймплеем, имеет тяжёлые стоки и конвертируется в $TRAIL по троттлингу. Защищает $TRAIL от инфляции «накликали — обвалили».

Это проверенная схема (мягкая + твёрдая валюта) и она идеально ложится на две сети: где играют — там мягкая валюта (TON), где рынки — там ценность (Solana).

3.2. Распределение $TRAIL (пример на 1 000 000 000)

3.3. Источники и стоки (это решает судьбу токена)

Железное правило: стоки ≥ источников по дизайну, иначе токен идёт в ноль. Каждую новую механику оцениваем вопросом «что она сжигает, а не только что печатает».

4. Telegram-игры, куда заходит механика «тропы»

Механика = ончейн-тропа/движение/территория + двухсетевые награды + моддируемый слой. Куда ложится естественно (с примерами из текущего ландшафта 2026):

Честно: «механика подходит» ≠ «игра её внедрит». Внедрение — это BD-работа. Но рынок показывает рабочий путь: партнёрские сети (Yescoin ↔ Catizen ↔ PixelTap) растут именно через интеграции, а MemeFi уже строит «экосистему мини-игр + NFT + ончейн-кошельки» — близкий к твоему «эко-моду» паттерн и одновременно конкурент. Тактика: сначала собственный mini-app с модом (контроль качества), потом Mod SDK (§8), чтобы чужие игры подключались на твоих стандартах.

Дополнительная осторожность: чистый tap-to-earn перегрет — инфляция наград и падающее удержание (Hamster Kombat просел с ≈300M до ≈27M активных). Дифференциатор $TRAIL — владение (NFT) и глубина тропы/территории, а не «ещё один кликер».

5. Как это описать в смарт-контрактах

Ниже — схематичные спецификации (не готовый к компиляции код): имена сообщений/инструкций, авторитеты, поля. Это то, что отдаёшь разработчикам как ТЗ.

5.1. Сторона TON (FunC/Tact; джеттоны TEP-74, NFT TEP-62)

Контракты, которые вызываются часто и дёшево:

• Джеттон-мастер STEP — мягкая валюта; admin = GameMaster. Минт только по вызову от GameMaster.
• Джеттон-мастер $TRAIL (мост) — представление твёрдого токена; mint_authority = bridge_adapter (минт при входе ценности, бёрн при выходе).
• GameMaster / Trail — сердце геймплея: энергия, кулдауны, заявки на территорию, чек-поинты тропы, выдача грантов, купленных за Stars.
• NFT-коллекции (TEP-62) — пассы, дееды территории, трофеи.

// TON — GameMaster (схематично)
message ClaimStep      { player: Address; segmentId: Int as uint64; nonce: Int as uint64; }
message Checkpoint     { merkleRoot: Int as uint256; epoch: Int as uint32; } // корень офчейн-тропы для аттестации в Solana
message RedeemStarsGrant { player: Address; grantType: Int; sig: Slice; }     // подпись доверенного бэкенда (Stars — офчейн)

contract GameMaster {
    minterPubKey: Int;        // ed25519 ключ бэкенда для проверки Stars-грантов
    stepMaster:  Address;     // адрес джеттон-мастера STEP
    energy:      map<Address, Int>;
    lastAction:  map<Address, Int>;

    receive(msg: ClaimStep) {
        require(now() - lastAction.get(msg.player)!! >= COOLDOWN, "cooldown");
        // списать энергию -> отправить mint STEP игроку через stepMaster
    }
    receive(msg: RedeemStarsGrant) {
        require(checkSignature(msgHash(msg), msg.sig, self.minterPubKey), "bad sig");
        // выдать пасс/энергию, оплаченные за Stars офчейн
    }
    receive(msg: Checkpoint) { /* зафиксировать корень эпохи -> его заберёт релеер для Solana */ }
}

Про Telegram Stars (важная честная деталь). Stars — офчейн (на стороне Telegram). Поток такой: бот выставляет инвойс (Bot API, валюта XTR) → пользователь платит картой → твой бэкенд подписывает грант → ончейн-контракт RedeemStarsGrant проверяет ed25519-подпись и выдаёт пасс/энергию. То есть мост Stars↔ончейн — это проверка подписи доверенного ключа, а не «оплата прямо в контракт».

Про тропу. Не пишем каждый шаг в блокчейн (дорого по смыслу и шумно). Тропу копим офчейн, а на TON периодически коммитим корень Меркла эпохи (Checkpoint). Это даёт дешевизну + проверяемость и служит источником аттестаций для Solana.

5.2. Сторона Solana (Anchor/Rust; SPL / Token-2022)

Контракты, где важны ликвидность и капитал:

• Мастер $TRAIL — Token-2022 (Token Extensions). Расширения: MetadataPointer + TokenMetadata (ончейн-метадата); опционально TransferFeeConfig (протокольная комиссия — но осторожно: ломает часть допущений DEX/CEX, многие предпочитают токен без transfer fee ради чистой ликвидности); опционально TransferHook (роялти/логика). Рекомендация: фиксированное предложение — выпустить один раз в распределяющую программу и отозвать mint authority (чисто и аудит-дружелюбно).
• Стейкинг-программа. PDA stake_account, период лока, начисление наград, вес голоса; инструкция attest_boost записывает вес стейка, который потом применяется как множитель на стороне TON (см. §5.3).
• cNFT-трофеи. Metaplex Bubblegum + state compression (concurrent merkle tree): mint_to_collection_v1 для дешёвых массовых трофеев; редкие — decompress в полноценный NFT для торговли на Tensor/Magic Eden.
• Роялти на премиум-активы — pNFT (программируемые NFT) или TransferHook Token-2022.
• Оракул Pyth — фиды цен для «Рынков троп» и любой price-aware конвертации.

// Solana — конфиг $TRAIL и стейкинг (схематично)
// $TRAIL mint = Token-2022 with extensions:
//   MetadataPointer + TokenMetadata  (ончейн-метадата)
//   (опц.) TransferFeeConfig          (протокольная комиссия — взвесить против DEX-чистоты)
//   (опц.) TransferHook               (роялти/логика)
// mint_authority: после первичной эмиссии -> revoke (фиксированный supply)

#[program]
mod trail_staking {
    pub fn stake(ctx: Context<Stake>, amount: u64, lock_days: u16) -> Result<()> { /* PDA stake_account */ }
    pub fn claim_rewards(ctx: Context<Claim>) -> Result<()> { /* начисление наград */ }
    pub fn attest_boost(ctx: Context<Attest>, sig: [u8; 64]) -> Result<()> {
        // релеер подписывает вес стейка; TON GameMaster позже проверит и применит множитель заработка
    }
}

5.3. Связка двух сетей — честная архитектура моста

Ключевой факт (проверено): нативного моста TON↔Solana нет — обе сети не-EVM, прямой маршрут требует кастомных валидаторов с обеих сторон (дорого, медленно, рискованно). Поэтому связку описываем двумя раздельными паттернами, а не одним «мостом токена»:

(A) Перемещение ценности (для пользователей, двигающих деньги). Опираемся на аудированные роутеры, которые ходят TON↔Solana через стейбл-промежуток (USDT/USDC): например, Symbiosis (есть TON Bridge v2) или Allbridge. Это даёт пользователю путь между твоими рынками на TON и Solana — без того, чтобы ты сам синхронизировал 1:1 предложение $TRAIL в обеих сетях.

(B) Аттестация состояния (для игровой логики — это и есть «соединение пользы»). Ты не мостишь шаги и не мостишь деньги для геймплея. Вместо этого: - TON-сторона коммитит корень Меркла достижений/тропы (Checkpoint); - релеер/оракул переносит подписанную аттестацию на Solana, где она гейтит минт cNFT-трофеев и буст стейкинга; - обратно: вес стейка с Solana аттестуется на TON и применяется как множитель заработка в GameMaster.

Так ты двигаешь доказательства, а не средства — а именно перемещение средств является мишенью №1 для взломов. Это и безопаснее, и архитектурно чище.

Если позже захочется каноничный мульти-чейн $TRAIL (один токен, синхронный supply в обеих сетях) — это путь lock-and-mint со своим набором гардианов/релееров + мультисиг + rate-limits + аудиты. Рекомендация: отложить до Фазы 4+ и запускаться на v1 c моделью «аттестация + стейбл-роутинг».

6. Какие NFT создать внутри этих блокчейнов

Каждый тип привязан к сети, чьё преимущество он использует. Оценки — по честной 8-факторной рубрике (composite 0–10, занесено в твой реестр идей).

Дизайн-логика: дешёвое и массовое (трофеи) → cNFT на Solana; внутри-Telegram и дарёжное (пассы, подарки) → TON; статусное и торгуемое (снаряжение, редкие дееды) → полноценные NFT на Solana, где есть рынок.

7. Роадмап

Сроки индикативные; вехи — по готовности, а не по календарю.

8. Какие ещё моды войдут в экосистему $TRAIL

Подобраны прицельно под бывшие пробелы реестра (DeFi-lite, аналитика, соц-координация, агенты, мост, оракулы). Оценки занесены в реестр.

9. Честные риски (не прятать)

• Устойчивость P2E. Главный убийца — инфляция наград и спираль вниз. Митигация: soft/hard сплит (STEP vs $TRAIL), стоки ≥ источников, NFT как долговечная ценность, троттлинг конвертации.
• Безопасность моста. TON↔SOL — самая трудная пара (обе не-EVM). Митигация: аттестация вместо моста средств, аудированные роутеры для ценности, каноничный мост — только поздно и с аудитами.
• Регуляторика. Токен может квалифицироваться как ценная бумага; «Рынки троп» граничат с гемблингом. Нужна юридическая консультация и гео-фильтры; честность про вероятности и комиссии.
• Усталость жанра. Кликеры перегреты, удержание падает. Дифференциатор — владение и глубина территории/тропы, а не «ещё один тап».
• Ограничения Stars. Комиссия сторов и лимиты на вывод — закладывать в юнит-экономику.
• Исполнение. Двухсетевая команда (FunC/Tact + Anchor/Rust + релеер + mini-app) — дорого. Фазировать; не строить всё сразу.

10. Куда копать дальше (по «идейному компасу»)

После этой партии идей в твоём реестре закрылись почти все пробелы (джеттоны, мост, оракулы, NFT, defi-lite, соц-координация, агенты). Остались незанятыми только две категории — это твой следующий фронтир:

• identity — «Личность Картографа»: .ton-привязанная soulbound-репутация, которую читают все моды (анти-сибил, ранги, доступы).
• publishing — цензуроустойчивые логи/сайты троп (TON Sites/Storage): публичная страница маршрута/гильдии как присутствие.
• Плюс: пока ни одна идея не имеет роли агента strategist (агент, который предлагает стратегию тропы, а человек одобряет) — потенциальный мод-помощник.

Приложение: что заносится в реестр идей

Эта сессия добавила 9 оценённых идей (ядро + моды/NFT) в персистентный реестр, и они учтены в анализе пробелов выше. Самые сильные по честной оценке: Пасс Первопроходца (7); ядро $TRAIL и большинство модов — 6 (промежуточные: сильная идея, но требует заострить слабую ось — обычно это feasibility из-за двухсетевой сложности или claim_integrity из-за P2E-обещаний).