Introducing Our New Whitepaper on Escrow-Less Bitcoin-Collateralized Lending

We are thrilled to release our latest whitepaper, elaborating on our innovative Escrow-Less Bitcoin-Collateralized Lending protocol. This pioneering system leverages the power of Discreet Log Contracts (DLCs) and Hash Time Lock Contracts (HTLCs) to create a trustless, peer-to-peer lending environment that aligns with the ethos of decentralization and user empowerment.

Empowering Users with Our Architecture

Our protocol is meticulously designed to empower users by allowing them to borrow against their Bitcoin while retaining full control over it. We believe that this is not just a technological advancement, but a crucial step towards crafting a more decentralized, trust-minimized, and secure financial ecosystem. By eliminating the need for intermediaries, we aim to give users greater autonomy and flexibility, freeing them from traditional constraints.

Addressing Market Needs for Peer-to-Peer, Trustless Lending

Extensive market research highlights a significant, growing demand for peer-to-peer, trustless lending solutions. Users consistently expressed a desire for more control over their assets and greater flexibility in their lending options. Our Escrow-Less Lending protocol directly addresses these needs, providing a robust framework that enhances user control while maintaining the integrity and security of the lending process.

Exploring the Potential of Ark for Microloan Liquidity Management

Initially, our focus was predominantly on micro-loans. However, user interviews revealed a relatively limited demand for such products at this time. Nonetheless, we identified Ark as good solution in the context of Bitcoin microloans. Ark's capabilities could unlock new possibilities and efficiencies, making microloans more viable and attractive.

Remaining Flexible and Adaptable

Even as our primary focus shifts, the potential of Ark continues to intrigue us. Our protocol's design is inherently flexible and adaptable, allowing for continuous refinement and adjustments based on user interest and feedback. Should there be sufficient interest in the future, we are open and ready to explore Ark's integration once again to better serve our users’ needs.

Revolutionizing Bitcoin Borrowing and Lending

We firmly believe that our Escrow-Less Bitcoin-Collateralized Lending protocol has the potential to revolutionize the borrowing and lending landscape within the Bitcoin ecosystem. Our commitment is steadfast; we aim to make this innovative protocol a reality and will diligently work to iterate and improve based on user feedback. Together, let’s shape the future of decentralized lending.

Your Feedback Matters

We invite you to delve into our whitepaper and share your thoughts and feedback on this groundbreaking approach. Your insights are invaluable as we strive to create a more user-centric, flexible, and secure lending protocol. Read the full whitepaper here

Feel free to reach out with your thoughts, questions, or suggestions. We’re eager to engage with you and iterate based on your valuable input.
CORRECTION:
As @supertestnet correctly points out in #648625, the protocol we propose is not trustless. The linked whitepaper does not claim such a thing, but our original post here used the word "trustless" incorrectly.
A DLC-based protocol necessarily involves an oracle, which acts as a trusted third party.
Sorry for the mistake.
reply
DLCs create a scenario that is equivalent to a 2 of 3 multisig
Alice has one key and Bob has another and neither one can spend the money on their own, they either need to spend it cooperatively or, if one of them refuses to cooperate, the victim needs to use a secret reveled by the DLC oracle to spend the money. That's essentially a 2 of 3 multisig, just with different math
And since it's essentially a 2 of 3 multisig, there is an escrow: the oracle. Just like hodlhodl is an escrow when they have the third key in their lending product.
And for the same reason, it's not trustless: the oracle can collude with Alice to always give her the money, or the oracle can do the same for Bob. Both users have to trust the oracle not to do that.
It is wonderful that you're making a new product and I hope lots of people freely decide to use it, but only if you tell the truth. This is not trustless or escrowless. You can't have those properties if you are relying on DLCs.
reply
Hey, @supertestnet! I'm a big fan of your work, so I'm very happy that we got your eyes on our proposal.
DLCs create a scenario that is equivalent to a 2 of 3 multisig Alice has one key and Bob has another and neither one can spend the money on their own, they either need to spend it cooperatively or, if one of them refuses to cooperate, the victim needs to use a secret reveled by the DLC oracle to spend the money. That's essentially a 2 of 3 multisig, just with different math And since it's essentially a 2 of 3 multisig, there is an escrow: the oracle. Just like hodlhodl is an escrow when they have the third key in their lending product.
I disagree with the premise that the oracle in a DLC protocol is an escrow in the traditional sense. The oracle is a trusted third-party that can operate without knowledge of the contracts that it signs for. Alice and Bob can set up a contract and the oracle does not need to see any of their coins or what they are doing with them. In comparison, an escrow is keenly aware of what goes on between Alice and Bob during contract setup, and if there is a dispute. With this knowledge, it's easier for an escrow to collude with Alice or Bob.
But I think you already know all this, so I guess we disagree on the semantics of what an escrow is. I think an oracle is sufficiently different to warrant a different category.
And for the same reason, it's not trustless: the oracle can collude with Alice to always give her the money, or the oracle can do the same for Bob. Both users have to trust the oracle not to do that.
I absolutely agree with you here. The protocol is not trustless. The linked whitepaper makes no such claim. In fact, section 6.1 is titled "Trusting the oracle", under "Limitations and future work".
Our post here does use that language, which is incorrect. I can take the blame for that: I did not read our post carefully before we hit submit. We can't edit it anymore, but we will pin a comment to the top to rectify this.
reply
interesting. will read later.
reply
Hypothetical situation: If I want to redeem my sats before Ark's vUTXOs, can I do it or will I need to wait?
reply
This new paper introduces a protocol that would work without Ark.
reply
Interesting. I'll read later.
reply
Bullshit crap. This system is a reminiscence of fiat system (spend what you do not have). Fuck that system. If I want to spend, I just spend what I have. If I do not have enough I will just work hard until accumulate what I need to spend. NEVER GO BACK TO DEBT.
This is how Saylor / Blackrock will get your sats! YOU HAVE BEEN WARNED!
reply
Good to know that you're not our primary target for this product.
People are massively using trust based and centralized/custodial services, we're offering an alternative!
reply
collateral loans with Bitcoin
You are pushing people back to fiat. You are supporting the use of fiat. Bitcoin was created to get rid of fiat not to keep using it.
you're not our primary target for this product.
I will fight all the time against these kind of "services". Are pure evil.
reply
We're addressing an existing market need by providing a solution to minimize risks for users. This way, users can still borrow against their Bitcoin while maintaining control over it.
"If you don't believe it or don't get it, I don't have the time to try to convince you, sorry."
  • Satoshi Nakamoto
reply
borrow what? fiat?
reply
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.