Our project seeks to build a system of foundational legos ("Solvers") for composing novel goods, labor and service solutions which can be used by non-developers. It also seeks to develop a crypto-economic incentive model to attract developers to the creation of new Solvers and introduction of additional utility to the system. Developers are rewarded with a small fee from funds which flow through their Solvers, incentivizing development of those with valuable general-purpose functionality or which capture profitable niches. We are also building a staking scheme to curate and signal high-value Solvers and Solutions in a marketplace, allowing third parties to easily select the best tools for their needs.

Solver implementations are instantiated as proxy contracts with custom parameters for instances of a project, which may be to:

• Hire freelancers for work
• Enter mutual funding agreements with other organizations
• Administer grants programs and public goods funding
• Sell labor and services on-chain
• Accountably allocate resources within decentralized organizations
• Run contests and lotteries
• Conditionally incentivize delegates and other entities. . .and much more!

A Solver instance uses the Conditional Token Framework to manage escrow for a discrete part of a Solution, a chain of Solvers deployed with some configuration for an instance of work, and provide unique utility for the administration of that part. A Solver instance manages a canonical CTF condition and splits a position, distributes conditional tokens to recipients including other Solvers, then runs its unique functions and can receive calls and pass data to other Solvers. It takes as parameters a keeper and optional arbitrator address (among others) which are authorized to stage and confirm CTF payout reports. We imagine these addresses will often be Gnosis Safes with their own access controls.

Solvers Illustrative Example

A DAO intrapreneur has identified a need for a new smart contract that would create value. Through our no-code platform, they create and pin to IPFS the execution parameters and descriptive terms of a Solution they believe will be amenable to the DAO. These parameters are made into a proposal with a funding goal. When funded, the Solution is deployed from the hash-checked parameters of the proposal.

The DAO funds the proposal to deploy a three-Solver Solution separately managing the tasks of:

1. Selecting a developer — Solver[0]
2. Approving the work — Solver[1]
3. Passing a security audit — Solver[2]

Solver[0] implements a prediction market, open only to the DAOs members, to select the developer from a list of applicants after some period. It splits a position of CT(A)("Successfully Chose a Developer") and CT(B)("Failed to Choose"). CT(A) is sent to Solver[1], and CT(B) is returned to the DAO for redemption in the event that a developer cannot be found. Its Keeper is a Gnosis Safe with the Zodiac Reality module which reports (A) only if the winning developer's tokens are trading above a certain price.

Solver[1] provides an interface for the developer to submit work for review. It splits CT(AC)("Work Completed") and CT(AD)("Not Completed"). CT(AC) is sent to Solver[2]. CT(AD) is sent back to Solver[0], allowing for reselection of a developer if the first choice fails to complete work by re-splitting a new position to be cascaded down-chain. Its Keeper is a Gnosis Safe with the multisig held by the DAO members reviewing the work.

Solver[2] splits CT(ACE)("Work is Good") and CT(ACF)("Issues to be Addressed") and submits a URI of the approved work from Solver[1] for an audit along with some CTs from both outcome collections as payment. The remaining CT(ACE) is distributed to the developer chosen by Solver[0]. CT(ACF) is sent back to Solver[1] to repeat the process if the audit shows improvements are needed. The Keeper is a Gnosis Safe with the Zodiac Reality module reporting on the audit results.