Swap between chains
Your keys, your coins. No custodian.
0.4% protocol fee (min 546 sats) paid as a separate output in the funding transaction — not deducted from funding amount. Please don't send funding directly to the DLC address.
How it works
- Create — Enter amount and sign. Your swap is added and matched automatically.
- Fund — Sign the transaction to lock your funds. Both sides fund; the system tracks it.
- Confirm — Wait for block confirmations (~3 BTC, ~10 FB, ~6 LTC, ~6 BEL).
- Claim — Sign the claim transaction. You receive your funds.
Funds stay on-chain. If the other party disappears, you can refund after the time limit.
Bridge activity
Live stats and recent swaps across the network
Open orders
No active orders right now
Recent completions
No completed swaps yet
My swaps
Connect a wallet to see your swaps
Self-custody · DLC-native · Multi-chain
Borrow anywhere. Lend with intent.
Lock collateral on one chain, draw liquidity on another—BTC, FB, LTC, and more. You choose LTV, term, and how settlement behaves. Counterparties meet you in the book; everything settles in contracts you hold the keys to.
No pooled custody. No blind trust. Just disclosed terms and on-chain DLCs.
Open a position
Set size, chains, and how liquidation works—then publish to the book.
1 Size & routing
Pick two different chains: collateral locks on one; loan proceeds arrive on the other.
Litecoin
2 Term & pricing
3 Settlement & liquidation
Selecting a mode updates the context and the liquidation row in the summary. It does not change your LTV or interest sliders.
4 Receive address
Lend
Match a request, fund the loan side, earn interest when it repays.
Filter by chain
Open requests order book
Live list of unmatched borrow orders. As a lender you pick one, match, then fund the loan on the loan chain. Nothing here is “yours” until you match — use Portfolio for positions you participate in.
Portfolio
Borrowing = you posted collateral-side terms or are repaying. Lending = you matched someone else’s request and funded the loan asset. Expand a row for settlement progress, addresses, and the full on-chain transaction list. Public milestones: Activity tab.
Platform activity
One card per loan: a compact milestone trail. Addresses and txids are shortened; open Portfolio for full explorer links and amounts.
Loading activity…
How cross-chain DLC lending works
For Borrowers
- Lock BTC, FB, LTC, BEL, DGB, or GRS as collateral; borrow a different asset on another chain (e.g. FB against BTC or BTC against FB)
- Keep your BTC exposure — no selling, no taxable event
- Safety timeout guarantees you can always recover your collateral
For Lenders
- Earn interest on idle coins by funding loan requests
- Over-collateralized: 75% LTV means 133% collateral ratio
- If borrower defaults, you claim BTC at a discount — profitable either way
All funds sit in Taproot DLCs (3-leaf MAST): repay, lender claim, and safety refund paths. No custodian can move coins alone; each path needs the right on-chain signatures (and, for oracle or FAL lender claims, the agreed attestation). CLTV safety timeout: borrower can always self-recover after the long lock.
Common Questions
What do lenders earn?
Interest paid by the borrower (1-20%, set by market). Loans are over-collateralized at 60-85% LTV, so if a borrower defaults, you claim their BTC collateral at a discount. Either way, you profit.
Is my collateral safe?
Collateral is locked in a 3-leaf Taproot DLC on-chain. Nobody can move it without the correct signatures. If everything fails, a safety timeout lets the borrower reclaim after ~90 days.
What if the borrower doesn't repay?
After the term (or a liquidation condition, depending on mode), the lender follows the on-chain lender-claim path: classic oracle co-sign, Fractal attestation (FAL) + hashlock preimage, or fixed-term CLTV only — whatever you chose when creating the request. Collateral value is designed to cover the loan.
What if the BTC price drops?
If the collateral ratio hits 90% LTV, the oracle triggers automatic liquidation. The lender claims collateral before it drops below the loan value. Lenders are protected.
What if the server goes down?
Safety timeout is a pure on-chain timelock (CLTV). After ~90 days, the borrower can always reclaim using just signer.py. No third party needed. No permanent loss.
For the curious — Fractal Attestation Layer (FAL), cross-chain DLC lending, and protocol guarantees
Fractal Attestation Layer (FAL)
FAL is the path for attested liquidation without a single trusted oracle key on the collateral chain: a per-loan secret is committed on Fractal Bitcoin in Taproot script-path leaves where N-of-M attestors must sign before the preimage can appear on-chain. That preimage then satisfies a hashlock on the collateral DLC’s lender-claim leaf, alongside the lender’s own signature. Collateral chains only need widely deployed script (e.g. OP_SHA256 and Schnorr checks). Fractal is merge-mined with Bitcoin-class hashrate, so attestations are publicly auditable on-chain rather than hidden in one server.
Stack (same family as the bridge)
Each side of a loan is a Taproot DLC: MAST trees with leaves for repay (adaptor + borrower), lender claim (mode-specific), and a long CLTV safety branch. The app matches parties, tracks funding and confirmations per chain, and builds PSBTs; signing stays in wallets or psbt-signer/signer.py. The service does not hold keys that can unilaterally spend user UTXOs.
Three attestation modes
Oracle — a dedicated oracle key co-signs lender claim on collateral. FAL — attestors unlock the Fractal output; the preimage unlocks the hashlock on collateral. Fixed-term — lender claim is absolute CLTV after term; no price liquidation and no Fractal covenant in that mode.
Ordering and safety (what the implementation is designed to enforce)
Funding order: The protocol requires loan delivery to be funded and confirmed before collateral funding proceeds, so collateral is not locked until the lender has locked the loan amount.
Activation: The loan becomes Active only after the borrower runs the loan-delivery claim flow. Liquidation and default handling apply to loans in that active lifecycle, not while the borrower has never activated.
Repay, then reclaim: The reclaim-collateral PSBT for the repay path is only built when the loan is in the repaid state and repayment has been confirmed on-chain to the required depth. There is no API-supported path to obtain that reclaim PSBT through the normal repay flow without meeting those checks.
Lender claim on collateral: The lender-claim PSBT is only built in liquidating or defaulted states. It is not offered for a loan that is still in funding, confirming, or a healthy active state without such a transition.
Emergency safety refund: The borrower-only safety path uses a high CLTV baked into the collateral DLC. The backend refuses to build that PSBT until chain height passes that lock, so it cannot replace an in-term repay or a timely lender claim under the designed timelines.
On-chain reality: Only one spend can consume a collateral UTXO; script paths enforce who may sign. The UI and API align state with those constraints before offering PSBTs.
Walking through a loan in the app
- Connect wallets for collateral and loan chains, or use
psbt-signer/signer.pywhen the UI indicates. - Post a request (attestation mode, duration, LTV, interest).
- Lender matches and funds loan delivery; borrower funds collateral after loan delivery is confirmed.
- After confirmation depth on both sides, the borrower uses Claim Loan (Activate).
- Repay to the published address, then Reclaim Collateral after repayment is confirmed.
- For default / liquidation, follow the dashboard; FAL surfaces Fractal links; Claim Collateral may need the preimage in
signer.pymode [1] on the collateral chain.
Open source
Bridge DLC documentation and the offline signer are linked from the Learn tab. A full distributable open-source lending package is planned so others can self-host the same flows; the scripts and PSBT shapes exposed here match that model.
$1.8 trillion of idle BTC. Earn yield. Borrow without selling.
Bridge between chains
Your keys, your coins. No custodian. P2P atomic swaps — you sign every transaction.
The journey
Questions we hear
Real answers
What even is this?
A swap service for BTC, FB, LTC, BEL, DGB, GRS. You send on one chain, receive on another. You're matched with a real person going the opposite direction — no pools, no wrapped tokens, no one holding your keys.
Is my money safe?
Yes. Funds stay on-chain in locked contracts. NexumBit never touches your keys — you sign every tx. If we disappear, the recovery kit lets you claim or refund yourself. You can always get your money back as long as it's not claimed by the other party.
How long does it take?
Matching depends on platform activity. After matching and users fund, confirmations run ~10–50 min. Then you claim. Total: ~15–95 min depending on chains.
What if they ghost?
Before you fund: Unmatch. After you fund: wait for the timeout, Refund, coins back.
I closed my browser. Now what?
Your funds are locked on-chain. Reconnect, hit My Swaps, your swap's there. Claim or refund when you're ready.
What wallets work?
BTC/FB: UniSat, OKX. LTC: Litescribe. BEL: Nintondo in-browser, or connect external bel1p… and use psbt-signer/signer.py (network bel). DGB / Groestlcoin (GRS): external Taproot + same tool (networks dgb, grs). Derive addresses: python3 signer.py derive-bel, derive-grs, derive-dgb, derive-ltc.
Open source
Build & recover
The NexumBit protocol is fully open. Run the signer when the platform is down, or dive into the spec.
For the curious — DLCs, recovery, terms
Bitcoin stack
NexumBit runs on the Bitcoin stack: Taproot (P2TR), Schnorr signatures, Discreet Log Contracts, and adaptor signatures. Each DLC is a Taproot output with two script paths — a claim path (adaptor + receiver sig) and a refund path (sender sig after timeout). No custom VM, no sidechains for the core swap logic.
How matching works
A background service scans the order book every ~5 seconds. It looks for pairs: same amount class, opposite directions (e.g. BTC→FB vs FB→BTC), rates within slippage. When compatible, it generates shared DLC descriptors and an adaptor secret, pairs the swaps, and both users get funding addresses.
How it's built
Backend handles matching, on-chain monitoring, and transaction building. Rates come from live markets. The web app connects to supported wallets for signing. No custom infrastructure — standard Bitcoin tooling.
How it's used
Create order → get matched → fund your DLC → wait for confirmations (3 BTC, 10 FB, 6 LTC, 6 BEL, 6 DGB, 6 GRS) → claim when ready. Or unmatch before funding; or refund after timeout if things stall.
Possibilities
Both fund and claim — swap completes.
One doesn't fund — unmatch before you fund; after you fund, wait for timeout then refund.
Both fund, counterparty abandons — claim what they locked, refund yours after timeout.
Rate moved beyond slippage — refund when eligible.
Backend down — use the recovery kit to build and sign claim or refund yourself.
Stuck waiting for confirmations — the app tracks it; claim when ready.
No expiry on the claim path — take your time.
What's a DLC?
Discreet Log Contract: an on-chain contract that locks your coins until the swap completes or a timeout hits. No one moves them without your signature. The two sides are cryptographically linked via an adaptor — both claim or both refund.
Adaptor & recovery
When you claim, the adaptor signature is revealed on-chain. The counterparty can extract it and claim their side (that's the atomic link). We embed the adaptor in claim PSBTs so most users just sign and broadcast. Skilled users can use the recovery kit — raw contract data and adaptor secret — to build and sign transactions without us.
Terms
Stay online to sign the claim once confirmed. Can't? Refund after timeout. Blockchain fees apply. Recovery kit always available in swap details.
Ready to swap?
Go to Bridge