Modular smart contracts called Solvers are chained in a Solution to manage on-chain conditional transactions.
Solvers receive the configuration of a condition, a Keeper, an Arbiter, and other data as inputs.
A Keeper is responsible for issuing the payout reports of the Solver's condition, as well as other actions which may be required by that Solver.
When a Solver executes it mints conditional tokens for each outcome in a condition and distributes them according to its configuration. The graph below shows a Solver configured to send "A" (success) tokens to a Seller, and "B" (failure) tokens to a Buyer. Which of these tokens is redeemable for ERC20 collateral depends on the payout report issued by the Keeper.
The Solver and its configuration details are specified by a Solution, which has been created by a Keeper and linked to a Proposal. When a Proposal is funded, the Solution and its component Solvers are executed.
Solutions may be composed of multiple Solvers in a chain, each with their own utility.
In this graph, Solver #0 is responsible for finding an appropriate seller for the service being purchased. Solver #1 is responsible for judging if the service is delivered. Solver #0 passes the address of the selected seller down the chain, as well as the conditional tokens representing condition "A" (Seller Found).
Solver #1 passes the next tier of conditional tokens, condition "AC" (Seller Found + Work Approved), to the seller. Tokens for condition "B" and "BD" denoting the failure cases are given to the Buyer.
This solution also selects a vendor and ultimately distributes its success and failure tokens the same, but a third Solver has been added which provides a fraud detection service.
We can imagine this hypothetical fraud detection may call upon off-chain oracles and/or subgraphs for running a proprietary algorithm.
There are also two more new connections:
In the simplest case, the Keeper is responsible for invoking custom functions in a Solver. In this case however, the buyer DAO wants their community to vote on if the purchased work is satisfactory.
This "DAO Voter" may be a contract similar to a Moloch DAO minion (for example). The Keeper itself can be a such a contract.
The Solver contract manages the flow and reporting of conditional tokens. A Solution consists of Solvers arranged in a chain, with each Solver being the child of exactly one parent.