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.

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.