Read the protocol description and spec - Train Documentation
- Implements HTLC-based cross-chain atomic swaps with solver-provided liquidity and incentives
- Permissionless and trustless protocol without reliance on 3rd parties
- Designed to support multi-hop routing across chains (future work)
- Alpha version available for testing on multiple testnets
This repository is organized so that audited, stable implementations live on the main branch, while networks that are still under active development or audit live on dedicated branches.
The following networks are considered stable enough to live directly in main:
-- EVM (Solidity) – chains/evm/solidity
-- Solana – chains/solana
-- Starknet – chains/starknet
-- Fuel – chains/fuel
The following networks are still under active development, testing, or audit.
Each one lives in its own long-lived branch:
- Aptos –
main-add-aptos - Aztec –
main-add-aztec - Bitcoin –
main-add-bitcoin - Stacks –
main-add-stacks - Sui –
main-add-sui - TON –
main-add-ton - XRP –
main-add-xrp
Train is a revolutionary bridging protocol designed to address the challenges of seamless asset movement across the rapidly expanding cryptocurrency ecosystem. As the number of blockchain networks grows, including L1s, L2s, side-chains, and app-chains, the need for efficient and secure cross-chain asset transfer becomes critical.
- Trustless: No reliance on oracle-based systems or 3rd parties
- Permissionless: Open for any participant to join without compromising security
- Multi-hop Routing (planned): Enables bridging between chains without direct liquidity pairs
- Censorship Resistant: Decentralized design resistant to censorship attempts
Train uses hash time-locked contracts (HTLCs) to coordinate trustless swaps between users and solvers.
- The user creates a lock on the source chain using a hashlock.
- A solver creates a corresponding lock on the destination chain using the same hashlock.
- The recipient redeems the destination lock by revealing the secret.
- The same secret is used to redeem the source-chain lock.
- If a swap does not complete before the timelock, funds can be refunded.
This design ensures that funds are either redeemed with the correct secret or safely refunded after timeout.
Please note that this project is actively under development. It is not ready for deployment on any mainnet environments, unless mentioned as audited. As we continue to experiment and test new ideas, expect significant changes to the interface. Please be prepared for ongoing modifications.
- The initial HTLC implementation was based on the work done in the atomic-port project by Yuki Uichiro