Returns the amount of Revenue Tokens held by Spigot that the Owner can withdraw.

Returns the amount of Revenue Tokens held by Spigot that the Operator can withdraw.

Returns if the function has been whitelisted across Revenue Contracts for the Operator to call in operate()

Returns the config for a Revenue Contract: - uint8 ownerSplit - % of revenue that goes to Owner. 0 decimals - bytes4 claimFunction - function selector on Revenue Contract to claim revenue - bytes4 transferOwnerFunction - function selector on Revenue Contract to relinquish ownership from Spigot

Returns the address of the current Spigot Owner.

Returns the address of the current Spigot Operator.

Returns the amount of Credit Tokens that have been bought with Revenue Tokens from the Spigot and which haven't yet been withdrawn by a Lender or otherwise used by the Borrower to repay. The system ensures that the first Credit Token in the repayment queue is the one being bought. A Line can have multiple Credit Tokens being lent out and borrowed plus multiple Revenue Tokens being escrowed to repay the debt. This variable holds all of these excess tokens

- Retrieves the next id in FIFO Lender repayment queue. - Returns null if no positions currently have debt (no reason to prioritize any Lender so no queue so no “next in queue”) - Returns the next position id in queue and the most up to date financial data on that position as of that block.

- interestAccrued stored in position data inside Line contract may not always be up to date since state only gets updated when a tx is sent. To view the actual must up to data interest owed on a position we add the existing interestAccrued and call the Line’s interest rate contract to calculate the remaining interest owed up until this block.

- Returns tuple of current amount of open positions on Line vs total amount of elements in ids array (closed positions are deleted and become null array elements)

Claims Revenue Tokens earned by one or more Revenue Contracts and updates amount claimable by Owner and Operator. If push payments: When revenue is sent directly to the Spigot without us doing anything. We must calculate how many have been sent to us and disburse. (push payments = claimFunction == bytes4(0)) if pull payments: When we must call the Revenue Contract to claim Revenue Tokens and then disburse the amount of tokens received from Revenue Contract. (pull payments = claimFunction == bytes4('0xrealfunc'))

Checks current status of Line and current owner split of Revenue Contract on Line’s Spigot. Based on status will update owner split if necessary. if Line status is ACTIVE AND owner split isnt the Line’s defaultRevenueSplit then calls Spigot to update owner split to default split. If Line is LIQUIDATABLE AND owner split isnt 100% then calls Spigot to update owner split to 100%. After setting owner split to 100%, we wait until revenue repayments returns Line status back to ACTIVE where updateOwnerSplit can be called again to set owner split back to the default.

- Checks if all Line modules have been initialized properly. Namely checks that Spigot and Escrow contracts marked as collateral are actually owned by the line. - All modules are required to pass back an OK signal. If, and only if, all modules pass the check then the Line sets its status to ACTIVE and lenders and borrowers can start transacting on the contract.

- Accrues interest across all positions currently open on the Line and updates state.

- Borrower can repeatedly call to cause rounding down when calculating interest. According to our math, the gas costs of such an attack is mitigated due to pure gas price costs even for 1 position. This attack vector becomes more expensive the more Lenders so most feasible when only 1 Lender.

- Checks all covenants programmed into Line contract and returns the current health status of the Line. - If borrower has broken covenants then status will be LIQUIDATABLE, otherwise it will usually be ACTIVE.

- Takes funds from callers wallet to repay Borrower’s debt. MUST repay next position in payment queue. - Can be called by anyone not just Borrower.

- ANYONE can repay so you might accidentally repay someone else’s debt

- Total debt owed by Borrower across all positions. Returns a tuple of (totalPrincipal, totalInterest). - Denominated in USD and 8 decimals. - Updates state with new interest accrued.

Deploys a new Spigot with provided config and starts tracking it in the Debt DAO subgraph.

Deploys a new Escrow with provided config and starts tracking it in the Debt DAO subgraph.

Deploys a new Line of Credit using the arbiter, oracle, defaultRevenueSplit, and minCRatio for this LineFactory and the provided borrower and term length. Starts tracking Line in the Debt DAO subgraph.

