/w=3840,quality=90,fit=scale-down)
Use Case 1: Offer Matching System
The Unite Kindness Flow is a matching engine that is mechanically similar to a securities trading engine’s order matching system to match offers to eligible individuals. Unite Kindness views those making an offer as the de-facto sellers and the individuals volunteering to accomplish tasks or participate in events or experiences as the de-facto buyers.
An individual offer, will require at least the following data:
- Address of the task to be performed
- GPS Coordinates (calculated automatically from usage of geolocation tools)
- A timetable for the accomplishment of the task
- A duration for the task
- A description of the task to be performed
- A description and method of how to prove the task has been performed
- A description of the reward
- A description of how to claim the reward (kept secret until task is completed)
An individual’s volunteer of their time, will require at least the following data:
- Address of the individual (preferably domicile)
- GPS Coordinates (calculated automatically from usage of geolocation tools)
- A timetable the individual will be available to accomplish offers.
- A distance tolerance (how far they are willing to travel to accomplish a task)
- Agreement to verify when the task is complete
The offer matching system on the Unite Kindness Flow Network has a preliminary and finalizing step. The preliminary step involves comparing a sale offer’s timetable to a buy offer’s timetable, with consideration given to the time interval needed. If a suitable time interval is found between a sale offer and a buy offer, it is called a preliminary match and is flagged to be evaluated.
Preliminary matches will then be finalized by evaluating the distance between the GPS coordinates of the individual’s address and the address of the task to be performed. This distance will be compared to the buy offer’s distance tolerance. If the evaluated distance is less than the distance tolerance, it is called a finalized match and may be delivered to the volunteer, or buyer in this case.
These steps are done in this specific way because timetabling can be done at high speed and without any external dependencies, allowing the majority of failures to be detected quickly, cheaply, and at arbitrary scale by using a microservice or cloud architecture.
There will be no support for counter-bidding the offerors/sellers, and as such arbitrage and “market making” is not possible in this system. Consequently, we provide a somewhat simplified and highly focused system that resists the usual market-maker movements that would otherwise affect it, providing the most efficient usage of resources to accomplish the largest amount of collective coherence within a marketplace for acts of kindness.
