P2PChange - P2P, non-KYC, and non-custodial crypto exchange with a reward system

[liberdapps]

Hi!

It’s a well known fact that keeping your funds in centralized exchanges is a big no-no, even though a lot of people still ignore that fact and, unfortunately,  have to learn the lesson in the hard way. Besides hacks and funds freezing, another big issue concerning centralized exchanges has to do with regulations (which are coming!) and lack of privacy.

Given that context, I’ve been working on a peer-to-peer and non-custodial solution for people that want to swap stablecoins (USDT, USDC, DAI, BUSD) and Bitcoin (real BTC, not wrapped, pegged, etc). But before further developing the project, I thought that it’d be wise to at least get a sense if that’s something that the community would actually use.

I’m aware that we have alternatives to traditional exchanges for swapping stablecoins and Bitcoin  (like FixedFloat, SideShift, ec) and other no-KYC solutions (https://kycnot.me). But, except from Bisq, I think they’re all centralized solutions — that again, may be vulnerable to regulations, may change terms at any time and even compromise your privacy —  that require you to trust them. Also, even in Bisq, you have the mediator risk, i.e, if a trade doesn’t go well, you need to trust their arbitrage system to resolve the dispute correctly.

My idea is to build a decentralized and p2p solution to the greatest extent possible, involving no intermediaries and relying only on smart contracts, timelocks and incentive mechanisms. Also, the idea is that the solution will be a 100% client-side app, meaning that all you’d need is a .HTML page and a web browser to use it, adding a bit more of censorship resistance on top the smart contracts + Bitcoin network.

I have written up the design for that solution but, before giving more details and asking for further feedback, I’d really love to know: is there a real demand for such a solution here? Would you personally use it?

Thank you!

[1715043087]

1715043087

[1715043087]

1715043087

[1715043087]

1715043087

[1715043087]

1715043087

[1715043087]

1715043087

[liberdapps]

Ops, sorry, I just realized I posted it in the wrong area and I can't self-delete my message. Could anyone please move it to the main Bitcoin Discussion topic?

[suzanne5223]

When I saw this thread I thought you said you created a p2p and noncustodial exchange services website but after going through the site I see that you only provided the list of sites that contributes to decentralization, privacy, and anonymity.
I can see that there's no advertisement or referral link. Will this change in the future?
Have you tested all the listed sites?
How are you going to manage the site?

[liberdapps]

Thanks, LoyceV, for pointing that out!

suzanne5223, sorry, I wasn't clear enough. So, I AM building a p2p and non-custodial exchange but I wanted to see if there's actually demand for such a service here before developing it further.

The list of no-KYC exchanges I posted isn't managed by me, and I haven't tested their solutions. I just posted the link to show projects which are similar to the one I'm currently building, but I believe my approach could be more trustless and decentralized than the services in that list.

I'm happy to give more details about the project I'm building and ask for further feedback if people find such a project useful.

Thanks again.

[OmegaStarScream]

There's definitely going to be demand for it, but the question here is how are you going to get people to join the platform? Because you see, the problem with most decentralized and P2P platforms now is liquidity. If you manage to solve that, then I really don't see why would anyone go elsewhere. Especially if it is trustless as you say. It's also worth mentioning that there is a similar protocol that is being built, it's called Thorchain protocol and currently has ~180M TVL.

[liberdapps]

Thanks for the reply, OmegaStarScream !

Yeah, you mentioned a crucial point: I think bringing liquidity to the exchange, i.e., getting people to use it is the most challenging thing I can see for the success of the project. In fact, my hope is that I could start building some community around the project here and grow it organically. Maybe that that same strategy could be applied to other forums/discussion groups but not sure how efficient that could be. So, yes, the liquidity issue is a big one and I still need to work on that. Open to any ideas you might have, BTW!

Regarding the Thorchain, I've heard about it but I haven't studied at depth their approach. Thanks for pointing it out.

I’m also going to create a GitHub page describing the protocol for the exchange I’m proposing, so hopefully that can bring more clarity and be an incentive for other people here to provide feedback.


Thanks again.

[OmegaStarScream]

Honestly, I don't see how else you would do it. In every crypto decentralized exchange I know, usually, developers go with liquidity pools. So for example, the users add usdc and btc to your platform, and in exchange, they'll earn fees on every transaction that happens on that trading pair (based on their share of course).

It would've been easier if you were going to make a P2P platform where fiat is involved. I would've then suggested you reach out to some users in the currency exchange board and try to cut some kind of deal with them, so they start selling in your platform but for crypto pairs, there's is already so many CEXes and DEXes out there, that it makes it difficult to attract new users. Sure, they're not "trustless" but the reality is that the average user doesn't care about that.

I'm also curious, are you planning to develop this on your own? Not to bring you or anything, but if you're planning to go with this, I don't think it would be that easy of a task. Not because I think you lack the skills but I've been following thorchain for quite some time now, so if you're really trying to go with the same concept, you must know that this could be very time-consuming.

[liberdapps]

Thanks again for the reply, OmegaStarScream!

Regarding incentive mechanisms, yeah, I also thought about giving users a share of the transaction fees happening in the platform, I think that could be an extra incentive for people to use my solution other than being more trustless and  decentralized than other solutions. I think that can be easily accomplished with smart contracts, so I'll see more about that.

Answering to your question: yes, I'm planning to develop that solution on my own and I know it can be challenging. I've been digging into Thorchain's approach and it looks like they have a more complex/elaborated system, involving external validators, pegged tokens and other governance mechanisms. My approach is definitely simpler, relying more on smart contracts, cryptography and incentives. In fact, I've written up the design proposal for my solution here: https://github.com/liberdapps/SwapBTC

Any comments/feedback would be deeply appreciated.

[LoyceV]

I've written up the design proposal for my solution here: https://github.com/liberdapps/SwapBTC

Bob, who wants to sell Bitcoin, needs to already own an altcoin (ETH or BNB) to pay the security deposit. And that brings me to a more fundamental problem: this "decentralized" trade relies entirely on a centralized altcoin (ETH or BNB) and on stablecoins, which are as custodial as it gets.

[OmegaStarScream]

Answering to your question: yes, I'm planning to develop that solution on my own and I know it can be challenging. I've been digging into Thorchain's approach and it looks like they have a more complex/elaborated system, involving external validators, pegged tokens and other governance mechanisms. My approach is definitely simpler, relying more on smart contracts, cryptography and incentives. In fact, I've written up the design proposal for my solution here: https://github.com/liberdapps/SwapBTC

Any comments/feedback would be deeply appreciated.

Thank you for your reply but there must be something I'm not getting right then. Maybe you could shed some light for me on this:

Code:

#5.....and signal to the smart contract that he has made the payment.

How is it possible for two assets in two different blockchains to communicate with each other?

Correct me if I'm wrong but from my understanding, this is the reason why we don't have (fully decentralized) DEXes that work on multiple blockchains and this is also why developers use wrapped bitcoin instead of the real BTC. Isn't?

[liberdapps]

I've written up the design proposal for my solution here: https://github.com/liberdapps/SwapBTC

Bob, who wants to sell Bitcoin, needs to already own an altcoin (ETH or BNB) to pay the security deposit. And that brings me to a more fundamental problem: this "decentarlized" trade relies entirely on a centralized altcoin (ETH or BNB) and on stablecoins, which are as custodial as it gets.

You're right! My assumption was that people using stablecoins are comfortable with the risks of holding these assets, i.e., centralization. And if they hold it, they're already relying on more centralized blockchains (Ethereum, BSC, etc) and using ETH/BNB to pay for transaction fees, so I thought that my solution would be basically okay for these people since it wouldn't imply in more centralization that people are already exposed to.

Answering to your question: yes, I'm planning to develop that solution on my own and I know it can be challenging. I've been digging into Thorchain's approach and it looks like they have a more complex/elaborated system, involving external validators, pegged tokens and other governance mechanisms. My approach is definitely simpler, relying more on smart contracts, cryptography and incentives. In fact, I've written up the design proposal for my solution here: https://github.com/liberdapps/SwapBTC

Any comments/feedback would be deeply appreciated.

Thank you for your reply but there must be something I'm not getting right then. Maybe you could shed some light for me on this:

Code:

#5.....and signal to the smart contract that he has made the payment.

How is it possible for two assets in two different blockchains to communicate with each other?

Correct me if I'm wrong but from my understanding, this is the reason why we don't have (fully decentralized) DEXes that work on multiple blockchains and this is also why developers use wrapped bitcoin instead of the real BTC. Isn't?

So, the idea here is that the trading process would be mostly governed by a smart contract on the altcoin blockchain. Once Alice generates a public Bitcoin address and Bob sends BTC to that address, Alice can be confident that she'll get the Bitcoins once the transaction is confirmed by the network. It's Bob's responsibility to signal to the altcoin blockchain (ETH, BSC, etc) that he has transfered the Bitcoins. Once he does it, the smart contract will give Alice a time X to verify that the payment has been made and either release the stablecoins to Bob or reject the trade -- which happens directly in the smart contract. If Alice doesn't act on time, the smart contract will allow Bob to get the stablecoins, so Alice has the incentive to act on time here. That system relies on incentive mechanisms. Does that make sense?

[moderator's note: consecutive posts merged]

[SFR10]

In fact, I've written up the design proposal for my solution here: https://github.com/liberdapps/SwapBTC

Any comments/feedback would be deeply appreciated.

It doesn't seem to be fairly balanced... In your proposal, the buyer ^{[AKA Alice]} had more leeway to influence or rather change certain situations in her favor...

• If Bob never sends the Bitcoins or never marks the trade as paid, after T1, Alice will be able to cancel the trade, unlocking their stablecoins and also getting Bob’s security deposit as a punishment to Bob not following the terms.

  That's absurd ^{[bolded parts]}! Perhaps there might be a way to automate the first part...
  
  

• Once Bob marks the trade as paid, Alice will have a time T2 to verify that the payment has been correctly made and either confirm or reject the trade.

  What'll happen if Bob sends the correct amount but Alice intentionally rejects the trade?

[liberdapps]

Hi, SFR10!

Thanks for the feedback!

Let me try to address your concerns:


1. The security deposit that Bob puts is meant to act like a anti-spam barrier, i.e, to prevent malicious users simply taking offers without intending to complete the trade, removing liquidity from buyers. I thought that this security deposit could be as low as the transaction fees that Alice would need to pay in order to cancel the trade after the expiring period. But perhaps it can indeed be eliminated. Since the logic is mostly governed by a smart contract, Bob would need to pay for the transaction fees in order to initiate trades, so maybe the transaction fee itself can act like a anti-spam feature and we could indeed remove the extra security deposit. Would that seem reasonable to you?


2. If Bob sends the correct amount but Alice rejects the trade, she must cancel the trade and release the one-time bitcoin private key to Bob so that he can get a refund on whatever funds he might have sent. So, at the end, Alice stays with her stablecoins and Bob gets back his Bitcoins. It's also worth mentioning that canceling a trade also incurs in transaction fees that are higher than the normal case where Bob sends the correct funds and Alice just accepts the trade, so the idea is that Alice would only cancel trades (and pay higher fees) when necessary, i.e., Bob never sends the payment or sends an incorrect amount. Does that make sense?

[SFR10]

Thank you for addressing my concerns, I appreciate it...

• Bob would need to pay for the transaction fees in order to initiate trades, so maybe the transaction fee itself can act like a anti-spam feature and we could indeed remove the extra security deposit. Would that seem reasonable to you?
  

  Yes, that seems more reasonable to me, especially since the security deposit would've defeated the purpose ^{[to a small extent]} of using such platforms for those who don't have smaller amounts of the coin that they wanted to buy.
  
  

• It's also worth mentioning that canceling a trade also incurs in transaction fees that are higher than the normal case where Bob sends the correct funds and Alice just accepts the trade,
  

  That's interesting ^{[am I right in assuming that it acts as a penalty?]}... May I know how these Tx fees would be calculated?

[liberdapps]

Hi, SRF10, thanks for the reply!

• Yes, that seems more reasonable to me, especially since the security deposit would've defeated the purpose ^{[to a small extent]} of using such platforms for those who don't have smaller amounts of the coin that they wanted to buy.
  

  Awesome! Thanks for the insight here! I'll change the design to eliminate the security deposit.
  
  

• That's interesting ^{[am I right in assuming that it acts as a penalty?]}... May I know how these Tx fees would be calculated?
  

  Sure. Yes, just like the case where Bob needs to pay transaction fees in order to start a trade, Alice also needs to pay for transaction fees when accepting or rejecting a trade. The transaction fees are actually the network fees needed to transact on the stablecoin blockchain (i.e, the gas fees for the Ethereum, BSC, RSK, etc). The actual transaction fee will depend on the network conditions + the total amount of gas needed to execute the smart contract call, i.e, a call to accept or reject the trade. If Bob sends the correct amount of BTC to Alice, Alice will just need to pay the network fees for releasing the stablecoins to Bob, so just 1 transaction and 1 fee. If Alice decides to reject the trade, she must do it in two steps: (1) make a call to cancel the trade and (2) make another call to release the one-time private BTC key to Bob, so that he can get a refund on his BTC. So, in the cancel case, Alice needs to pay 2 transaction fees, and it can indeed be a counter-incentive for her to cancel trades deliberately.
  

I hope that makes sense but, please, let me know otherwise.

Thanks again!

[SFR10]

Sure. Yes, just like the case where Bob needs to pay transaction fees in order to start a trade, Alice also needs to pay for transaction fees when accepting or rejecting a trade. The transaction fees are actually the network fees needed to transact on the stablecoin blockchain (i.e, the gas fees for the Ethereum, BSC, RSK, etc). The actual transaction fee will depend on the network conditions + the total amount of gas needed to execute the smart contract call, i.e, a call to accept or reject the trade. If Bob sends the correct amount of BTC to Alice, Alice will just need to pay the network fees for releasing the stablecoins to Bob, so just 1 transaction and 1 fee. If Alice decides to reject the trade, she must do it in two steps: (1) make a call to cancel the trade and (2) make another call to release the one-time private BTC key to Bob, so that he can get a refund on his BTC. So, in the cancel case, Alice needs to pay 2 transaction fees, and it can indeed be a counter-incentive for her to cancel trades deliberately.

Thank you for the in-depth explanation... It seems that I misunderstood that part yesterday since you're basically referring to the Tx fees collectively, but what I had in mind was about an added function in the smart contract ^{[not sure if it's possible since my knowledge is quite limited in regards to such things]} that would've deducted a small amount for canceling certain types of deals.
^{- Everything makes perfect sense now [thank you once again]}

