Depths of Interest

Scope

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/56a57a42-dd35-4976-a39b-1469a7d13f46/Untitled.png

Proposal 8 (@petdetective006)

Detailed

This summary proposal - Please also read the "Detailed" attached above.

The matter at hand -

  1. ETH pool is currently at 6 ETH and 1,276,568.7899061 (see below chart)
  2. The data being used is included in the below table

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/f89b087a-7a04-4277-af4a-3bb49ff2b184/Thorchain_-_ETH_Hack_Data.pdf

  1. The LP activity from Height - 1478894 (pre hack) needs to be considered and adjusted to the fix - otherwise it seems to me we are overfunding the problem and double paying LPs that w/drew between the pre hack height and height 1483166. I do not have this data to analyze yet
  2. The pre-hack pool value for prices at the time of the hack and divide by the LP units outstanding is $16.20 and the pre-hack pool value at current price is - $13.55. I have not yet considered who takes this loss due to price movement from hack height (see [TehColeSlaw] comments in Detail) - if LP take this loss the liability to treasury is reduced.

The road map to Asgard - "Divided we are Wrong - Together we are Strong"

  1. NO should contribute back their windfall gains from this hack - this is an investment back into themselves and the platform. They should be rewarded with the historical bonding APYs and not a big bonus based on the hack fees generated.

    1. a side project (for a later date maybe) should be to look into how the fees on this hack were allocated and audit it - I believe [TheArchitect] said he may have a tool to do this.

  2. All arb trades in ETH in the queue should be refunded so as not to have further negative impact on TC

  3. Other options to consider -

    1. Use current liquid asset position (all assets on the table except RUNE including LP position) to fund the 4,232.9927301 ETH (less the adjustment for LP withdrawals and potential value loss absorbed by LP in [TehColeSlaw] comment below). The amounts of USDC, BTC, BNB or existing LP positions should be relatively proportional to not significantly change the asset mix on the balance sheet (unless that is intended).
    2. Establishing a Line of Credit (if available) to provide liquidity and give flexibility on treasury function - I would consider carefully before using an extended term debt to fill the gap. Using the LOC for a short-term (say 30-60 day) bridge loan to fund the ETH insolvency with an understanding it would be paid off from Treasury at end of month (as described in "a" above) if other capital is not raised at favorable prices is a strong strategy. The LOC would also then be a good tool for future Treasury moves. Leverage can be dangerous for a trading balance sheet in a down or sideways market.
    3. Do NOT currently sell RUNE into this market at current prices! - OTC or in the market. I think that is a bad signal to the market and should only be considered after all other options have been exhausted. (See item h below is a RUNE buy back option - the complete opposite of this - also not a good idea right now). i.e. I would not be buying or selling RUNE from the treasury currently if I had other tools to solve this shortfall.
    4. Consider contributing the Treasury LP position to the pool to lower the outstanding LP units and close the shortfall. This is one of the biggest assets on the balance sheet - not sure of unintended consequences I am not considering to do this.
    5. Open up all potential discussions with VC firms to raise capital. One of the biggest mistakes CEO/CFO's make is to not raise aligned money when it is available - most regret that after the fact. Use the community experts to be involved in this process to build management team in areas VC's would want to see experience.
    6. Include a Chief Financial Officer (type) in the core team - they can coordinate all these matters, watch the balance sheets (that includes TC and all the pools are basically separate balance sheets), treasury function, insurance requirements, VC raise, LOC or Debt raise (i.e. capitalization), community and public relations on financial matters, analyze financial attack vectors, financial modeling, etc. They can also begin to consider, propose and implement plans to decentralize the treasury function safely amongst the community for when the time comes. This person should also create policy and procedures around the CFO/Treasury function so there are guiding principles that can be used and referred to in order to best navigate the growth. Once you have this prioritized it provides a framework and process to make these big decisions.
    7. There is NO need to consider raising the 500,000,000 RUNE cap - that would have a negative effect and is effectively a stock split. This would make this fix harder to solve - stock splits are not economic fixes and do not work!

    Timeline and Key Milestones

    1. Immediate (i.e. ASAP)
      1. Decide what LP value you want to reset the ETH pool at - either $16.32 or even $16.20 (will give withdrawing LPs windfall over others who stayed) or at $12.00 to $12.50 as proposed above. [From TehColeSlaw] The math calculates that $13.24 is the correct price to target for a complete make whole (based on current ETH, RUNE prices). My $12.00-$12.50 proposal was to illustrate that other LP prices can be targeted. There may be adverse PR as a consequence of less than 100% fix.
      2. Decide if you will adjust pool value for reduction in LP units from 1,009,519.87535883 to 990,697.19755601 - these are the effect of the LP w/draw that went out post hack.
      3. Decide how to fund the shortfall (as decided in a & b above) - which assets our of treasury, sale (OTC or Market not preferred), borrowing and or VC (this is generally not a 48 hour process but maybe in Crypto it is now)
      4. If viable - Ask for participation from community (NOs, Arbs and Devs) to support funding the liability [From TehColeSlaw] Consider asking ecosystem projects which plan future airdrops to show particular generosity to the wallets that participate in any community funding efforts
      5. Refund all pending arb trades
      6. Reset the pool
      7. Push update fixes and kick start the network begin to rebuild momentum (minus ETH or ERC20?)

    Pros

    Cons

Addendum : Purging outbound queue (@HoweFai)

[[Additional Notes added by MoDee227 with double brackets ]]

This is not a proposal per se, it could be included in any of them, so it is a bit unorthodox. But I think if the outbound queue is purged we must know the different options and how to proceed. (link for reference: https://thornode.thorchain.info/thorchain/queue/outbound )

It is important to note that some pending transactions do not appear in the json resulting from the link. [can we host the json somewhere in the file?]

First, lets list the different types of transactions that we have pending.

[[There are 2 broad categories of transactions pending:

A. ATTACK DAY TRANSACTIONS NOT PROCESSED. These are transactions that happened on the day of the attack and were held up to stop the attack. After the attacker's address was blocked, these transaction were to have been completed and processed first when trading opened. They were not processed. And these transactions don't seem to be in the current outbound queue. It's not clear where they have all gone. I can provide one example. Full disclosure, this is my transaction, which is why I know about the issue:

https://viewblock.io/thorchain/tx/5DA16A69219663C6376085FA959F600AAC5C6E2EA2E5658BCCC2B35DF2EE4AF7

Transaction

B. CURRENT OUTBOUND QUEUE. This consists of 3 types of transactions:]]