Cerera

This project extends 1inch Fusion+ to Bitcoin by leveraging the Lightning Network for instant Bitcoin settlements.

Using HTLC escrows on EVM and Lightning invoices with matching hashlocks, we implemented a fully non-custodial atomic flow that mirrors Fusion+’s architecture: EIP-712 orders, gasless settlement, and resolver logic.

The Problem We Address

• Fragmented Ecosystem: Bitcoin and Ethereum capital is isolated in separate ecosystems

• Slow Cross-Chain Swaps: Traditional atomic BTC swaps take 20+ minutes and require complex on-chain transactions

Our Solution

• Instant Bitcoin Settlement: Lightning Network provides sub-second Bitcoin transfers

• Seamless Integration: architectured to work on 1inch's Fusion+ infrastructure

• Zero Counterparty Risk: Hash Time Locked Contracts ensure atomic execution

• Cost Effective: Lightning Network fees are negligible compared to on-chain

✅ Hashlock and timelock functionality are preserved in the non-EVM implementation, which uses the Lightning Network for Bitcoin. This ensures atomicity and secure time-bound conditions across chains.

✅ Bidirectional swap functionality is fully supported, enabling atomic swaps between Bitcoin (via Lightning Network) and Ethereum-compatible chains (e.g., Polygon mainnet) in both directions (BTC ↔ ETH).

✅ The final demo includes a live execution of a token swap between Bitcoin via the Lightning Network and Polygon mainnet, showcasing seamless cross-chain interoperability.

Two entry scripts simulate actors and swap scenarios:

• relay-evm2btc-example.ts for ETH→BTC scenario

• and relay-btc2evm-example.ts for BTC→ETH scenario

What the user actually experiences?

EVM → BTC

User submits LN invoice (string), and signs EVM transaction to deposit escrow.

BTC → EVM

User pays LN invoice via QR code and receives ETH

Bridging

Bitcoin Mainnet ←→ Lightning Network ←→ Polygon ←→ Ethereum Mainnet

Escrow contracts (evm-side/eth-escrow/contracts/escrow.sol)

Minimal HTLC with hashlock, timelock, deposit(), claim(secret), cancel().

Relay service (cross-chain/src/relay/relay.ts)

• Decodes/creates LN invoices with ln-service.

• Builds Fusion-style EIP-712 orders.

• Watches escrow.sol events and LND SubscribeInvoices.

Order API (cross-chain/src/api/order.ts)

REST API from unite-defi-1inch-ethglobal-back. Handles two endpoints: POST /evm2btc and POST /btc2evm, forwarding JSON payloads to the relay.

Frontend (unite-defi-1inch-ethglobal)

Browser interface that lets users initiate and monitor swaps. Communicates with the backend REST API to initiate cross-chain flows.

All components spin up with one docker-compose up, which starts 3 Lightning nodes, a Hardhat chain, the relay, and the UI so CI can execute a real swap on every push.

Our system consists of three open-source repos:

• UniteDefi2025 (Solidity escrows, Hardhat tests, deploy scripts, R&D scripts)

• unite-defi-1inch-ethglobal (React frontend for LN invoice generation, order creation, swap tracking)

• unite-defi-1inch-ethglobal-back (REST API + relay that bridges LN and EVM events)

We deeply studied Fusion+ internals and reproduced its logic to work with real BTC flows — no wrapped assets, no custodians

For the demo, we have used EVM (Polygon) and BTC LN testnet.

⚠️ For safety: since the bridge connects Polygon mainnet to Bitcoin testnet, we disabled the backend before submission to prevent live token drain from bots.

Deep-dive: EVM → BTC scenario (walk judges through the logs)

1 User generates LN invoice (see log: “✅ Lightning invoice issued successfully”).

2 Order API receives maker order JSON — file: order.ts (step “🔄 Received EVM to BTC order from maker”).

3 Relay decodes invoice, extracts hashedSecret, starts polling escrow (see “🤖 RESOLVER: still waiting for escrow”).

4 User deposits 0.015 ETH — escrow contract emits DepositCreated (Tx hash 0x6d10…).

5 Relay detects deposit, pays LN invoice, receives secret, and executes claim(secret) (Tx hash 0x5f5f…).

6 Both sides log 🎉 Cross-chain swap completed successfully.

BTC → EVM is the mirror image; judges can run relay-btc2evm-example.ts to watch that flow.

Why this beats the track requirements?

We implemented Fusion logic without changing user UX — resolvers pay gas, orders stay EIP-712, only BTC side is new.

Video demo shows real funds moving; logs are human-readable for verification.

Also it brings value to 1inch

1 New liquidity — Lightning’s ~6 000 BTC capacity can now hit 1inch order books natively.

2 Zero extra UX — Bitcoin holders need no ETH, no MetaMask, no bridges; they only pay a Lightning invoice.

3 Proof of Fusion’s extensibility — we did in two weeks what the SDK doesn’t yet support, showing the design’s power.

4 emplate for future SDK — our relay.ts can be upstreamed as a Lightning adapter module.

As a team, we truly enjoyed working with the 1inch Fusion+ stack and dove deep into its architecture, order structure, and resolver logic. This project was our entry point, but not the end.

We’re excited to continue building relayers, solvers, and algorithmic liquidity on top of 1inch. That means more volume, more gas fees paid by resolvers, and a fresh stream of cross-chain users engaging with the ecosystem.

We kept the 1inch playbook intact and just taught it a new language — Bitcoin Lightning.That’s why our submission deserves to top the “Extend Fusion+” track.

Where the magic lives (file index for reviewers):

• cross-chain/src/relay/relay-evm2btc-example.ts – demo script #1.

• cross-chain/src/relay/relay-btc2evm-example.ts – demo script #2.

• evm-side/eth-escrow/contracts/escrow.sol – HTLC contract, 150 SLOC.

• cross-chain/src/api/order.ts – 2 REST handlers, validates JSON, calls relay.

• cross-chain/src/relay/relay.ts – core engine: gRPC ↔ ethers.js bridge.

• README.md

⸻

The ask

• Seal of approval from 1inch + prize funding to harden contracts & add Doge/LTC adapters.

• Guidance on integrating our relay into the official Fusion resolver marketplace.

We kept the 1inch playbook intact and just connected it in a new capital channel — Bitcoin Lightning.

Comment: The auto-review flagged "Too many lines changed in a single commit" because we reorganized the repository structure, moving files into new subfolders. No functional code changes were made—only file relocations to improve project organization.