Scope

Spec

• Names, addresses, and networks of the contracts deployed on MAINNET
• scenarios list

LoC

Invariants

• (with no lender withdrawals) Total combined assets between Line + Spigot should always remain equal (incorporates inbound revenue flow to Spigot + claimAndTrade/Repay logic is correct)
• Can only _reduce_credit up to the amount of principal + interestRepaid
• queue ordering

Suspsicious Activity

• Borrower’s withdrawing more money then they should
• Any Transfer event with amount more or less than the deposit/withdraw input of the function (non-standard ERC20s, technically allowed not our problem tho)
• multiple failed tx to the same contract (same or diff functions)
• UI/UX issue we want to find and fix or unknown bug in contract
• oracle price failure
• queue ordering not as expected

Spigot

Invariants

• push payment claimed == balance - ownerTokens - operatorTokens

Suspsicious Activity

• recycling spigot revenue to inflate numbers (dont know how exactly to track)
• whitelisting functions on spigot that exist on multiple revenue generating contract
• want to allow bc it means dont have to send 4 tx to whitelist func on 4 diff rev contracts but also it enables a security bug
• anyone else calling claimFunction or transferOwnerFunction on revenue contract that isnt Spigot
• anytime a Revenue Contract is added run a simulation to see if transferOwner will fail. Lets us know if Spigot is misconfigured and needs to be updated to allow Owner to regain control of their rev contract
• same rev contract settings added on multiple Spigots/lines (actual rev contract can only be owned by own but people can spoof our UI by just adding settings to make it seem like they have the actual rev contract)

SpigotedLine

Invariants

• line.unusedTokens = spigot.ownerTokens - position.principal - position.interestAccrued

Suspsicious Activity

• Arbiter calling claimAndTrade on all line assets to rugpull borrower funds.
• anytime claimAndTrade is called bc we dont really need use it rn and want to be extra suspicious of ourselves
• line reserves acting wonky - more activity than there should be,
• claimAndTrade and claimAndRepay trades executing prices at >5% difference from market price
• someone calling updateOwnerSplit right before calling claimRevenue()

• If updateOwnerSplit() would update state and should be called
• If healthcheck() would update state and should be called

Pools

Invariants

1. _unlock_profit, _calc_locked_profit, _max_liquid_assets, _get_share_price, MUST NOT revert
2. _reduce_credit with amount > 0 MUST reduce total_deployed AND/OR increase share price
3. Make sure using appropriate instances of total_assets, total_deployed, liquid_assets, owned_assets, etc. in state updates and price algorithms to ensure other invariants’ math is note false positive
4. _impair and _divest_vault losses on all lines/vaults at same time can never exceed total_assets
5. min_deposit > 1 always + can never deposit 0 shares (even if min_deposit == 0)
6. always emit RevenueGenerated even if 0 revenue generated
7. self.impairments MUST NOT exceed principal on line’s position
8. 0 <= total_deployed <= total_assets + debt_principal
9. total_assets == asset.balanceOf(pool) + total_deployed
10. total_assets == total_deployed + locked_profit + locked_profit

Suspsicious Activity

1. massive fluctuations (> MAX_PITTANCE_FEE) in share price during txs that dont call update_shares() (could be non-standard ERC20 token which we would want to warn people about or could be error in our math or could be an exploit)
1. Functions that can change share price - collect_interest
2. Functions to watch deposit, withdraw, transfer, transferFrom, repay_debt, borrow, set_XXX, sweep, add_credit, increase_credit, set_rates, use_and_repay

ABM

• does referral fee > deposit fee introduce new attack vectors

Website

Suspicious Activity

• Want to create a canary page that you guys can monitor to see if our webapp has been compromised via DNS, Vercel, supply chain attack, etc.