Context
Follow up on blue team discussion specifically on game theory scenarios we want to test
Blue Team Intro
Debt DAO Ecosystem API - Programmatic CRM
Current Pool Game Theory
Misc.
vesting_rate
for investment profits being distributed to share holders. Interesting parameter to play with to ensure reliable TVL, prevent MEV exploits from instant price changes, calculating APR, and idk what else.- forked algo from yearn v2 vaults who also wrote it in vyper. I just renamed some variables but exactly the same (besides the surrounding contract code ofc).
- I’m thinking 2-4 eeks which is ~18-36 days so ~10-20 vesting cycles a year. Yearn does like 6 hours or ~1,500 cycles a year but we have a very different model.
- 7 different types of fees
- Deposit - To owner.
- Withdraw - To owner.
- Performance - To owner. On earned profits.
- Collector - To caller. On earned profits (owner is prevented from getting collector fees)
- Snitch - To caller. On liquidated owner assets
- Referral - To referrer. on deposit
- Flash - To share holders.
- Referral fees are v important for decentralizing frontends and onchain integrations. Want to optimize for that which means deposits.
Security Related
- want to mitigate ability of pool delegate to rugpull, make bad investments, etc
- e.g. could add checks that when they add credit or withdraw that appropriate amount of tokens are taken but currently we dont. This means u are trusting the delegate to also audit the contract they are interacting with, cant only trust the Pool contract, but you are trusting them to do DD on all the deals/vaults/etc anyway. And u still have to trust delegate to not give money to themselves via legitimate contracts so it protects against honest fuckups but not against dishonest actors so i dont totally see the point of implementing
- Want to automate as much of the mundane operations as possible
- as permissionless as possible = as automated as possible
- would love help thinking through more checks needed on all the below functions to make the more secure as permissionless+trustless mechanisms.
- e.g. divest_vault() i dont have checks on the other vault’s share price when someone is snitching to see if they snitch is redeeming so many vault shares that the price slips causing a loss.
- collect_interest() (fees) - only allows collecting excess profits and pays caller for getting it for us
- impair() (fees) - when an arbiter declares a line insolvent, pay to report loss (+ hopefully snitch on delegate)
- unlock_profit() (no fees) - releases vested profits into the pool to actually increase share price
- emergency_repay() (fees) - when a pool defaults on its debt, anyone can liquidate owner fees or pool assets to repay its debt.
- divest_vault() (fees) - only permissionless if snitching a loss in a 4626 vault investment, otherwise only owner can call if reducing position.
- snitching = liquidating owner assets before taking pool funds
- snitch should only be able to operate when it benefits the pool share holders, regardless of effects on pool delegate
- snitch shouldnt be able to profit off snitching besides the snitch fee internally to pool e.g. mint/redeeming while manipulating share price.
- Externally we cant do anything about DEX arb or something
- a ton of fucked up shit with a pool borrowing + lending to/from the same line. Idk if this falls under game theory but the owner could intentionally manipulate share prices by borrowing/lending between the pool’s own accounts
- currently debt doesnt affect share price bc we havent fully implemented borrowing side of pool, focused on lending. But once we connect pool’s debt to it’s share price then things get more complicated
Questions
- thinking about renaming
accrued_fees
toowner_stake
and allowing owner to deposit additional assets from their wallet in there, not just performance fees. Thoughts? - Should we only pay snitches for burning delegate fees or should we also pay snitches from pool assets for things that benefit Debt DAO externally e.g. forcing repayment of pool debt even if its with pool assets?
- i think snitching could be a big boom or bust. What do you think about it so far?
- not sure what the possible exploits are atm, it seems pretty good
- Would love to turn snitching into a MEV auction instead of a hard coded fee %
- not sure how it would work at all but ideally happens offchain
- goals:
- burn as many of owner’s asset (
accrued_fees
) as possible - burn as little of pool’s assets as possible
- pay snitches the smallest % possible of
accrued_fees
for liquidating - constraints:
- should only happen if
accrued_fees > 0
- Must be in pool’s base asset
- has to happen nearly instantly so that pool delegate doesnt frontrun snitchs
- therefor means cant send a tx onchain to kick it off. or auction would have to finish next block and pay extra to be included first in front of owner
EIP4361 Auth for CRM API
will ‘s Qs
Research
- https://eips.ethereum.org/EIPS/eip-4361#security-considerations
- JS lib for role base access control
Recommendations
- add nonce to sessions, randomly generated
- domains is a big issue. lock down API TLS/HTTPS + namecheap DNS
- session invalidation
- close browser, etc → server ends in db
- input validation
- conform to onchain EIP712 domain + structure
- validate actual submitted data isnt tainted too
- PID in a separate database. different identifiers across db
- firewalls, caching, CDN, etc. to prevent DDoS
- logging middleware to see who requested + accessed what data
- data classification
- then tie roles to it
- default is no access unless data class and role
Next Steps
- halborn talk internally, define scenarios, design attack vectos, test cases
- implementation details for implementing login with eth
- JS - secure libraries for nonce generation, encryptying+decrypting messages, ethersjs
- look into EIP-1271 for signing mgs from smart contract for multisig authentication