Greetings to everyone in the NEARverse, my name is Celestine Kariuki, or Celestino for short. I am a developer on NEAR, beginner to intermediate level(still learning). I am really grateful for the awesome community here at NEAR and the opportunities given for anyone and everyone to engage and also grow.
That said, let me quickly rush to the subject matter of this proposal, or rather largely a request from another perspective.
So, some weeks ago, I stumbled upon an idea for a very useful application that could be built on NEAR. This idea quickly turned into a project I started believing that it could really take NEAR to the next level, as well as solve a real-world problem in our communities, and the world at large.
I crystallized this project:
Tenderbox.
Tenderbox is a fully decentralized application that leverages smart contracts to enable small businesses and merchants to issue tenders and source products for their enterprises.
Problem
Issuing tenders and sourcing products especially for small businesses and merchants is a grave problem in my community. The tendering process is always marred by corruption, and big business cartels tend to bully small businesses and merchants. Additionally, in my country, local authorities often demand bribes from these small businesses and merchants just so they could get tendering services. I had this personal experience with my mother when she opened a cosmetics shop. She would be try sourcing beauty products to stock her business but then she would often receive commands from big business cartels to the only source from them in downtown Nairobi, Kenya. Eventually, she had to close her cosmetics shop back in 2017 because it became more costly to run it due to paying the irrelevant bribes and extra costs charged from the rent-seeking big businesses. Now, this scenario is not one of a kind and many across my country.
Just to add salt to this evident problem is the fact that there is a lack of free trade in Africa. With overburdening government regulations, rampant corruption, and huge infrastructure gaps, it is safe to say that these are the reasons Africa remains so much behind economically. According to the African Union, intra-African trade stands at between 10% to 12%, which should be a validating statistic for the problem Tenderbox aims to solve. Also considering the numerous conflicts in the continent, and radical Islamic terrorists wreaking havoc, it is safe to say that when trade stops war starts, and war starts because trade stopped. So indeed there is an urgency for innovations and products that engage the African people into more trade, and also the world at large, otherwise we are doomed to return to wars. Tenderbox wants to address this problem.
Functionalities
Tenderbox is a product that is going to solve all these problems with much more opportunities. But how does it work?
On the Tenderbox platform, we have three users/entities:
- A merchant or small business, who proposes and posts a tender. They create a tender and own it. They have the ability to put up a tender for auction. In order to be recognized as a user on the platform, one registers with a smart contract. The Admin registers them onto a smart contract. To continue being recognized as one(as a user?), a record of posting legit tenders will be monitored. (USER A)
- The administrator has the privilege to register and/or withdraw a small business/merchant and/or a supplier/vendor(USER B)
- Supplier/vendor. He has the ability to bid on a tender. They are actually the targeted bigger audience. (USER C)
Ok, so, here is the process of bidding:
-
USER A creates a tender proposal and posts the tender. He submits some tokens to safeguard as a security deposit(This will prioritize the tender as safe to bid on)
-
Once the tender is up for auction/sale, it will be recorded on the blockchain(NEAR and/or on the NEAR EVM) and an event will be published
-
After the tender gets confirmed in the valid block, they emit events that are listened to by USER C as bid-feed
-
USER C is allowed to bid on any of the tender proposals in the feed provided they have enough NEAR Token balance in their account
-
The tender posted already indicates the unit price of the product and the volume of the product needed for it to get executed.
-
USER C must observe the tender details and then he/she will transfer an amount of tokens needed to safeguard his/her interest in executing the tender. This submission of tokens ensures real interest on the tender is evaluated and that USER C is serious about being considered for executing the tender.
-
USER A, at the moment of creating the tender, also has the option of setting the time limit for USER C to bid his/her interest on the tender. When this time limit expires, the number of USER C participants who submitted their bids, by clicking on the tender(UI) and submitting tokens to stake interest, are the ones who will be considered.
-
Next, USER A has an option of entering into a private chat, a group chat, a call, or even a live stream(like Zoom using WebRTC tech) with the USER C bidders that showed interest in the tender. This is useful since USER A can quickly get to talk and set his/her own terms with each of the bidders(USER Cs)
-
Once USER A has made a decision, he selects the bidder he wants to supply the tender. He picks the winner himself. This signals the end of the bidding session on the specified tender and after that, all tokens of the ones who weren’t selected are released. Then, a tender execution process starts between USER A and the winner he/she selected.
-
We will need to implement a Factory for Tender forms(or simply Tenders). The factory churns out a Tender with a unique registration ID assigned to it
-
The Factory will produce an empty Tender form having a unique registration ID once USER A presses a button on the frontend to create a Tender.
-
We will implement a random number generator that ensures we have unique Tenders created every time. The Tender created by the Factory will then be rendered to the front end where the USER A who fired up the button gets it and has the chance to fill it out.
So, to minimize logistical costs and to live by the intention of this project to uplift local economies, we are looking to implement a feature that allows the tenders of a merchant/small business(USER A) to only be displayed to bidders(USER C) in a specific economic geographical radius. This means that:
- Small businesses and merchants(USER A) will get their tenders delivered as quickly as possible, and at low costs
- This would mean that suppliers/vendors(USER C) will not have high logistical costs to deliver the products required as per the tender.
Also, as an addition to ensure suppliers execute the tenders they bid for, a supply-chain smart contract will be implemented. The supply-chain smart contract will manage all the hassles to ensure it is a solid trust-based system.
When USER A selects the supplier he made a decision upon(USER C), the supply chain smart contract kicks off and the tokens of this winner are all locked in the contract. At this point, these tokens are not accessible to the winning bidder(USER C) nor the small business/merchant(USER A).
Since the tender requires that USER C has to deliver some products to USER A. USER C has to deliver the products at the stated terms in the tender proposal, or as USER A sees desirable.
The dashboard for USER A has a section that has a screen barcode reader(implemented using a barcode reader SDK). Once USER C delivers the products, USER A has the option of cross-checking the credibility of the products(that they are not fake/counterfeit) by scanning them on this section of the dashboard. The scanning data is updated on the blockchain by using Blockchain Oracles code e.g from Chainlink(Blockchain Oracles for Connected Smart Contracts | Chainlink) since it is off-chain data.
This data updates the blockchain and if valid, is used as a parameter to verify the tender was executed. The final say on whether the tender was executed or not rests on USER A. USER A can select whether he feels it was executed or not.
If the winning bidder fails to execute the tender, since the Supply Chain smart contract locked in his tokens, it will then split the tokens and give some to the USER A who offered up the tender, and some back to the admin(USER B).
How will it help the NEAR Ecosystem
Currently, I have personally started working on the contracts, but I really need assistance in terms of fast-tracking the project to reality. I have been evaluating different contract design decisions for the feature of enforcing tenders. I realized that if we can crack this using Tenderbox, we could reinvent the idea of the Zero Aggression Smart Contract. This will put the NEAR Ecosystem at the forefront of inventing how smart contracts would achieve legibility in the real world and enable them to solve real-world problems.
Also, the Tenderbox platform will help the NEAR Ecosystem by onboarding small businesses and merchants, who are non-technical and normal day-to-day people, onto the crypto ecosystem. This will put NEAR as one of the first-ever crypto ecosystems to solve real-world problems and be used by real-world normal people.
What we need
We mostly need extra developers from the NEAR Ecosystem to help us with fast-tracking the project to reality. More specifically, we are looking to pay developers some bounties for specific implementations of smart contracts. As highlighted earlier, we want to implement this new form of smart contract that specifically locks $NEAR from a vendor who is interested in delivering a tender, and then the smart contract will release that $NEAR once the vendor delivers to the small business by receiving off-chain data from a QR Code pasted on a product, and also from a confirmation button pressed on the frontend by the small business. Currently, we have no $NEAR ourselves, and so we are seeking some community funds or NEAR grants to pay developers the bounties to do so, so that we can finish up on the Tenderbox product and get it to the world as soon as possible.
Here is a link to the active Github repository of the project for anyone willing to contribute(specifically Rust smart contracts): GitHub - TendRer/contractsTenderbox
If interested, ping me for the whitepaper, apparently, I cannot share another link here just yet.
I really hope that the NEAR Community may see value in this project
Let us take NEAR to the next level, and save the world at the same time 
Thank you to everyone and anyone who read this.
Sincerely,
Celestine Kariuki