[liberdapps]

Hello!

Thanks again for all the feedback here!

I was doing some review and getting more feedback concerning the project and realized a flaw in the previous design where Alice decides to cancel the trade, exposing her private key to Bob (so that he can get a refund). The issue is that, since Alice knows the private key, she could front run Bob by both getting the stablecoins and transferring the Bitcoins to another address before Bob has a chance to do it.

It turns out that a better system should have a mediator role and a good incentive mechanism for people to use the platform, so I have a better proposal with a better incentive mechanism and examples here: https://github.com/liberdapps/P2PChange


I’d be grateful if anyone could take a look and share any thoughts.

Thanks!

[SFR10]

It turns out that a better system should have a mediator role and a good incentive mechanism for people to use the platform, so I have a better proposal with a better incentive mechanism and examples here: https://github.com/liberdapps/P2PChange


I’d be grateful if anyone could take a look and share any thoughts.

How smart contract selects and specifies mediators for each of the trades?
^{- I hope it doesn't have something to do with the other traders on the platform.}

• 10. If Alice doesn't release the funds to Bob after 24 hours and the smart contract mediator verifies that Bob has sent the INCORRECT amount:
  ~Snipped~
  The smart contract will automatically recalculate how many stablecoins the amount of bitcoins corresponds to — using Alice’s stablecoin/bitcoin price — and refund Alice the extra stablecoins locked. For example, if Bob asks for 500 stablecoins but only send bitcoins worth of 200 stablecoins, 300 stablecoins go back to Alice.

IMO, 24 hours is a bit too long before the mediator jumps in... You might want to also consider allowing Bob to send the remaining amount with a second transaction.

[liberdapps]

Thanks for the reply, SFR10!

How smart contract selects and specifies mediators for each of the trades?
^{- I hope it doesn't have something to do with the other traders on the platform.}

At first, I'll be the mediator since I'll develop the smart contract and it'll be of my total interest to do a good job in order to attract new users. In the future, I was hoping to invite some reputable escrow members to join the platform.

IMO, 24 hours is a bit too long before the mediator jumps in... You might want to also consider allowing Bob to send the remaining amount with a second transaction.

That's a good point. I suggested 24 hours so that traders would consider that acting dishonestly would leave their funds locked for a reasonable time. Perhaps 8-12 hours is a better compromise? Regarding allowing Bob to send the remaining funds in further transactions, that's a good point! I'll consider that. Thanks!

[SFR10]

Thanks for the reply, SFR10!

You're very welcome.

In the future, I was hoping to invite some reputable escrow members to join the platform.

That'd be great, but despite offering an incentive for such users, you'll probably have a hard time convincing them to join in ^{[judging by a few other recent projects that were also looking for escrow providers]}.
^{- In case you ever come to that point, you may refer to "these two (#1 and #2)" lists.}

I suggested 24 hours so that traders would consider that acting dishonestly would leave their funds locked for a reasonable time. Perhaps 8-12 hours is a better compromise?

When you put it that way, it makes more sense to stick to 24 hours instead.