Atomic cross-chain swaps without custody
You trade with a peer moving the opposite way—not against a pool. Liquidity locks in Discreet Log Contracts and HTLCs on-chain; you keep signing keys and approve every PSBT. We match routes and surface settlement—you never hand us custody of your keys.
-
Self-custodial signing
Quotes and spends are BIP-322 and PSBTs you sign in your wallet or offline signer. We do not hold your private keys.
-
Contract-locked, not pooled
Funds sit in Taproot DLC-DLC or hybrid DLC-HTLC outputs governed by explicit scripts—not a company omnibus wallet.
-
Peer-matched flow
The protocol pairs complementary trades. Atomicity depends on both sides completing their on-chain leg—there is no synthetic balance sheet behind your position.
-
Verifiable exits
Refund and claim paths are script-defined. You can audit addresses and timeouts on-chain; coordinate through the app, verify with any block explorer.
Swap between chains
Pick assets, connect your wallet, settle on-chain—no custodial deposit step.
Advanced — rate, slippage & fees
1 BTC ≈ — FB
0.4% protocol fee (min 546 sats) as a separate output in the funding tx — not taken from your send amount. Do not send to the DLC address directly.
How it works
- Post — Sign your intent. No funds locked yet; claim keys are wallet-derived from your quote signature.
- Match — Paired with a counterparty. One side is the secret holder (claims first); the other waits for the on-chain reveal.
- Fund — Each party locks their send leg. Secret holder funds first; hybrid routes may need an HTLC hash commitment.
- Confirm — Wait for required confirmations on both chains.
- Claim — Secret holder claims first; counterparty claims second. Either side can refund after its timelock.
Liquidity stays in on-chain contracts—not our balance sheet. If a counterparty stalls, script timeouts unlock the refund path on each leg.
After match, your swap card shows Secret holder (amber) or Second claimer (cyan).
What we stand for
After a string of major hacks in 2026, more people are asking the same question: who actually holds my Bitcoin? NexumBit is built so the answer is always you—not us, not a bridge treasury, not a pooled wallet.
Peer settlement
You trade with another person going the other way. We find the match and help build the PSBTs. No pooled wallet. Nobody at NexumBit holds your coins.
Contracts, not IOUs
Your funds sit in on-chain DLCs and scripts—not on our balance sheet. Read the contract and timelocks before you send a single sat.
Realistic but ambitious
We will not tell you we are unhackable. We build systems you can inspect, say plainly what we assume about security, and keep making them stronger and easier to use.
Bridges, exchanges, and custodial wallets kept getting hit. One breach often meant everyone’s funds were gone—not just one person’s mistake. People are waking up to what Bitcoin was always about: using your own coins, with rules you can read before you sign.
Most cross-chain products ask you to deposit into their pool and trust their books. We took a different path. Your funds lock into Taproot DLCs and HTLCs—real on-chain contracts between two people. We match orders and help build PSBTs. We do not hold your money.
You sign the contract. Your coins never sit in our wallet.
Sign in your wallet, fund when you are ready, and use our open-source Signer if you ever need to recover without us. For developers and backers: our protocol spec and builders are public. We are building cross-chain Bitcoin liquidity without another custodial middleman in the middle.
- Transparency Open protocol. Open source. Every settlement path is on-chain before you commit.
- User sovereignty Your wallet keys stay on your device. We never custody balances.
- True interop Atomic swaps across Bitcoin-family chains—matched peer to peer, not routed through our vault.
Bitcoin should work across chains without handing it to someone else first. That is what we are building—in the open—for users, developers, and anyone who wants to back real non-custodial infrastructure.
Bridge activity
Live route marketplace — bridge auto-matches by default; use Match to target a specific intent.
0
Active
0
Pending intents
0
Matched
No active orders right now
Recent completions
No completed swaps yet
My swaps
Connect a wallet to see your swaps
Borrow and lend on-chain
Collateral on one chain, liquidity on another. You set LTV, term, rate, and settlement—counterparties meet in the book; funds stay in contracts you control.
—
Locked by chain
Native units · protocol-wide (all wallets)
—Active loans
5%Avg rate
Borrow
New request
Size, chains, term, rate, and settlement mode—then publish to the book.
You lock
BTC
You receive
LTC
1 Size & routing
Pick two different chains: collateral locks on one; loan proceeds arrive on the other.
Litecoin
2 Term & pricing
3 Settlement & estimate Enter collateral amount to open automatically, or expand to configure now.
Selecting a mode updates the context and the liquidation row in the summary. It does not change your LTV or interest sliders.
Estimate · USD ≈ from live spot
You lock (collateral)
—
You receive
—
Interest
—
Total repayment
—
Loan ÷ collateral (USD, spot)—
Collateral not borrowed (USD, spot)—
Position LTV—
Liquidation LTV90%
Repayment is principal + interest on the loan chain. Collateral is locked as security (not part of that total); it is released when you repay, or used if oracle liquidation triggers.
4 Receive address
Market
Live borrow intents—match to supply liquidity on-chain
Chains
Order book
How this list works
Only unmatched requests appear here. When you match, you are counterparty to a DLC-shaped route—review the PSBT flow, then fund on the loan chain. Active positions live under Portfolio.
Portfolio
Your positions as borrower or lender. Expand a row for settlement, addresses, and txs.
Role glossary
Borrowing — you posted terms or are repaying.
Lending — you matched a request and funded the loan asset.
Public milestones: Activity tab.
Platform activity
Anonymized milestones per loan. Full amounts and explorers: Portfolio.
Loading activity…
Lifecycle
Request
Borrower posts collateral amount and loan terms
Match
Lender matches and funds the loan delivery
Active
Borrower has liquidity, collateral is locked on-chain
Settle
Repay + interest to reclaim, or lender claims on default
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
Security
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.
Put BTC and L1 assets to work—or borrow without selling.
How NexumBit works
Atomic cross-chain swaps — you sign every transaction. Non-custodial: NexumBit never holds your wallet keys, claim keys, or adaptor secrets.
The journey
Post
Sign intent — no funds locked
Create
Match opposite direction
Fund
Holder funds first, then you
Confirm
Wait for confirmations
Claim
Holder first, then counterparty
Your role at match
Timelocks assign one secret holder (amber) and one second claimer (cyan) — not chosen by you. Follow your column below; funding order is enforced in the app.
Three different keys — do not mix them up
- Wallet signing key (UniSat, etc.) — signs fund and refund only. Stays in your wallet. NexumBit never sees it.
- Claim signing key (wallet-derived) — derived from quote BIP-322 + swap_id. Re-sign the quote message to recover. Never stored on NexumBit.
- Adaptor secret (secret holder only) — wallet-derived from the same quote signature. Published as T after funding; revealed on-chain at first claim.
We match and relay transactions only — we never hold wallet keys, claim signing keys, or adaptor secrets.
Secret holder
- Fund your send leg first (optional Recovery Kit for descriptors only)
- Fund your send leg first (your lock becomes their receive leg)
- Wait for them to fund + chain confirmations
- Claim first — your on-chain claim reveals the adaptor secret
Second claimer
- Wait until holder funds — optional Recovery Kit for descriptors only
- Wait until their fund tx is on-chain — the app blocks you from funding first
- Fund your send leg, then wait for confirmations
- Claim second — adaptor secret is read from their public on-chain claim (not from your wallet)
When to download (optional)
Claim keys are derived from your quote signature — re-sign to claim after clearing storage. Recovery Kit is optional (descriptors and refund reference only).
Why holder funds first & refund safety
If the second claimer funded first, a dishonest holder could claim without locking theirs — holder-first funding prevents that. If the swap stalls, each side refunds its own send leg after its timelock.
Real answers
What even is this?
P2P atomic swaps across BTC, FB, LTC, BEL, DGB, GRS — no pools or wrapped tokens.
Does NexumBit hold my private keys?
No. Your wallet key never leaves your wallet. Claim and adaptor material are derived from your quote BIP-322 signature and never stored on our servers. After the holder claims, the adaptor secret becomes public on-chain.
Is my money safe?
Funds stay on-chain in locked contracts. You sign every tx with your wallet or browser keys. NexumBit is non-custodial — we never hold wallet keys, claim keys, or adaptor secrets.
How long does it take?
Usually ~15–95 min after both sides fund — matching time varies, then chain confirmations (~10–50 min).
What if they ghost?
Before funding: unmatch. After funding: wait for timeout, then refund your send leg.
Who should fund first?
The secret holder (amber) always funds first. The second claimer (cyan) must wait until the holder's lock is on-chain before funding — the app blocks early funding to protect you.
Who claims first?
Secret holder (amber) claims first and reveals the secret. Second claimer (cyan) waits, then claims. Shown on your swap card and funding modal.
Do both users need a Recovery Kit?
No — claim keys are wallet-derived. Re-sign your quote BIP-322 message when claiming. The optional Recovery Kit is descriptors, txids, and refund timeouts for your records.
Can both sides get a refund?
Yes — each leg refunds independently after its timelock. No counterparty cooperation required.
I closed my browser. Now what?
Funds stay on-chain. Reconnect your wallet and re-sign your quote message to derive claim keys again, then claim or refund.
What wallets work?
BTC/FB: UniSat, OKX, or signer.py. LTC/BEL: Litescribe/Nintondo or external + signer.py. DGB/GRS: external Taproot + signer.py.
Build & recover
For the curious — Bitcoin stack, DLCs & recovery
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 P2P matching service scans open swap intents every ~5 seconds (and on each new post). It pairs opposite directions with compatible amounts and rates within your slippage — automatically on Bridge, or when you Match a specific intent on Activity. At match it builds on-chain contracts (Taproot DLC or hybrid Taproot + P2SH HTLC). Claim and adaptor material are wallet-derived from your quote signature; NexumBit never stores private keys or adaptor secrets.
How it's built
Backend runs the intent matcher, on-chain monitor, and PSBT builder. Activity shows live open intents (not a liquidity pool). Bridge auto-matches by default; Activity lets you target a specific counterparty. Rates come from live markets. Wallets sign fund/refund; v2 claims use wallet-derived adaptor keys in-browser.
How it's used
Post on Bridge (auto-match) or Match on Activity → fund your send leg (holder first; hybrid may need HTLC hash) → wait for confirmations (3 BTC, 10 FB, 6 LTC, 6 BEL, 6 DGB, 6 GRS) → claim when ready. Unmatch before funding; 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.
Hybrid v2 — secret holder may need to publish HTLC hash before P2SH leg is fundable.
Backend down — optional Recovery Kit (descriptors) plus psbt-signer/signer.py for offline PSBTs; re-sign your quote message to derive claim keys.
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
v2 swaps link both legs with Taproot adaptor signatures. When the secret holder claims, the adaptor signature is revealed on-chain so the second claimer can finish. You adaptor-sign in the app using keys derived from your quote BIP-322 message — re-sign when prompted. Hybrid P2SH receive legs use an external wallet with the revealed preimage. Optional Recovery Kit exports descriptors and refund reference only (no private keys); psbt-signer/signer.py works offline.
Secret holder vs second claimer
Taproot DLC adaptor signatures link both legs. At match, timelocks decide who claims first. Claim keys are wallet-derived from your quote signature — re-sign to claim. NexumBit never stores private keys.
See Your role at match above for funding order and claim order.
Ready to swap? Keys in your hands, contracts on-chain.
Go to Bridge