Skip to content

Instantly share code, notes, and snippets.

@pyggie
pyggie / uma-liquidation-liquidity.md
Created December 10, 2020 04:20
UMA liquidation liquidity during a market panic

The uUSDrBTC synth has about $7.3M minted (seen here: https://tools.umaproject.org/?address=0xaBBee9fC7a882499162323EEB7BF6614193312e3), of which $7.2M is in the uUSDrBTC-USDC pool at Balancer (here: https://pools.balancer.exchange/#/pool/0x2dd7255b487a62d738110bd10f8bc4b4ea989778/). At first this seemed strange to me, but it makes sense that the asset will find its way to the highest yielding opportunity.

The synth is backed at a global collateral ratio > 2.5, which is very conservative. Still, during market panics we've seen the price of BTC quickly drop 50% or more, which would be enough to trigger liquidations on a substantial fraction of sponsors. During a liquidation, the liquidator repays the sponsor's uUSD synth debt and receives the renBTC collateral in return a few hours later. Where does the liquidator get the uUSD? There are only two places: from the Balancer pool or by minting it fresh. From the liquidator's perspective, minting it is both capital inefficient and risky (it's a panic!), so buying

@pyggie
pyggie / geth.2.log
Last active July 9, 2020 16:41
geth log showing failure to shut down gracefully (https://github.com/ethereum/go-ethereum/issues/21273)
panic: boom
goroutine 139 [running]:
github.com/ethereum/go-ethereum/internal/debug.LoudPanic(...)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/internal/debug/loudpanic.go:26
github.com/ethereum/go-ethereum/cmd/utils.StartNode.func1(0xc0000e2280)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/cmd/utils/cmd.go:84 +0x284
created by github.com/ethereum/go-ethereum/cmd/utils.StartNode
/home/travis/gopath/src/github.com/ethereum/go-ethereum/cmd/utils/cmd.go:70 +0xad
@pyggie
pyggie / buidler.config.ts
Last active May 24, 2020 18:08
Buidler / Use native solc compiler, instead of default solcjs
const { TASK_COMPILE_RUN_COMPILER } = require('@nomiclabs/buidler/builtin-tasks/task-names')
internalTask(TASK_COMPILE_RUN_COMPILER)
.setAction(async (taskArgs, bre, runSuper) => {
const { input } = taskArgs
const { execSync } = require('child_process')
const fetch = require('node-fetch')
const version = config.solc && config.solc.version || '0.5.16'
const solcPath = `cache/compilers/solc-v${version}`
if (!fs.existsSync(solcPath)) {
@pyggie
pyggie / gist.md
Created October 19, 2019 09:30
Critique of Compound v2's liquidation system

Currently, Compound (v2) handles liquidations by enabling anybody to liquidate an at-risk account by repaying some of the account's debt and receiving collateral in return worth 105% of the amount repaid. The fixed 5% "liquidation incentive" has a few weaknesses. Most of these arise from the liquidator's need to rebalance their portfolio by converting the seized asset gained back into the repaid asset lost. If the liquidator does not rebalance, they are now exposed to market movements in both assets and possibly run out of inventory to perform additional liquidations. Some weaknesses with this system:

(1) The incentive does not vary by asset. For very liquid collateral types (say ETH or DAI), the liquidator can easily convert the seized collateral back to the asset used to repay the borrower's debt, losing little to slippage. In this case, 5% may be too generous. For illiquid collateral types (say REP or WBTC), the liquidator may struggle to unload the collateral. In this case, 5% may be too little.

(2) The