Deploys a new Line of Credit using the arbiter, oracle for this LineFactory and the provided borrower, term length, defaultRevenueSplit, and minCRatio. Starts tracking Line in the Debt DAO subgraph.

misconfigured defaultRevenueSplit and minCRatio that is too high or low. These are immutable so cant be changed once contract is deployed.

Deploys a new Line of Credit using existing Spigot and Escrow contracts that have already been configured.

misconfigured defaultRevenueSplit and minCRatio that is too high or low. These are immutable so cant be changed once contract is deployed.

Takes debt terms for an existing Line of Credit, copies them and deploys a new Line of Credit for a new (or same) borrower and term length. After this call succeeds, Borrower can call rollover on their Line with their new Line address.

mutualConsent proposal functionality: - Requires mutualConsent of Line’s Borrower and the Lender passed in as addCredit params. - First call to addCredit executes mutualConsent and creates the onchain proposal, second call accepts the onchain proposal and executes addCredit function. - Lender or Borrower can call in either order. Whoever calls first is proposing the terms to the other. - Lender and Borrower can call addCredit multiple times with different params to create multiple proposals - Proposal is not accepted until Borrower AND Lender both send the EXACT same proposal params. addCredit functionality once proposal is accepted: - Position data is initialized in contract state with agreed terms - Lender must approve amount of token before call to accept proposal - Tokens are transferred from Lenders address to Line contract - Facility rate interest starts immediately accruing on full Lender deposit - Borrow must call borrow() to get receive tokens.

- Could approve malicious token that can steal your funds (ass borrower or lender) - Create proposal with wrong terms (e.g. interest rate = 0%) that counterparty immediately accepts to exploit your fat finger mistake. - May add volatile token which could cause borrower to be liquidated while borrowing if price moves against them -

Must have gone through addCredit flow to create position with id already. Allows Line’s Borrower and position’s Lender to agree to increase total amount of Credit Tokens available to Borrow on that position. mutualConsent proposal functionality: - First call to addCredit executes mutualConsent and creates the onchain proposal, second call accepts the onchain proposal and executes increaseCredit function. - Proposal is not accepted until Borrower AND Lender both send the EXACT same proposal params. addCredit functionality once proposal is accepted: - position data is updated in state to increase deposit - Lender must approve amount of token before call to accept proposal - Tokens are transferred from Lenders address to Line contract

Allows Borrower and Lender to agree to change the drawn rate and/or facility rate on an existing position.

Internal util function that allows for arbitrary 2/2 multisigs with dynamic participants on any function in our contract. Requires 2 different addresses to be signers and the exact same msg.data when calling the mutualConsent modified function. This function is the basis for allowing borrower to have agreements with multiple lenders at the same time.

Must have gone through addCredit flow to create position with id already. Allows Line’s Borrower to withdraw funds from specified position. Borrower starts paying drawn rate and/or facility rate based on position balance. Position gets sorted into FIFO repayment queue if not already in queue.

Takes funds from Borrower’s wallet to fully repay all outstanding debt and interest on position and then closes position permanently. MUST repay and close next position in payment queue

Allows Borrower to close any position with no outsanding debt. Takes funds from Borrower’s wallet to repay accrued facility fee and then closes position permanently.

Helper function to allow Borrower to easily transfer settings and collateral from this line to a new line. Useful after ttl has expired and want to renew Line with minimal effort. Transfers Spigot and Escrow ownership to newLine. Arbiter functions on this Line will no longer work. The new, uninitialized Line deployed by borrower

Claims Revenue Tokens from the Spigot as Owner, trades them for Credit Tokens via a DEX and repays debt on next Lender in repayment queue. Stores any bought Credit Tokens in excess of debt obligation + any leftover Revenue Tokens from trade into the Line’s unusedToken to use in useAndRepay for self-service repayments by Borrowers and Lenders or later trades.

