DLC-native · Bitcoin-family chains · On-chain enforcement
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
- 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.
Liquidity stays in on-chain contracts—not our balance sheet. If a counterparty stalls, script timeouts unlock the refund path.
What we stand for
NexumBit exists to make verifiable, Bitcoin-native contracts a practical way to move liquidity across chains—without asking you to trust our balance sheet.
Peer settlement
You trade with a counterparty going the other way. We coordinate matching and PSBT flows—not a pooled omnibus wallet that holds everyone’s coins.
Contracts, not IOUs
Liquidity locks in DLCs and HTLCs on-chain. You sign; you can read the scripts and timeouts before you fund.
Honest scope
Software has bugs; chains reorg; markets move. We don’t promise “unhackable”—we promise inspectable, non-custodial mechanics and clear limits.
There is more cross-chain activity today than ever—L2s, wrapped assets, and bridge products compete for the same flows. Many designs still rely on pooled custody, IOU accounting, or trusted bridge operators. That can be convenient, but it concentrates risk: when coordination or keys fail, users discover the limits too late. None of that is inevitable—it is a design choice.
We focus on a different choice: native Bitcoin-style contracts—oracle-conditioned DLCs and time-bound HTLCs—where your funds sit in outputs you can verify, and where “success” means both sides actually settled on-chain. It is not magic; it is engineering with fewer hidden intermediaries.
Contract-native settlement is our default—not pooled custody.
In practice: you and a peer lock liquidity, collaboratively sign PSBTs, and use our matching engine to find routes. No NexumBit bridge token. No deposit into our treasury. If something stalls, script-level refunds and claim paths exist because they were part of what you signed—not because we promise to “make you whole” off-chain.
- Transparency Every contract path is on-chain and auditable before you commit a single satoshi.
- User sovereignty You hold your keys end-to-end. We never custody balances.
- True interop Atomic legs across chains when both parties complete their on-chain steps—coordination without a custodial hop through us.
We’re here to make Bitcoin-native DeFi usable: sovereign where it can be, transparent by construction, and honest about what software can and cannot guarantee. No custodial pool from us—just tooling and matching so these contracts are yours to sign and verify.
Bridge activity
Live stats and recent swaps across the network
Active orders
No active orders right now
Recent completions
No completed swaps yet
My swaps
Connect a wallet to see your swaps
Allowlisted LPs · BTC / FB
CoinPool liquidity console
Join or update a chain-local shared UTXO, track shares and fees, and manage cooperative sweep exits from one production-grade LP surface.
Loading pool status...
Liquidity operations
LP actions
Build a CoinPool top-up PSBT, sign it with your wallet, broadcast, then report the txid so the pool state can advance.
No pool action yet.
Your capital
Your LP position
Shares, accrued route fees, pending deposits, and withdrawal queue.
Connect a BTC/FB wallet and refresh to view positions.
DLC-native · Cross-chain · Self-custody
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.
Bridge between chains
Your keys, your coins. No custodian. P2P atomic swaps — you sign every transaction.
The journey
Create
Match with someone going the opposite way
Fund
Lock your coins on-chain
Confirm
Wait for blocks
Claim
Receive on the other chain
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, or external bc1p… + signer.py. LTC: Litescribe in-browser, or connect external ltc1p… + signer.py (network ltc). BEL: Nintondo in-browser, or connect external bel1p… (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 — 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 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.
Settle across chains the Bitcoin-native way—keys in your hands, contracts on-chain.
Go to Bridge