Seeking feedback: cBTC – a Bitcoin-native working capital / credit protocol

[James tector]

Hello everyone,

I’m looking for technical and conceptual feedback on a project I’ve been working on called cBTC.

The goal of cBTC is to explore whether Bitcoin can be used as productive capital (working capital / credit) without introducing fiat pegs, price oracles, liquidations, or custodial risk.

This is not a token sale, not a stablecoin, and not a DeFi-style lending platform.

High-level idea

cBTC is a Bitcoin-native credit protocol built around the following principles:

Everything is denominated in BTC, not fiat

• No price feeds or liquidations
• No rehypothecation
• No custodians holding user funds
• Deterministic, conservative rules

Credit is issued via Minting Channels:

• A Bitcoin holder locks BTC on-chain
• For each 1 BTC deposited:

70% is time-locked as principal
15% goes to a global Redemption Pool
15% is prefunded yield

• A fixed amount of cBTC is minted at 30% LTV
• cBTC is a bearer asset, intended to circulate mostly off-chain

Key mechanics

Issuance

• Fixed issuance rate (no dynamic leverage)
• Max LTV: 30%
• No refinancing or rollovers

Yield

• Prefunded at channel creation
• Non-linear and time-based
• Full yield only after 1 year
• Early exit forfeits unvested yield to the Redemption Pool

Redemption

• Uses a global BTC Redemption Pool
• cBTC is burned on redemption
• No principal or yield is ever touched
• Deterministic haircuts based on reserve coverage
• No liquidations, ever

Solvency

• Global rule: Redemption Pool ≥ 50% of max redemption liability
• Hard halt on new issuance if violated
• No discretionary intervention

Current status

• Whitepaper rewritten to reflect the above design
• A regtest MVP is being built using Bitcoin Core
• Coordinator scripts simulate:

opening Minting Channels
BTC collateral flows
cBTC accounting (off-chain for now)


The code and documentation are public here:
👉 https://github.com/jamestector-coder/cbtc-protocol/tree/main

There’s a full regtest setup guide so others can reproduce the environment.

What I’m looking for feedback on

I’d really appreciate critical feedback, especially on:

1. Economic design

• Does the model make sense without liquidations?
• Are the incentives coherent?
• Any obvious attack vectors?

2. Redemption mechanics

• Tiered haircuts vs FIFO vs pro-rata
• Edge cases under stress

3. Trust model

• Separation between Bitcoin-enforced custody and coordination
• What assumptions feel too strong or too weak?

4. Comparison

• How you’d position this vs wrapped BTC, Fedimint, Lightning-native assets, etc.

I’m not assuming this is “the right answer” — the purpose is to get informed critique early, before anything solidifies.

What this is NOT

• Not a stablecoin
• Not pegged to USD
• Not yield farming
• Not a promise of returns
• Not production-ready

This is an open experiment, and I’m intentionally putting it out early to learn from people who’ve thought deeply about Bitcoin economics.

Thanks in advance for any feedback — even (especially) if it’s critical.

James Tector

[EL MOHA]

I am not actually downplaying your efforts here but with bitcoin I have come to realize that its users are actually looking for something simple and that draws my question. Who holds the custodianship of the intended lock bitcoin, is the custodianship actually shared or not even half custodial because if it is like the previous inventions of bitcoin staking and locking platforms I think you need to do better to convince bitcoiners. Do not regard the amount of bitcoin on custodial platforms like centralized exchanges if bitcoiniers cannot have self custody they hardly ever prioritize such protocols.

Out of context question is this cBTC that different with the new ctBTC that I am also seeing building a similar protocol too

[James tector]

Fair questions — and you’re right that Bitcoiners care first and foremost about simplicity and self-custody.

Custody:
There is no central custodian holding user BTC. Collateral is locked via Bitcoin-native scripts (timelocks / covenant-style constraints), not pooled under an operator’s keys. The protocol is designed so that no single party can move or rehypothecate funds. If that bar isn’t met, cBTC simply isn’t worth building.

This is explicitly not “staking”, yield platforms, or exchange custody under a different name. Self-custody is a hard requirement, not a trade-off.

Why this matters:
If Bitcoiners can’t keep custody, they won’t use it — agreed. cBTC only makes sense if BTC remains sovereign capital while cBTC acts as a separate, spendable credit layer.

On ctBTC:
I’ve seen ctBTC mentioned, but from what’s public it appears to be a synthetic / wrapped representation with different trust and custody assumptions. cBTC is not a wrapper or bridge token — it’s a Bitcoin-native credit instrument, with redemption rules enforced at the protocol level rather than by an issuer or federation.

Happy to clarify specifics once ctBTC details are fully public — but custody and redemption design are the real differentiators.

Appreciate the pushback — these are exactly the questions that should be asked.