Claims Revenue Tokens from the Spigot as Owner, trades them for Credit Tokens via a DEX and immediately stores any bought Credit Tokens + any leftover Revenue Tokens from trade into the Line’s unusedToken to use in useAndRepay for self-service repayments by Borrowers and Lenders or later trades.

Calls addSpigot on Line’s Spigot to add Revenue Contract config. addSpigot call has to come from Line’s address because it is the owner of the Spigot.

Could add a malicious Revenue Contract and/or config that causes funds to be stolen from Spigot.

Sets or updates the whitelisted functions that a Borrower (or whoever is Spigot’s Operator) can call on Revenue Contracts so they continue generating revenue while they are collateralized in the Spigot to repay debt. Only callable by an Arbiter.

Forcefully take collateral from Escrow and repay debt for lender. The current implementation just sends "liquidated" tokens to Arbiter to sell off how the deem fit and then manually repay with DepositAndRepay.

Enables automatic repayment of the loan by diverting revenue from the Borrower’s revenue generating contract/s.

Risk is that you add you revenue contract with incorrect claim transfer ownership selectors making it impossible to claim revenue

If the borrower is incapable of repaying the loan, there needs to be an attempt to make the lender whole

Called before a borrower can deposit a token as collateral

Attach a new Revenue Contract to a Spigot. MUST include revenue split + valid transferOwner and claimRevenue functions SpigotSettings: - uint8 ownerSplit - % of revenue that goes to Owner. 0 decimals - bytes4 claimFunction - function selector on Revenue Contract to claim revenue - bytes4 transferOwnerFunction - function selector on Revenue Contract to relinquish ownership from Spigot

Could add a malicious Revenue Contract and/or config that causes funds to be stolen from Spigot.

Allows the Owner to update Spigot whitelist of functions Operator can call on Revenue Contracts. This allows Operator to perform managerial tasks on its Revenue Contracts so they continue generating revenue while they are collateralized in the Spigot to repay debt.

Could add a malicious function on Revenue Contract that causes funds to be stolen from Spigot.

Owner withdraws their share of Revenue Tokens that have already been claimed via claimRevenue()

Changes the revenue split between the Operator and the Owner based upon programmed conditions or otherwise if the Owner and Operator wish to change the split.

Puts a new Owner in control the Spigot.

- Calls transferOwnerFunction on Revneu Contract settings and transfers ownership to Operator.

- Operator withdraws their share of Revenue Tokens that have already been claimed via claimRevenue()

- Allows an Operator to call the whitelisted functions on its Revenue Contracts attached to the Spigot and carry on its business as usual activities.

- Puts a new Operator address in place to interact with the Revenue Contracts if ever this were needed.

If either a Borrower or Lender to create a proposed position (or update an existing position) and then changes their mind (e.g. params are wrong / unfavorable) they can revoke their proposal. This means the other party cannot complete the other half of mutualConsent() to create/update the position. This works on only one (1) proposal at a time, if you have made multiple proposals with different terms, you must manually revoke each proposal. proposalData param is the original msg.data when registering your consent. Must be reconstructed from original data stored offchain and passed in as the ABI encoded function selector + function arguments from addCredit, increaseCredit, or setRates or any other mutualConsent function. This data is used along with the senders address to regenerate the actual proposal ID hash that is then removed from the mutualConsents[] mapping. msg.data is .

Allows the Borrower or next Lender in repayment queue to use Credit Tokens stored in Line’s unusedTokens to repay debt. Credit Tokens must have already been claimed/traded in claimAndTrade or claimAndRepay and put in unusedTokens for this call to succeed.

Transfers ownership of the entire Spigot from the Line of Credit to either the Borrower (if a Line of Credit has been been fully repaid) or to the Arbiter (if the Line of Credit is liquidatable).

After a loan has been repaid, sends any remaining Revenue Tokens or Credit Tokens from a Spigot to the Borrower. In case of a Borrower default however (loan status = liquidatable), this function serves as a liquidation mechanism that is called in an effort to increase the Lenders' recovery rate and reduce the "loss given default (LGD)”