Fusion+ Extensions

1inch Fusion enables trustless cross-chain swaps through hash-locked limit orders, but currently supports only EVM-compatible chains. This project extends the protocol to Bitcoin (both on-chain and Lightning Network) and TON blockchain by implementing the necessary bridge infrastructure and smart contracts. For Bitcoin integration, we developed HTLC scripts that use SHA256 hashing compatible with Bitcoin's native cryptographic functions, while maintaining interoperability with 1inch's keccak256-based EVM contracts through dual-hash secret generation. The Lightning Network implementation uses HODL invoices as the commitment mechanism, allowing atomic swaps between Lightning satoshis and EVM-based tokens. For TON blockchain integration, we created custom smart contracts written in FunC that handle Jetton deposits, implement hashlock mappings, and manage timelock-based refunds. The TON contracts use SHA256 hashing for compatibility and include sophisticated state management with persistent storage dictionaries for efficient swap lookups. Each swap creates a fresh contract instance with unique context IDs to ensure isolation. The implementation supports bidirectional swaps between TON Jettons and EVM tokens, with proper balance verification and atomic completion or refund mechanisms that maintain the trustless guarantees of the original 1inch Fusion protocol.

For the Bitcoin and Lightning part: This project orchestrates three distinct technologies: the 1inch Fusion SDK, Bitcoin's native scripting, and the Lightning Network's advanced features. On the EVM side, we used the @1inch/cross-chain-sdk to allow a user to cryptographically sign an order off-chain. This order, containing a keccak256 hash of a secret, acts as a verifiable commitment that a Resolver can later execute on-chain. For all blockchain interactions, ethers.js was used for sending transactions and deploying contracts, while the prool/anvil framework provided high-performance local chain forks for realistic and rapid testing. For the Bitcoin side, we leveraged bitcoinjs-lib to manually construct on-chain Hashed Time-Lock Contracts (HTLCs). This involved creating custom Pay-to-Witness-Script-Hash (P2WSH) scripts with OP_SHA256 and OP_CHECKLOCKTIMEVERIFY opcodes to build the atomic swap's trustless foundation. For the Lightning integration, we interfaced directly with LND's REST API using axios. The key was using HODL Invoices (/v2/invoices/hodl), which allow a payment to be held in an ACCEPTED state without being settled, providing a crucial commitment signal before the secret is revealed and the payment is finalized with /v2/invoices/settle. The most notable implementation detail was orchestrating the asynchronous flow within a Jest test suite. To avoid deadlocks—where one action waits for another that can't complete yet—we managed promises concurrently. For instance, a Lightning payment was initiated without being awaited, while a separate listener waited for the invoice to be ACCEPTED. This allowed the test to proceed with the on-chain steps before returning to await the final resolution of the payment. This "clean hack" accurately models the event-driven, asynchronous nature required for a real-world deployment of this cross-chain system.

For the TON integration: we wrote custom smart contracts in FunC that replicate the HTLC escrow functionality for Jetton tokens, mirroring the behavior of our Solidity HashedTimelockERC20 contract on the EVM side. Our TON contract maintains a dictionary mapping hashlocks to swap data structures containing depositor, recipient, amount, and timelock information. The hardest part was implementing proper Jetton deposit handling since contracts can't receive tokens as straightforward as in EVM - TON's Jetton standard requires contracts to receive tokens via JETTON_TRANSFER_NOTIFICATION (0x7362d09c) messages, so we had to craft complex message payloads that wrap the jetton transfer with our swap parameters using createTonSwapDepositMessage(). When users deposit Jettons, our contract receives the notification, extracts the swap parameters from the message payload using OP_DEPOSIT_NOTIFICATION (0xdeadbeef), and stores the swap indexed by its SHA256 hashlock. The contract exposes three main operations: deposit handling that locks Jettons in escrow, completion via OP_COMPLETE_SWAP (0x87654321) that releases Jettons to the recipient when the correct secret is provided, and refund via OP_REFUND_SWAP (0xabcdef12) that returns Jettons to the original depositor after timeout. We deployed contracts dynamically using @ton/ton and @ton/crypto libraries, generating fresh addresses with random salts for each test to ensure clean state. The tricky part was managing TON's asynchronous transaction model - we had to poll for transaction confirmations and parse message bodies to extract swap completion events. We used @ton/core for Cell serialization and deserialization, carefully constructing message payloads that include swap parameters, hashlocks, and timelocks. The contracts maintain persistent state across multiple operations using global variables that get serialized to storage, and we implemented custom getter methods to query swap status without modifying state. Both TON and EVM implementations use SHA256 hashing in this specific test setup, ensuring direct hash compatibility across both chains from the same original secret.