Contract Overview

Step 1: The borrower creates a new Crowdfund contract via the CrowdfundFactory * We require the factory because we need to keep track of loan params via an index (see below). We also may want to approve who can create loan requests (you need a Bloom ID, or w/e). * In dharma, you only have 32 bytes to store loan params, and 108 of the 256 bits are taken up by collateral information, which I want to preserve as that logic is baked into the Collateralizer contract. * The simple loan example encodes all it’s parameters in the 148 bits remaining. * I didn’t see it as enough space for our complex loans, so I’m storing the parameters as a pointer to an index in a known contract address.

Step 2: Lenders Fund Crowdfund

Step 3: Funding Complete - Now, the borrower sends a message to the rowdfund accepting the money, saying to submit the debt order to dharma. They sign a message as part of that, and the contract submits an order to the DebtKernel and dharma handles the transfer of funds and issues the singular NFT "Debt Token" to the contract.

Step 4: Repayments - Repayments are send to the RepaymentRouter and are forwarded to the contract. This triggers a contract call to the TermsContract for the loan which can update data as needed.

The TermsContract contains all logic for a type of loan. The specific data from the instance is loaded based on the params. In our case, it's loaded from a known 'data contract' which stores all loan data.