Please describe your proposed solution.
This section covers:
- Problem
- Short solution
- Where we are now
- Where we want to go
- Detailed description
Problem
The person(s) with money (Investors) is often not the same as the executing party (Doer). One party is paying another party to do something. Friction can arise in several ways. If the money is paid upfront, then what happens if the Doer doesn't do what was promised? But if the money is paid retroactively, what if the Investor don't pay up? An escrow doesn't fully resolve the problem either. The manager of the escrow becomes a central point of trust with full discretion of the funds (even if it is a multi-sig).
Short Solution
A smart contract which first pools funding from an arbitrary number of Investors whilst enabling a number of Approvers who select Recipient(s) to carry out a project. The project is divided into milestones. One or several Examiners decide whether milestones were completed. If the proposal was not completed before the expiration date, then funds can be returned to Investors or another wallet.
Video
You can watch a 5 min video explaining the proposal here:
<https://youtu.be/CkmwDaQFBxg>It was recorded for the Fund 10 version of the proposal. The proposal is largely the same with some slight improvements and clarifications.
Where we are now
We have currently completed a prototype thanks to funding from F8. You can view the closeout video for this proposal here. The prototype showcases the simplest situation for what we want to achieve on the preproduction testnet using the emulator:
- Donors can contribute to a scholarship pool (Pooling Smart Contract)
- Two entities must each send an NFT to a student whom they approve for a scholarship.
- The student makes a transaction with those 2 NFTs to the Pooling Smart Contract, which initialises their Milestones Smart Contract.
- When a student passes a milestone, an "Examiner" sends an NFT that the student can use to withdraw a tranche of their scholarship.
Where we would like to take this
We want to make this smart contract more generally useful. In other words, we want to build out an audited open-source repository which enables any web2 and web3 developer to implement an instantiation of this smart contract (with parameterization tailored for the specific use-case).
Description of the general solution
There are four types of Agents and two smart contracts involved.
A person (here understood as a Cardano stake address) can have any number of roles at the same time. We shall define all four Agent types below. We will then describe how they interact.
"Pooling Smart Contract", the smart contract defines the number Agent type (defined below), who they are (stake address) and the parameterisation of the Milestones Smart Contract.
"Milestones Smart Contract", defines the Recipients, number of milestones, token and amount of each token.
"Facilitator", the agent defining the parameters of the milestones smart contract, responsible for deployment, defines which people (Cardano wallets) will be Reviewers and Examiners.
"Investor", the agent(s) providing liquidity to the pooled smart contract(s).
"Approver", the agent(s) with the (joint, if mulitple) power to approve which "Recipient(s)" will receive Funding.
"Recipient", the agent(s) receiving the funds.
"Examiner", the agent(s) with the power to determine if a milestone has been reached. Can be interpreted as a "Human oracle" if it is a physical person, or a smart contract making decisions purely based on an oracle data feed.
How the Agents Interact
Let X, Y, F, A, B, N and M be integer variables strictly greater than 0.
We assume that the Facilitator has already defined all relevant parameters and deployed the smart contract. We will describe the flow for an arbitrary number of each of the other Agents but just one Recipient, the user flow is identical for several Recipients.
- X investors sends funds to the "Pooling Smart Contract" on the Cardano blockchain.
- Y Approvers each send an Approver NFT to "Recipient 1". This means that they approve Recipient for a distribution of Funds (F) divided into M tranches/milestones, each with A amount (hence, F=M*A is Funding amount approved for "Recipient 1"). "Approving" means sending an NFT to the wallet of "Recipient 1".
- "Recipient 1" sends Y Approver NFTs to the "Pooling Smart Contract". This initialises the "Milestones Smart Contract 1", taking F from "Pooling Smart Contract" to "Milestones Smart Contract 1". Each Recipient has a unique "Milestones Smart Contract".
- "Recipient 1" provides evidence of progress towards milestone M. Each of the N Examiners mints and sends a milestones completion NFT for milestone M to "Recipient 1" if they deem that milestone M was met.
- "Recipient 1" sends N milestone NFTs for milestone M to smart contract. The smart contract burns the milestone NFTs and returns "A" amount to "Recipient 1".
- The process is repeated until all milestones have been met or if the Deadline defined in the "Milestones Smart Contract" has been reached and funds are returned to a predefined address.
Extra notes
- Amount A and types of Cardano native tokens can vary for each milestone M.
- Each milestone distribution require a unique set of NFTs.
- The NFT from each Reviewer is necessary but not sufficient to receive milestones funding (Examiner NFT is also necessary).
- The Pooling Smart Contract contains a timer such that if not all funds have been approved for a particular Milestones Smart Contract, then it can be returned to a pre-defined wallet.
The above-described Smart Contract Primitive has a very large number of business use cases, depending on the parameterisation of the above. Any situation which requires accountability and where parties would like to distribute the approvals mechanism and automate the payout mechanism would be suitable.
To illustrate, we will sketch a small number of them below, including the use-case that inspired the development of it.
- DirectEd Development Foundation Access Scholarships. Donors contribute to a scholarship pool for students from a specific school. The School and DirectEd are the "Approvers". Students have to pass milestones in order to receive further mobile data stipends or incentive prizes. A Chief Examiner (DirectEd or external) is the Examiner. This was the first use-case.
- NFT projects. Most NFT project launch products with great promises but little accountability. A smart contract like ours can hold all funds in a general pool, with trusted community members (NFT holders) holding “Approver” and “Examiner” roles, thus ensuring that the project owner's ability to rug is very limited.
- Catalyst funding. Project proposals in Catalyst would be approved by the community, currently represented by IOG who would be the "Approver". Right now, Challenge Team members have served as "Examiners" in a manual process. The decisions on milestones pass examinations would become highly transparent. - Building Construction work. Upon approval of a loan, bank would fund a Pooling contract. A Lender who wants to build a house selects a service provider (Recipient) and defines trusted domain experts (Examiners) and can assess the quality of work of construction workers for each milestone.