At Verify, we’re building a reputation protocol on the Ethereum blockchain. In this post we will talk about why we exist and how we are different from the previous attempts like Monetha and UTRUST. So let us jump right into it:
As crypto-currencies started to gain popularity, people started using them alongside fiat to make purchases. There are services and shops that accept payments using crypto-currencies. Entities that accept crypto-currencies for their product usually wait a number of confirmations before sending the item (resulting in some degree of protection against a double-spend attack by malicious buyers). However for buyers, this is risky business. You are giving money to a seller without any kind of insurance that you will receive the item. Even if you get the item, nothing guarantees that you can get your money back if the item is not as described or faulty.
This lead to the rise of what is known as escrows. They are third party services or entities that hold the money until the seller delivers the item, and the buyer indicates their satisfaction with said item. It is meant to protect the seller from fraudulent buyers and buyers from fraudulent sellers. But does it really solve the problem?
Not really. Buyers may like it if they could land a trusted and affordable escrow service but sellers hate it because they have to wait long for their payments. Since sellers have to approve the use of escrows in the first place, guess what happens?
That’s right: sellers don’t offer escrows. Also, cryptocurrencies are highly volatile so if the seller is selling an item for 1 ETH which equates to say 295 USD by the time the seller receives his money it may be at a lower value say 285 USD.
A better solution must exist to enable commerce using cryptocurrencies. Before deciding on the best solution we need to boil down the problem to its essence. If you really consider the previous example, you’ll find the problem with commerce using cryptocurrencies is trust, between the buyer and the seller. But how do we solve it?
Previous Attempts at Solving Trust
Before arriving to the solution let us explore previous attempts and existing solutions meant to solve this problem. Let us start with existing solutions. It’s important to clarify, out the gate, that there isn’t a fully functioning solution that solves the trust problem for cryptocommerce. Solutions exist that facilitate money transfer between buyer and seller; meaning they basically do what multi-sig wallets do.
Aside from these solutions, one noteworthy attempt made to solve the trust problem through the creation of a trust and reputation system is Monetha. While it is not fully operational (and a solution hasn't even been created yet), we could gather from published material that their focus is to facilitate a smooth transaction between the buyer and the seller using Ethereum — with an automatic rating system that according to the transaction details would rate the buyer and the seller. The idea sounds appealing at first, but lacks one crucial element: buyer protection. Monetha displays a rating for stores, but fails to offer the escrow mechanism that would facilitate dispute resolution between buyers and sellers. They are thus unable to offer buyers a refund if the transaction does not work out. The only recourse they offer is a “hit” to the seller’s reputation — the damage to the buyer, however, would be irreversible (given that crypto-payments are strictly one-way). Further, Monetha only accepts Ethereum based payments, completely disregarding the largest cryptocurrency in existence: BTC.
Another issue with Monetha is that the feedback system is automated using smart contracts; this means that there is no mean for end users to express their true experiences, it is mere system rating users based on given conditions.
A recent attempt to solve the problem of trust is that employed by UTRUST. Before proceeding, it is worth mentioning that this material is based entirely on the UTRUST whitepaper and website. The team has not delivered any product to date, and do not even tout an MVP. Now, unlike Monetha, UTRUST promises buyers a refund in the form of UTRUST tokens in two cases where 1) the seller voluntarily agrees to refund the buyer or 2) when the UTRUST resolution team decides on refunding the buyer; in the case of the latter, a 2% fee is levied on the amount on hold. The way UTRUST achieves this is through holding the transaction value until the transaction is completed. The hold period changes for sellers if they perform well. This protects buyers from sellers and vice versa. It fails to consider the inherent cost in exchanging tokens to fiat (typically 0.5% each way, resulting in a 1% fee on the total transaction).
Also, ratings are automatically generated by machines, not allowing both buyers and seller to express their true experiences. Another issue with UTRUST is that the reputation system at hand is domain specific; in this case specific to payments. The final issue is the same one we started with: the lack of domain and execution record for the team. The white paper only outlines a high-level description of a reputation system with no consideration for crucial implementation decisions related to hold periods, recourse and risk management (e.g. for various forms of established reputation system vulnerabilities like Sybil attacks, ballot stuffing, etc.).
Enter Verify
Then there is Verify. Verify addresses all issues and drawbacks in previous attempts by providing a reputation-first protocol. The reputation protocol is a layer where applications interact with to influence trust among
interacting parties. The protocol is fueled and also fuels the applications built on top of it. This means that applications built on top of the Verify protocol utilize the reputation rules and data it has, at the same feeding it with newly generated data. This allows for various applications, and not be limited to specific domain.
The Verify protocol assigns participants a reputation score that is dynamically adjusted based on their participation in the network. Each transaction or participation in the network is ensured using CRED tokens; i.e an insurance policy for every transaction that happens in the network. The insurance policy is set to protect both buyers and sellers. Note here that a transaction does not necessarily mean payments it means any kind of participation between parties in the network.
Verify protocol allows for custom applications catered for various domains. One application that kickstarts the reputation protocol is Verify payments. Verify payments enables two key advantages to buyers and sellers. For buyers it is a 100% protection and for sellers it allows for much better cash flow through faster payments. The only fees in place is the 1% insurance fee.
Sellers can easily integrate Verify payments in the checkout page allowing for seamless transactions. When a buyer decides to buy from the seller, Verify payments will show the reputation of the seller and accordingly facilitate the payment with the insurance policy for that transaction. The reputation protocol then governs the next step. If the seller has no reputation then the value of the transaction will be converted to stable coin to protect the seller and the buyer from cryptocurrencies volatility and the stable coin will be kept in escrow until buyer receives his/her item. If the seller has reputation, then a CRED ceiling is extended to him or her that would make them eligible for advanced payment. Upon every transaction the buyer and seller will be given the opportunity to rate the transaction to express their true experiences; here is a link to our whitepaper for more details.
Verify.as
Verify is a Reputation Protocol for buying and selling things using
cryptocurrencies → https://verify.as/