CIP-???? | Trustless BTC Bridge

[siran]

Abstract

This proposal defines eBTC: a trustless, one-way bridge allowing BTC to enter Cardano as a native token. Users burn BTC on Bitcoin and present cryptographic proofs (NIPoPoW/SPV) to a Cardano smart contract, which mints a corresponding amount of eBTC. This solution removes reliance on custodians and oracles, enabling purely decentralized conversion and unlocking BTC’s liquidity for Cardano DeFi.

---

(latest document) - @siran please keep updating this link whenever pathname changes.

[rphair]

I'm converting this into Draft review status until it complies with the CIP format as described in CIP-0001 (#955) with about 100 examples of CIPs in the repository to imitate if there is any uncertainty. See here & the following "checklist" page for factors that make a good CIP: https://github.com/cardano-foundation/CIPs/wiki/2.-CIPs-for-Reviewers-&-Authors

The term CPS was originally in the title although this appears to be a plan for a particular method. @siran if you think this is instead a class of possible approaches to BTC wrapping on Cardano that could generate multiple CIPs, please say so here and we'll try to get you started converting your draft into a proper CPS draft.

[siran]

Thanks so much for your comments and patience. This is my first attempt at a CIP. So i'll check and imitate previous CIPs.

I do not know if this is a CIP or a CPS. Nor if it would devolve into multiple CIPs. I would be happy just with it being discussed :).

I'll try to read around to meet standards. Tried Discord server but didn't get response.

Thanks.

[rphair]

@siran it's still not in the form of CPS a which has different sections than a CIP. If you could please refer to it consistently as a CIP (as opposed to this Discord comment), and change the title of your containing directly to something like CIP-XXXX or CIP-BTC-bridge, it will help potential reviewers.

Also you should include the Cardano Forum post in the CIP header (https://forum.cardano.org/t/ebtc-a-trustless-btc-bridge-on-cardano/141117) now that discussion has emerged there.

I'll leave it as a CIP in the PR title since that's definitely what it appears to be. FYI here is the specification for the CPS (which I don't think it's in your best interest to use): https://github.com/cardano-foundation/CIPs/blob/master/CIP-9999/README.md

[yihuang]

how can a contract manage keypairs on-chain and keep private key secret?

[siran]

thanks for your interest.

would this work?

A contract alone typically cannot hold a private key “secret” on a fully transparent blockchain. Instead, one must use threshold cryptography or multi-party computation (MPC), where the key is split among multiple participants/nodes. Each piece is useless by itself, so no single party or on-chain entity has the entire private key. The contract effectively “manages” the key by coordinating partial signatures from these participants. Another approach is to store an encrypted key on-chain, and only decrypt it in a secure off-chain or MPC environment when the contract logic calls for a signature. In both cases, the actual private key bits are never revealed in plaintext on the public ledger.

(cBTC is a better name)

[siran]

Proposed Approach

1. Key Generation & Distribution

   • The bridging contract generates a Bitcoin key, then splits it into multiple fragments (e.g. via Shamir’s Secret Sharing).
   • Each fragment is encrypted for a specific stake pool operator, using that operator’s on-chain public key.
   • The contract publishes these encrypted fragments on-chain, so nobody sees the raw private key.

2. Minting cBTC

   • User deposits BTC to a 2-of-2 address (part user key, part bridging key).
   • A proof (e.g. NiPoPoW) is submitted to the bridging contract.
   • The contract “mints” cBTC tokens on Cardano for that user, representing the locked BTC.

3. Burn-to-Release Process

   • To unlock the BTC back on Bitcoin, the user burns their cBTC on Cardano.
   • The contract detects this burn event and proceeds to reassemble its share of the private key.

4. Recombining Key Fragments

   • Each stake pool operator retrieves its own encrypted fragment from the chain, decrypts it locally (with its private key), and provides a partial signature or partial decryption to the contract.
   • Once the threshold (e.g. t-of-n stake pools) has cooperated, the contract can reconstruct its share of the BTC key on-chain.

5. Completing the BTC Spend

   • The contract then co-signs (with the user’s key) a transaction that releases BTC to the user’s chosen address on Bitcoin.
   • This happens automatically as soon as enough stake pool operators submit valid partial decryptions.

Why It’s Trustless & Automated

• No single stake pool operator or the contract itself holds the entire private key; collusion of at least t is required.
• The bridging contract enforces “burn cBTC first” before releasing key material to sign the BTC transaction.
• Stake pools already run infrastructure for Cardano, so they can securely manage key fragments in a similar automated fashion.
• Everything from fragment distribution to partial-sig aggregation is orchestrated by the contract, on-chain, ensuring transparency and preventing unauthorized BTC spends.

I was not sure about this, so additional info:

How the User Gets a Deposit Address & Provides a NiPoPoW

1. Contract Generates Address

   • First, the user calls the bridging contract on Cardano asking for a unique deposit address on Bitcoin (e.g., a 2-of-2 multi-sig address).
   • The contract creates this address by combining the user’s public key with the contract’s bridging key.

2. User Deposits BTC

   • The user sends BTC to that newly generated address.
   • Once enough confirmations have passed, the user (or any off-chain service) can gather a NiPoPoW (Non-Interactive Proof of Proof-of-Work) that proves “X BTC was deposited to that address.”

3. User Submits NiPoPoW

   • The user returns to the Cardano contract and submits the NiPoPoW proof, indicating the transaction ID, the address, and the confirmed deposit.
   • The bridging contract verifies the proof on-chain to confirm the BTC is locked at the multi-sig address.

4. Contract Mints cBTC

   • After successful verification, the contract mints the corresponding amount of “cBTC” for the user on Cardano.

Thus, the user first obtains a fresh deposit address (step 1), sends BTC to it (step 2), then uses NiPoPoW (steps 3–4) to prove that deposit to the bridging contract—no trust in a single custodian required.

the idea is a wip

hope it helps