Last updated 2 weeks ago
Pairfy is a highly horizontally scalable e-commerce protocol for the sale and purchase of physical products using ADA that does not require oracles, expensive infrastructure or product trackers.
This is the total amount allocated to Pairfy: A P2P e-commerce protocol based on trust rating and blind mediators. 2 out of 3 milestones are completed.
1/3
Kubernetes app repository with frontend and user services.
Cost: ₳ 11,340
Delivery: Month 3 - Jun 2024
2/3
Requirements for negotiation sessions
Cost: ₳ 11,340
Delivery: Month 6 - Sep 2024
3/3
Demonstration of pairfy operation.
Cost: ₳ 15,120
Delivery: Month 7 - Oct 2024
NB: Monthly reporting was deprecated from January 2024 and replaced fully by the Milestones Program framework. Learn more here
Pairfy is a highly horizontally scalable e-commerce protocol for the sale and purchase of physical products using ADA that does not require oracles, expensive infrastructure or product trackers.
No dependencies.
Pairfy is open source from day one. MIT licence. Any member of the community can contribute and use.
>> SDG SELECTION:
>> PHDI SELECTION:
The following report is applied for the selected Planetary pressures-adjusted Human Development Index:
'''
Central African Republic is ranked 188 (Human Development Index) and when adjusted for the Planetary pressures is ranked 187 a rise of 1.
In 2021 it had a Human Development Index (HDI) value of 0.404 that when adjusted for the Planetary pressures-adjusted HDI (PHDI) had a value of 0.401, a difference of 0.74.
The Planetary Pressures adjustment factor of 0.99 is made up of the SDG9.4 Carbon dioxide emissions per capita (production) 2020 of 0.04 tonnes (indexed value 1.00), and the SDG8.4 and 12.2 Material footprint per capita of 1.57 tonnes (indexed value 0.99).
For more information about the details of the PHDI please reference:
https://hdr.undp.org/planetary-pressures-adjusted-human-development-index#/indicies/PHDI
https://hdr.undp.org/system/files/documents/phdi2020technicalnotespdf.pdf
The specific SDG targets
https://indicators.report/targets/9-4/
https://indicators.report/targets/8-4/
https://indicators.report/targets/12-2/
Source data:
https://hdr.undp.org/sites/default/files/2021-22_HDR/HDR21-22_Statistical_Annex_PHDI_Table.xlsx (table 7)
'''
#proposertoolsdg
In a successful P2P negotiation of a product the seller delivers the product and the buyer pays the price of the product ending the trade naturally. The problem arises when one of the participants does not fulfill their obligations such as when the seller does not deliver the product but argues that he does. Using physical blockchain infrastructure, i.e. hardware connected to oracles it is possible to determine if the product was actually delivered. The problem with this is that many shipping companies do not have blockchain infrastructure so humans inevitably participate throughout the product delivery process.
Connecting the blockchain to the real world is an expensive challenge at least for trading physical products. A lot of infrastructure deployed around the world is necessary to achieve a fully decentralized e-commerce protocol. Clearly this represents a very difficult challenge to achieve in contrast to another option which is to use the human brain as a source of truth. With the right conditions the human brain can make correct logical reasoning about facts or propositions to declare a truth as occurs with the peer review system in the scientific area or the legal area.
The peer review system in the academic world allows a research paper to be reviewed by randomly assigned experts. A blind reviewer does not know who is the author of the paper he is reviewing and the author also does not know who the reviewers are. The system maintains confidentiality to prevent biases ensuring an impartial assessment. The system acts as a quality control mechanism identifying errors and providing arguments based on scientific knowledge to ensure the greatest precision and reliability of the research paper.
A system of blind reviewers trained in conflict resolution can decide on a disputed negotiation session in the event that the buyer or seller defaults on their obligations or another problem arises that does not allow the natural conclusion of the negotiation session.
Pairfy allows the community to buy and sell physical products using their ADA wallet through a plutus P2P exchange system that uses a pool of blind mediators to resolve only dispute cases.
Peer-to-Peer cryptocurrency exchange services such as localbitcoins or binance P2P have proven to be systems that work for secure trades. These systems are based on trust rating and involve real-world action on the part of the buyer such as making a transaction to the bank account provided by the seller.
In Binance P2P, disputes between buyers and sellers can be addressed through an appeal process. Common reasons for initiating an appeal involves problems with payment confirmation, disagreements over payment quality, or disputes regarding trade terms. To protect the cryptocurrency involved in the trade an escrow system locks the funds.
Both the buyer and seller are afforded the opportunity to present evidence or explanations supporting their case during the appeal. A mediation team at Binance reviews the appeal carefully considering the evidence and arguments put forth by both parties. Subsequently, Binance reaches a decision which may involve upholding the original trade agreement, releasing funds from escrow to the appropriate party, or taking other actions based on the specific circumstances of the dispute.
The fundamental idea of Pairfy is to avoid using expensive infrastructure and oracles as a source of truth. Instead, use mediators as a source of truth in a disputed negotiation session.
1. REQUIREMENTS - Negotiation session
The negotiation session is a 4-stage synchronous process Waiting, Locking, Delivery, Finish. The stages of the session are sequential and not parallel.
1.1 Waiting
When a seller offers a product to the public by activating a slot (sale order) a small plutus script with state machine logic is activated in the blockchain. The seller must lock an amount greater than 0 ADA as collateral. If the seller acts in bad faith during the negotiation session the seller will lose the collateral. If the seller is a good agent during the negotiation session the collateral will return to him. Collateral guarantees that the seller behaves honestly. This mechanism of coercion allows to generate trust in potential buyers. It also allows the seller to increase their trust rating. Example. Alice publishes a book with 20 units of stock. She activates only 10 slots (sale orders) each with a collateral of 20 ADA. In the first few hours 7 books were sold and now there are only 3 slots left. Alice decides to activate the 10 remaining slots due to demand. Bob sells the same product with the same stock but offers collateral of 5 ADA. The community prefers to buy the books from Alice since she is more committed to fulfilling her obligation by offering 20 ADA collateral. Other factors increase the seller’s trust rating such as the total number of successful sales, seniority, or profile information. In the background for each activated slot individual scripts are deployed on the blockchain waiting to be occupied by buyers.
1.2 Locking
In Figure 2 you can see the collateral of 50 ADA given by the seller and the price of the product 100 ADA given by the buyer. When the buyer presses the buy button a slot is occupied and the state of the script transitions from Waiting to Locking. Blocking funds allows participants to advance their obligations. The seller’s obligation is to deliver the correct product with the correct specifications. The buyer’s obligation is to receive the product and pay the price. It is important to clarify that the buyer’s obligation to pay the price is guaranteed when he occupies a slot since the amount in ADA of the product price is a necessary condition to occupy a slot.
From this point the seller can start with questions such as: What is the delivery point? Description of delivery point? Any questions necessary to guarantee the effective delivery of the product. All information provided by both actors in the user interface is contained within a websocket instance and can only be observed by the blind peers in case of a dispute. The websocket server does not store any type of information about the negotiation session once legal certainty is declared about the business between the parties. Legal certainty is declared by the blind peers and refers to the absence of reasonable doubt regarding compliance with the obligations that correspond to the buyer and the seller.
1.3 Delivery
When the shipping company confirms the effective delivery of the product the seller can invoke the @delivered endpoint. The script transitions from Locking to the Delivery state which indicates that the seller has fulfilled its delivery obligation. Finally, the buyer confirms whether he received the product by invoking the @received endpoint. By doing so, the script transitions to the last state Finish which releases the funds to the seller’s wallet.
1.4 Finish
The seller receives 50 ADA of collateral and 100 ADA equivalent to the price of the product he sold to the buyer.
2. REQUIREMENTS - State machine
A state machine also known as a finite state machine (FSM), is a mathematical model used to describe the behavior of a system or process that can exist in a limited number of distinct states. The system transitions from one state to another in response to specific events or input conditions and these transitions are defined by a set of rules or conditions known as transitions.
A deterministic finite state machine (DFSM) is a specific type of state machine that exhibits deterministic behavior, meaning that for any given state and input there is a unique and unambiguous next state. In a deterministic state machine the transition from one state to another is uniquely determined by the current state and the input with no ambiguity or randomness involved.
Figure 5 shows the deterministic state machine concepts applied to the steps of a negotiation session. The EUTXO model of the Cardano blockchain implies that smart contracts need an initial transaction for their logic to be activated and establish their initial state. When the seller activates a slot his wallet deploys a plutus script that receives the collateral in ADA and necessary parameters for the session.
The data type sessionState represents the initial state of the plutus script once deployed by the seller. These variables will remain in the default state indefinitely until the buyer’s wallet interacts with the script taking the slot.
bSlot represents the variable that indicates whether the script has been occupied by a buyer. The boolean value True means that the slot has been occupied by a buyer which makes the script transition from Waiting to Locking.
pDelivered is a variable of type boolean that represents the delivery of the product or not. At this point the seller has invoked the @delivered endpoint stating that he has fulfilled his obligation to deliver the product. This action makes the script transition from Locking to Delivery.
pReceived is a boolean variable that represents whether the buyer confirms receipt of the product or not. This variable is modified only by the buyer using the @received endpoint. By doing this, the script transitions to its final state Finish which releases the funds to the seller.
3. REQUIREMENTS - Blind peers
Connecting the blockchain to the real world is an expensive challenge at least for trading physical products. Shipping companies would have to connect their vehicles to supervised oracles and the products must have an infallible tracker to check if were delivered. A lot of infrastructure deployed around the world is necessary to achieve a fully decentralized e-commerce protocol. Clearly this represents a very difficult challenge to achieve in contrast to another option which is to use the human brain as a source of truth. With the right conditions the human brain can make logical reasoning about facts or propositions to declare a truth. For example, the peer review system in the academic world allows a research paper to be reviewed by randomly assigned experts. A blind reviewer does not know who is the author of the paper he is reviewing and the author also does not know who the reviewers are. The system maintains confidentiality to prevent biases, ensuring a rigorous and impartial assessment. Serving as a crucial quality control mechanism, it identifies errors, provides constructive feedback to authors and contributes to the overall accuracy and reliability of published work. A system of blind peers trained in conflict resolution can decide on a dispute in a negotiation session in the event that the buyer or seller fails to comply with their obligations or another problem arises that does not allow the natural conclusion of the session. A blind peer system can decide on a disputed trading session. Some characteristics of the profile of a mediator are:
1. Mediators must stay neutral and impartial to ensure a fair and unbiased assessment of disputes fostering trust in the mediation process for all parties involved.
2. Effective communication is vital for mediators, involving active listening, skillful facilitation of discussions and clear conveyance of information to aid parties in mutual understanding and resolution.
3. A mediator needs strong problem-solving skills to navigate complex disputes and find mutually acceptable solutions.
4. Mediators require patience as mediation processes take time, allowing parties to express themselves, explore solutions and reach agreements at their own pace.
5. Mediators must uphold ethical standards ensuring the confidentiality of the mediation process to establish and maintain the crucial element of trust for successful resolution.
6. Mediators require a comprehensive skill set encompassing technical, legal, and cultural knowledge to effectively carry out their duties.
3.1 Appeal
Peer-to-Peer cryptocurrency exchange services such as localbitcoins or binance P2P have proven to be systems that work for secure trades. These systems are based on trust rating and involve real-world action on the part of the buyer such as making a transaction to the bank account provided by the seller. In Binance P2P, disputes between buyers and sellers can be addressed through an appeal process. Common reasons for initiating an appeal involves problems with payment confirmation, disagreements over payment quality, or disputes regarding trade terms. To protect the cryptocurrency involved in the trade an escrow system locks the funds. Both the buyer and seller are afforded the opportunity to present evidence or explanations supporting their case during the appeal.
A mediation team at Binance reviews the appeal carefully considering the evidence and arguments put forth by both parties. Subsequently, Binance reaches a decision which may involve upholding the original trade agreement, releasing funds from escrow to the appropriate party, or taking other actions based on the specific circumstances of the dispute.
In the case of Pairfy the seller is the party that has control over the terms of the negotiation. The UI view of a published product contains the product description, seller name, seniority, trust rating, number of successful sales, number of total sales, and the terms that any buyer must meet to be able to negotiate with the seller. These terms must be clear, enumerated and determined. Any buyer who accepts the seller’s terms must comply with them.
It is not convenient for the seller to use the @delivered endpoint if he has not fulfilled his obligation since he has to prove it to a level of certainty at the risk of losing his collateral. The seller also cannot use the endpoint by mistake since the user interface would have mechanisms to prevent this.
It is also not convenient for the buyer to use the @received endpoint without having received the product since he would lose the funds corresponding to the price. He also cannot do it by mistake since the UI does not allow it. If the buyer does not comply with his obligation to receive the product, the seller can initiate the appeal. If the intention of abuse is proven, then the buyer loses the equivalent of the collateral proposed by the seller. Both parties can resort to appeal in case of dispute, a group of blind mediators can take action on a case-by-case basis.
3.2 Pool
According to the principle of least cardinality in data modeling which states that one-to-many relationships such as between the author and the N of published posts, the identifier that relates them should be stored on the “many” side. In other words, when data modeling is designed posts should store the author identifier, authors should not store identifiers about their posts. As long as the author has a small number of published posts there are no problems with storing and consulting the information. The problem arises when the author has a large number of published posts, the storage of post identifiers in one of the author variables represents a scaling problem and the query time can be affected. The application of this principle in the protocol architecture allows high horizontal scalability. Pairfy uses a masterslave pattern in which the master is the main contract of the protocol which manages the pool of mediators. Slaves are the individual scripts that are in charge of the trading sessions. For each activated slot of a product a script is deployed waiting to be occupied by a buyer.
Figure 6 shows a grouping of consecutive contracts representing horizontal scaling to ensure high concurrency and availability of the Pairfy service. When a seller enables a product slot a slave script with state machine logic is deployed in the blockchain waiting for a buyer to occupy it to start a negotiation session. Each slave script has by default the PubKeyHash of the master contract in its datum. A slave cannot interact with another contract other than its master.
Master contracts do not have any information about their slaves, their function is to provide mediation service in case of a dispute during a negotiation session by enabling an endpoint called @appeal. The endpoint is designed to be used by slave scripts and requires an ADA fee to prevent abuse.
The mediator pool is basically a set of PubKeyHash each corresponding to the wallet of a certified and active mediator. When @appeal is triggered by a slave the master contract mint an NFT and within the NFTdatum the contract adds three (3) PubKeyHash contained in the pool of mediators. Subsequently the contract removes those three PubKeyHash from the pool queue.
The slave receives the NFT and adds to its own datum the three PubKeyHash that are within the NFTdatum. After this process the slave has exact information about the mediators authorized to decide on the current dispute. Mediators are the only ones who can activate special @endpoints of the slave to decide the dispute.
3.3. Designation
The community using governance can change the policies and parameters of the protocol. The community can also decide who meets the characteristics to be a mediator or not. Mediators can have two states: active and inactive. Only active mediators can enter the pool.
3.4 Rewards
To avoid bias and inactivity mediators are rewarded every 30 days with utility token. The amount will be decided by community governance. Only active days in the pool can be rewarded.
4. REQUIREMENTS - User interface
4.1 Product
Any member of the community can publish a product only if they meet the following conditions: 1. Cannot be published any object, substance, biological, physical matter in any of its states and forms, declared illegal or prohibited by any type of international, state, federal, local or other regulations on the subject.
2. Comply with international, state, federal, local or other regulations on money laundering and drug trafficking.
3. Only physical products can be published, publication of services is not allowed.
4. Know and understand the licenses associated with the product.
5. Write in a specific and enumerated way the terms and conditions that the buyer must comply with.
6. Product must meet safety standards, must not pose a threat to the health or safety of the consumer.
7. Buyer have the right to be informed about the terms and conditions of a transaction, warranties, and return policies.
8. Comply with all international, state, federal, local and any regulations that regulate intellectual property rights.
9. Description of the product in a determined, fair, exact and precise manner.
10. Send the product with a recognized shipping company that allows tracking service. In the user interface the product view must have the name of the product, the description of the product, the terms of the seller, the number of total sales of the seller, the number of successful sales of the seller, information about the seller, the stock number of the product, the number of activated slots, amount of ADA as collateral and trust rating. In the backend of the protocol there must be an automated service in charge of verifying the products before they are visible to the community.
4.2 Session
When a buyer presses the buy button on a product publication the website redirects them to a single page. The view of a negotiation session contains all the information corresponding to the product, about the seller, the terms of sale, the appeal button, buttons to upload attached images as evidence, alert indications and for the user experience. It also contains live chat to establish bilateral communication between the parties and the mediators.
4.3 Mediators
Mediators assigned to a disputed negotiation session will have a special section in the live chat to communicate with the buyer and the seller at the same time. The mediators have no knowledge about the seller and the buyer because they are shown as anonymous digital entities. Mediators cannot be identified by their wallet addresses because they are dynamic addresses changed by the backend.
Pairfy is a proof of concept and anyone can contribute to the repository. I will involve people who contribute to the repository frequently. To any member of the Cardano community who is interested in e-commerce and wants to contribute to the state of the art.
In what way will the success of your project bring value to the Cardano Community?
Using the keywords (market, e-commerce, amazon, ebay, aliexpress, P2P) in some Cardano explorers, there is no Dapp or proposal that offers a solution to market physical products in the form of a marketplace.
Cardano Cube: https://www.cardanocube.io/explore
How will you measure this impact?
How will you share the outputs and opportunities that result from your project?
During 2021-2023 I worked as a backend, frontend developer and visual content creator for a Cardano project called SCATDAO🔍.
4,301 contributions in 2023 (Monday to Sunday)
2,444 contributions in 2022 (Monday to Sunday)
64 contributions in 2021
Open source contributions in Cardano:
DYORTOOL ( backend and frontend except the questionnaire )
The purpose of dyortool is to have a repository of fundamental research reports on Cardano projects, reports with quality and verifiable information are rewarded with AUDIT token.
AuditOcean ( backend, frontend except the questionnaires )
The purpose of auditocean is to have a repository of research reports on Cardano projects carried out by expert people called auditors. Similar to dyortool but the quality of the reports increases.
Github account:
Risk and mitigations:
The proposal has 2 milestones. The first milestone is divided into six 1-month steps. Each step represents a complete element and not in parts. This allows the payment of the monthly salary to be justified as work done paid work.
In case of physical inability to continue with the project, the progress is completely open source and can be forked and stop sending funds. In CONTRIBUTION.md there will be instructions and schedule to follow in case of physical inability to continue with the project.
I have accumulated experience making open source tools that have real use for the Cardano community. I like my job and I can dedicate a large part of my life to creating great things. The requested budget is divided into several 9 objectives (12 months) which will be met and delivered in their entirety.
Initial requirements, Outputs and Acceptance criteria (6 months)
A. Kubernetes cluster and manifests. ( 1 Month )
-Output: Files, folders and manifests for the operation of kubernetes cluster services and configurations for development and production environment.
-Acceptance criteria: Creation of the repository with the manifests, scripts and instructions necessary to deploy a kubernetes cluster with ingress and load balancer.
B. Main view of published products. ( 1 Month )
-Output: Code corresponding to the home page on which all products by category are displayed.
-Acceptance criteria: It must display the products in the form of a grid, be responsive for all devices, have a banner and header with the necessary functional and user experience requirements.
C. Page view dedicated to the product. ( 1 Month )
-Output: Landing page code with customization attributes for each product.
-Acceptance criteria: The product page must show the name, description, seller, information about the seller, sales number, stock number, number of slots, photo gallery.
D. Page view for negotiation sessions. ( 1 Month )
-Output: Code of the page that the buyer and the seller use to communicate and generate the negotiation context.
-Acceptance criteria: The page must have session ID, script address, chat box for seller and buyer, bottom chat box for mediators, button to upload evidence, button to use appeal.
E. Page view to add the product. ( 1 Month )
-Output: Page code which has the purpose of allowing the community member user to publish a product.
-Acceptance criteria: The page must have the option to upload an image of the product, name, description, stock, price in ADA.
F. Country identifier service. ( 1 Month )
-Output: Service/pod code, which has the functionality of locating page visitors as a geolocation service to show only publications from their country.
-Acceptance criteria: The service must process the visitor's publicly accessible IP and identify only the COUNTRY where the visitor is located. In order to show available products only available in the country, changing country in the user interface will be optional.
Contributions will be daily and the final product of this milestone will be found in the pairfy repository: https://github.com/pairfy/marketplace
Initial requirements, Outputs and Acceptance criteria (6 months)
A. Live chat websockets service. (2 Month )
-Output: The code necessary for bilateral communication between the buyer and the seller. This is a websocket server service.
-Acceptance criteria: The service must be able to create websocket instances for each open trading session, allowing bilateral communication between the buyer and seller. Also the option to add more participants as mediators.
B. User account service. (2 Month )
-Output: The code that defines the account system service for registered users.
-Acceptance criteria: The CRUD service must be able to create users, log in users and modify their attributes.
C. Mediator account service. (2 Month )
-Output: The code that defines the account system of the protocol mediators.
-Acceptance criteria: The CRUD service must be able to create users, login mediators and modify their attributes.
Contributions will be daily and the final product of this milestone will be found in the pairfy repository: https://github.com/pairfy/marketplace
After 12 months along with the delivery of the finished project, there will be a video explaining the project operation, general thoughts, recommendations and invitations.
Juan C. Rey - Architect and Software Developer - Plutus Pioneer First Cohort.
https://www.linkedin.com/in/juanrey1/
Programming language skills:
Skill with tools and others:
The costs represent the programmer's development time and costs of vital and technical services. Currently I can supply approx 420 development hours per month (Monday to Sunday) as I have demonstrated on my github account.
My daily work routine is:
8:00 AM to 12:00AM (4 hours)
3:00PM to 1:00AM (10 hours)
420 hours a month x $2.9 dollars per hour x 12 months = ~14.500 USD
Milestone 1 ---------------------- 19800 ADA
Milestone 2 ---------------------- 18000 ADA
The costs represent the programmer's development time and costs of vital and technical services. Currently I can supply approx 420 development hours per month (Monday to Sunday) as I have demonstrated on my Github account.
My daily work routine is:
8:00 AM to 12:00AM (4 hours)
3:00PM to 1:00AM (10 hours)
420 hours a month x $2.9 dollars per hour x 12 months = ~14.500 USD
---
During 2021-2023 I worked as a backend, frontend developer and visual content creator for a Cardano project called SCATDAO🔍.
4,301 contributions in 2023 (Monday to Sunday)
2,444 contributions in 2022 (Monday to Sunday)
64 contributions in 2021
Open source contributions:
DYORTOOL ( backend and frontend except the questionnaire)
AuditOcean ( backend, frontend except the questionnaires )
REPOS: