Standard Sharing Economy Protocol for Smart Contract
Blockchain is a good target to establish sharing economy, because the lessor and lessee can connected each other without any intermediates, like Uber or Aribnb. So, the lessor no longer be bothered by high margin cost.
Origin Protocol is the pioneer of sharing economy on top of the Ethereum. We can learn much of things from them.
When you try to develop sharing protocol seriously on Ethereum, you definitely face several problems as follows. Then, I provide solutions for each problems.
1. Different type of assets listing
The asset information is totally different from assets so that asset property structure should be not be fixed format. How to achieve this on Ethereum where the deployed contract is immutable?
The solution is that storing asset properties out side of blockchain. And the blockchain only hold the reference to it. To be more specific, we store asset properties on IPFS, and we store the IPFS hash on the blockchain.
Let’s show example. The bellow JSON is the example of asset property structure. I’ll emphasizes that this is totally free format.
{
title: "xxxxx",
desc: "xxxxx",
pictures: ["xxxxx", "xxxxx", "xxxxx"],
price: {
weekdayPerHour: "00",
weekendPerHour: "00",
},
conditionCharges: {
"xxxxx": "xxxxx",
"xxxxx": "xxxxx",
"xxxxx": "xxxxx"
}
conditionDiscounts: {
"xxxxx": "xxxxx",
"xxxxx": "xxxxx"
}
}Next, show solidity code example. The asset struct hold IPFS hash as a reference to above JSON.
struct Asset {
address payable lessor; // Leassor wallet
string ipfsHash; // IPFS hash, asset
}2. Dispute settlement
For dealing with a dispute, a lessor and a lessee choose an arbitrator beforehand. Once a dispute happen, they ask settlement for the arbitrator. To be more clear, Let’s show an example process.
I. Make Offer
First, a lessee make a rental offer and deposit rental fee. Key points is that the lessee specifying an arbitrator address and a window of dispute.
The arbitrator address is the address of arbitrator. The window of dispute is a window when a lessor or a lessee can request dispute settlement to an arbitrator. This window start after rental end. Only after this window, payment is executed(In most of the case, the lessor obtan total amount of deposit ETH).
function makeOffer( // ID of the offering asset
uint256 assetID, // IPFS hash containing offering detail
string memory _ipfsHash, // Arbitrator address
address _arbitrator // a window of dispute
uint64 disputeWindow,) public payable {}
Ⅱ. Accept Offer
A lessor accept the above offer checking who is the arbitrator.
function dispute(uint256 assetID, uint256 offerID) public {}Ⅲ. Dispute
We assume the following situation.
The rental start but the asset have problems. And the lessor don’t recognize the problems.
Under this situation, the lessee want to get back the deposit ETH, So he ask the arbitrator for help.
function dispute(uint256 assetID, uint256 offerID) public {}Ⅳ. Execute Ruling
Please look at function argument named as ruling. This is the percentage of deposit ETH the lessor can get. In above situation, this value must be less than 100%, like 50%. The lessor get only 50% and the left 50% is backed to the lessee.
function executeRuling(
uint256 assetID
uint256 offerID,
uint8 ruling
) public payable {}In the opposite situation, like the asset was damaged by lessee. The ruling argument must be more than 100%, like 150%. The additional charge is imposed to the lessee as damage charge.
3. Gas cost of available assets searching
Before start of every rental, we should make sure that no double booking exist. This process is a problem in terms of gas cost.
So we execute this calculation totally off chain. We prevent duplicate booking by using “Request and Accept” flow model.
Whenever a rental request come, a lessor make sure that a requested booking is not duplicate. Only then a lessor accepts the request.
4. Rental flow standardization across different type of assets
Let’s consider actual existing rental service. Obviously, the rental operation flow is different from asset types or company strategies. So standardization of rental flow is a serious problem.
As a conclusion, we solve this problem by “off chain cost calculation” and “Add or Redeem funds during rental”. Let’s explain by breaking down the difficulty of standardization as follows.
Ⅰ. Payment method difference
Ⅱ. Booking Expansion
Ⅲ. Booking Cannel
Ⅳ. Penalty charge
Ⅰ. Payment method difference
We categorize payment methods as few types by observing existing sharing economy service. Then, show solutions to each case.
A. Pay 100% when booking
B. Pay more than 100% when booking, like paying insurance fee
C. Base fee + Used fee
D. Charge balance before booking (Required charging a wallet beforehand)
( A ) This case is no problem
( B ) The total cost is calculated totally off chain. On chain hold the calculation result reference to verify off chain calculation integrity. More specifically, the calculation result assumed to be stored on IPFS.
( C ) Before rental, a lessee pay base fee. After rental, a lessee pay used fee by adding funds.
( D ) Before rental, a lessee charge balance by depositing enough funds. After rental, a lessor pay back the left deposit to a lessee through redeeming funds process.
Ⅱ. Booking Expansion
Booking expansion can be achievable by executing add funds function.
Adding function assume to be executed by lessee freely. Booking expansion is not required a lessor acceptance so that a lessee can expand booking with violence manner. If this situation happen, don’t worry, we can ask for help to an arbitrator.
Ⅲ. Booking Cannel
Booking cancel can be achievable by executing redeem funds function.
Redeeming function assume to be executed by lessor freely.
Ⅳ. Penalty charge
Penalty charge is like, damage charge or overtime charge etc…
Every kind of penalty charges are handled by adding function. A lessor can request penalty charge against a lessee during dispute window.
5. Conclusion
Finally, show the standard sharing economy state flow.
