Hi l3pox,

Thank you for your comments! I will answer below:


The idea is to open it, yes, but not with the objective of becoming silk road 2.0. However, I do not think I can block specific products in the smart contract (at least in any effective way that would not be easily skipped). In the front end app it could be possible to block by hand, but the front end app is not the only way to interact with the smart contract...


That is a really good point. Initially I believed that I needed the wallet account to be able to retrieve the data from the smart contract, but now thinking about it it should be feasible. I will certainly try to implement this soon.


Initially I thought about a system to manage disputes with another specific role of users (let's call them "dispute resolvers") for that purpose. For example, selecting 5 of these dispute resolvers randomly, making them chat with the sender and receiver to cast a vote on who is right about the dispute, and selecting the winner of the dispute by majority and giving part of the loser's deposit to the dispute resolvers. However, I thought it would be difficult to set up and wasn't sure on how easy would it be for wrongdoers to fabricate false proof of shipping... So I decided to first go for a simpler approach, which is to make sure that all users are incentivized to behave correctly by setting up deposits ad studying all potential situations. Here is the diagram of all possibilities and how much money would be lost for each user en each case.



The principle is that if the receiver does not receive the product, it will not finalize the offer, penalizing himself but also the sender. To avoid blocking the funds forever in the escrow, there is something called lottery, which allows any user to forfeit offers that have been accepted but not finalized in a given amount of time (of the order of months), giving the user that triggered the forfeiture 10% of the funds locked, the contract creator 10 % and another random user that has previously interacted with the smart contract the remaining 80% (as the lottery winner).

The worst situations are:

• When the sender does not send the product and the Receiver confirms the delivery, effectively transferring unfairly from the receiver to the sender 100% of the price of the product. To avoid this happening, the receiver can choose to not confirm the delivery, but in that case, the receiver wold loose 150% of the price, instead of 100%. Another option is to confirm the delivery but give the sender a bad review. The idea is that users can build a reputation that allow the rest of the users to trust them.
• When the receiver receives the product but does not confirm the delivery. The main purpose of the deposit of the receiver is to avoid this situation. If the receiver did not have to provide a deposit, he would not loose anything by not confirming.

Yes, there is a fee for 1% of the product price and 10% for the forfeitures.


Also good point, I have deployed to the networks that I know better, but I certainly look forward to deploying in other networks.

Hi all,

I just wanted to show you a project that I have been working on and maybe get some feedback about it. It is called Palket: the Pal-to-Pal market. The idea is to use a smart contract as an escrow to facilitate the exchange of goods for cryptocurrency. It would also allow users to post offers either for selling a product, in a similar fashion to ebay, or even for requesting to receive a product. The idea is that senders (sellers of the product) would be interested to sell a product to gain a profit in crypto and they would be able to either sell their own products or to dropship products from any website, from Alibaba to Amazon. Also, the receivers (buyers of the product) would be interested in paying that profit to the senders in exchange of using the cryptocurrencies directly, without needing to convert them to fiat and therefore, without needing to pay large fees and reveal their wallet identities to the governments (whom may request additional tax payments).

The project depends on a smart contract that acts as an escrow and database for offers and user profiles. Currently the smart contract is deployed in Ethereum Mainnet, Ethereum Sepolia Testnet, Polygon Mainnet, Polygon Amoy Testnet and RSK Testnet. The smart contract can be interacted with through the frontend app deployed at https://palket.github.io/app/, which also includes an integration with XMTP, which is a decentralized P2P chat, to be able to transmit sensitive data such as the delivery address to the sender without needing to publish it anywhere. Feel free to give it a try in the testnets (you will just need testnet gas, which you can get from any faucet such as https://www.alchemy.com/faucets) and do not hesitate to provide any kind of feedback, it is very much appreciated.

Some areas of improvements that I see is a better management for the shipping fee and a more structured description of the product. Currently the description of the product is too open, 200 characters to write anything, but it would be nice to have smaller sections like title, description, tags, delivery notes, etc. In any case, it could be handled by the frontend and parsing the inputs into the raw description, so not change in the smart contract may be needed.

What do you think? Is the idea worth it?

BR,

Palkedev

PD. This is my first post, please be good.