FAQ

wBTC, tBTC and others require you to send your BTC to their custody. With dlCBTC, your Bitcoin remains in your custody, in a locked state.

As proposed in this article: https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953 Quick comments: The paper dates one year back, and it describes a theoretical approach. What we do has been theorized, developed and tested over several years (starting with Suredbits' pioneering work 2019 onward). There is a saying: "In theory, theory and practice are the same. In practice, they're quite different." Implementing the system in practice will likely raise a lot of additional questions At first read, it's clear that the user has to trust the system that generates the secret keys and the Bitcoin deposit addresses. They make the point that only one generator has to be truthful, but I'm still thinking through how that works. Also: the WE system sounds like an enhancement to Avalanche's BTC.B. There, 8 wardens in Intel SGX enclaves secure the system. 6-of-8 is required to verify a transaction. In the WE paper, they propose an N-of-N to secure the system.

* Stacks sBTC is focused on DeFi in the Stacks ecosystem only. dlcBTC is focused on Ethereum primarily, and can bridge to other chains from there (potentially using CCIP, LayerZero or Axelar) * Stacks sBTC has a different security model and uses Stacks validators. dlcBTC uses DLCs * Stack’s design allows for more flexibility, as they produce both the wrapped Bitcoin token and the chain. DLCs are more rigid but do not require Stacks smart contracts, validators or the Stacks chain

- Atomic swaps are just simple swaps, so their functionality is very simple. DLCs escrow Bitcoin and move it based on any smart contract logic - DLCs are guided by off-chain data, e.g. from a smart contract and an oracle network. Atomic swaps are triggered by the state of two blockchains, but cannot enforce conditional logic based on off-chain information (e.g. asset price)

dlcBTC's use of DLCs, paired with a network of decentralized attestors, eliminates the risk of theft. The BTC depositor "self-wraps" to lock with himself, and only the original depositor can ever receive BTC funds..

Yes, dlcBTC can be pitched to large institutions like Blackrock, with the primary message being the ability to earn yield on BTC held in vaults. However, the sales process is significantly longer, typically spanning 2-3 years, akin to elephant hunting. A major technical difference in such cases is that institutions like Blackrock would not utilize our standard $DLC node operator network. Instead, they would operate a private attestor network, ensuring they have control over the keyshares to the multisig at all times. In this scenario, the product would not be dlcBTC as it is known, but rather a variant, potentially named BdlcBTC. While this situation might not arise frequently, if it does, the response is that we can support this adaptation either as a technology vendor or in a joint venture.

dlcBTC is not a security because: 1. The user (the dlcBTC merchant) self-wraps their own BTC and maintains self-custody 2. There is no scenario where we receive the user’s funds. So, we are not a money transmitter 3. dlcBTC tracks BTC price and maintains its peg through an arb mechanism. So, there is no inherent price appreciation

We do not hold user’s BTC. We make software that lets them lock up their own BTC to use in DeFi protocols. So, we are not a money transmitter and do not require a Money Transmitter License. We do not require SEC or CFTC registration

If merchants in the dlcBTC merchant network are unwilling or unable to redeem dlcBTC for underlying BTC, then the amount of reserve represented by that BTC is effectively illiquid for some amount of time. This can lead to a loss in consumer confidence of dlcBTC and a depeg. This is similar to when, in 2023, Silicon Valley Bank became insolvent and was taken over by NY Department of Financial Services (NYDFS). For a few days, SVB’s USD reserves backing USDC were illiquid. This led to a loss in consumer confidence and a temporary depeg. (This also created an opportunity for investors to buy USDC at a discount — as low as $0.85 — which they later redeemed for the full $1.) This scenario can happen for a number of reasons, including: * Insolvency: The depositor who holds the DLC becomes insolvent and is unable to obtain authority to redeem the dlcBTC. In this case, the ownership of the DLC would move through bankruptcy courts to an eventual new owner. During that time, the BTC remains illiquid. * Loss of Private Keys: If the dlcBTC merchant loses their private keys, they may be unable to retrieve the underlying BTC. In this case, the underlying BTC is permanently illiquid and inaccessible. * Bad Trades: If the dlcBTC merchant has traded away their dlcBTC for stablecoins or other tokens, and has lost money on those trades, then the merchant may not be able to acquire enough dlcBTC to unlock their DLC position. In such a case, an external entity might buy out their BTC position. The BTC is illiquid until the DLC can be unlocked. We are designing risk management mechanisms to protect the dlcBTC merchant ecosystem from loss of consumer confidence due to these and other liquidity issues.

HTLC refers to Hash Time Locked Contract, which is the most popular way to lock BTC, pending an event within a specific amount of time. DLCs use PTLCs (Point Time Locked Contracts), which can lock BTC on other conditions than just time. We use DLCs to create the self-wrapping mechanism, by enabling dlcBTC merchants to lock their BTC into a multisig that can only pay out to them.

dlcBTC is an oracle-free solution. 1 BTC is equal to 1 dlcBTC. Longer explanation: The original whitepaper refers to a “Bitcoin oracle” that decides whether Alice or Bob “win the bet”. In the way that we’ve implemented DLC.Link, we implement DLCs as a human user entering into a DLC with a protocol. In our design, the “Bitcoin oracle” has been split into a blockchain and a DLC Attestor. The blockchain refers to a smart contract chain such as Ethereum, which emits an event that is read by a DLC Attestor. The Attestor runs an Eth validator node and can verify the event on-chain, before publishing its attestation. So, our attestors are more like relays — they translate a signal from Eth to Bitcoin settlement instructions. Once the event has been verified, the Attestor publishes its attestation which lets the Bitcoin to be moved.

DLC Attestors can never receive BTC, so they cannot steal it. The smart contract risk is: if the system were hacked, the DLC’s unlock could be censored. So, the dlcBTC merchant has deposited BTC, minted dlcBTC, burned dlcBTC but does not receive their BTC deposit back. We are mitigating this through smart contract audits, white hat hacking, bug bounties and other standard crypto protocol security mechanisms. Smart contract risk is always a feature of crypto protocols. However, dlcBTC is unique in that it is impossible for the BTC to be stolen. This is why we can call dlcBTC a “theft-proof” bridge. Read more here: https://www.dlc.link/blog/the-theoretical-risks-of-dlcbtc

Attestors in dlcBTC provide decentralized verification of peg-in and peg-out transactions on Ethereum. They secure the locking and unlocking of Bitcoin without holding user keys, offering an additional layer of security and trust.

dlcBTC maintains user sovereignty by allowing Bitcoin holders to keep ownership and control over their assets at all times, unlike custodial and bridged models that require BTC to be transferred to third parties.

Yes. Our development team has created dlcBTC, an ERC-20 token that looks and feels like wBTC, but operates differently under the hood. Integrating dlcBTC in DeFi protocols is as simple as listing it as accepted collateral. At institutions, this may require separate security and compliance approvals. Also, we’re launching $DLC token in Q3 2024 to decentralize our DLC Attestor network.

DLCs were invented at MIT 6 years ago, but only became feasible with Bitcoin's recent Taproot update (Nov 2021). Taproot added Schnorr signatures and Point Time Locked Contracts (PTLCs), both of which are required to use DLCs in production.